Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I know this is not the right place for general questions about versioning control. But Salesforce.com projects are someone special from regular local Java/.NET projects. That is why you find many Salesforce.com specific documentations about versioning using SVN (Subversion).

We just switched from Subversion to Git (private Github repos) and want to rethink our process and folder structure to better suite Salesforce.com specific development.

  1. Are you already using Git and which experience and best practices can you share?8
  2. Are you using separate repositories or branches for Patches / patch orgs?
  3. Are you using feature branches?
  4. How mature is the eGit tooling in the Force.com IDE (=Eclipse)?
  5. Any positive or negative experiences with Github as private repository provider?
  6. How to you bridge the gap between Eclipse having a seperate project per patch and Git working with potential switchable branches.
  7. Could you get merging and diffing work between trunk and branches?
  8. Do you also store your git repository in the eclipse workspace project folder (although this is not recommended)?

I will leave this somewhat open question, unanswered for a week to invite many answers and diverse feedback and than after a week select the most detailed and valuable feedback as answer.

share|improve this question

2 Answers 2

I started down a similar path about 9 month ago when I started at the Salesforce.com Foundation and was tasked with building the continuous integration architecture for the next major version of the Nonprofit Starter Pack. We're now at the release phase of the development process and have confronted a lot of the questions you pose.

Before diving in on the specific questions, I wanted to point to a few resources from our project which might help:

I created the following documentation a few months about about our process and setup. It's evolved quite a bit since then and I intend to update the docs over the next month or so to reflect the new process: http://developer.salesforcefoundation.org/CumulusCI/

There's also this webinar with more detail on the process and (hopefully) a better explanation of the diagram in the documentation: http://www.youtube.com/watch?v=Cm42ZF5MrLA

You can also see the whole process in operation along with all the build scripts we use: https://github.com/SalesforceFoundation/Cumulus http://ci.salesforcefoundation.org

Are you already using Git and which experience and best practices can you share?

We use mostly a variant of GitHub Flow rather than git-flow. We use one master branch (which we name "dev") and feature branches for all development. Pull requests in GitHub are how a feature branch gets into dev. We use a script to copy the merged code from dev into all open feature branches after it passes build. This keeps feature branches up to date with the dev branch.

Our project is open source so we have our internal developers work in the main org repository but anyone can fork the project, create a feature branch, and submit a pull request back to us.

Are you using separate repositories or branches for Patches / patch orgs?

Our main goal is to have such a frequent release cadence that we hardly ever need to worry about patch orgs. If you're releasing a new version every 2 weeks, patches are the exception.

If we need to create a patch, we use a patch org and a branch dedicated to the patch. We then create a pull request to merge the hotfix changes from the patch back into the main dev branch.

Are you using feature branches?

Yes. We do all development in feature branches. We also test every commit to any feature branch with a complete deployment to a shared feature org. One challenge of this approach has been to ensure the org is cleaned out as different feature branches can contain different metadata.

How mature is the eGit tooling in the Force.com IDE (=Eclipse)?

Some of our team members have been using eGit and are quite happy with it. I still do my development in vim, command line git, and ant though so others might have more to say here.

Any positive or negative experiences with Github as private repository provider?

We started our project with a private repository which eventually became public. I can't think of any issues I've run into with the private repository or GitHub. All in all, we designed a good bit of our process around some of their features on top of git (pull requests, commit status api, etc).

How to you bridge the gap between Eclipse having a seperate project per patch and Git working with potential switchable branches.

This varies mostly by project and developer preference. A developer who is more comfortable with git branching will likely be more comfortable working in one project. My experience is more with switching between feature branches rather than patches though.

All our devs do all their development against their own DE orgs using whatever tools they want. When they are comfortable with their changes, they push them to the feature branch in GitHub where their code gets tested by the build system. The push is essentially the only defined interface between the developer's local environment and process and the rest of the team.

Could you get merging and diffing work between trunk and branches

Pull requests have been incredibly reliable to merge feature branches into our dev branch.

One thing that has helped a lot is using an automated script to push dev changes back into all open feature branches. Consider this scenario:

  1. Developer A is working on branch feature/1. They complete their work, submit a pull request to merge branch feature/1 into branch dev, and the request is accepted. At this point, the dev branch contains feature/1.

  2. At the same time, Developer B has been working on branch feature/2. When they created feature/2, it was in sync with dev but is now out of sync as dev has new changes.

  3. When Developer B goes to push changes to GitHub, they are not notified that there have been changes to dev which they need to incorporate into their branch. Their push is tested against dev + feature/2 but does not include changes from feature/1. The longer running the feature branch becomes, the more changes it becomes out of sync with.

By automating this process, #3 changes to Developer B goes to push changes to GitHub but the push fails telling them there are remote changes in their branch which they need to first pull. If there are any conflicts, the developer merges them with their changes locally and pushes the merged code. Their commits then get tested against dev + feature/1 + feature/2

Do you also store your git repository in the eclipse workspace project folder (although this is not recommended)?

We store the local cloned repository in the eclipse workspace and have not noticed any issues from it.

share|improve this answer
1  
Thanks for sharing your experience in such a great detail. This is highly appreciated. –  Robert Sösemann Jul 21 at 20:48
    
This is a great answer Jason Lantz, great detail. –  greenstork Jul 21 at 21:07
    
Just a quick update, I'm giving a presentation at Dreamforce (Wednesday 5:00-5:40pm) on the process we've built (success.salesforce.com/Ev_Sessions#/session/a2q30000000gttvAAA). I'm also giving a theater session on Tuesday (I think at 11:30) which will be more hands on in how to use our build scripts and automation scripts to setup our whole process for your own projects. The theater session should be fun. My goal is to show how to take an unmanaged project on GitHub, configure the build scripts, and setup the whole automation system in about 15 minutes :) –  Jason Lantz Sep 19 at 21:27

I cannot answer the Git related parts, since we are using BitBucket with Mercurial, but i can give some insight to question 2, 3 and 7.

Are you using seperate repositories or branches for Patches / patch orgs?

We are opening a new branch for each patch. The branch starts at the commit, which marks the release. Older patch branches are closed over time, but can be reopened any time. Applicable bug fixes are transported via cherry picking from/to patch branches. Patch branches do never get merged.

Are you using feature branches?

Yes. Most of the time each user story (aka feature) has its own feature branch. Each feature branch branches off the last release commit. Each feature branch is connected with its own dev org. Each dev org has its own namespace. The deployed code will be uploaded as managed released right after branch/first deploy. This helps us to lock down the same components, which are locked at the staging org. Feature branches do get merged to the default branch eventually (e.g. after test, code review...).

After a feature branch has been merged, we are abandoning the accompanying dev org. Or in other words: each branch gets a new dev org. The setup of a new dev org is fairly easy: create a new namespace, enable languages at the translation workbench, deploy, upload, retrieve.

Deployment and retrieve is done via the ant migration tool and some scripts, which do take care of a different namspace for each dev org.

Bug fixing does occur where it fits best. This might be a feature branch or a patch branch. Bugs with a huge impact (many code changes, aka. disguised user stories) may receive their own branch.

Could you get merging and diffing work between trunk and branches?

Most of the time, merging is as good as the merge tools we are using. The key aspect is that we are using namespaces at each feature dev org and are uploading the code first. This prevents most of the issues, which would make new code undeployable to our staging org. Special features (e.g. multicurrency, person accounts, opportunity product schedules...) are addressed such that the code can be deployed to a dev org, which has none of this enabled. Tests for that code detect, if the feature has been enabled and are skipped otherwise.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.