Manage Development, Staging and Production

Published 2026-10-07 · Updated 2026-10-07

Manage development, staging and production by defining each environment’s purpose, data and connections. Test an identifiable version with reviewed settings, then deploy and inspect its actual outcome rather than relying on a page opening.

Define each environment and how to identify it

List the environments that actually exist, rather than the ones you hope to have. Use development for ongoing work, staging for reviewing a release candidate and production for real use. Record each location, responsible person, active version and identification method. Give test environments a visible label so reviewers do not confuse them with the public application. If only a preview is available, explain what it allows you to try and what it cannot establish. Do not automatically treat it as a fully independent environment with separate resources.

Choose one review path, such as creating a service request, displaying it and changing its status. State where reviewers begin, which sample information they use and who checks the outcome. When working with Infera Agent, verify available preview, publishing and resource options before designing the environment plan. Do not assume a transfer or cloning button exists. If an independent environment is unavailable, design a limited trial using actual options and document its limits. Reviewers need to know where they are working and what their actions could affect.

• List actual environments and locations.
• Record purpose, owner and version.
• Describe preview and testing limits.

Review configuration and data before testing

Make a review list for each environment: data source, service destinations, return locations and team access. Inspect values where the project actually uses them, not in an old note. Configuration varies between deployments; environment variables can separate it from code according to the application design. Reference: https://www.12factor.net/config . Record each setting’s name, purpose and owner without copying secret values into the report. Check missing values and the resulting behavior before testing the full path. The list should guide inspection rather than claim correctness solely because someone completed its entries.

Prepare examples representing the needed states: a new request, an in progress request and a completed one, plus long text or missing information where relevant. Confirm the storage destination and the account that can see the records. Do not copy customer information just to make the test look realistic; carefully designed samples often suffice. If the path includes a message or external connection, state the intended destination and check what happened. A test label on the screen does not establish that every connection uses a test destination, so inspect the actual operation.

• Inspect the configuration actually used.
• Check storage and connection destinations.
• Prepare clearly defined sample cases.

Test a defined version and record differences

Tie review to an identifiable version or change reference. Environments may run different versions of the same project; reference: https://12factor.net/codebase . Define the requested change and its success criteria before trying it. For a service request, check one created record, visibility to the intended account and a status update without unrelated changes. Try missing input, navigation back and reopening the record. Save results with version and environment so feedback from a previous release is not mistaken for evidence about the latest one. Keep the tested case and its expected result together.

Compare factors that affect behavior in staging and production, and record meaningful differences. Keeping environments close reduces testing gaps; reference: https://www.12factor.net/dev-prod-parity . Do not describe them as identical without checking. Information, connections or users may differ, so identify what has not been tested realistically and what needs inspection during deployment. If the version changes during review, repeat affected cases and save the new outcome. An old success does not validate a new change merely because its name or appearance stayed similar. Resolve or explicitly record each important difference before proceeding.

• Record version and environment with results.
• Check the flow and stored outcome.
• Document differences and verification limits.

Deploy and inspect production afterward

Prepare a brief deployment record: intended version, reviewed settings, completed checks and person following up. Distinguish preparing the build, combining it with configuration and running it; reference: https://www.12factor.net/build-release-run . Use the project’s available deployment steps rather than assuming particular controls exist. After transfer, check location, version, essential path and stored outcome. An opening page does not prove the operation succeeded. Inspect user feedback, record state and associated connection destinations. Choose a suitable check that does not accidentally create an unwanted real request or external effect during verification.

Write what happens if a problem appears: who evaluates it, where evidence is found and how to contain its effect or return to a suitable version using project tools. Returning the application to an earlier version does not necessarily restore earlier data, so check compatibility with current records before returning. Separate affected record handling from the correction of future behavior. Record decisions, outcomes and follow up limits, then update the environment list. The team should know what currently runs and what needs observation, rather than treating deployment as an undocumented event dependent on one person’s memory.

• Check production version and essential path.
• Separate application return from data repair.
• Record decisions and follow up ownership.

Questions

Start free Templates