2

I have 50 post-deployment steps and I need to perform on UAT, Pre_Production, and Production. Is there any way that we can automate the steps?

1
  • what kind of postdeployment steps? few config records or profile fls? Apr 14 '20 at 17:37
1

Large numbers of post-deployment steps usually reflect a weak source control or change control program. Unfortunately, that means that the solution is architectural: there will be a need for a significant investment in product, and possibly tooling as well, to eliminate these steps.

For example, if post-deployment steps include making manual changes to Page Layouts, the solution is to make those changes as part of development, version control them, and deploy them to production alongside other application changes.

However, if the organization is used to being able to make page layout changes directly in Production, this could be a significant, and potentially disruptive, shift.

Many tools, both commercial and otherwise, are available to facilitate a comprehensive source control/continuous integration/continuous deployment strategy. It's essentially always going to be a fact, though, that none of these tools will provide a push-button fix to correct a specific problem, like this one, that is representative of a fundamental weakness in architecture. You're going to have to make some level of change to your development strategy, org pipeline, source control, etc., in order to achieve a genuine fix.

4
  • I do agree most can be scripted or part of the deployment package, but I do find few things not available for source control or in fact deployable(Omnichannel, chatbots amongst the few). Plus deploying profile is nightmarish. it's impossible to resolve conflicts in 10k+ line profiles. it's better to do these as post-deployment steps by an admin. Selenium or any automation tools do help. If there is 1 thing that I want SF Santa is the ability to split profiles in a different subfolder like they did for object in dx. Apr 14 '20 at 17:45
  • Good points. For undeployable metadata, orgs have to make a call: are you going to be deploying this once, or many times as part of a process? If the latter, it calls for automation with Selenium or Robot or similar. I just hate Profiles. Permission Set Groups are the future.
    – David Reed
    Apr 14 '20 at 17:49
  • We are trying to move toward the permission set group, the experience has been a quite nice, less hassle. But it might not be fully functional as default record types, page layout, lightning Flexi pages assignment are still profile-based. We still have to create different profiles just for page layouts and lightning page. Once SF finds something to replace, I believe transition to PSG would be smooth. Apr 14 '20 at 17:59
  • 1
    Yeah, the model I'm seeing so far is skeleton Profile (with no FLS) to do assignments, and then the PSG holds everything else.
    – David Reed
    Apr 14 '20 at 18:13
1

We've used the SandboxPostCopy interface to create a script that runs after the sandbox is created.

Documentation: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_System_SandboxPostCopy.htm

One potential gotcha: the script runs as the "Automated User". So make sure any test records you create have a specified owner.

Some things can't be updated easily via apex. I'd be interesting in knowing what specific steps are being done. But in any case, you may be able to cut your 50 steps down to <5.

0

I doubt that any product out there provides one click solution to automate the post deployment steps. You could explore paid solutions likes AutoRABIT, BlueCanvas etc., but they won't provide complete automation either. If the post deployment steps are something that can be performed by APEX or LIGHTNING, then you could develop custom solutions.

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.