In DeployHQ, you can setup atomic deployments to your servers to ensure that there is zero downtime during the actual deployment process.
You'll be able to find out useful information about how the process works and how to set it up below.
When you first run an atomic deployment to your server, DeployHQ will prepare 3 directories within your deployment path:
- cache (this will be created if you set up the cache strategy)
And one symlink:
That points to a folder within the releases directory, named as a timestamp from when you ran the associated deployment.
Your files will be uploaded to that directory, then once this process has finished, the current directory will be symlinked to that release. This is where your live app will be run from.
The current symlink will therefore look like so:
current -> releases/20190123120000
This will also happen in exactly the same way during any subsequent deployments, but because the symlink doesn't get created until after files are transferred, your site will continue to run in its previous state.
Additionally, if the deployment fails at any point before that time, the site will stay pointed to the last release, completely unaffected.
To start using Atomic deployments, you'll need to add a new server to your project which supports SSH access, with the ability to run POSIX operations (for both copying, and symlinking to release directories).
Just configure a new SSH server as normal, but then also enable the option for Zero-downtime deployments at the same time:
And choose your atomic deployment strategy. You can read more about that further down this guide.
Finally, you'll be able to control how many releases are kept on your server. This is set to 3 by default (including the latest that is symlinked from current), but you can raise or lower the number as required.
Please note that each release will take up additional disk space on your server so we recommend keeping the number as low as possible.
Once you've added your server, you'll need to run a full deployment as normal on the first deployment, so that the correct directories are prepared and a full copy of your site is uploaded to it.
After that, only your changes will be uploaded but onto a new, full copy of the last release on every subsequent deployment.
Atomic deployments are fully supported for server groups too, and with this in mind, you can also now set up different deployment strategies when configuring a server group.
You'll see two options, sequential or parallel when you're setting up a group:
Sequential will deploy to each server in turn, whereas parallel will deploy to each server at the same time (up to 3 at once), ensuring that each step is completed on all servers before moving onto the next step.
Therefore, when using atomic deployments with a server group it is strongly recommended that you use the parallel strategy.
When you first configure your server, you'll see an option to set a "Atomic deployment strategy". This works one of two ways:
During each deployment, the last release directory will be copied to a new release directory, and all changes will be uploaded directly there. The current symlink will then be switched to the new release folder.
This means that any changes you make to the release directory outside of the deployment process will be copied over.
During each deployment, a cache directory that contains a clean copy of your repository only will be updated with the latest changes from the deployment. This will then be copied across to a new release folder before the current symlink is switched.
This means that any changes you make to the release directory outside of the deployment will not be copied over.
Some useful information about the process:
- DeployHQ will only keep 3 releases (the current, and 2 previous ones) on your server, and automatically tidy up older releases during the deployment process.
- At present, atomic deployments are only supported on SSH servers, when you first add a new server to your project.
- You can use the shared directory to keep files in that you want to be persisted across all releases, such as user uploads or config files.