Continuous Deployment

Continuous Deployment is a strategy in which every change to code in the main branch of the repository (usually the 'master' branch) is automatically released onto the production server.

Please mind that implementing Continuous Deployment project requires the application to be thoroughly covered with tests and established work culture in the team.

Continuous Deployment pipeline

The basic requirement of Continuous deployment is version control. To begin with your deployment you need to add a project in Buddy and connect it to the repository from which you want to deploy. You can choose a GitHub, Bitbucket or GitLab repository, as well as any custom Git repository.

Creating a new projectCreating a new project

Once the project is synchronized, you can add the delivery pipeline. In order to deploy in a continuous manner, set the trigger mode to On events → Git push, and make sure the ref is pointing to the production branch:

Creating a new pipelineCreating a new pipeline

Pipelines can be also triggered manually and assigned to multiple branches with a wildcard. Read more about pipelines here.

After adding the pipeline, it's time for tests and deployment. Pipelines in Buddy are built of actions which perform specific tasks. For example, the pipeline below runs unit tests, performs a static code analysis using ESLint, and builds assets with Gulp. The next step is uploading files to an SFTP server and assets to an S3 bucket. Finally, Buddy sends information to a Slack channel that a new version has been deployed:

Pipeline examplePipeline example

Buddy features over 100 actions and integrations that you can use to build your pipeline: from builds and tests, to deployments, notifications, script executions, website monitoring, Android development, to Docker and Kubernetes orchestration.

Here is a pipeline that builds a Docker image from a Node application. The image is then tested and, if everything is fine, pushed to a Docker registry from which it is deployed to a Kubernetes cluster:

Docker Pipeline exampleDocker Pipeline example

Continuous Delivery pipeline

There is one thing that distinguishes Continuous Delivery from Continuous Deployment. In both approaches, changes are automatically tested, the build is automatically executed and both the deployment and the release are automated.

Continuous Deployment processContinuous Deployment process

The difference is that although in Continuous Delivery tests, builds and deployments run automatically, the release to Production must be approved manually:

Continuous Delivery processContinuous Delivery process

Continuous Integration pipeline

The idea behind Continuous Integration is very simple: all changes should be merged with the main branch and tested as quickly as possible. In fact, Continuous Integration is the backbone of Continuous Deployment – there is no point of automating deployment if the software hasn't been properly tested.

A CI pipeline should fulfill three key conditions:

  1. It should run automatically on every push to the repository
  2. It should thoroughly test every commit
  3. It should inform the committer or the team in case something goes wrong.

See also

Last modified on July 25, 2023


Not sure how to configure a pipeline for your process? Reach out on the live-chat or contact support

Get Started

Sign up for free and deploy your project in less than 10 minutes.