by DreamOps Crew.
For administrators working with a single company, changesets are a great way to move updates between sandboxes and a parent org. However, when working on the enterprise tier, we often need to transfer components between various test and developer environments, which are outside the scope of changesets.
To support multiple developers working across multiple environments on various features and fixes, a proven path is to use an automated continuous integration system to simplify deployments and promote transparency.
One approach, outlined in the Force.com Development Lifecycle guide, is to use a separate developer org for each coder. While multiple orgs is better than one org, for larger teams, the org-per-developer approach presents challenges:
CumulusCI is the process used by the Salesforce.com Foundation for the Cumulus project, the next generation of the Non-Profit Starter Pack (NPSP).
The process integrates GitHub, Jenkins, the Salesforce.com Ant Migration Tool, and a custom web application called mrbelvedere running on Heroku.
While this process was specifically built for the Cumulus project, it should be useable by other Force.com projects.
For a high-level overview, see the project's GitHub page.
In the session "How to Setup Continuous Integration with Git, Jenkins, and Force.com" (Dreamforce 2013), Derek Hansen and Ted Husted presented an approach that maps Feature Branches to Feature Sandboxes.
For a detailed step-by-step, visit the session's git repository.
In the session "Continuous Delivery with Force.com" (Dreamforce 2012), Tim Inman and Sanjay Gidwani also presented on the same topic. For Dreamforce 2011, James Hatton with Alexis Williams presented "Continuous Delivery in the Cloud".
How Atlassian uses JIRA and Bamboo to update their own Salesforce org using continuous integration and deployments.
Also presented at Dreamforce 2014 and Dreamforce 2015.