Learn about the actual costs of executing quick fixes in production and the critical 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 delivery structure. Organizations still execute quick hits directly into production despite having lower environment frameworks. This means having developer environments to build the requirements and a separate integration environment to test the functionality against broader systems, where applicable. A staging environment will collate all requirement functionality, and a UAT environment will serve as your pseudo-production environment for stakeholder testing and confirmation.
The Importance of Lower Environment Frameworks
Why does this matter?
Let’s say someone from one of your teams 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 accessing the field because the field contains sensitive data.
The Pitfalls of Quick Fixes in Production
In this scenario, what was initially raised as a defect request and seemingly remedied quickly will again become another defect. Why? When the lower environment scope gets pushed back to prod, the field-level security will 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 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 to follow environment management best practices for anyone looking to follow environment management best practices.
Synchronizing Functionality Across Environments
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 regardless of your environment. How is your organization delivering today? Do you have an environment management strategy currently in place?
The Consequences of Ignoring the Path to Production
I have seen deliveries fail the most because organizations do not follow the path to production. 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 production release, you should constantly refresh your lower environments. Doing so is one of the most accurate fits/gaps in discovering cohesive functionality. Too often, I have worked with clients who either have no path to production or are operating in unchecked chaos where every environment is so out of sync that every deployment is a disaster.
Constant Refresh: A Key Practice
But how do you guide your delivery teams to a successful path to production? Buying a new tool doesn’t always solve your challenges. Instead, focus on enforceable processes.
It would be best to do so whenever you develop new functionality in your developer org. Clearly capture any pre- and post-deployment steps, test your new functionality, submit it for peer review, and then promote it to the following environment. What does this look like in practice?
Build > test > peer review > deploy. Wash / Rinse / Repeat for every environment stage.
Although testing your scope in each environment may sound daunting, doing so will save your team 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, stakeholders will force their approaches onto you. Suppose you implement a solid process structure where you demonstrate code freeze guardrails between releases to allow for sandbox refreshing. In that case, you will quickly close the gap of opportunity to create many defects throughout your delivery and implementations.
Are you a Provar user looking for more software delivery leadership guidance and Salesforce testing tips, and are you looking to gain more best practices? Join our Provar Community, where we post weekly leadership resources.