Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Chef Cookbooks Developer Guide > Developer > Development Workflows > Chef Source Control Management

Chef Source Control Management

Overview

If you are developing your own library of Chef cookbooks and recipes, it's important to understand and implement the following best practices to ensure that you or your development team have a streamlined process for code development.

General Best Practices

  • Test a code change before you add and commit the change. 
  • Commit minor changes. It will be easier to perform differentials if each commit applies to a specific change.
  • Always provide helpful and descriptive commit messages.

Development Lifecycle Diagrams

Branch of Master

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

diag-GitHubDevelopmentCycle_Standard-v1.png

  • 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.

diag-GitHubDevelopmentCycle_Branch-v1.png

 

You must to post a comment.
Last modified
22:03, 16 May 2013

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.