Versioning Plan Configuration In VCS

Consider working on a product which has numerous officially supported releases developed over a span of several years. From a business perspective, support is offered until the release reaches EOL. Each official release and subsequent service pack may have a branch in the VCS. Customers may pay for patching and old unsupported release, so you should have to capacity to maintain and build them.

At some point during the lifecycle of a product you're going to upgrade the tooling, underlying frameworks and thus the build process. This poses a problem.

If release v1 of the product was built using Visual Studio 2010 and MSBuild v4.0, then all subsequent maintenance to that branch should be built with Visual Studio 2010 and MSBuild v4.0.

If release v10 of the product was built using Visual Studio 2013 and MSBuild v12.0, then all subsequent maintenance to that branch should be built with Visual Studio 2013 and MSBuild v12.0.

In the case of Visual C+, applications built in Visual Studio 2010 uses the Visual C+ 2010 runtime, and those built with Visual Studio 2013 uses the Visual C++ 2013 runtime. It may not be feasible to upgrade the runtime for v1.0 of the product, since this requires changes to installers etc. Since there may be regressions, the testing effort may be stupendous.

The same challenges applies when developing commercial off-the-shelf applications in Java, Ruby, Python, C/C++, Node.js etc.

Lets consider that numerous teams distributed different locales are maintaining the product. Feature branches are heavily used as to not disrupt other teams. You may end with tens if not hundreds of feature, release and hot fix branches.

So to reduce the cost of maintenance, you'd like Bamboo to automatically manage build plans for branches. In essence, a developer creates a feature branch and bamboo will maintain the build plan. After all, the build process is almost identical for every VCS branch, except perhaps for the version of the tools being used and how its invoked.

It seems that for Bamboo to effectively manage and build branch specific plans, that it must support the capacity to version some part of the plan configuration to allow for differences between branches. For example, when you developed release v1, you had a job named "Build" which used MSBuild 4.0 (32bit) to build the Visual Studio solution. For v10, that changes to MSBuild 12.0 (32bit).

It is thus feasible to request that Bamboo store the plan and its corresponding stages, jobs and tasks in a file that can be versioned with the source. Upon a build, Bamboo can read this information, detect the appropriate agents and then execute the build. TFS already supports that today.

Some plan configurations, such as additional requirements, the location of artifacts, tool output (NCover, NUnit), build hung properties, can be versioned too, since they may change from VCS branch to VCS branch.

Sure, we can write scripts to do this and keep Bamboo plans really dumb. But that mitigates the usefulness of Bamboo. It requires build masters to cherry pick agents for branches, which doesn't scale well; nor is it efficient.

Here's a scenario I experienced more than once. I took the liberty to assume that Bamboo would support versioning plan configurations in the branch its trying to build.

Year 1

1. A customer reports an issue with release v1.0
2. A JIRA issue (DP-123) is created.
3. Using JIRA, the developer creates a feature branch (DP-123) from release v1.0
4. The developer fixes the issue using Visual Studio 2010 (which is installed on his workstation)
5. Developer commits the change
6. Bamboo builds the DP-123 branch using a build agent with only Visual Studio 2010 installed.
7. The patch is submitted to the customer
8. The developer merges DP-123 with release v1.0
9. Bamboo builds a new version of release v1.0
10. The developer merges DP-123 with master
11. Bamboo builds a new version of master
12. The developer merges DP-123 with develop
13. Bamboo builds a new version of develop

Year 3

1. Every developer demands that Visual Studio 2013 and Microsoft.NET 4.5.1 should be used for release v10.
2. An JIRA issue is created DP-999 to upgrade the toolset.
3. Using JIRA, a developer creates a feature branch DP-999 from master.
4. The developer changes the Bamboo plan configuration, versioned with DP-999, to use Visual Studio 2013 and MSBuild 12, rather than Visual Studio 2010 and MSBuild 4.
5. Developer commits the change to branch DP-999.
6. Bamboo fails to build branch DP-999 since no agent exists with Visual Studio 2013. None of the other builds are broken.
7. Buildmaster creates a new agent with Visual Studio 2013.
8. Bamboo builds branch DP-999 on the new build agent.
9. Developer merges DP-999 with the develop branch (assuming the upgrade was seamless)
10. Other developers are instructed to install Visual Studio 2013
11. DP-999 is merged with feature branches intended to be part of v10. Older releases are left alone.

Its important to note that while upgrading the toolset, no one else is impacted. The work of the build master is minimal. It is also possible to abandon the effort without any changes to the plan configuration.

Year 5

1. Customers reports an issue with release v1.0
2. A JIRA issue (DP-2563) is created.
3. Using JIRA, the developer creates a feature branch (DP-2563) from release v1.0
4. The developer fixes the issue using Visual Studio 2010 (which is installed on his workstation)
5. Developer commits the change
6. Bamboo builds the DP-2563 branch using a build agent with only Visual Studio 2010 installed.
7. The developer merges DP-2563 with release v1.0.
8. Bamboo builds a new version of release v1.0.
9. The release v1.0 patch is submitted to the customer.
10. The developer merges DP-2563 with all official releases (if needed)
11. Bamboo builds a new version of all official releases (if needed)
12. The respective patches are released to customers (if needed).
13. The developer merges DP-2563 with develop, addressing any incompatibilities between Visual Studio 2010 and Visual Studio 2013.
14. Bamboo builds a new version of develop, using Visual Studio 2013