3

Looking for suggestions on:

  • GIT branching/pull/merge best practices
  • Deployment best practices
  • Automation tips

I've found articles about Continous Integration but generally they are for DEV->QA or DEV->QA->PROD. I'm looking more for the reverse, continually integrating Prod changes into Dev, DEV->PROD.

Background: A developer can't keep up with the constant changes in production. We can't re-train the Admins to only work in a Sandbox. Too much overhead and not reasonable for simple changes to Picklists, Reports, Validation Rules, etc. that our Admins love to create and customize. A developer needs these changes available in their dev environment. During deployment, developers don't want to overwrite a change made directly in Prod. During code cleanup and refactoring, developers need to be able to search all the latest code (metadata) in Prod. Sound Familiar?

Environment:

  • We have Salesforce Unlimited, 2 Full Sandboxes, 3-5 active Dev Sandboxes.
  • There are 8 Users with the System Admin profile in Prod.
  • There are 2 full time developers and sometimes contract developers.
  • Developers use Sublime/Mavensmate (sometimes Eclipse).
  • GIT for Source control, we all work off 1 branch (master), sometimes create a separate branch for long projects.
  • CopyStorm Backup/Restore for loading data into Dev Sandboxes
  • Deployments are done through MavensMate from a Dev Sandbox to Prod and Full Sandboxes (as needed).
Improve this question

3 Answers 3

Reset to default
3

If your production changes are all checked into your git master branch (assuming this is the branch representing production) you can merge the production changes into the other working branches and those changes can then be pushed to the orgs just like any other modification to the source would be.

This really isn't any different than a patch or a breakfix change that's made upstream of other development. Those changes just need to be merged back into the downstream repositories as well.

Your git repository needs to be the source of truth and in every case where it's possible, your org's metadata config should be there.

To speak directly to a statement in your question: "Too much overhead and not reasonable for simple changes to Picklists, Reports, Validation Rules, etc. that our Admins love to create and customize."

  • What type of change management do you have in place?
  • What's your process for making changes to production?

If your change management processes allow for modifications directly in production, the process must include the steps of documenting and checking in those modifications to git so that those same changes can be merged into other branches and their respective orgs.

Improve this answer
2
  • 2
    Thank you. I'm thinking of automating a nightly "refresh" of ALL metadata from Prod and committing to master. Each morning developers will merge master into their Dev or Feature branch. Would you see any problems with this? When it's time to deploy to production, I would: 1. Manually run the process that does a prod refresh and commit to master. 2. Merge master with Dev and fix any conflicts. 3. Deploy to prod from the Dev branch. Do you see any problems with that deploy process? Where would Jenkins or some other CI process come into play?
    – Christian Anderson
    Commented Nov 24, 2015 at 23:32
  • 1
    This conversation is far too complex to be contained in comments here. Generally speaking, you should be deploying incoming changes out of the master branch into the production org, not from a dev branch to your production org. Your step 3 should be to merge your dev branch changes into your master branch and then step 4 is to push those changes from the master branch to your production org.
    – Mark Pond
    Commented Nov 25, 2015 at 20:05
2

I would use Jenkins, CircleCI or any other "continuous integration" tool to do this. These work better if you go only in "one direction" (i.e. Sandbox->Prod) but should work both ways.

The con of this is that you need to maintain that tool and resolve conflicts that arise when changes are made to the same object both in Prod and in Sandboxes.

If you did implement that tool, I would recommend that you do not allow people to make changes in Prod. If the admins make changes in sandbox and those "automagically" make it to Prod, perhaps it'll be easier to adapt. I know, I know, but I had to say it. :)

Improve this answer
2
  • 3
    I've worked in environs where changes directly to prod were forbidden and Jenkins was the primary integration tool. It's amazing how much less trouble you go through when you adopt a decent system.
    – sfdcfox ♦
    Commented Nov 18, 2015 at 19:49
  • In one of my clients, we also use Jenkins and, except for the overhead of having to use an 'SE' to do the deployment, it is remarkably easy to keep the PROD org and Dev orgs in sync. That said, we allow Reports to be built in PROD without having to replicate / sync them in DEV
    – cropredy
    Commented Nov 18, 2015 at 21:02
-1

Have you ever considered these 3rd party alternatives?

I have only used Flosum, but I'm one person. And it all requires access to the same org.

Autorabit is a custom UI pulling in the metadata, but carries their own licensing minimums.

These are all new products (less than 2 to 3 years old) for the most part, so I'd be curious to see what people think.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .