Continuous Delivery is mainly related with the DevOps movement and the practice of continuous deployment. There are many case studies that fall into this sweet spot. If you want to see more companies talk about their journey, check out the videos from the DevOps Enterprise Summit. It’s important to note that continuous delivery has been widely adopted by many web companies, the techniques described in this article can be used in all sorts of domains—essentially, anywhere where your software development capability is considered as a strategic asset.
CASE STUDY
Like many companies, “Company A” has also used the cloud since day one. The company has always used the cloud as a flexible way to spin up the servers and to store the data. The targets set by the company leadership were to improve developer productivity by a factor of 10, so as to get material off the critical path for product development and can reduce the expenses. The company has three high-level goals:
Creating a single platform to support all the devices.
Increasing the quality and reducing the amount of stabilization required prior to release.
Reducing the amount of time spent on planning.
The key elements in achieving these goals was implementing continuous delivery, with a particular focus on:
The practice of continuous integration.
Significant investment in test automation.
Creating a hardware simulator so that tests could be run on a virtual platform
THE BENEFITS
Developers now have consistent environments in which deploy code for the company’s applications. By using Amazon Cloud, the team has saved money and improved the end-user experience. With Amazon Cloud the company has better access to data, more agile, and they can get feedback on product performance in days
A pipeline helps the user to automate the steps in their software delivery process, such as commencing automatic builds and then deploying to Amazon EC2 instances. The user will be using AWS CodePipeline, a service that builds, tests, and deploys the code every time there is a code change, based on the release process models which the user defines. Use CodePipeline to orchestrate each step in the release process. In this article, we will show you how to create a simple pipeline that pulls code from a source repository and automatically deploys it into an Amazon EC2 instance.
AWS CODEPIPELINE
AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release the user’s software. A developer can quickly model and configure the different stages of a software release process. AWS CodePipeline automates the steps required to release the user’s software changes continuously.
HOW TO GET STARTED WITH AWS CODEPIPELINE
AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release the user’s software. A developer can quickly model and configure the different stages of a software release process. AWS CodePipeline automates the steps required to release the user’s software changes continuously.
Continuous Delivery and Integration with AWS CodePipeline
AWS CodePipeline is a continuous delivery service that automates the building, testing, and deployment of the user’s software into production.
Continuous delivery is a software development methodology where the release process is automated. Every software change is automatically built, tested, and deployed to production. Before the final push to production, a developer, an automated test, or a business rule decides when the final push should occur. Though every successful software change can be immediately released to production with continuous delivery, not all changes need to be released immediately.
Continuous integration is a software development practice where team members use a version control system and integrate their work frequently to the same location, such as a master branch. Each change is built and verified by means of tests and other verifications in order to detect any integration errors as speedily as possible. Continuous integration is focused on automatically building and testing code, as compared to continuous delivery, which automates the entire software release process up to production.
HOW ACTUALLY THE AWS CODEPIPELINE WORKS?
AWS CodePipeline helps the user to create and manage their release process workflow with pipelines. A pipeline is a workflow construct which describes how software changes go through a release process. A user can create as many pipelines as they need within the limits of AWS and AWS CodePipeline, as described in Limits.
The following diagram and accompanying descriptions introduce you to some of the terms unique to AWS CodePipeline and how these concepts relate to each other:
When the user creates the first pipeline using the console, AWS CodePipeline creates a single Amazon S3 bucket in the same region as the pipeline to store items for all pipelines in that region associated with the user’s account. Every time the user creates another pipeline within that region in the console, AWS CodePipeline creates a folder in that bucket for that pipeline and uses that folder to store artifacts for the user’s pipeline as the automated release process runs. This bucket is named as codepipeline-region-1234567EXAMPLE, where a region is the AWS region in which the user creates the pipeline, and 1234567EXAMPLE is a ten-digit random number that ensures the bucket name is unique.
If the user creates a pipeline using the AWS CLI, the user can choose any Amazon S3 bucket to store the artifacts for that pipeline, as long as that bucket is in the same region as the pipeline.
AWS CodePipeline breaks up the workflow into a series of stages. For instance, there might be a build stage, where the code is built and tests are run. There are also deployment stages, where code updates are deployed to run-time environments. The user can configure multiple parallel deployments to different environments in the same deployment stage. Also, the user can label each stage in the release process for better tracking, control, and reporting.
Every stage contains at least one action, which is some kind of task performed on the artifact in that stage. Pipeline actions occur in a specified order or in sequence, as determined in the configuration of the stage. For instance, a beta stage might contain a deploy action, which deploys code to one or more staging servers. You can configure a stage with a single action to start, and then add additional actions to that stage as needed.
RUNNING A PIPELINE
A pipeline starts automatically as soon as it is created. The pipeline might go to pause while waiting for the events, such as the start of the next action in a sequence, but it is still running. When the pipeline completes the processing of a revision, it will wait until the next revision occurs in a source location as defined in the pipeline. As soon as a change is identified in a source location, the pipeline will begin running it through its stages and actions.
The user cannot manually stop a pipeline after it has been created, but you can disable transitions between stages to prevent stages and actions from running or adding an approval action to the pipeline to pause the execution until the action is manually approved. To assure a pipeline does not run, the user can also delete a pipeline or edit the actions in a source stage to point to a source location where no changes are being made. If the user deletes a pipeline for this purpose, make sure that a developer should have a copy of its JSON structure first. That way the developer can easily restore the pipeline when they want to re-create it.
“Continuous” is the word that you would often hear constantly in any discussion around DevOps. Almost everything in DevOps is continuous: be it Continuous integration, Continuous deployment, or Continuous delivery. So let’s take a closer look at the idea of continuity and why it has become central in the DevOps world.
CONTINUOUS INTEGRATION:
Continuous Integration is a software development practice where members of a team integrate their work frequently. In a broader sense, a continuous integration that aims at integrating the whole system or solution as often and as early as possible.
Continuous Integration is a software development practice where members of a team integrate their work frequently. In a broader sense, a continuous integration that aims at integrating the whole system or solution as often and as early as possible.
CONTINUOUS DELIVERY:
Continuous Delivery is the process of delivering code to the customer or end user whenever the developer feels that a section of code ready to be released, rather than releasing the entire code at one time. If the new release fails any of the set parameters, it is returned to the developing team for corrections before it gets integrated into the main system.
The major advantage of using continuous delivery is the improved communication with the client. Hence, the client need not to wait for the whole project to be completed to check whether the work meets his expectations or not. Also, the process of continuous delivery allows the developer to fix bugs, new products, and updates to be released quickly with less risk and without a huge labour costs.
CONTINUOUS DEPLOYMENT:
Continuous Deployment makes use of automated processes for both release of new code into the main environment and to test the code before it is integrated into the system. The major advantage of this process is, it allows the developer to concentrate on the tasks which is in hand, rather than continually test previously-written code and keep track of potential issues. Using this process, the developer simply delivers the new code to the automated system when the developer believes it to be ready. In continuous deployment, there is no large batch processing. Each individual of an element of a project can be released when it is ready using this process.
THE MAJOR BENEFITS OF CI/CD:
The three major benefits of CI/CD are listed below
* The increase in deployment frequency.
* Increase in release/delivery frequency.
* Decrease in the number of broken builds going into the production.
Once you have moved to Continuous Deployment process, the developer has to make several pieces of automation in place. The developer must automate the Continuous Integration Build Server and Continuous Delivery to Staging, as well as it has the ability to automatically deploy to production.
In the Ideal Workflow, the entire process could be automated from start to finish:
* Firstly, the developer checks-in the code to development branch.
* The Continuous Integration server picks up the changes need to be done.
* Then it performs the unit test.
* The unit test will be performed from Merge to Staging environment, the voting will be made based on the test results.
* If the deployment is successful in Staging environment,
* QA tests the environment and if the test is successful then it is moved to production.
* The Continuous Integration server picks this up again and regulates whether it is OK to merge into the production or not.
* If successful, then it will deploy to the Production environment.
This process varies slightly depending on needs, requirements, and approaches.
According to the DevOps.com’s survey, over 80% identify CI/CD as part of their DevOps initiative.
The survey pinpoints CI/CD as the dominant DevOps solution being implemented now.
MAKING SENSE OF THE DIFFERENCES:
Though all these terms look similar, there are some essential differences in these three processes. For precedent, continuous deployment requires both continuous delivery and continuous integration in order to work properly and to avoid errors in the release. In addition, continuous deployment is dependent on having automated testing, analysis, and release systems in place.
All the three processes are useful in minimizing risk and labour cost while allowing developers the greatest creative freedom. Understanding the exquisite differences among the three is essential for making use of the process that will benefit your team and company.
