Deployment Tools that Integrate with TFS?

Question

So I have this issue. The Operations team where I work has taken over TFS because they are using MS Build to build and deploy code to production servers. As a result developers have lost A LOT of functionality from TFS (see earlier question.)

Essentially the operations team has taken owner ship of Trunk in order to manage their deployments. The development cycle thus goes something like this:

1. Request Operations Team to create a Branch from Main for development work.
2. Perform Development work on development branch.
3. Merge from Trunk to development branch prior to release (basically make sure that the development branch has all of the latest changes)
4. Request Operations Team merge to Trunk from development branch (Developers do not have permissions to do this) -> this request will cause Operations to not only to merge to Trunk but also to deploy to the development environment.
5. Perform integration Testing, fix defects found in development branch.
6. Repeat steps 3 - 6 as necessary.
7. Request Operations Team merge from Trunk to a QA branch (there is only ONE on-going QA branch per project) -> this request will cause a deployment into the QA environment (An MS Build template is used to compile the code from QA branch and then deploy to QA servers)
8. QA tests, fix defects found in development branch.
9. Repeat steps 3 - 8 as necessary.
10. Request Operations Team merge from QA branch into PROD branch (there is only ONE on-going PROD branch per project) -> this request will caus a deployment into the PROD environment (Again an MS Build template is used to re-compile the code from PROD branch and then deploy to PROD servers)

As a result of the Ops team using an MS Build template to deploy to Production servers, the Development team has now lost the "Builders" role. We cannot create our own MS Build templates, we cannot create or edit a Build definition, and we cannot queue a build -- Even in the Development Environment -- because the Build process runs under a service account which has access to Production servers (since it is use to deploy to production servers).

Besides the removal of TFS permissions, I have some issues with this process:

1. The assemblies which were compiled and tested in the QA environment are not the assemblies being deployed into the Production environment. Because the MS Build process is being used to deploy to production, code is recompiled and deployed from the Production branch. In theory, the resulting assemblies should be the same, however this is depenent upon a) the operations team (who are not developers) properly merging the code from the QA branch to the PROD branch (human error potential) b) the build environment not changing in such a way as to affect the way assemblies are compiled (since this is primarily .Net improbable but not impossible)
2. Since there is only ONE QA branch, if I have a production issue which needs a "hot fix" after other work has been merged to QA, I have to wait for Ops to rollback changes to the QA branch, merge my changes in and perform the build and then HOPE that operations correctly performed the rollback and merge operations on the QA branch in order to get my "hot fix" into the QA environment.
3. Many of my projects have multiple outputs (e.g. a web-application and a windows service). Often I may want to only deploy one or the other. But if I upgrade one to a new version, I no longer have a PROD branch which represents the one I didn't upgrade.
4. Operations team has already demonstrated that merge operations are not being performed correctly: Following a recent merge from Development to Trunk I performed a compare on the two branches and they were different.
5. Because code is recompiled for each environment we cannot use automated versioning, or make use of the "build quality" features of TFS.

Essentially what it comes down to is the Operations Team has attached themselves to using MS Build for deployments and as such have adopted a rediculous Source Control branching and merging strategy to support using MS Build for managing deployments. (I see no benefit in having a QA and PROD branch other than to support MS Build based deployments).

What I am trying to do is convince the powers that be and the operations team that what we're doing is a bad practice, and also give them an alternative deployment strategy. What I need for this is a Deployment tool that integrates with TFS (e.g. it will show a list of Builds that have a specified "build quality" level (depending upon the environment being deployed into) as a "deployment source" and allow then to maintain a list of "deployment targets" so that at deployment time, they simply pick the build (source) and the target and click the "GO!" button.

A proper deployment tool will hopefully eliminate their dependence upon MS Build, allow them to remove access to QA and Production servers from the MS Build process, follow a more sane approach to branching and merging (e.g adopt a "branch per release" best practices strategy) and restore to the developers the TFS permissions which were revoked to support this rediculous process.

Answer 1

We're using Visual Build Pro. It allows you to do what you're talking about (if I'm following what you're saying correctly). We use it to deploy builds of both desktop apps and web services to test, user acceptance and production environments. We can select the TFS branch we want to build and where to deploy it to. Click the 'run' button, answer some dialogs, and you're done.

The trick with it is setting up the automation scripts. I didn't create the scripts we're using, they were done by a predecessor, however, it doesn't look that difficult to figure out.

Answer 2

Do you maintain/support multiple releases? If not why use a branch per release strategy? The one flaw I see in your current branching strategy is the hotfix scenario you mentioned. If you have a hotfix that needs to be applied after work on the next release has commenced, there is no way to deploy that hotfix independent of the new release. Well there is a way, but it takes a lot of discipline to isolate the code that applies only to the hotfix from the code for the new release.

You are also correct when you say that rebuilding the code for the various environments can potentially create problems. Check out Continuous Delivery for some ideas on addressing some of your very concerns.

To answer your question about a separated Build/Deployment tool, Paul Stovell is working on a product called Octopus That uses the Nuget system to do just what you want.

Answer 3

I would suggest the following changes:

• Do not deploy from trunk. Trunk is for integration between all project and release branches. Instead, create a branche from trunk for each release. Operations can than build and deploy the results from there. This allows operations to focus on the release.
• Use separate team projects for different teams, so you can apply different permissions per project.
• Request your own build server (which you can host in development), to build and deploy your development version.