Learn about the real costs of executing quick fixes in production and the key deployment strategies to help guide your software delivery teams to a successful path to production.
Recently, I spoke at a Salesforce conference, and was surprised to learn how many organizations are still following a rogue structure of delivery. Organizations are still executing quick hits directly into production despite having lower environment frameworks in place. Meaning to have developer environments in place to build the requirements, a separate integration environment to test the functionality against broader systems, where applicable. Staging environment to collate all requirement functionality, and a UAT environment to serve as your pseudo-production environment for stakeholder testing and confirmation.
Why does this matter?
Let’s say someone from one of your team executes a quick hit fix in production to calm a noisy stakeholder by adjusting the field level security on an object. Unbeknownst to the executioner, the upcoming scope release changes the same field level security to prevent that profile from having access to the field because the field contains sensitive data.
In this scenario, what was initially raised as a defect request and seemingly remedied quickly will once again become another defect. Why? Because when the lower environment scope gets pushed back to prod, the field level security will once again be updated, thus making it unavailable for the reporting user.
On the surface, it may seem to some this is an unlikely scenario, but in fact it occurs all too often. The path to production is not just about keeping your development in lower environments, but also about keeping functionality synchronous across all your environments. I would recommend that any leaders also review this resource for following environment management best practiceFor anyone looking also follows environment management best practices.
Think of the best path to production as you would a conveyor system. Start with your developer org > move it to integration org (if you have one) > move it to QA staging > UAT > production > refresh production so all lower environments are synchronous. Wash > rinse > repeat. When leaders follow this process, functionality will behave the same no matter what environment you’re in. How is your organization delivering today? Do you have an environment management strategy currently in place?
Where I have seen deliveries fail the most is by organizations not following the path to production. More-so, once they’ve delivered to production, they immediately push their developers to grab the next batch of scope where they continue building. This is where you should hit the brakes.
After every release to production, you should always refresh your lower environments. Doing so is one of the most accurate fit/gaps of discovering cohesive functionality. Too many times I have worked with clients who either have no path to production at all or frankly, they are operating in unchecked chaos where every environment is so out of sync with each other that every deployment was a disaster.
But how do you guide your delivery teams to a successful path to production? Buying a new tool isn’t always going to solve your challenges. Instead focus on enforceable processes.
Whenever you develop new functionality, you should do so in your developer org. Capture any pre & post deployment steps clearly, test your new functionality, submit for peer review, and then promote it to the next environment. What does this look like in practice?
Build > test > peer review > deploy. Wash / Rinse / Repeat for every environment stage.
Although the sound of testing your scope in each environment may sound daunting, doing so will save your team’s costly headaches during deployment in the 11th hour.
While velocity is key in any Salesforce SDLC engagement, so is efficiency and practicing proper environment maintenance. If you don’t have a system in place, stakeholders will force their own approaches onto you. If you implement a solid structure of process where you demonstrate code freeze guardrails between releases to allow for sandbox refreshing, you will quickly close the gap of opportunity to create many defects throughout your delivery and implementations.
Are you a Provar user and looking for more software delivery leadership guidance, Salesforce testing tips, and/or looking to gain more best practices? Join our Provar Community where we post weekly leadership resources.