Collaborative Confidence: Empowering Teams for Seamless Deployments and Cross-Departmental Success

At the start of any new product, the focus is quickly getting stuff in front of customers. The usual workflow tends to be:

• Write code and push it to some test environment
• Test the code on the test environment
• Push the code in front of real users in a production environment

As your organization grows, so will your requirements, and this workflow will have some drawbacks.

Deployments don’t always go flawlessly.

I’ve caused many problems trying to deploy new functionality, and the reason is always something different — missing permissions, missing secrets, services being deployed in the wrong order, etc.

The bigger the functionality, the bigger the risk that something goes wrong when deploying.

Production differs from other environments.

The bigger your product, the bigger your production environment. Keeping an exact duplicate environment on staging is not fiscally responsible. The main differences I’ve seen are:

• The data in production differs from the staging environment
• The staging environment runs in a single region, while the production environment has multiple regions
• The staging environment machines are scaled down to a single instance
• The staging environment machines are less powerful than the production ones.

With these changes in mind, functionality that works on staging might not always work in production.

Timing matters

With larger organizations, it’s no longer just about shipping code; it’s about collaborating on feature releases with other departments.

When pushing changes to end users, you have to think about more than just the feature, e.g.,

• Is customer service aware of the functionality and can assist users with questions?
• Is the operational team aware of how the functionality works and how to use it?
• Is the marketing team ready to market the new feature?

It’s time to decouple deployments from releasing

With all these challenges in front of us, it becomes clear we need to separate pushing code to production and releasing functionality to customers.

Feature flags are a great way of achieving this. They are nothing fancy; essentially, they are just if statements around your code.

if (featureFlags.isNewRegistartionFlowEnabled) {
  // new registration flow
} else {
  // old registration flow
}

The feature flag system itself is a bit more advanced — it’s not just booleans you flip on and off; instead, you should support a wide range of functionality:

• User targeting (enabling the feature for certain users only, e.g., testers who do a final sanity check on production)
• Geospatial targeting (enabling the feature in certain regions)
• Percentage-based releasing (enabling the feature only to a certain amount of users)

I would not recommend building a feature flag system, but evaluate if one of the existing SaaS platforms works for you — I would check out LaunchDarkly.

In conclusion, deploying new functionality in development can be a complex process, especially as organizations grow and requirements evolve. By acknowledging the potential pitfalls of traditional deployment workflows and recognizing the unique challenges posed by production environments, we can proactively address issues and ensure a smoother deployment experience. Collaboration with other departments, such as customer service, operations, and marketing, becomes essential to maximize the impact of feature releases. Decoupling deployments from releasing through the use of feature flags provides a powerful solution, allowing for controlled feature availability and targeted releases. Leveraging existing SaaS platforms like LaunchDarkly can further streamline the implementation of feature flags. With a focus on collaboration, strategic planning, and the adoption of modern deployment practices, teams can deploy new functionality with confidence, empowering their organizations to deliver exceptional experiences to their customers.