CODEWITHSUNDEEP
visual-studiotfswebdeployms-release-management
thebogman
thebogman

Reputation: 59

Anyone successfully implemented MS InRelease for automated deployments?

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..

Upvotes: 3

Views: 2059

Answers (2)

Daniel Mann
Daniel Mann

Reputation: 58980

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!

Upvotes: 9

Aghilas Yakoub
Aghilas Yakoub

Reputation: 28970

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)

Upvotes: 1

Related Questions