0

Apologies for the broad question, but there's considerable detail to add here in the body that wouldn't fit in the title.

I need to craft a deployment approach for our dev sprints that aligns to our Enterprise IT standards and factors in the following :-

  • Source control using Subversion (non-negotiable, i.e., I can't switch to Git)
  • Scriptable deployment packages that can be run in by an Ops team that doesn't have Salesforce knowledge (pretty sure I'll be using Force.com Migration Tool/Ant for this)
  • Reconciles against the Production Org for any config changes that our App Support team (who are all admins) make directly in that instance (sadly, that happens)

I can work out the process for getting code in and out of SVN to a Dev sandbox (largely based on https://developer.salesforce.com/page/Using_Force.com_with_Subversion_for_Team_Development) and I know how to use Force.com IDE and/or Mavensmate to select the metadata I am working on, both of which helpfully build the package.xml manifest needed for deployment.

The challenge, then, is to define a process that encompasses all the three streams (packaging for deployment, source control and Prod reconciliation). To this end, I've started with the diagram shown below, but it still doesn't cover all requirements.

Anyone able to help plug the gaps?

Deployment Structure

Improve this question
1
  • I am torn...While this is overly broad and subject to opinion, It is applicable to a wide audience and could serve a good purpose with a solid answer. The gabs I see are the reconciliation of the dev/stage with the production org changes that have not been pushed downstream. While I do not have an answer (I have not had a need to do this) I am interested in what the solution may be....
    – Eric
    Commented Mar 23, 2017 at 23:27

2 Answers 2

Reset to default
0

Not sure what exactly you are missing. Every org has their own flows. But you have covered the base already here. Anything specific you are looking for ?

Improve this answer
5
  • Main concerns are - how do I build a package.xml from the subversion "version of truth" and how do I ensure changes made in Production directly aren't overwritten by the Dev stream?
    – Rob Cowell
    Commented Mar 23, 2017 at 16:15
  • The conflicts should be already catched during code merge in lower environment. Everyday Developers are working, they will get the latest code from the branch they are working from.
    – Amit Sahu
    Commented Apr 3, 2017 at 18:03
  • Not necessarily true Amit - the support team are unlikely to be checking in admin/config changes they make in Production into source control. At the moment I'm having to solve this with an Org Compare tool and make judgement calls on what is a change we need versus what we don't
    – Rob Cowell
    Commented Apr 4, 2017 at 8:11
  • So are you saying Admins do it on production directly ? I mean I have a scenario where Admins have their own sandbox. They do changes there first and get approvals before making those changes into production. We are talking about only Metadata changes. If they do update metadata, these changes can be pushed to Git as well from where developers are working.
    – Amit Sahu
    Commented Apr 11, 2017 at 18:48
  • yes that would be the ideal scenario for me, but the current model with my employer is that they make changes in Production due to a perceived urgency. :-(
    – Rob Cowell
    Commented Apr 19, 2017 at 13:53
0

So we're now working with a dual-diff approach using ANT to pull down the org state and Subversion.

  • The first is comparing local copy (from dev sandbox) against SVN for differences. This picks up developer changes.
  • The second comparison is Production (via a local copy in a different folder) against SVN. This picks up admin metadata changes (with usual caveat about config changes not supported in Metadata)

The advantage to this approach is that we have the same tooling for both scenarios.

I had been using the Org Compare tool by Ben Edwards (https://sftoolkit.co) to directly compare orgs, but my employer is nervous of an external third-party tool and the fact that the hosting of it may be pulled at any time. It's open source, but the Django platform and other pre-requisites make it hard to self-host your own copy.

Improve this answer

You must log in to answer this question.

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