Version 1
Our first CI/CD strategy was very basic; and for a simple reason, we didn’t have control of what SalesforceDX (SFDX) generated. The fear that I had was that we in the engineering community would start embracing the coded aspects of the Salesforce configuration and start to use cherry picking and end up in a broken state that would be difficult to work our way out of. After all, when you change a single field/object sometimes SFDX would come down with a whole host of files that were modified. Because of this the strategy was a one-way path:
Scratch/Devlopment -> Staging -> Pre-Production -> Production
Challenges with version 1
The largest challenge here is that you’re stuck between a rock and a hard place. On one hand your business owners want an extended period of time to validate functionality in Staging. On the other hand, everything ships from one instance to the next at the same time. So, if you have a promotion cadence of 1 week, that means the business owners have a week to test. But it also means that your urgently needed hotfix that impacts Production is over a week out, even after the code is written. It’s a sticky place to be, and ultimately we’re not sure where we’re going to end up on this strategy. Having a clearly defined cadence certainly helps, however, there are times where we promote changes faster than we want to push a critical piece of functionality.
Embrace an agile, fix-forward mentality. Complete development in small, meaningful chunks to avoid merge conflicts and accelerate review times.
Version 2
This next iteration is currently under debate. We want to keep version 1 mostly intact, but have a more cohesive strategy that allows cherry picking of hotfixes. Once we have that figured out and put a few miles on it then I’ll update this post.
Remaining General Challenges
Inability to accomplish automated destructive changes
One key challenge is that when using SFDX there is no such thing as an automated, destructive change. For example, if I delete the Products table/object in my scratch org and replace it with a Product Lines object then both objects will continue to exist in the Production instance. Deletes aren’t automatic, and deleting APEX classes is also something that requires manual, code-based intervention. It’s not a great scenario, however much like low code on Salesforce in general, it’s great, until it’s not. To be honest it’s a love/hate relationship and we’ve had our very painful moments. However, it’s also safe to say that without the low-code capabilities that Salesforce has provided we would not have been able to complete what we have in the time period we’ve already accomplished.
Change Control Strategy
If you don’t have a strategy to do Change Control, even for a low-code environment, you need to rectify that immediately. Regardless if it’s tracking the manual operations where you are deleting objects left behind, or keeping track of just who is changing what inside your configuration. This information is critical, even to a low-code world. This is actually in introduction to what I believe is the largest lack of informed visibility in the darker side of low-code, the world of lifecycle. More about that to come in the blog on lifecycle management.
Next Up – The Road to Low-Code | Will (and Should) They Come?