If we all had our way in the world of development, everything from new software to features and apps would be flawless the moment they are released from the development environment and into the production environment.

That means no bugs, no latency issues, no weird errors—just smooth sailing from the outset…until it’s time for the next release.

Unfortunately, that’s not how things work. Until that day of instant perfection arrives (hint: it’s never happening), we’ll have to rely on the various stages in the development pipeline that leads to the production environment. In this post, we'll talk about production environments, and give a quick refresher on some of their capabilities.

What is a production environment?

A production environment is a real-time setting where you push the latest versions of software, products, or updates into live, usable operation for the intended end users. This environment serves as the active, operational space where users can access, experience, and interact with the software in its most current form.

A common example of this would be a company updating a new version of their app and making it live for all users. The production environment essentially hosts the new app so that end users can use it.

Production environment vs. test environment or staging environment

Unlike testing or staging environments (which simulate real-world conditions), the production environment deals with real user data, traffic, and interactions. This makes it the most important and sensitive environment in the software development and deployment process because any issues here directly impact users and the business.

A test environment provides engineers with a place to execute more complex and time-consuming tests for new code using both automation and non-automated techniques. Testers can also create multiple environments for parallel testing if needed. The testing environment is typically focused on individual components instead of the new application as a whole, which includes testing compatibility between old and new code and the overall performance of the system.

The staging environment can be viewed as a sort of behind-the-scenes, pre-production environment where a new release can be tinkered with and tested before going live. These artificial environments are created to mirror the production environment as closely as possible so developers can run the new release and observe it will potentially perform in the production environment before the rollout. 

Some of the tests commonly run in a staging environment include:

• Unit Testing - determines whether individual functions or units are working as intended and checks the smallest unit of code that can be logically isolated.
• Regression Testing - confirms that all previous features and functionality included in the new release still work as expected.
• Integration Testing - tests all software dependencies and all software modules together as a single group to evaluate system functionality and compliance. 
• Chaos Testing - helps provide a better sense of how the new software or app will hold up under different types of chaotic conditions, which helps the final product to be much more resilient.

What can you do in a production environment?

Although testing was once reserved mainly for staging environments, feature flags enable developers to perform various tests and checks in production thanks to the ability to instantly roll something back if there’s an issue (more on this later).

And since the production environment is the real thing, testing in a production environment yields better releases because you can do things like gathering user data and feedback and uncovering bugs that wouldn’t otherwise be apparent in an artificial staging environment. 

Here are some examples of what you can perform in a production environment:

1. A/B testing
2. Canary testing
3. Application monitoring and performance testing
4. User acceptance testing (UAT)

​​1. A/B testing

A/B testing involves comparing two different versions of the same release. For example, let’s say you have a new version of an app that needs testing. In an A/B test, you would push the new version of the app to one group while the other group receives the old (current) version. You can then observe and compare user data and behavior between the two app versions, which often provides valuable insights while also uncovering any issues that need to be addressed or improved upon. 

2. Canary testing

Canary testing involves rolling out a new release to a small percentage of users so you can see how they respond. That way, if they respond unfavorably or experience any issues with the new release, only a small percentage are affected rather than the entire user base. 

3. Application monitoring and performance testing 

Testing is not just about features and functionality; you also need to test how the new release performs and handles requests from users. With real-time application monitoring and performance testing within a production environment, you can determine if the app is performing poorly in a certain market due to factors like bandwidth and connectivity. You can also run load tests and stress tests to see how a release behaves when there are spikes in production traffic.

4. User Acceptance Testing (UAT)

UAT involves analyzing the application to ensure it can reliably handle various user challenges while performing and functioning as intended (and promised). 

Although UAT was once generally performed before the application hit the actual production environment, many DevOps teams now conduct UAT within it. This newer approach enables teams to test in small phases to groups of love users, thus shortening the production cycle.

How do feature flags make production testing safer?

A feature flag (sometimes referred to as a feature toggle) is a software development process used to enable or disable specific functionalities without the need to deploy code. By wrapping a feature in a flag, you can deploy them to the production environment without making them visible to all users.

Once the flag is live in production, test engineers or software engineers can be provided access to run tests or experiments like the ones listed above. If they identify an issue of any sort, the flag can be toggled off to instantly roll back the problematic feature and prevent it from reaching live end users. 

Put simply, feature flags are essential to test in production safely.

Example: Let's say an e-commerce company wants to test a new checkout process. They can wrap this feature in a flag, deploy it to production, but only enable it for internal testers initially. If any issues arise, they can instantly toggle off the flag, reverting to the old checkout process without any code deployment.

Safely test in production with LaunchDarkly

LaunchDarky’s feature management platform lets your development team quickly create and manage feature flags when testing code changes in a production environment. It gives them a seamless, low-risk way to test changes in production at a high frequency (and on a large scale with several layers of redundancy).

Ready to take the stress out of releases and embrace Progressive Delivery? Request a demo today and see see how LaunchDarkly can transform your development process.

Want to dive deeper? Learn more about feature management and how it can revolutionize your approach to software development and deployment.