Team Development on Force.com

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!

 

 

13 thoughts on “Team Development on Force.com”

  1. This is a great post. I feel that team development on the Force.com platform is actually pretty difficult for newer developers transitioning from other languages to wrap their heads around.

    Specifically, (and this has been resolved now), approval process wasn’t able to be moved through metadata (neither was Site.com changes). How do you manage those types of changes? I would also love to hear how you manage working with set up data and scripting all of that out between the multiple environments.

    1. Thanks Jesse! Right now we still do a lot of manual steps to get certain changes into the staging org. I’m still experimenting with what works best. One issue I’ve run into is that MavensMate only pulls a subset of metadata so if we want other metadata such as approval processes, then we have to use Ant to pull them.

      As far as data goes, we have some Apex scripts that we run in Anonymous to get some data in. A lot of that is a manual process as well.

    1. Yes, sometimes our builds fail, but it is actually not that often. Part of it is keeping your developer orgs up to date and remembering to make the manual changes needed.

  2. Nice post !

    I see using more GIT is helpful, i.e. have CI flow to FORK out from master GIT repo and then deploying it to a developer specific org. Once developer has done the changes, he can raise a pull request. This pull request will clearly highlight the changes, and will give an opportunity to do a safe merge using GIT tools.

    1. I don’t have a lot of experience with Jenkins. I found that with Drone I could do everything I was doing with Jenkins. Basically just executing the Ant command. Drone was a heck of a lot easier to set up.

    1. I don’t have any experience using SVN with force.com. Since Eclipse and MavensMate both copy your metadata locally, you should be able to use any svn tools out there.

  3. Hi.How can we maintain version control using Force.com Ide and using bitbucket. Scenario:- One developer makes changes in a class and commits the changes using Force.com Ide. Other developer has checked out the code using source tree. He should be in position to see the changes made by first developer when he pulls the code from bitbucket. How is it possible?Which version control tool we can use to syncup the developers changes .

Leave a Reply