ShippedStaging and production
Give changes a place to prove themselves before customers use them. Keep testing configuration separate from the application people rely on.
Separate configuration and data
Run staging with its own resource bindings, secrets, and public address. The same application code can use different databases and external integrations in each environment. That separation lets you test a new release without pointing a test process at production records or giving it credentials that can contact real customers.
Check the complete application
Test more than the home page before a release. Verify login, database changes, file uploads, background jobs, and integration callbacks in the target environment. Use realistic but appropriate test data and destinations. A successful build confirms that code can be packaged; a useful staging check confirms that the connected application behaves as intended.
Make promotion a deliberate release
Review the release and production configuration before deploying a change to customers. Staging and production can have different capacity, domains, and usage, so passing a staging check is not permission to reuse every setting unchanged. Keep compatible recovery options available and account for each environment’s resources when planning the project’s spending.
A little more detail
Questions about Staging and production?
Can staging share the production database?
Use separate data resources for normal testing. Sharing a writable production database lets test code change real records and weakens the isolation you expect from having a staging environment.
Are staging resources free because they are not production?
Resources in each environment contribute to usage according to the selected service rates. Choose staging capacity intentionally and include it in your project’s budget.
From your workspace to the web