Managing your PaaS subscription
Although you're free to develop your codebase in whatever manner you desire, we encourage you to use the Branch-per-Feature (BPF) model as you develop and maintain your Acquia Cloud Site Factory code.
For additional information, visit Acquia Academy (sign-in required) for the Acquia Cloud Site Factory Code Management Concepts video tutorial.
When you're working in a distributed version control system (DVCS) such as Git, if several developers develop features and then integrate them into the shared codebase, it can become difficult to manage. To address this, Adam Dymitruk developed the Branch-per-Feature methodology, which allows project teams to work on small, specific features as separate branches, allowing each branch to be excluded from the release at the end of the sprint, if necessary.
The Branch-per-Feature method (as implemented by Acquia) includes the following attributes:
- All work is done in feature branches.
- All feature branches start from a common point (branched from master at the point of the last release).
- All work is regularly merged into a temporary integration branch to resolve merge conflicts and to ensure that tests aren't breaking.
- All completed features are merged into a QA branch, which is created from master and recreated for each new feature.
- All manual testing is done on the QA branch (leaving out failed test items the next time the branch is recreated).
- When ready to release, the QA branch is recreated with all features that passed testing, merged into master, and then tagged.
For more information about the Branch-per-Feature method, see Adam Dymitruk's blog post on the topic.
At the heart of this branching strategy is the idea that your feature branches are completely unadulterated by anything else happening in the code repository; their history should be a series of commits, each one of which is related solely to the feature itself (for example, no back merges). Here's an illustration of this clean commit history:
Both a QA (green) and a feature (red) branch are made from the master branch (black) in the example. The developer makes commits to the feature branch until they're complete and then merges them into the QA branch. After testing, the QA branch is merged back into master for release.
Areas of caution
As you begin to implement BPF with your codebase, be mindful of the following areas of caution:
Don't deploy the integration branch
Because developers merge their features into the integration branch continuously, it can be tempting to deploy the integration branch to a test environment for evaluation. Doing this is an abuse of the integration branch and is contrary to the purpose of the integration branch, which is to ensure that commits are able to merge with each other and don't break tests.
If you need to test features in a test or staging environment during the sprint, recreate the QA branch with that feature in it, and then deploy the QA branch. You can always recreate the QA branch without the feature if it's not yet complete for release.
Don't make the creation of the QA branch the task of a single person
Feature developers should recreate the QA branch from scratch each time they add a new feature instead of requiring a dedicated release manager to create the QA branch with all of the new features at the end of the sprint.
This is important because even though merges into integration will catch most merge conflicts with other features (which are resolved and the resolution shared using the rerere cache), it's possible that the order of commits is different when merging into QA. Because of this, conflicts can arise for which no existing rerere will work. The best person to deal with merge conflicts is the merged feature's developer, and when the developer resolves conflicts as they happen, the shared resolution will work for future iterations of the QA branch (because the branches get merged in the same order each time).