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 are still executing 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. 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 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.

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 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 practices for anyone looking to follow 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 production release, you should constantly refresh your lower environments. Doing so is one of the most accurate fits/gaps in discovering cohesive functionality. Too many times, 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 with each other that every deployment is 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 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 structure of process 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 and looking for more software delivery leadership guidance, Salesforce testing tips, and looking to gain more best practices? Join our Provar Community, where we post weekly leadership resources.