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.
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:
To learn more about trigger modes and branch settings, click here.
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
releases/ inside this path. Make sure that your server serves the application from the
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 points
releases/– contains the history of uploaded releases. For each version a directory with the name of the revision tag is created
deploy-cache/– used for storing new files during the deployment. Once the upload has finished, its contents are copied to a new directory in the
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 uploaded
An SSH action which performs the following tasks on your server:
- copy the
deploy-cache/folder to the
releases/$REVISIONfolder after the deployment
- change the symbolic link
current/so that it points to
- 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
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.