3

Just looking for feedback on anyone who is currently using InRelease for deployment scenarios in an enterprise application?

InRelease has been recently acquired by microsoft and have a trial up there at the moment http://www.microsoft.com/visualstudio/inrelease/ This will be integrated in future version of TFS as far as I know.

I have been trialling it for a while now and would be interested in hearing from any existing customers with any feedback, either positive or negative including info on: Pros/Cons of using this v's webdeploy / powershell etc. Stability of the product. etc..

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
thebogman
  • 59
  • 1
  • 4
  • I haven't the reputation yet to add a new tag so if someone could add one for InRelease that would be great! – thebogman Nov 08 '13 at 11:05

2 Answers2

9

I've been talking about MS Release Management (aka InRelease) a lot for the past few months. It's great, and it's available for download as of 11/13/2013.

It has some huge advantages over more traditional methods of deployment:

  • Tons of built-in tools for deploying software. It comes with a bunch of stuff out-of-the-box so you don't have to mess around with writing PowerShell scripts to set up IIS or start up an Azure VM. The tool system is fully extensible, so you can plug in any batch file, PowerShell script, or executable that you want. It also automatically captures the output of anything it runs and attaches it to the deployment log.
  • Rollback functionality. You can define what actions it should take if a deployment fails, so you can make sure a bad deployment never takes down a critical service.
  • Config file management. You can parameterize your config files and then use Release Management to specify what values should be used. This helps reduce (or even eliminate) the nightmare of managing multiple web/app.configs.
  • The ability to define approval workflows. This is huge if you want to be able to have specific people responsible for approving/rejecting releases based on whether it passed QA, etc.
  • Release path definition. This ties into the approval workflows -- you can set it up so that you have environments for each "stage" of your release process -- DEV, QA, PROD, etc. Then you can set up what servers are members of those stages, what order your software should take through those stages, and who's responsible for approving/validating each stage.
  • Full traceability into the release process -- you can see what builds of your software are currently on a server, when it got there, who approved/rejected it, full logs of all of the deployment actions that were taken. It can really give you some great insight into where your process needs improvement. Let's say you have the QA team failing tons of releases because of bugs. You can see that, and go back to your developers and say "We need to put better automated testing in place; we're swamping the QA team with work when we could be catching these defects earlier!"
  • Integration with TFS, so you can easily set up continuous deployment.
  • Microsoft Test Manager integration. You can set it up to run automated tests (e.g. coded UI) out of an MTM test plan after your release is complete, so you can automatically fail the release if any of your tests fail.

And it's only going to get better in the future. The Release Management team has some really cool stuff on their backlog!

peterh
  • 11,875
  • 18
  • 85
  • 108
Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
1

The first advantage is that you have a strong coupling with the TFS platform, you don't have a special development bridges to integrate, so that side me I'm like, but with professional process of management release The second point is that worklfow spots has execute, which facilitates reading process for Deployment. (Three months on project R&D)

Aghilas Yakoub
  • 28,516
  • 5
  • 46
  • 51
  • Hey Aghilas, Just in relation to your project where you are using MS Release Management /inrelease, how do you manage database deployments, schema changes etc? Curious as to the best way to set this up for automation. Our dbas currently have ownership of any scripts that get run against production. – thebogman Nov 21 '13 at 16:41
  • @thebogman My recommendation is to use SSDT, which handles a lot of the heavy lifting for you. SSDT is pretty great even outside the context of RM. RM can publish SSDT dacpacs out of the box. Past that, it can also execute SQL scripts. If DBAs have the production databases on tight lockdown, it could be a tough sell. You could put a "manual intervention" step in your release template for just the production stage that notifies the DBAs to run the SQL scripts manually. It's not ideal, but it could act as a stopgap. – Daniel Mann Nov 23 '13 at 09:05
  • EF Code First Migrations also give a great story for deployment of databases, including complex migrations, version rollbacks, etc. – RMD Mar 18 '14 at 18:04