Version Control – Teamwork

Over the last three weeks, I have written three separate articles in my Version Control series:

All three of those articles build up to this one. If you have not already read them, please do so.

On my latest article, Guy Keshet commented with a great question:

Hi Jesse

I’m interested in hearing about your experience of using the above mentioned setup with MULTIPLE developers.

I’ve used eclipse with git an ant (based on Jenkins or Bamboo) several times, and it all works well with ONE person managing the code.

As soon as I try this with one then one developer, I find that after the 2nd person pushes a change, git goes into conflict

I’ve yet to identify the issue, but I reckon it’s a combination of package.xml being a local file (so each person has a slightly different project) and slight differences in the way SFDC build the xmls locally on each machine

Have you had these issues before? have you managed to find a solution?!?

This is an interesting question. It is one I faced when I first started working on the platform. Before I continue, some of what I am going to say in this article may be a bit controversial. Please remember, everything on this site, this article included, is purely my own opinion and does not reflect that of any organization I am associated with.

Coming from a traditional development background, it was a difficult transition to begin working with the platform. Salesforce has a comprehensive guide written on the Development Lifecycle, but all of it seemed rather odd. The idea that you could have multiple applications all working within the same context didn’t make any sense to me. It was even more challenging when it came to managing changes between myself and the rest of my team. We immediately ran into problems.

Ideal (Multiple Developer Sandboxes)

The ideal way to development on the platform would be something like:

The way this works is:

As I mentioned, ideally, this is the way development should occur. Before I go further, I want to point out that even in the ideal environment, there are some challenges you need to take into account. For one, any data that is needed to develop properly will need to be shared across each environment. You will want a way to quickly refresh your development environment anyway, so you need to script out some data entry. You can use the Data Loader or you can now use the Force.com CLI and write some batch scripts. Another problem you could potentially run into would be controlling changes that are not available in the metadata. For instance, when Approval Processes were first introduced, they were not available through metadata. The only way to get that type of change across multiple sandboxes is to duplicate that effort. To facilitate those changes, you need to make sure you have a solid change management system in place.

The issues that are present are solvable, but in order to solve them you need time. Unfortunately, for many of us, time is not a luxury we have. In the consultant world, setting up a structure like this simply isn’t always possible.

Simplified (Single Developer Sandbox)

The simplified way to development on the platform would be something like:

The way this works is:

  • Each developer works in the same sandbox.
  • All changes that are made in the sandbox are committed to Git (or a different version control system)
  • Each developer does pull requests from Git to keep their development environments in sync
  • Each time a commit is made, a build gets kicked off in your continuous integration (CI) environment (this may be optional if no sandbox is available)
  • All deploys to your staging environment happen from tags in Git
  • All deploys to your production environment also occur from tags within Git (only have they have been validated in staging)
  • After any deploy to production, each sandbox can be refreshed from production

This method reduces the need for additional sandboxes (which is a problem in many scenarios). It also removes the problem of data being different for each developer and removes the issue of making changes manually across every development environment. This does however present a new set of issues. With each developer working in the same environment, you can run into overwrite issues if you aren’t paying close attention to who is working where. You can also run into issues where developers can commit changes they did not make if they incorrectly pull down changes someone else made in the sandbox.

Conclusion

Each methodology provides positives and negatives. As I originally mentioned, this may be controversial as I know some people feel very strongly about a specific way to develop on the platform. I think external factors usually are the deciding factor. If you are building a product, the investment to set up the ideal development environment makes sense. If you have to change projects constantly or if you have a small amount of sandboxes available, a simplified development environment may make more sense.

Either way, there is no “perfect” or even “correct” way to set up your development environment in my mind. You will need to work through any of the issues that may come up with your team and figure out what works for you, not what works for everyone else. Good luck!

Important Note: It is important to remember that this is my personal opinion. As with any opinion, it may or may not reflect the opinion of any organization I am associated with.

7 Responses to “Version Control – Teamwork”

  1. February 10, 2014 at 10:55 am #

    Very nice article summarizing two reasonable development options. Thanks!

  2. Paul
    February 18, 2014 at 6:49 am #

    Jesse – very useful set of articles, on one of the more problematic areas of the platform! If you get a chance i’d love see you “finish the series” with the article on branching!

    • February 18, 2014 at 7:20 pm #

      Thanks for the feedback Paul! I definitely plan on doing just that. I just needed a break from the series last week. It will be coming soon!

  3. November 4, 2014 at 11:56 am #

    Hi Jesse,

    Your post is really interesting. Question….do you know what it happend with the Force.com IDE in eclipse that prevent you to save a component if other developer saved it before you?. That´s feature showed you a warning like this. “Please, refresh from server before you save …..”. That was so useful for not to overwrite the work of others developers, and the new plugin is not showing that anymore. Do you know why?. Thanks a lot

  4. santhosh
    November 2, 2015 at 10:53 am #

    Jesse,

    Thanks for the nice article. I have a quick question. How do you build package.xml? manually? Assume I have modified a bunch of components and wanted to move it to staging and then production. It seems difficult and lot of effort to build package.xml manually. Do you have any ideas?

    Santhosh

Trackbacks/Pingbacks

  1. Using Gulp to Manage All Your Static Assets | Bob Roberts - June 24, 2015

    […] have your own development environment. For reference, check Jesse Altman’s ideal explanation and for more depth, read the other articles he has in the […]

Leave a Comment