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:
- Request Operations Team to create a Branch from Main for development work.
- Perform Development work on development branch.
- Merge from Trunk to development branch prior to release (basically make sure that the development branch has all of the latest changes)
- 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.
- Perform integration Testing, fix defects found in development branch.
- Repeat steps 3 - 6 as necessary.
- 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)
- QA tests, fix defects found in development branch.
- Repeat steps 3 - 8 as necessary.
- 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:
- 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)
- 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.
- 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.
- 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.
- 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.