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: Adding a new pipeline

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': Atomic deployment template

Now you can add your server data: Atomic Deployment template configuration

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 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 /releases directory

The template creates two actions in the pipeline:

  1. 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

  2. An SSH action which performs the following tasks on your server:

    • copy the deploy-cache/ folder to the releases/$REVISION folder after the deployment
    • change the symbolic link current/ so that it points to releases/$REVISION
    • clear old releases – by default Buddy will keep the last 10 of them, which will let you easily perform a rollback if required

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. Adding environment 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. Atomic deployment configuration

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: Atomic deployment pipeline example

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.

See also