WIXLIB

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSA pathway to continuous integration/continuousdeliveryCI/CD can be pictured as a pipeline (refer to the following figure), where new code issubmitted on one end, tested over a series of stages (source, build, staging, andproduction), and then published as production-ready code. If your organization is new toCI/CD it can approach this pipeline in an iterative fashion. This means that you shouldstart small, and iterate at each stage so that you can understand and develop your codein a way that will help your organization grow.CI/CD pipelineEach stage of the CI/CD pipeline is structured as a logical unit in the delivery process.In addition, each stage acts as a gate that vets a certain aspect of the code. As thecode progresses through the pipeline, the assumption is that the quality of the code ishigher in the later stages because more aspects of it continue to be verified. Problemsuncovered in an early stage stop the code from progressing through the pipeline.Results from the tests are immediately sent to the team, and all further builds andreleases are stopped if software does not pass the stage.These stages are suggestions. You can adapt the stages based on your business need.This versionarchived.Some stages can be repeatedfor multiplehastypesbeenof testing,security, and performance.Depending on the complexity of your project and the structure of your teams, somestages can be repeated several times at different levels. For example, the end productof one team can becomein the projectthe next team. ThisFor thea dependencylatest versionof thisof document,visit:means thatthe first team’s end product is subsequently staged as an artifact in the next team’sproject.The test/of a CI/CD pipeline will have a large impact on maturing the capabilitiesof your organization. The organization should start with small steps and not try to build apracticing-continuous-integration-continuousfully mature pipeline, with multiple environments, many testing phases, and automationdelivery/welcome.htmlin all stages at the start. Keep in mind that even organizations that have highly matureCI/CD environments still need to continuously improve their pipelines.5

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSBuilding a CI/CD-enabled organization is a journey, and there are many destinationsalong the way. The next section discusses a possible pathway that your organizationcould take, starting with continuous integration through the levels of continuous delivery.Continuous integrationContinuous integration—source and buildThe first phase in the CI/CD journey is to develop maturity in continuous integration.You should make sure that all of the developers regularly commit their code to a centralrepository (such as one hosted in CodeCommit or GitHub) and merge all changes to arelease branch for the application. No developer should be holding code in isolation. If afeature branch is needed for a certain period of time, it should be kept up to date bymerging from upstream as often as possible. Frequent commits and merges withcomplete units of work are recommended for the team to develop discipline and areencouraged by the process. A developer who merges code early and often, will likelyhave fewer integration issuesthe road.Thisdownversionhas been archived.You should also encourage developers to create unit tests as early as possible for theirapplications and to run these tests before pushing the code to the central repository.Errors caught earlyin theare the cheapestand easiestForthesoftwarelatestdevelopmentversion ofprocessthis document,visit:to fix.When the code is pushed to a branch in a source code repository, a workflow enginemonitoring thatbranch will send a command to a builder tool to build the code and the unit tests in olled environment. The build process should be sizedappropriately to handle all activities,including pushes and tests that might happendelivery/welcome.htmlduring the commit stage, for fast feedback. Other quality checks, such as unit testcoverage, style check, and static analysis, can happen at this stage as well. Finally, thebuilder tool creates one or more binary builds and other artifacts, like images,stylesheets, and documents for the application.6

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSContinuous delivery: creating a staging environmentContinuous delivery—stagingContinuous delivery (CD) is the next phase and entails deploying the application code ina staging environment, which is a replica of the production stack, and running morefunctional tests. The staging environment could be a static environment premade fortesting, or you could provision and configure a dynamic environment with committedinfrastructure and configuration code for testing and deploying the application code.Continuous delivery: creating a production environmentThis version has been archived.For the latest version of this document, visit:Continuous hitepapers/latest/In the deployment/deliverypipeline sequence, after the staging environment, is duction environment, which delivery/welcome.htmlis also built using infrastructure as code (IaC).7

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSContinuous deploymentContinuous deploymentThe final phase in the CI/CD deployment pipeline is continuous deployment, which mayinclude full automation of the entire software release process including deployment tothe production environment. In a fully mature CI/CD environment, the path to theproduction environment is fully automated, which allows code to be deployed with highconfidence.Maturity and beyondAs your organization matures, it will continue to develop the CI/CD model to includemore of the following improvements: More staging environments for specific performance, compliance, security, anduser interface (UI)Thistests version has been archived. Unit tests of infrastructure and configuration code along with the application code Integration with other systems and processes such as code review, issueForeventthenotificationlatest version of this document, visit:tracking, and Integration with database schema migration (if applicable) Additional steps for auditing and business test/Even the most matureorganizations that have complex multi-environment ipelines continue to look for improvements.DevOps is a journey, not a destination.delivery/welcome.htmlFeedback about the pipeline is continuously collected and improvements in speed,scale, security, and reliability are achieved as a collaboration between the different partsof the development teams.8

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSTeamsAWS recommends organizing three developer teams for implementing a CI/CDenvironment: an application team, an infrastructure team, and a tools team (refer to thefollowing figure). This organization represents a set of best practices that have beendeveloped and applied in fast-moving startups, large enterprise organizations, and inAmazon itself. The teams should be no larger than groups that two pizzas can feed, orabout 10-12 people. This follows the communication rule that meaningful conversationshit limits as group sizes increase and lines of communication multiply.Application, infrastructure, and tools teamsApplication teamThis version has been archived.The application team creates the application. Application developers own the backlog,stories, and unit tests, and they develop features based on a specified applicationtarget. This team’sorganizationalis to minimizethedocument,time these developersForthe latestgoalversionof thisvisit: spendon non-core application tasks.In addition to having functional programming skills in the application language, theapplication teamshould have platform skills and an understanding of st/configuration. Thiswill enable them to focus solely on developing features dening the application.delivery/welcome.html9

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSInfrastructure teamThe infrastructure team writes the code that both creates and configures theinfrastructure needed to run the application. This team might use native AWS tools,such as AWS CloudFormation, or generic tools, such as Chef, Puppet, or Ansible. Theinfrastructure team is responsible for specifying what resources are needed, and itworks closely with the application team. The infrastructure team might consist of onlyone or two people for a small application.The team should have skills in infrastructure provisioning methods, such as AWSCloudFormation or HashiCorp Terraform. The team should also develop configurationautomation skills with tools such as Chef, Ansible, Puppet, or Salt.Tools teamThe tools team builds and manages the CI/CD pipeline. They are responsible for theinfrastructure and tools that make up the pipeline. They are not part of the two-pizzateam; however, they create a tool that is used by the application and infrastructureteams in the organization. The organization needs to continuously mature its tools team,so that the tools team stays one step ahead of the maturing application andinfrastructure teams.The tools team must be skilled in building and integrating all parts of the CI/CD pipeline.This includes building source control repositories, workflow engines, buildenvironments, testing frameworks, and artifact repositories. This team may choose toimplement software such as AWS CodeStar, AWS CodePipeline, AWS CodeCommit,AWS CodeDeploy, AWS CodeBuild and AWS CodeArtifact, along with Jenkins, GitHub,ThisversionhasSomebeenarchived.Artifactory, TeamCity, andothersimilar tools.organizationsmight call this aDevOps team, but AWS discourages this and instead encourages thinking of DevOpsas the sum of the people, processes, and tools in software delivery.For the latest version of this document, visit:Testing stages in continuous integration andcontinuous test/The three CI/CDteams should incorporate testing into the software nuouslifecycle at the differentstages of the CI/CD pipeline. Overall, testing should start asearly as possible. The followingdelivery/welcome.htmltesting pyramid is a concept provided by Mike Cohn inthe book Succeeding with Agile. It shows the various software tests in relation to theircost and the speed at which they run.10

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSCI/CD testing pyramidUnit tests are on the bottom of the pyramid. They are both the fastest to run and theleast expensive. Therefore, unit tests should make up the bulk of your testing strategy.A good rule of thumb is about 70 percent. Unit tests should have near-complete codecoverage because bugs caught in this phase can be fixed quickly and cheaply.Service, component, and integration tests are above unit tests on the pyramid. Thesetests require detailed environments and therefore, are more costly in infrastructurerequirements and slower to run. Performance and compliance tests are the next level.They require production-quality environments and are more expensive yet. UI and useracceptance tests are at the top of the pyramid and require production-qualityenvironments as well. This version has been archived.All of these tests are part of a complete strategy to assure high-quality software.However, for speed of development, emphasis is on the number of tests and theFor theversion of this document, visit:coverage in the bottomhalf latestof the pyramid.The following sections discuss the CI/CD stages.Setting up https://docs.aws.amazon.com/whitepapers/latest/the At the beginning of the project, it’s essential to set up a source where you can storedelivery/welcome.htmlyour raw code and configuration and schema changes. In the source stage, choose asource code repository such as one hosted in GitHub or AWS CodeCommit.11

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSSetting up and running buildsBuild automation is essential to the CI process. When setting up build automation, thefirst task is to choose the right build tool. There are many build tools, such as: Ant, Maven, and Gradle for Java Make for C/C Grunt for JavaScript Rake for RubyThe build tool that will work best for you depends on the programming language of yourproject and the skill set of your team. After you choose the build tool, all thedependencies need to be clearly defined in the build scripts, along with the build steps.It’s also a best practice to version the final build artifacts, which makes it easier todeploy and to keep track of issues.BuildingIn the build stage, the build tools will take as input any change to the source coderepository, build the software, and run the following types of tests:Unit testing – Tests a specific section of code to ensure the code does what it isexpected to do. The unit testing is performed by software developers during thedevelopment phase. At this stage, a static code analysis, data flow analysis, codecoverage, and other software verification processes can be applied.Static code analysis – ThisThis testis performedexecuting the fter the build and unit testing. This analysis can help to find coding errors and securityholes, and it also can ensure conformance to coding guidelines.StagingFor the latest version of this document, visit:In the staging phase, full environments are created that mirror the eventual productionenvironment. The following tests are latest/Integration testing– Verifies the interfaces between components against usdesign. Integration testing is an iterative process and facilitates building robustdelivery/welcome.htmlinterfaces and system integrity.12

Amazon Web ServicesPracticing Continuous Integration and Continuous Delivery on AWSComponent testing – Tests message passing between various components and theiroutcomes. A key goal of this testing could be idempotency in component testing. Testscan include extremely large data volumes, or edge situations and abnormal inputs.System testing – Tests the system end-to-end and verifies if the software satisfies thebusiness requirement. This might include testing the user interface (UI), API, backendlogic, and end state.Performance testing – Determines the responsiveness and stability of a system as itperforms under a particular workload. Performance testing also is used to investigate,measure, validate, or verify other quality attributes of the system, such as scalability,reliabili

Continuous delivery is not continuous deployment One misconception about continuous delivery is that it means every change committed is applied to production immediately after passing automated tests. However, the point of continuous delivery is not to apply every change to production immediately, but to