Zero downtime deployment
Deployment automation with pipelines aims at eliminating manual errors and shortening the application downtime. Pipelines in Buddy let you easily configure zero downtime deployment.
The actual mechanism behind zero-downtime deployment is that first the files are uploaded to another directory on the server, and only when the deployment has finished the link to the application is swapped.
Configuration
To begin with your deployment you need to add a project and connect it to the repository from which you want to deploy (e.g. GitHub or Bitbucket). Then you can add your first pipeline and specify when it should run:
The next step is adding actions to the pipeline. Switch to the Templates section and choose Atomic Deployment:
Now you can add your server data:
When you add the remote path to the configuration, Buddy creates folders current/
, deploy-cache/
and releases/
inside this path. Make sure that your server serves the application from the $REMOTE_PATH/current
folder.
How zero downtime deployments work
While adding the Atomic Deployment to your pipeline, Buddy creates 3 folders on your server in the provided path:
current/
– a symbolic link to the current version in the releases directory to which your web server pointsreleases/
– contains the history of uploaded releases. For each version a directory with the name of the revision tag is createddeploy-cache/
– used for storing new files during the deployment. Once the upload has finished, its contents are copied to a new directory in the/releases
directory
The template creates two actions in the pipeline:
An SFTP action which uploads the changes to the
deploy-cache/
folder. The deployment is based on changesets, which means that only files that changed since the last deployment are uploadedAn SSH action which performs the following tasks on your server:
- copy the
deploy-cache/
folder to thereleases/$REVISION
folder after the deployment - change the symbolic link
current/
so that it points toreleases/$REVISION
- clear old releases – by default Buddy will keep the last 10 of them, which will let you easily perform a rollback if required
- copy the
Environment variables
All access data that you provide during the Atomic deployment configuration is saved in the pipeline as encrypted environment variables. These variables are used in both actions, so in case you need to change the access data, you'll only have to edit the variables.
Editing atomic deployment
Atomic deployments in Buddy can be easily edited. The template's logic is hardcoded in the SSH action. There you can manage previous versions, configure rollbacks, and set the folder to the proper release. The scripts can be freely modified by defining your own rules.
The pipeline in which atomic deployment is made can be modified as well. E.g. you can run builds and application tests (compile css, js files) before the deployment. After the deployment you can also send a Slack message about a new version available:
In general, Buddy features more than a 100 dedicated actions to use while defining your own pipeline – just about anything to get the job done.