-
Developers working in parallel with Continuous Integration builds for Dev and QA
November 20, 2016 Rodrigo Peplau 0
When multiple developers are working in parallel (at the same build, but working in different parts) it is very common to use branches at source control, to keep each developer working in isolation and eliminating any chance that one developer’s work interferes with the work of another. Of course one day their work will have to be integrated, and that is the moment when things can go wrong. The following article proposes one of many possible setups to enable that isolation.
Creating a branch from another branch is very simple and easy. When working with a Continuous Integration system, however, your branch is supposed to be monitored, built and deployed to a place people can access and test it.
A branch and its servers with Continuous Integration
The following image illustrates a scenario where multiple developers are working at the same branch, and a second branch is used as a basis to deployments. The blue boxes at the right represents servers with specific purposes. Being now a Sitecore good practice to develop and test in scaled environment, all environments will have two nodes, one for Content Management (CM) and another for Content Delivery (CD).
The Continuous Integration server monitors the branch “All developers” and deploys changes to DEV (at every change) and QA (manually). When the time for a deployment comes, the work is merged to Deploy Branch. The Continuous Integration server will then make the last integration to the servers “Deploy-CM” and “Deploy-CD”, where things can be tested for the last time before the actual deployment.
The Problem with this approach is that all developers are pushing their modifications to the very same branch, and thus deployments must carry everything at that branch (except of course, if very granular merges are made, but that can also be tricky and error-prone). To enable a better safe separation, the following setup is proposed.
Multiple Branches
The image below now shows a second branch, with its respective DEV and QA servers. Now each developer can make their work at their own branch, keeping a physical separation that guarantees one developer’s work won’t interfere with the other.
The image also shows that branch “Dev1” (the older branch) were used to create branch “Dev2”, which guarantees that both branches are identical at that point in time. Obviously, each branch will have their modifications from that time on, and the code integration is now a bit harder to be executed. As time passes, each branch will be more and more different, bringing the need to a more careful exercise during the integration, executed at the “Deploy” branch.
Deployments and Reverse Merges
When all developers were working at the same branch, the act of checking in their changes were the integration itself. Continuous Integration server would push it to the servers, and integrations were continuously made due to the same code base. But now with physically separated branches, developers must communicate and keep their branches as much in sync as possible. The following images shows a sequence of deployments and reverse merges, that would keep both Dev branches in sync while sustaining their separations.
Image 1 – First Deployment (by Dev1) and Reverse Merge (by Dev2)
Image 2 – Second Deployment (by Dev1) and Reverse Merge (by Dev2)
Image 3 – First Deployment (by Dev2) and Reverse Merge (by Dev1)
Health Check builds with Continuous Integration - How big and how often these needs to be? Workflow not starting (state field is empty) when Versions.AddVersion after Sitecore upgrade from 6.5 to 8.1