3

I'm looking for best practices for a SDLC workflow given the following scenario:

  • Team consists of a mix of point-and-click admins and developers
  • Project is based around CPQ or FSL where data is used as metadata (For example in CPQ, Product and Price Rules automate some functions and interact with code written)
  • Some team members will know git and SFDX's CLI, while others will not

We'd like to have a workflow setup where every team member works in their own sandbox but have the following struggles:

  • Ideally, we'd use git without pulling in everything into the git repo - however, we can't find a good way for point-and-click admins to add their changes without becoming proficient at git which seems like a huge overhead
  • With the project being so data dependent, it seems to rule out using scratch orgs and it's a struggle to develop against data that isn't there
  • Some of the code is also stored in records (for example, CPQ has a "Custom script" object that allows you to write Javascript plugins) that we haven't been able to figure out how to version
5
+50

Disclaimers: I am on the team at Salesforce.org responsible for building this free and open source toolchain, and I haven't worked on an FSL/CPQ project with it.

Salesforce.org's CumulusCI (CCI) hits several of your important points here, albeit not all of them. It's a build automation and CI tool oriented towards creating identical, repeatable scratch org builds for development, including use by admins.

Specifically, CCI can hit these points from your wishlist:

  • Build scratch orgs with a selection of managed packages plus in-house customizations for doing development and QA.
  • Interoperate seamlessly with Git version control (CCI comes with extensive automation for use in what we call CumulusCI Flow and GitHub).
  • Capture, persist, and load complex configuration data (sObjects) across scratch orgs and persistent sandboxes, storing the data in version control.
  • Assist in capturing declarative and code changes to version control.
  • Automate builds to production or staging environments (with MetaCI, below, or your CI system of choice, or manual operation).

Plus it's free, open source, configurable with simple YAML text files, extensible in Python, and used to build the Nonprofit Success Pack, Volunteers for Salesforce, EDA, and other major projects at SFDO.

Combining CCI with MetaCI, Salesforce.org's open source, continuous integration platform that runs on Heroku, helps to close - but does not entirely close - some of the needs of your point-and-click administrators. MetaCI provides a web interface for building scratch orgs so that those more comfortable with clicks need not use the command line for that purpose, in addition to all the build and workflow automation you'd expect from CI.

However, your admins would still need to use the command line, or get developer assistance to do so, while capturing their changes from scratch orgs.

3

This is what we do:

Talend:

For moving CPQ data(Product Rules, Custom Script etc) between environments, I created a ETL job in Talend and made it an executable jar file.

We have also a created ETL job in Talend to migrate some data(like Contacts, Accounts and etc..) from production and made it an executable jar file.

These executable jar files are shared with the team and they can run these executable jar files only into their dev sandboxes but not into QA,UAT,Stage and Prod environments.

Git:

We store most of our changes in Git so that environment can be recreated by deploying all the changes present in QA branch to a sandbox and that becomes QA environment(There are few manual steps needed though..)

Gearset:

Our Admins use Gearset to move the changes that they do to push from their sandbox to feature branch and pull request.

CI/CD:

We have CI/CD built using combination of Jenkins and Gearset to QA environment but for all higher environments(UAT,Stage and Prod) only Lead has merge permissions to deploy to UAT,Stage and Prod branches(and respective environments).

Sandboxes:

Our Admins refresh their sandboxes every two to four weeks from Production and deploy everything that is there in QA_Branch to the new sandbox and run Talend scripts to get CPQ and some test data.

NOTE: This would be a lot easier if Salesforce allows refreshing of Developer(or Developer Pro) Sandboxes from Full Sandbox(assuming QA,UAT and Stage are Full Sandboxes). Until Salesforce makes this feature available, I don't see a easy way of doing this.

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.