Dev, Test and Prod Environment Best Practices: Ten Steps in Order, With Owners

Dev, test and prod environment best practices work best as an order of work. Find what differs, agree a baseline, put it in version control and build from one definition. Then keep settings apart, review each change, refresh test data safely, catch differences, retire hand fixes and name owners. Across dev, test and production environments, each stage has one job. Development is where people build, test is where the team checks behavior, and production serves customers.

This guide covers what to do and in what order. For how environments move apart over time, read our explainer first. The target state for matching development, test and production environments is on the use case page.

Ten Dev, Test and Prod Environment Best Practices in Order

The ten steps run in three groups: record what exists, build from one source, then keep the stages matched. In a team that follows DevOps practice, each stage can also answer one release question. Development asks whether the code runs, and test asks whether it behaves. Staging asks whether it is safe to promote, while production shows whether it works for users.

The order matters because Steps 4 to 10 depend on the record built in Steps 1 to 3. Without that record, a later comparison has nothing to compare against. The leads in the last column are our suggestions.

Dev, Test and Prod Environment Best Practices, Steps 1 to 3: Inventory and Baseline

Dev, test and prod environment best practices start with a record of what is true now, before any server changes.

Step 1 is an inventory. For each stage, list the operating system, runtime and dependency versions, network rules, settings values and data. Cover these as well as the application code. When the layers under the code differ, a pass in test says less about production. Write each difference as its own row, for example “test runs an older database version than production”. Then add who found it and when. At this point the list only records facts, and deciding which differences are acceptable comes later.

Step 2 turns that list into a baseline. NIST’s guide to configuration management describes a baseline configuration as a set of specifications that has been formally reviewed and agreed at a point in time. After that, it changes only through change control. In Signisys’s working view, that means one written description of each stage, signed off by the people who run it. When stages share one agreed baseline, a fault tied to one stage’s setup is more likely to surface in test than at go-live.

Step 3 puts the baseline and every configuration file in version control. Each change then carries an author, a date and a reason. Anyone can also see how a stage looked last month. We recommend keeping the baseline in the same repository as the code that depends on it. That way, a change to either one is reviewed in the same place, by the same people.

Steps 4 and 5: One Definition, Settings Kept Apart

Steps 4 and 5 turn the baseline into working stages. Every stage comes from one definition, and only the values that should differ live outside it.

Step 4 builds development, test, staging and production from the same definition. That definition is written as code and kept in the repository from Step 3. Size and count may change by stage, while the shape stays the same. When a stage needs something new, the change goes into the definition first and then reaches each stage in turn. This guide leaves out the provisioning steps themselves, which have their own walkthrough.

Step 5 keeps settings apart from code. The Twelve-Factor App’s page on config defines config as everything likely to vary between deploys, such as handles to the database and credentials for outside services. It also asks for a strict split between config and code. In Signisys’s working view, the aim is that one tested build moves from test to production, while each stage supplies its own settings. If the code is rebuilt for each stage, production can end up running a build the testers did not see.

Give each stage its own service identities as well. Test jobs should run under accounts with no rights in production, and production accounts should have no use outside production. A test job that misbehaves then holds no rights in production.

What Stays the Same and What May Differ Between Stages

Matched stages still differ in places. Each area either stays the same or may differ on purpose, and someone checks it either way.

The Twelve-Factor App’s page on dev/prod parity warns that different backing services in development and production can let tested code fail in production. For that reason, the database type sits in the “same” column below. This table applies the dev, test and prod environment best practices from Steps 2 and 8, area by area.

Differences Outside the Table

We recommend that any difference outside this table needs the baseline owner’s written approval. Otherwise, it is hard to tell a planned difference from an accident.

Dev, Test and Prod Environment Best Practices, Steps 6 and 7: Review and Test Data

Under dev, test and prod environment best practices, every change gets checked before it reaches a stage. The data in test also gets the same care.

Step 6 is review. Each change to the definition or the settings goes through review before it applies. The reviewer is someone other than the author. Automated tests run on the change too. When a test fails, the change stops and does not move on to the next stage. For production, name the reviewer in advance. Then an urgent change does not wait while people work out who may approve it.

Access also narrows on the way to production. A wide group of engineers may change development, fewer may change test or staging, and only a small named group may change production. Write that rule into the review step itself.

Step 7 refreshes test data on a schedule. Use masked copies of production data, synthetic data, or a mix, chosen by what the privacy rules allow. In addition, keep each stage on its own database.

Before each refresh, check the copy against the data protection rules that apply to it. For a firm in India, that means the Indian rules on personal data. For a firm in the GCC, the rules of each country where the data is collected or held may apply. A group with offices in Bengaluru, Dubai and Riyadh may face a different rule for each copy. In that case, ask legal or compliance to approve the masking method once, and then record each refresh against it.

Steps 8 and 9: Catch Differences Early, Retire Hand Fixes

Steps 8 and 9 keep the stages matched after the first clean build, when small changes start to pile up.

Step 8 compares each live stage with the definition on a schedule. Run the comparison automatically where you can, and send each difference to the stage owner. The kinds of tool that can run it, from scripts to a self-service platform, are compared in a guide matched to stage, skills and audit needs. Agree beforehand what happens to a difference: it goes into the definition through review, or it is reversed. We recommend a weekly comparison for staging and production to start with. Adjust it later to how frequently those stages change. A difference found this way tends to be easier to trace than one found during a release. The change is more recent, and the person who made it is more likely to remember why.

Step 9 retires hand fixes. A production incident can call for a change made by hand, at speed. Each such fix gets a follow-up ticket before the incident closes, and the ticket has four parts.

Until the ticket closes, the definition and production disagree, and the next build from the definition would undo the fix. For example, an engineer might raise a connection limit on a production database late at night during a festival sale. The next morning, a ticket should carry that change back through development and test. The engineer’s extra access should also end.

Dev, Test and Prod Environment Best Practices, Step 10: Owners for Each Stage

Dev, test and prod environment best practices hold up only while someone owns each stage. Step 10 names those people. The table below sets out our recommended owners as roles, so your own titles may differ.

We recommend a second trained person for each stage as well. Then a holiday or a resignation does not leave a stage without an owner. Write the names next to the roles, and update them whenever people change jobs. Once the stages run, review them against a score sheet with one mark per stage for each check.

Four Set-Up Mistakes and the Step That Prevents Each

These four mistakes come from Signisys’s working view of set-up work. Each one has a step above that guards against it.

1. Starting the build before the inventory exists. The new definition can then copy whatever one stage happens to hold, faults included. Step 1 comes first for that reason.
2. Treating every difference as a fault. A team that removes all differences can strip out planned ones, such as masked test data or narrower production access. The same-or-differ table sorts them first.
3. Closing the incident while the emergency change lives only in production. The next build from the definition would then reverse it. Step 9 keeps the ticket open until the change is in the definition.
4. Letting the same engineer change, review and approve. Then nobody else may know the stage, and the review adds little. Step 10 splits those roles and adds a second person.

Signisys provides DevOps and IT automation services and infrastructure as code work. Keep that in mind when you weigh the advice here, as it comes from a firm that sells this work. For help planning this order across your own estate, a consultation is the place to start. No charge, with a fixed scope.

Dev, Test and Prod Environment Best Practices FAQ