I am planning to implement continuous integration using Git,Jenkins and Github in salesforce.My query is regarding the repository structure.We have 3 salesforce environments Production,QA and Integration sandboxes.is it advisable to have 3 different repositories for the 3 environments or one repository and multiple branches.My concern with second approach is if we maintain a single repository the individual developer would get access to complete production codebase and he would be able to commit the changes to master branch.Please let me know which approach is the best one to go.In case first approach is advisable then can we merge two different repositories in github?


Your question does not have an easy answer, and it looks like there are lots of tradeoffs.

In our company we have CI with salesforce. Every time a developer checks in, our CI server runs an ant script, using the Force.com migration tool, and runs all the unit tests in a test environment.

We use a single trunk and no branches. We have different revisions of the same trunk deployed to different environments (dev, staging, etc.).

We thought using one branch per environment, ideally automatically deploying to that environment once we check into the right branch. we didn't see that many advantages on this approach and for the time being we haven't implemented it.

If you use 3 different repositories, then I don't know how you can easily push a change from dev to staging and to production.

I would tend to go for the 3 branches.

What is concerning is that you said:

if we maintain a single repository the individual developer would get access to complete production codebase and he would be able to commit the changes to master branch

That sounds to me like there is a trust issue with the developers. I'm sure you can use some sort of permissions to limit who can check in to master. If you use Git, I think that you could have your devs doing push requests to master. You could then have a 'trusted developer' to review and accept those push requests into the master branch.

I don't know much about git permissions so once you've designed your strategy, you could ask elsewhere for the implementation specifics.

Hope it helped

| improve this answer | |
  • 1
    In my opinion you only have 1 version of live, so there should only be 1 repository. Your sandboxes should represent the flow of code through the various deployment stages to live, which is done with revisions. If you need to create a new feature that will be long running before going to live then branching is a solution, but it's use should follow the normal considerations you would make for branching. – Mark Keats Jan 4 '16 at 10:49

It will be a best practice to have one repository for your project rather than for your Sandbox. While your project moves across various stages , your code will flow across multiple branches and get ready for go-live.

It is good to write your own script to filter and include metadata components since some metadata components like Flows , Documents, profiles are not as simple as they appear in API guide. GITHub doesn't have branch level permissions. BitBucket has it. So, if you are using GITHub, best way is to one tightly controlled repository with all the branches and one public repo which developers can work and commit. The merges from Public repo to secured repo has to be managed internally

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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