The Unicorn blog
Make your next release a repeatable process
Make the release identifiable
A release should refer to a specific commit and its dependency lock file. Build and validate that version so everyone can trace what changed and reproduce the same application.
Check before changing production
Validate dependencies and custom code, then test on a suitable staging environment. Confirm that the hosting runtime matches the application requirements and that the deployment account can access only what it needs.
Treat data as part of the release
Take a database backup before applying updates and keep it outside the public web directory. Know which commands change the database and how configuration changes will affect the site.
Make failure visible
Stop deployment when a required step fails. Keep logs, record which release was attempted, and check the application after the release. A successful file transfer alone does not mean a successful deployment.
Write down recovery steps
Document how to restore code, configuration, and the matching database backup. Test recovery on a non-production environment and decide who is responsible for verifying the site after a rollback.
Have a project in mind?
We can help turn the next step into a practical plan. Talk to Unicorn Digitech.