Chef Source Control Management

Branch of Master

The diagram below highlights a standard development cycle where you create separate development branches from the master branch.

• Isolate Code Development
  • Any new code development stories or projects should not be performed on the master branch. Alternatively, you should create desginated development branches from master. Create a development branch for each new feature or major change.
  • Create development branches from the same commit ID so that each development branch is based off of the same snapshot of code. For example, in GitHub, the commit ID is a SHA. Note: The first SHA of a branch matches the SHA that the branch was created from.
  • Each development branch should be used to modify a different section of your code base. For example, you might create one development branch to modify the "database" cookbooks while another branch is used to add new features to the "application" cookbooks. It's important to isolate changes across all development branches to prevent multiple users/teams from modifying the same section of code, which can often lead to major headaches and problems when you try to merge the changes back into the master branch.
• Quality Assurance Testing
  • Test a feature using its development branch before you merge the changes back to the master branch.
  • Once all of the development branches have merged their changes back to the master branch, perform a complete regression test.
• Merging Changes to Master
  • Coordinate merges from/to the master branch. You should only merge from and to the master branch one branch at a time.
  • When you merge from the master branch, you may have to resolve any conflicts based on changes that were added to the master branch after you created the branch. 
  • Perform a complete regression test using all of the ServerTemplates that use the new codebase. Although you may find it more convenient to make minor bug fixes or update the metadata directly on the master branch, it's recommended that more extensive changes should be performed in separate branches, if necessary.
• Publishing a Release
  • Once you have a solid codebase that's ready for release, you should create a designated release branch. Any ServerTemplates that you are going to publish should have RepoPath objects where the referenced repositories are locked down to a specific commit ID of the release branch. 
• Bug Fixes
  • When you need to fix a bug in a published release branch, you can troubleshoot the bug directly on the release branch. If the bug fix needs to be added to the master branch, you can perform a standard merge.

Branch of a Branch

Under certain circumstances, it may become necessary to have a branch of a branch. For example, if there are two stories where the second story is dependent on the first story being completed prior to any code development. In such cases, you will need to create a branch of a branch.

Once both stories are completed, you can merge all of the changes back to the master branch.