It is not surprising that Amazon Web Services is ahead of the rest of the world in terms of software integration and continuous deployment, especially since it presents itself as a must for organizations looking to put CI / CD fully into practice. The online services giant, however, has taken its own internal CI / CD practices to the next level, essentially making it a completely “no-action” operation.
At AWS, changes in microservices are automatically rolled out to production “several times a day by continuous deployment pipelines,” according to Clare Liguori, senior software engineer at AWS. This pipeline-centric strategy is key to its ability to continue pumping code. In one recent article, she explains how Amazon moves software through its phases quickly and automatically. Remarkably, managers and developers spend little or no time overseeing deployments and monitoring logs and metrics to assess their impact. “Automated deployments in progress usually don’t have a developer who actively monitors each deployment, checks the measurements, and backs up manually if there are any problems. These deployments are completely independent. The deployment system actively monitors an alarm to determine whether it should automatically cancel a deployment. “
Verification steps
AWS software code goes through four main steps, with automated mechanisms and processes that verify and recheck results at each step:
- Source changes, validated: Amazon pipelines “automatically validate and safely deploy any type of source change in production, not just application code changes,” says Clare Liguori. “They can validate and deploy changes to sources such as static website assets, tools, testing, infrastructure, configuration, and the underlying operating system for the application.” All of these changes are version-controlled in individual source code repositories. Source code dependencies, such as libraries, programming languages, and settings like AMI IDs, are automatically updated to the latest version at least once a week. “
- Build, a teamwork process: the code is compiled and tested individually, continues the engineer. “Teams can choose the unit test frameworks, linters and static analysis tools that suit them best. In addition, teams can choose the configuration of these tools, such as the minimum acceptable code coverage in their unit testing framework. “
- Test and test again: the pipeline performs the latest changes through a set of deployment security tests and controls. “These automated steps prevent faults that impact customers from reaching production and limit the impact of faults on customers if they reach production. “
- Production, which includes the “cooking time”: the code is put into production in stages in all regions of the AWS, in order to mitigate the problems that arise. “We have found that grouping deployments by” waves “of increasing size helps us achieve a good balance between risk and speed of deployment,” explains Clare Liguori. “Each stage of the wave in the pipeline orchestrates deployments to a group of regions, with changes promoted from wave to wave. New changes may enter the production phase of the pipeline at any time. She adds that each production deployment has a “cooking time” to assess the impact, because “sometimes the negative impact caused by a deployment is not easily visible. It is a slow process; it does not appear immediately during deployment, especially if the service is then little used. Each stage of the pipeline has a cooking time, that is to say that the pipeline continues to monitor the team’s global alarm for any slow combustion impact after deployment and before proceeding to the next stage ” .
AWS doesn’t just automate its processes and expect the best: its automated deployment practices are carefully crafted, tuned and tested, observes the engineer, “depending on what helps us balance security and speed deployment. At the same time, we want to minimize the time developers have to spend worrying about deployments. ”
Source : ZDNet.com
– .
