Better support to Continuous Deployment Practices
The Microsoft ALM platform has adopted a lot of Agile practices. The new Dev11 Agile Planning Tool is the dream of any agile team. So, we have fantastic tools for planning, designing, developing, testing, building, but what about deployment?
A software can be done without “formal requirement”, without design, test, etc. But we have to deploy it in order to use. So, I think we could make the life of build master easier and add a kind of deployment process in team build.
I know we can customize the build process template, we can use BRD Lite from Rangers, but we need something easy to install, easy to setup and easy to use. We need something to cover the following stories:
- As a Build Master, when I change the build quality to “Staging” I want to deploy my solution using a set of parameters (IIS URL, Connection String, …) named “Staging” so that I can deploy the same build in several environments.
- As a Build Master, I want to specify a default environment so that after the build, my solution be deployed in the default environment;
- As a Build Master, I want to specify a test list (normally with integration tests created with coded ui) so that I can run integration tests in the environment that I just deployed;
- As a Build Master, I want to rollback a deployment so that I can abort a deployment with any error;
We have a lot of other scenarios to cover the characteristics of Continuous Deployment. But covering these will help us a lot :-)
Under review by ALM Rangers.
Perfect idea! As a build or release manager it should be as easy as possible to deploy a build to different environments! Additionally it would be fine when someone could be informed about the state of development, like successfully finished or failed and rolled back to last successfully build
Michael Paterson commented
My #1 request for TFS. What a horrible pain it is to try to implement continuous deployment in TFS - the standard answer from the rangers is to "deploy lab management". There's a number of major problems with the platform right now:
* No build numbering - TFS build workflows require significant customization to "stamp" binaries with the build version.
* C# web projects don't automatically build using WPP, and the process needs to be customized using MSBuild targets files that have non-existent documentation.
* No ability to easily place build output in solution or project subfolders. Everything gets dumped into one directory mess.
* Deployment tightly integrated into the "Test" workflow in TFS/Visual Studio. That's not our use case - what we really need is continuous deployment of our databases and servers so that the different divisions of the company and target the latest code as it is built. Ie/ we have development, qa, and staging environments. These environments are used for integration, not running automated UI tests (as assumed by the current lab management tools in VS).
Fokko Veegens commented
No votes left, but I really like this idea! +3
Martin Rajotte commented
There are solutions tightly integrated with TFS that does this. Bing "agile release management tfs"...
Philip Coupar commented
First class support for Azure would also be of great benefit.
Things to add to this list are:
The ability to specify an azure host to deploy to (or different hosts depending on build quality)
The ability to run tests against the staging slot and only allow VIP switch after all tests have passed. (hooks for rollback changes would also be useful, especially for deployments that include database changes)
The ability to deploy, test & teardown in an automated sequence
Antonacci Enrico commented
Excellent idea....I need this!