Building a deployment artifact in CI A deployment artifact is the complete tested output that will run on the server. Building it once reduces differences between a reviewed release and…

Deploying with a release directory and a controlled switch A release-directory workflow prepares new files separately before making them active. This reduces the time the public application spends with a mixture…

Giving a deployment server read-only Git repository access A deployment server usually needs to fetch a private repository, not modify it. A narrowly scoped deploy key or application credential limits what a…

Maintaining a deployment log and release identifier A concise release record connects an observed problem to the code, configuration and database changes that reached the server. It reduces guesswork…

Preventing simultaneous deployment jobs Two deployments changing the same environment can overwrite files, race migrations or restart each other’s processes. Give each environment a clear…

Protecting production secrets in CI jobs A deployment workflow can access powerful credentials. Limit each secret to the jobs and environments that need it, and treat build logs and artifacts…

Removing credentials accidentally committed to Git A committed secret should be treated as exposed to anyone who could access the repository or its copies. Removing the line from the latest commit does…

Rolling back application files without losing new user data Code recovery should preserve records and uploads created after the release unless a separately approved data recovery requires otherwise. Treat…

Setting up a staging branch deployment workflow A staging deployment should test the application without changing production data or sending real customer actions. Separate configuration and service…

Verifying a deployment with application smoke checks A smoke check confirms that the release’s essential user journeys work in the deployed environment. It should be small, meaningful and safe to repeat.…