Everything works in the preview, and the client has approved the changes. Production, however, has its own data, accounts and integrations. Treat publishing as a separate task with a defined scope and a way of checking the result.
Write down what is to be deployed
In the release context, specify the code version. Check whether it needs database migrations, new settings or additional services. Prepare a list of steps in the order they will be carried out. Each item should have a simple way of confirming that it worked.
Protect the data that already exists
Since the development copy was created, new orders and accounts may have appeared in production. Moving the whole test database would wipe out that state. Work out which changes concern the structure, which the configuration and which the code, and prepare a suitable way to deploy them.
Make a backup of the current environment. Also decide how to roll back the change if a problem appears. Going back to the previous code does not always mean the database returns to a consistent state.
Check the production configuration
Connect the target domain and HTTPS through the panel. Verify the application’s public address, the database connection details, email sending and integration keys. A test mode for payments or debugging may be needed in the working environment, but it should not end up in production by accident.
Keep a separate development environment. Develop the next tasks there instead of experimenting on the application that serves users.
Check the whole user scenario
After publishing, open the application under the correct domain. Test logging in, the form and saving data, as well as the integrations affected by the change. Check the logs. A running container and an HTTP response do not yet confirm that the whole process works correctly.
Record the date, the deployed version and the test result. In Contextadmin, you can continue to handle backups and uptime checks. At the next release, this record will help you establish what state is running in production.