One of the challenges of working with a team of developers is managing the changes everyone is making and not have one developer overwrite the changes another one makes. In this post, I’ll describe the setup I’ve found to work. I’ll be writing followup posts with more detail describing exactly how I use some of these tools. All tools described work on both Windows and Mac.
1. One developer per sandbox
Each developer should get their own sandbox or developer edition to work in. All changes should be made in their sandbox. This prevents a developer from making a change to a class in their IDE which hasn’t been refreshed recently overwriting a change another developer did recently.
2. Sublime Text with Mavensmate
The combination of Sublime Text with the MavensMate plugin is really powerful. MavensMate makes it easy to retrieve metadata from Salesforce and saving is super quick compared to the Eclipse IDE. I never want to open Eclipse again.
3. Use Source Control to Track Changes
I prefer to use Git because that’s what all the cool kids seem to be using and the tools out there are fantastic. I use Bitbucket because they provide free private repositories for up to 5 developers. The nice thing is there are many options out there that are free/low cost and you don’t have to install a server locally. I like to use the free SourceTree client because I can never remember the git commands. It also lets me more easily see the changes I’m about to commit. As each developer works, they should be working on their own branch and then merging their changes into the master branch as they are finished. I can’t tell you how many times I’ve used source control to go back and see the changes done. In one situation, a change caused major issues, I was able to go back, reverse the commit, and we were back in business really quickly. When a developer needs to bring their sandbox back in sync with the master branch, they can use the Force.com Migration Tool to deploy all the changes back into the org.
4. Use a CI Tool to Build to a Staging Sandbox
Now that you’ve got everything merged into source control, you need an org to test everything in. You could have each developer deploy their changes manually to a staging org, but I prefer to use a Continuous Integration tool to do it for me. I recently found Drone.io and it is really easy to setup to automate the deploy of all metadata to your staging org. Drone.io adds hooks to Bitbucket so when a change is committed to the repository, it automatically begins a build using the Force.com migration tool. You can get emails on successes and failures. The one drawback is that there isn’t a way to deploy destructive changes automatically. Any deletion of objects, classes, pages, etc need to be done by hand.
I hope this description of my environment helps you get your team up and working peacefully together!