Everyone agrees that continuous deployment helps accelerate innovation. However, Continuous Deployment (CD) today is synonymous with fragile homegrown solutions made of disjointed tools cobbled together with thousands of lines of imperative scripts. Avi Cavale walks you through the CD maturity model and demos an end to end continuous deployment with declarative pipelines for Docker applications.
As you know, we released our new implementation of continuous deployment pipelines last month. While our basic documentation is up to date, we believe that learning the new pipelines is best done with quick tutorials that demonstrate the power of CD and how easy it is to get started.
We have created a sample project and sample configuration to deploy the project to a test environment, create a release with semantic versioning, and deploy the project to production. The entire end to end scenario should take less than 30 mins to try out and while you won't learn every little trick, it will definitely make you comfortable with the configuration and how to set things up.
So read on and try it out!
In the previous part, we went over the steps of source code deployment to AWS Elastic Beanstalk using a simple Node.js app. We deployed the source code natively at first, then compared with deploying it through Shippable. The latter approach showed actions in the work flow executed automatically for you, by Shippable's unified CI/CD platform.
I'll take a similar approach for this part where we'll go through a deployment of a Docker container of a Node.js app to AWS Elastic Beanstalk. To fully understand this tutorial, complete the previous source code deployment to AWS Elastic Beanstalk first.
Containers. Continuous Integration. Microservices. These are among the leading buzzwords of modern application delivery.
There have been several requests on our support forum on how to customize environments to specific branches while running Continuous Integration (CI) builds for a repository that has multiple branches. In this tutorial, I'll go over a common scenario and review the multiple ways we can configure branch-specific actions during the CI build.
The scenario I use for this tutorial is, to pull a Docker image in the CI process and upon completion, use different tags for the branches when pushing the Docker image to Docker Hub. The Docker tags should be customized to the specific branch where the CI was processed and should include the build number. The final results of successful CI process tagging different branches looks as shown.