Continuous Deployment pipeline
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.
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 every push, and make sure the ref is pointing to the production branch:
Pipelines can be also triggered manually and assigned to multiple branches with a wildcard. You can 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:
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:
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.
The difference is that although in Continuous Delivery tests, builds and deployments run automatically, the release to Production must be approved manually:
To learn how to properly configure a Continuous Delivery pipeline, check out this article.
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:
- It should run automatically on every push to the repository
- It should thoroughly test every commit
- It should inform the committer or the team in case something goes wrong
You can read how to create a Continuous Integration pipeline in Buddy here.