1

Wanted to get few suggestions from the community regarding feature based branching strategy. We are a large healthcare company with fair bit of presence on Salesforce.com platform.

We currently follow one pipeline per release :

ORG Pipeline

Dev -> Packaging (CI) -> SIT -> Hardening -> UAT -> Production

However, from SVN perspective, there is only one branch where all the code gets committed and changes pushed up the chain from single branch.

All developers share a common development ORG per release which is mapped to respective SVN branch.

This approach has resulted in ALL or NOTHING strategy where either we can go live or cannot if one feature is not fully accepted. Teams were forced to work relentless hours to ensure the release branch is stable and can be deployed to production.

To help untangle from this mess, we decided to switch to feature based development to help manage scope and bring more frequent releases, providing continuous value to the business. However, there is severe resistance from the development team to switch to this model. Couple of reasons that were given were

  1. Managing and maintaining individual sandboxes and keeping them in sync with each other is a big task
  2. There are too many manual deployment steps which need to be synced up with each individual sandbox
  3. How to resolve dependencies between features and how it is reflected in the respective sandboxes, too many merges which means way too much time going in to resolving merge conflicts
  4. How are features integrated and promoted up the environment chain ? Can the features be independently tested.

Also most of the development is not custom but leveraging Salesforce standard objects such as Account, Contact, Case, Opportunities etc... hence there is a lot of interdependencies between the stories which is complicating things for us. I am wondering if anyone in this group practices feature-based development with a similar setup like ours (Predominantly standard objects) and if you did, how did you go about doing it and whether you have used any tools or other mechanisms to help the development team address concerns I outlined above. I couldn't find any articles addressing this topic in detail for Salesforce.

Appreciate all your help.. and apologies for a long post...

4

Managing and maintaining individual sandboxes and keeping them in sync with each other is a big task

Stop using Sandboxes. Salesforce DX makes it trivial to spin up a new org as frequently as you need to in order to keep your source in sync with development, no matter how many developers are in play. With the ability to push all the metadata and even upload sample data via a script, there's no reason why you need to lose coutless manhours waiting for sandboxes to spin up, then loading new data in to them, etc.

There are too many manual deployment steps which need to be synced up with each individual sandbox

Arguably, that's a problem with your current process. Manual steps like importing custom settings, updating metadata records, etc, can now largely be scripted and/or configured in packaging metadata, drastically reducing the manual steps required. Of course, when moving to production, you may still have manual steps, like when you need to change a formula field to a text field, etc, but your DX orgs won't have to worry about this as much, since you can delete and create new scratch orgs as often as you need to*.

* There is a limit of at least 40 new scratch orgs per day, but this is rarely a problem for most small-to-medium sized development groups, and you can get more if you need them.

How to resolve dependencies between features and how it is reflected in the respective sandboxes, too many merges which means way too much time going in to resolving merge conflicts

You should rarely, if ever have merge conflicts; if you do, there's something wrong with your branching strategy. We have a few merge conflicts every few months, not nearly as frequently as you imagine. We have a ton of branches, too: master, uat, qa, testing, experimental, feature, and hotfix branches. The important part is to always make sure your branches flow correctly. You'll want to do some research on proper branching strategies. Using DX also minimizes conflicts, because more of the metadata is broken out into smaller files (e.g. each field is now its own file).

How are features integrated and promoted up the environment chain ? Can the features be independently tested.

Yes, you can generally test them independently. There's several different ways to approach this, actually. First, you could branch out an experimental branch, merge the feature branch in to it, push it to a scratch org, make sure it works, and when you're satisfied, merge back into the parent branch and delete the experimental branch. If something goes wrong, you can delete the experimental branch, do additional work, then merge again until you're satisfied.

4
  • 2
    Depending on the edition, the daily/active scratch org limits are likely high enough to avoid issues.
    – David Reed
    Mar 25 '18 at 17:04
  • @DavidReed Thanks for the link. They've upped the limits quite significantly.
    – sfdcfox
    Mar 25 '18 at 19:45
  • @sfdcfox Thank you very much for your detailed response. Highly appreciate it. Unfortunately the doesn't seem to be ready to switch to DX yet... Does it mean that without switching to DX, it will be a futile attempt to apply feature branching ? Mar 26 '18 at 0:13
  • @BuffaloGrovian You can do it (we do this internally), but it's still relatively painful compared to actually being able to use the DX tools. We've been trying to migrate to DX for a few months now, but it's hard with a large code base (we have ~9800 artifacts...). I think mostly it's about learning how to properly use Git branching, and it really helps to have a tool like GearSet or AutoRabit to help deployments (you'll need to do some research to see if any particular tool might be right for you).
    – sfdcfox
    Mar 26 '18 at 0:40

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