Para aprovechar al máximo la agilidad que ofrecen las aplicaciones modernas, es esencial crear prácticas de CI / CD que ayuden a los equipos a iterar en el código y liberar funcionalidades rápidamente. En este webinar, compartiremos las mejores prácticas para crear flujos de trabajo de CI / CD para administrar sus implementaciones tanto en Serverless como en contenedores en AWS.
ES: Las técnicas de integración continua y entrega continua (CI/CD) permiten a los equipos aumentar la agilidad y entregar rápidamente un producto de alta calidad. En esta charla, le guiamos sobre las prácticas recomendadas para crear canalizaciones CI/CD que le permitan administrar aplicaciones sin servidor y en contenedores. Cubriremos el modelo Infrastructure as Code (AWS SAM), así como cómo configurar canalizaciones con AWS CodePipeline y AWS CodeBuild, y le mostraremos cómo automatizar las implementaciones con AWS CodeDeploy.
EN: Las técnicas de integración continua y entrega continua (CI/CD) permiten a los equipos aumentar la agilidad y liberar rápidamente un producto de alta calidad. En esta charla, le guiamos a través de las prácticas recomendadas para crear flujos de trabajo de CI/CD que le permitan administrar sus aplicaciones sin servidor y en contenedores. Cubriremos los modelos de aplicación Infrastructure as Code, como AWS Serverless Application Model (AWS SAM), así como cómo configurar canalizaciones de lanzamiento de CI/CD con AWS CodePipeline y AWS CodeBuild, y le mostraremos cómo automatizar implementaciones seguras con AWS CodeDeploy.
Vamos a contarles de la agenda de esta presentación
Em la prime parte vamos a hablar de CI/CD/ para aplicaciones moderas
Integración Continua
Y en la segunda parte nos estará acompanhando Camilo Cortes para entrear em mayor detalle para el despliegue continuo e infraestructura como código
Whenever we talk to people about how we transformed our development practices, they want to know how they can do it themselves. And the good news is – they absolutely can, using the same tools that we built from our experience learning these lessons.
We’ve built services to help with each stage of the development lifecycle, and we’ve also got Code Pipeline to manage the entire release process
Our sample pipeline in practice…
Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example.
Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket.
Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage.
In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction
Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage
The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.
S3 storage is used as an intermediary through these steps.
IAM controls can be placed on components in this workflow to ensure security of the process
CodePipeline will show where a task has failed or succeeded
We have partnered with popular source, build, test and deployment systems to provide out-of-the-box integrations.
Jenkins, CloudBees and Solano offer CI services for build stages
BlazeMeter, Apica, HP StormRunner and Runscope are load testing partners.
GhostInspector is a User Interface Testing partner
GitHub is a source code partner
Xebia Labs is a deployment partner.
For each report, you can see the breakdown of individual unit tests, status of the tests, duration, and messages from the tests. The summary section shows you the overall Passed/Failed test count and pass rate along with the duration taken
Automates code deployments to any instance and Lambda
Handles the complexity of updating your applications
Avoid downtime during application deployment
Roll back automatically if failure detected
Deploy to Amazon EC2, Lambda, ECS/Fargate or on-premises servers
Limit “blast radius” with traffic control
Ok, so here’s our setup. Nothing fancy here, just an auto scaling group set to a capacity of 3 registered to a load balancer. While a deployment is in progress, we don’t want the load balancer to keep sending traffic to the instance. To do this, when an instance begins a deployment, we’ll move it to “Standby” in the autoscaling group.
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Provisions “green” tasks, then flips traffic at the load balancer
Validation “hooks” enable testing at each stage of the deployment
Fast rollback to “blue” tasks in seconds if case of hook failure or CloudWatch alarms
Monitor deployment status and history via console, API, Amazon SNS notifications, and CloudWatch Events
Use “CodeDeploy-ECS” deploy action in CodePipeline or “aws ecs deploy” command in Jenkins
Code Completion - no round trips to the docs
Encapsulate the resources as reusable constructs for sharing both privately and publicly
Python
JavaScript
Typescript
Java
C-Sharp
CDK CLI that developers use to build and deploy their CDK Applications
Init - Templates
Synth – Verify
Deploy – Send changes
Destroy – Clean up dev environments
Here’s and example of a pattern construct
Let’s take a look at an example Pipeline. I’ve created a simple 3 stage Pipeline to talk though my example.
Source actions are special actions. They continuously poll the source providers, such as GitHub and S3, in order to detect changes. Once a change is detected, the new pipeline run is created and the new pipeline begins its run. The source actions retrieve a copy of the source information and place it into a customer owned S3 bucket.
Once the source action is completed, the Source stage is marked as successful and we transition to the Build stage.
In the Build Stage we have one action, Jenkins. Jenkins was integrated into CodePipeline as a CustomAction and has the same lifecycle as all custom actions. Talk through interaction
Once the build action is completed, the Build stage is marked as successful and we transition to the Deploy stage
The Deploy stage contains one action, an AWS Elastic Beanstalk deployment action. The Beanstalk action retrieves the build artifact from the customer’s S3 bucket and deploys it to the Elastic Beanstalk web container.
You can add a manual approval at the point where you want the pipeline to stop running until someone approves or rejects the revision in progress.
Pipeline will stop executing when it has reached the point at which you set the approval action
Pipeline execution resumes only when the action has been approved
Approval action managed with AWS Identity and Access Management (IAM) permissions
Notify approvers in several ways including email, SMS, webhooks, and more
Useful for manual QA actions or as part of “Canary” deploy models