# Implementación de integración continua y entrega continua
En esta sección se describen las formas en que puede empezar a implementar un modelo de CI/CD en su organización. En este documento técnico no se analiza cómo una organización con un modelo maduro de DevOps y transformación de la nube crea y utiliza una canalización de CI/CD. Para ayudarle en su recorrido hacia DevOps, AWS cuenta con varios [socios de DevOps certificados](https://aws.amazon.com/devops/partner-solutions/) que pueden proporcionarle recursos y herramientas. Para obtener más información sobre cómo prepararse para pasar a la nube de AWS, consulte [Creación de un modelo operativo en la nube](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf).
# Un camino hacia la integración continua/entrega continua
La CI/CD se puede representar como una canalización (consulte la siguiente figura), donde el código nuevo se envía en un extremo, se prueba en una serie de etapas (origen, compilación, ensayo y producción) y, a continuación, se publica como código listo para producción. Si su organización es nueva en CI/CD, puede abordar este proceso de manera iterativa. Esto significa que debe comenzar poco a poco e iterar en cada etapa para poder comprender y desarrollar el código de una manera que ayude a la organización a crecer.
![\[Canalización de CI/CD\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
*Canalización de CI/CD*
Cada etapa de la canalización de CI/CD se estructura como una unidad lógica en el proceso de entrega. Además, etapa actúa como una puerta que examina un cierto aspecto del código. A medida que el código avanza en la canalización, se supone que la calidad del código es mayor en las etapas posteriores porque se siguen verificando más aspectos del mismo. Los problemas descubiertos en una etapa temprana impiden que el código avance a través de la canalización. Los resultados de las pruebas se envían inmediatamente al equipo y todas las compilaciones y versiones posteriores se detienen si el software no pasa la etapa.
Estas etapas son sugerencias. Puede adaptar las etapas en función de las necesidades de su negocio. Algunas etapas se pueden repetir para varios tipos de pruebas, seguridad y rendimiento. Dependiendo de la complejidad de su proyecto y de la estructura de sus equipos, algunas etapas se pueden repetir varias veces en diferentes niveles. Por ejemplo, el producto final de un equipo puede convertirse en una dependencia en el proyecto del siguiente equipo. Esto significa que el producto final del primer equipo se presenta posteriormente como un artefacto en el proyecto del siguiente equipo.
La presencia de una canalización de CI/CD tendrá un gran impacto en la maduración de las capacidades de su organización. La organización debe comenzar con pequeños pasos y no intentar crear una canalización completamente madura, con múltiples entornos, muchas fases de prueba y automatización en todas las etapas al principio. Tenga en cuenta que incluso las organizaciones que tienen entornos de CI/CD muy maduros aún necesitan mejorar continuamente sus canalizaciones.
Crear una organización habilitada para CI/CD es un viaje y hay muchos destinos en el camino. La siguiente sección analiza un posible camino que su organización podría tomar, comenzando con la integración continua a través de los niveles de entrega continua.
# Integración continua
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
*Integración continua: origen y compilación *
La primera fase en el viaje de CI/CD es desarrollar la madurez en la integración continua. Debe asegurarse de que todos los desarrolladores confirmen regularmente su código en un repositorio central (como uno alojado en CodeCommit o GitHub) y fusionen todos los cambios en una ramificación de lanzamiento para la aplicación. Ningún desarrollador debe mantener el código de forma aislada. Si se necesita una ramificación de función durante un cierto período de tiempo, debe mantenerse actualizada mediante la fusión desde el flujo ascendente con la mayor frecuencia posible. Se recomiendan compromisos y fusiones frecuentes con unidades de trabajo completas para que el equipo desarrolle la disciplina y el proceso los alienta. Un desarrollador que fusione código de forma temprana y frecuente, probablemente tendrá menos problemas de integración en el futuro.
También debe alentar a los desarrolladores a crear pruebas unitarias lo antes posible para sus aplicaciones y a ejecutar estas pruebas antes de enviar el código al repositorio central. Los errores detectados al principio del proceso de desarrollo de software son los más baratos y fáciles de corregir.
Cuando el código se envía a una rama en un repositorio de código fuente, un motor de flujo de trabajo que monitorea esa ramificación enviará un comando a una herramienta de compilación para compilar el código y ejecutar las pruebas unitarias en un entorno controlado. El proceso de compilación debe tener el tamaño adecuado para manejar todas las actividades, incluidas las presiones y las pruebas que puedan ocurrir durante la etapa de confirmación, para obtener una retroalimentación rápida. En esta etapa también se pueden realizar otras comprobaciones de calidad, como la cobertura de pruebas unitarias, la verificación de estilo y el análisis estático. Por último, la herramienta de compilación crea una o más compilaciones binarias y otros artefactos, como imágenes, hojas de estilo y documentos para la aplicación.
# Entrega continua: creación de un entorno de ensayo
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
* Entrega continua: ensayo *
La entrega continua (CD) es la siguiente fase e implica implementar el código de la aplicación en un entorno de ensayo, que es una réplica de la pila de producción, y ejecutar más pruebas funcionales. El entorno de ensayo puede ser un entorno estático prediseñado para las pruebas, o puede aprovisionar y configurar un entorno dinámico con una infraestructura y un código de configuración comprometidos para probar e implementar el código de la aplicación.
# Entrega continua: creación de un entorno de producción
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
* Entrega continua: producción *
En la secuencia de canalización de implementación/entrega, después del entorno de ensayo, se encuentra el entorno de producción, que también se construye utilizando la infraestructura como código (IaC).
# Implementación continua
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
* Implementación continua *
La fase final de la canalización de implementación de CI/CD es la implementación continua, que puede incluir la automatización completa de todo el proceso de lanzamiento de software, incluida la implementación en el entorno de producción. En un entorno de CI/CD completamente maduro, la ruta al entorno de producción está completamente automatizada, lo que permite que el código se implemente con alta confianza.
# Madurez y más allá
A medida que su organización madure, continuará desarrollando el modelo de CI/CD para incluir más de las siguientes mejoras:
+ Más entornos de ensayo para pruebas específicas de rendimiento, cumplimiento, seguridad e interfaz de usuario (IU)
+ Pruebas unitarias del código de configuración e infraestructura junto con el código de la aplicación
+ Integración con otros sistemas y procesos, como la revisión del código, el seguimiento de problemas y la notificación de eventos
+ Integración con la migración de esquemas de base de datos (si procede)
+ Pasos adicionales para la auditoría y la aprobación empresarial
Incluso las organizaciones más maduras que tienen canalizaciones complejas de CI/CD multientorno siguen buscando mejoras. DevOps es un viaje, no un destino. Los comentarios sobre la canalización se recopilan de forma continua y se logran mejoras en velocidad, escala, seguridad y fiabilidad en colaboración entre las diferentes partes de los equipos de desarrollo.
# Equipos
AWS recomienda organizar tres equipos de desarrolladores para implementar un entorno de CI/CD: un equipo de aplicación, un equipo de infraestructura y un equipo de herramientas (consulte la siguiente figura). Esta organización representa un conjunto de prácticas recomendadas que se han desarrollado y aplicado en empresas emergentes de rápido crecimiento, grandes organizaciones empresariales y en la propia Amazon. Los equipos deben estar compuestos de no más de 10 o 12 personas. Esto sigue una regla de comunicación: las conversaciones significativas alcanzan límites a medida que el tamaño de los grupos aumenta y las líneas de comunicación se multiplican.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
*Equipos de aplicación, infraestructura y herramientas*
## Equipo de aplicación
El equipo de aplicación crea la aplicación. Los desarrolladores de la aplicación son propietarios de las tareas pendientes, las historias y las pruebas unitarias, y desarrollan características basadas en un objetivo específico de la aplicación. El objetivo organizativo de este equipo es minimizar el tiempo que estos desarrolladores dedican a tareas no esenciales de la aplicación.
Además de tener habilidades de programación funcionales en el lenguaje de la aplicación, el equipo de la aplicación debe tener habilidades de plataforma y comprender la configuración del sistema. Esto les permitirá centrarse únicamente en desarrollar características y reforzar la aplicación.
## Equipo de infraestructura
El equipo de infraestructura escribe el código que crea y configura la infraestructura necesaria para ejecutar la aplicación. Este equipo puede utilizar herramientas AWS nativas como AWS CloudFormation, o herramientas genéricas, como Chef, Puppet o Ansible. El equipo de infraestructura es responsable de especificar qué recursos se necesitan y trabaja en estrecha colaboración con el equipo de aplicación. El equipo de infraestructura puede estar formado por solo una o dos personas para una aplicación pequeña.
El equipo debe tener habilidades en métodos de aprovisionamiento de infraestructura, como AWS CloudFormation o HashiCorp Terraform. El equipo también debe desarrollar habilidades de automatización de la configuración con herramientas como Chef, Ansible, Puppet o Salt.
## Equipo de herramientas
El equipo de herramientas crea y administra la canalización de CI/CD. ES responsable de la infraestructura y las herramientas que conforman la canalización. No forman parte del equipo de aplicación; sin embargo, crean una herramienta que utilizan los equipos de aplicación e infraestructura en la organización. La organización necesita madurar continuamente su equipo de herramientas, de modo que el equipo de herramientas esté un paso por delante de los equipos de aplicación e infraestructura en proceso de maduración.
El equipo de herramientas debe ser experto en la creación e integración de todas las partes de la canalización de CI/CD. Esto incluye la creación de repositorios de control de código fuente, motores de flujo de trabajo, entornos de compilación, marcos de pruebas y repositorios de artefactos. Este equipo puede optar por implementar software como AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild, y AWS CodeArtifact, junto con Jenkins, GitHub, Artifactory, TeamCity y otras herramientas similares. Algunas organizaciones pueden llamar a esto un equipo de DevOps, pero AWS lo desaconseja y, en cambio, anima a pensar en DevOps como la suma de las personas, los procesos y las herramientas para la entrega de software.
# Etapas de prueba en integración continua y entrega continua
Los tres equipos de CI/CD deben incorporar las pruebas en el ciclo de vida de desarrollo de software en las diferentes etapas de la canalización de CI/CD. En general, las pruebas deben comenzar lo antes posible. La siguiente pirámide de pruebas es un concepto proporcionado por Mike Cohn en *Succeeding with Agile*. Muestra las diversas pruebas de software en relación con su coste y velocidad a la que se ejecutan.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
* Pirámide de pruebas de CI/CD *
Las pruebas unitarias están en la parte inferior de la pirámide. Son las más rápidas de ejecutar y las menos costosas. Por lo tanto, las pruebas unitarias deben constituir la mayor parte de su estrategia de pruebas. Una buena regla general es alrededor del 70 por ciento. Las pruebas unitarias deben tener una cobertura de código casi completa porque los errores detectados en esta fase se pueden corregir de forma rápida y económica.
Las pruebas de servicio, componentes e integración están en la pirámide por encima de las pruebas unitarias. Estas pruebas requieren entornos detallados y, por lo tanto, son más costosas en cuanto a requisitos de infraestructura y más lentas de ejecutar. Las pruebas de rendimiento y cumplimiento son el siguiente nivel. Requieren entornos de calidad de producción y son aún más caras. Las pruebas de aceptación de la interfaz de usuario y de usuario están en la parte superior de la pirámide y también requieren entornos de calidad de producción.
Todas estas pruebas forman parte de una estrategia completa para garantizar un software de alta calidad. Sin embargo, para acelerar el desarrollo, se hace hincapié en el número de pruebas y la cobertura en la mitad inferior de la pirámide.
En las siguientes secciones se analizan las etapas de la CI/CD.
## Configuración del origen
Al principio del proyecto, es esencial configurar un origen en el que poder almacenar el código sin procesar y los cambios de configuración y esquema. En la etapa de origen, elija un repositorio de código fuente, como uno alojado en GitHub o AWS CodeCommit.
## Configuración y ejecución de compilaciones
La automatización de compilaciones es esencial para el proceso de CI. Al configurar la automatización de compilaciones, la primera tarea es elegir la herramienta de compilación correcta. Existen muchas herramientas de compilación, tales como:
+ Ant, Maven, y Gradle para Java
+ Make para C/C\$1\$1
+ Grunt para JavaScript
+ Rake para Ruby
La herramienta de compilación que funcione mejor para usted depende del lenguaje de programación de su proyecto y del conjunto de habilidades de su equipo. Después de elegir la herramienta de compilación, todas las dependencias deben definirse claramente en los scripts de compilación, junto con los pasos de compilación. También se recomienda crear una versión de los artefactos de compilación finales, lo que facilita la implementación y el seguimiento de los problemas.
## Compilación
En la etapa de compilación, las herramientas de compilación tomarán como entrada cualquier cambio en el repositorio de código fuente, compilarán el software y ejecutarán los siguientes tipos de pruebas:
**Pruebas unitarias:** prueba una sección específica del código para garantizar que el código hace lo que se espera que haga. Los desarrolladores de software realizan las pruebas unitarias durante la fase de desarrollo. En esta etapa, se puede aplicar un análisis de código estático, un análisis de flujo de datos, una cobertura de código y otros procesos de verificación de software.
**Análisis de código estático:** esta prueba se realiza sin ejecutar la aplicación después de las pruebas de compilación y unitarias. Este análisis puede ayudar a encontrar errores de codificación y agujeros de seguridad, y también puede garantizar el cumplimiento de las pautas de codificación.
## Almacenamiento provisional
En la fase de ensayo, se crean entornos completos que reflejan el entorno de producción final. Se llevan a cabo las siguientes pruebas:
**Pruebas de integración**: verifica las interfaces entre los componentes en relación con el diseño del software. Las pruebas de integración son un proceso iterativo y facilitan la creación de interfaces robustas y la integridad del sistema.
**Pruebas de componentes:** prueba el paso de mensajes entre varios componentes y sus resultados. Un objetivo clave de estas pruebas podría ser la idempotencia en las pruebas de componentes. Las pruebas pueden incluir volúmenes de datos extremadamente grandes o situaciones perimetrales y entradas anómalas.
**Pruebas del sistema:** prueba el sistema de extremo a extremo y verifica si el software cumple con los requisitos comerciales. Esto puede incluir probar la interfaz de usuario (IU), la API, la lógica de backend y el estado final.
**Pruebas de rendimiento:** determina la capacidad de respuesta y la estabilidad de un sistema a medida que se desempeña bajo una carga de trabajo en particular. Las pruebas de rendimiento también se utilizan para investigar, medir, validar o verificar otros atributos de calidad del sistema, como la escalabilidad, la fiabilidad y el uso de recursos. Los tipos de pruebas de rendimiento pueden incluir pruebas de carga, pruebas de esfuerzo y pruebas de picos. Las pruebas de rendimiento se utilizan para la evaluación comparativa con criterios predefinidos.
**Pruebas de cumplimiento:** comprueba si el cambio de código cumple con los requisitos de una especificación o reglamento no funcional. Determina si está implementando y cumpliendo con los estándares definidos.
**Pruebas de aceptación del usuario:** valida el flujo empresarial de extremo a extremo. Esta prueba la ejecuta un usuario final en un entorno de ensayo y confirma si el sistema cumple con los requisitos de la especificación de requisitos. Por lo general, los clientes emplean metodologías de prueba alfa y beta en esta etapa.
## Producción
Finalmente, después de pasar las pruebas anteriores, la fase de ensayo se repite en un entorno de producción. En esta fase, se puede completar una *prueba de valor controlado* final implementando el nuevo código solo en un pequeño subconjunto de servidores o incluso en un servidor, o uno Región de AWS antes de implementar el código en todo el entorno de producción. Los detalles sobre cómo implementar de forma segura en producción se tratan en la sección [Métodos de implementación](deployment-methods.md).
En la siguiente sección se analiza la creación de la canalización para incorporar estas etapas y pruebas.
## Desarrollo de la canalización
En esta sección se analiza el desarrollo de la canalización. Comience por establecer una canalización con solo los componentes necesarios para la CI y luego haga la transición a una canalización de entrega continua con más componentes y etapas. En esta sección también se explica cómo puede considerar el uso de funciones AWS Lambda y aprobaciones manuales para proyectos grandes, planificar para varios equipos, ramificaciones y Regiones de AWS.
# Inicio con una canalización mínima viable para la integración continua
El recorrido de su organización hacia la entrega continua comienza con una canalización mínima viable (MVP). Como se explica en [Implementación de la integración continua y la entrega continua](implementing-continuous-integration-and-continuous-delivery.md), los equipos pueden comenzar con un proceso muy simple, como implementar una canalización que realice una verificación de estilo de código o una prueba de una sola unidad sin implementación.
Un componente clave es una herramienta de orquestación de entrega continua. Para ayudarle a desarrollar esta canalización, Amazon desarrolló [AWS CodeStar](https://aws.amazon.com/codestar).
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* Página de configuración de AWS CodeStar *
AWS CodeStar utiliza AWS CodePipeline, AWS CodeBuild AWS CodeCommit y AWS CodeDeploy con un proceso de configuración, herramientas, plantillas y panel integrados. AWS CodeStar proporciona todo lo necesario para desarrollar, compilar e implementar rápidamente aplicaciones en AWS. Esto le permite empezar a publicar código de forma más rápida. Los clientes que ya están familiarizados con la Consola de administración de AWS y buscan un mayor nivel de control pueden configurar manualmente las herramientas de desarrollo que prefieran y pueden proporcionar servicios individuales de AWS según sea necesario.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* Panel de AWS CodeStar *
AWS CodePipeline es un servicio de CI/CD que se puede utilizar a través de AWS CodeStar o a través de la Consola de administración de AWS para obtener actualizaciones rápidas y fiables de aplicaciones e infraestructura. AWS CodePipeline compila, prueba e implementa el código cada vez que hay un cambio de código, en función de los modelos de proceso de lanzamiento que defina. Esto le permite entregar características y actualizaciones de forma rápida y de confianza. Puede desarrollar fácilmente una solución integral usando nuestros complementos prediseñados para servicios de terceros populares como GitHub o integrando sus propios complementos personalizados en cualquier etapa del proceso de lanzamiento. Con AWS CodePipeline, solo paga por lo que usa. No es necesario pagar cuotas iniciales ni asumir compromisos a largo plazo.
Los pasos de AWS CodeStar y AWS CodePipeline se asignan directamente a las etapas de [CI/CD de origen, compilación, ensayo y producción](testing-stages-in-continuous-integration-and-continuous-delivery.md). Si bien la entrega continua es deseable, puede comenzar con una canalización simple de dos pasos que verifique el repositorio de origen y realice una acción de compilación:
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline: etapas de origen y desarrollo*
Para AWS CodePipeline, la etapa de origen puede aceptar entradas de GitHub y Amazon Simple Storage Service (Amazon S3).AWS CodeCommit La automatización del proceso de desarrollo es un primer paso fundamental para implementar la entrega continua y avanzar hacia la implementación continua. La eliminación de la participación humana en la producción de artefactos de compilación elimina la carga de su equipo, minimiza los errores introducidos por el empaquetado manual y le permite comenzar a empaquetar artefactos consumibles con más frecuencia.
AWS CodePipeline funciona a la perfección con AWS CodeBuild, un servicio de compilación completamente administrada, para facilitar la configuración de un paso de compilación dentro de su canalización que empaquete su código y ejecute pruebas unitarias. Con AWS CodeBuild, no necesita aprovisionar, administrar o escalar sus propios servidores de compilación. AWS CodeBuild se escala continuamente y procesa varias compilaciones al mismo tiempo para que sus compilaciones no se queden esperando en cola. AWS CodePipeline también se integra con servidores de compilación como Jenkins, Solano CI y TeamCity.
Por ejemplo, en la siguiente etapa de compilación, se ejecutan en paralelo tres acciones (pruebas unitarias, verificaciones de estilo de código y recopilación de métricas de código). Al usar AWS CodeBuild, estos pasos se pueden agregar como proyectos nuevos sin ningún esfuerzo adicional en la compilación o instalación de servidores de compilación para manejar la carga.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
* AWS CodePipeline: funcionalidad de compilación *
Las etapas de origen y compilación que se muestran en la figura *AWS CodePipeline: etapas de origen y compilación*, junto con los procesos de soporte y la automatización, respaldan la transición de su equipo hacia una integración continua. En este nivel de madurez, los desarrolladores deben prestar atención regularmente a los resultados de compilación y prueba. También necesitan crecer y mantener una base de prueba unitaria saludable. Esto, a su vez, refuerza la confianza de todo el equipo en la canalización de CI/CD y promueve su adopción.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
*Etapas de AWS CodePipeline*
# Canalización de entrega continua
Una vez que se haya implementado la canalización de integración continua y se hayan establecido los procesos de soporte, sus equipos pueden comenzar la transición hacia la canalización de entrega continua. Esta transición requiere que los equipos automaticen tanto la compilación como la implementación de aplicaciones.
Una canalización de entrega continua se caracteriza por la presencia de etapas de preparación y producción, donde la etapa de producción se realiza después de una aprobación manual.
De la misma manera en que se desarrolló la canalización de integración continua, sus equipos pueden comenzar a crear gradualmente una canalización de entrega continua escribiendo sus scripts de implementación.
Según las necesidades de una aplicación, los servicios de AWS existentes pueden abstraer algunos de los pasos de implementación. Por ejemplo, AWS CodePipeline se integra directamente con AWS CodeDeploy, un servicio que automatiza las implementaciones de código en instancias de Amazon EC2 e instancias que se ejecutan localmente, AWS OpsWorks, un servicio de administración de configuración que le ayuda a operar aplicaciones con Chef y en AWS Elastic Beanstalk, un servicio para implementar y escalar aplicaciones y servicios web.
AWS tiene [documentación](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment) detallada sobre cómo implementar e integrar AWS CodeDeploy con su infraestructura y canalización.
Una vez que su equipo automatice correctamente la implementación de la aplicación, las etapas de implementación se pueden ampliar con varias pruebas. Por ejemplo, puede añadir otras integraciones listas para usar con servicios como Ghost Inspector, Runscope y otros, como se muestra en la siguiente figura.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
* AWS CodePipeline: pruebas de código en etapas de implementación *
# Adición de acciones de Lambda
AWS CodeStar y AWS CodePipeline admiten la [integración con AWS Lambda](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html). Esta integración permite implementar un amplio conjunto de tareas, como crear recursos personalizados en su entorno, integrarse con sistemas de terceros (como Slack) y realizar comprobaciones en su entorno recién implementado.
Las funciones de Lambda se pueden usar en canalizaciones de CI/CD para realizar las siguientes tareas:
+ Desarrollar cambios en su entorno aplicando o actualizando una plantilla de AWS CloudFormation.
+ Crear recursos a demanda en una etapa de la canalización utilizando AWS CloudFormation y eliminarlos en otra.
+ Implementar versiones de aplicaciones sin tiempo de inactividad en AWS Elastic Beanstalk con una función de Lambda que intercambia los valores del [registro de nombre canónico](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME).
+ Implementar en instancias Docker de Amazon Elastic Container Service (ECS).
+ Hacer una copia de seguridad (es decir, crear un instantánea de AMI) antes de proceder a la creación o la implementación.
+ Hacer posible la integración con productos de terceros en su canalización, por ejemplo para publicar mensajes en un cliente Internet Relay Chat (IRC).
# Aprobaciones manuales
Añadir una acción de aprobación a una etapa de una canalización en el punto donde quiere que el procesamiento de la canalización se detenga de modo que alguien con los permisos de AWS Identity and Access Management (IAM) necesarios pueda aprobar o rechazar la acción.
Si se aprueba la acción, se reanuda el procesamiento de la canalización. Si la acción se rechaza, o si nadie aprueba o rechaza la acción en el plazo de siete días después de que la canalización alcance la acción y se detenga, el resultado es el mismo que si se produjese un error en la acción y el procesamiento de la canalización no continúa.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
* AWS CodeDeploy: aprobaciones manuales*
# Implementación de cambios en el código de infraestructura en una canalización de CI/CD
AWS CodePipeline permite seleccionar AWS CloudFormation como acción de implementación en cualquier etapa de su canalización. A continuación, puede elegir la acción específica que AWS CloudFormation desea realizar, como crear o eliminar pilas y crear o ejecutar [conjuntos de cambios](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952). Una [pila](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929) es un concepto de AWS CloudFormation y representa un grupo de recursos de AWS relacionados. Si bien hay muchas formas de aprovisionar la infraestructura como código, AWS CloudFormation es una herramienta integral recomendada por AWS como una solución escalable y completa que puede describir el conjunto más completo de recursos de AWS como código. AWS recomienda usar AWS CloudFormation en un proyecto de AWS CodePipeline para [realizar un seguimiento de los cambios y las pruebas de infraestructura](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html).
# CI/CD para aplicaciones sin servidor
También puede utilizar AWS CodeStar,AWS CodePipelineAWS CodeBuild, yAWS CloudFormation para desarrollar canalizaciones de CI/CD para aplicaciones sin servidor. Las aplicaciones sin servidor integran servicios administrados como [Amazon Cognito](https://aws.amazon.com/cognito), Amazon S3 y Amazon DynamoDB con un servicio basado en eventos y AWS Lambda para implementar aplicaciones de una manera que no requiera la administración de servidores. Si es desarrollador de aplicaciones sin servidor, puede utilizar la combinación deAWS CodePipelineAWS CodeBuild, yAWS CloudFormation para automatizar el desarrollo, las pruebas y la implementación de aplicaciones sin servidor que se expresan en plantillas creadas con el AWS Serverless Application Model. Para obtener más información, consulte la documentación de AWS Lambda sobre [Automatización de la implementación de aplicaciones basadas en Lambda](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html).
También puede crear canalizaciones de CI/CD seguras que sigan las prácticas recomendadas de su organización con AWS Serverless Application Model Pipelines (AWS SAM Pipelines). Las canalizaciones de AWS SAM son una nueva característica de la CLI de AWS SAM que permite obtener beneficios de CI/CD en cuestión de minutos, como acelerar la frecuencia de las implementaciones, reducir el plazo de entrega de los cambios y disminuir los errores de implementación. AWS SAM Pipelines incluye un conjunto de plantillas de canalización predeterminadas para AWS CodeBuild/CodePipeline que siguen las prácticas recomendadas de implementación de AWS. Para obtener más información y ver el tutorial, consulte el blog [Introducing AWS SAM Pipelines](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/).
# Canalizaciones para varios equipos, sucursales y regiones de AWS
Para un proyecto grande, no es raro que varios equipos de proyectos trabajen en diferentes componentes. Si varios equipos usan un único repositorio de código, se puede asignar para que cada equipo tenga su propia ramificación. También debe haber una ramificación de integración o lanzamiento para la fusión final del proyecto. Si se utiliza una arquitectura orientada a servicios o de microservicios, cada equipo podría tener su propio repositorio de código.
En el primer escenario, si se usa una sola canalización, es posible que un equipo pueda afectar el progreso de los demás equipos bloqueando la canalización. AWS recomienda crear canalizaciones específicas para las ramificaciones del equipo y otra canalización de lanzamiento para la entrega del producto final.
# Integración de canalizaciones con AWS CodeBuild
AWS CodeBuild está diseñado para permitir que su organización cree un proceso de creación de alta disponibilidad con una escala casi ilimitada. AWS CodeBuild proporciona entornos de inicio rápido para varios lenguajes populares, además de la capacidad de ejecutar cualquier contenedor de Docker que especifique.
Con las ventajas de una estrecha integración con AWS CodeCommit, AWS CodePipeline y AWS CodeDeploy, así como con las acciones de Git y CodePipeline Lambda, la herramienta CodeBuild es muy flexible.
El software se puede crear mediante la inclusión de un archivo `buildspec.yml` que identifica cada uno de los pasos de compilación, incluidas las acciones previas y posteriores a la compilación, o las acciones especificadas a través de la herramienta CodeBuild.
Puede ver el historial detallado de cada compilación usando el panel de CodeBuild. Los eventos se almacenan como archivos de registro de Amazon CloudWatch Logs.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
* Archivos de registro de CloudWatch Logs en AWS CodeBuild *
# Integración de canalizaciones con Jenkins
Puede utilizar la herramienta de compilación de Jenkins [para crear canalizaciones de entrega](https://www.jenkins.io/doc/book/pipeline/getting-started/). Estas canalizaciones utilizan trabajos estándar que definen los pasos para implementar etapas de entrega continua. Sin embargo, este enfoque puede que no sea óptimo para proyectos más grandes porque el estado actual de la canalización no persiste entre los reinicios de Jenkins, la implementación de la aprobación manual no es sencilla y el seguimiento del estado de una canalización compleja puede resultar complicado.
En su lugar, AWS recomienda implementar la entrega continua con Jenkins mediante el [complemento AWS Code Pipeline](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin). Este complemento permite describir flujos de trabajo complejos utilizando un lenguaje específico de dominio similar a Groovy y se puede usar para orquestar canalizaciones complejas. La funcionalidad del complemento de AWS Code Pipeline se puede mejorar mediante el uso de complementos satelitales, como el [complemento Pipeline Stage View](https://plugins.jenkins.io/aws-codepipeline/), que visualiza el progreso actual de las etapas definidas en una canalización, o el [complemento Pipeline Multibranch](https://plugins.jenkins.io/workflow-multibranch/), que agrupa desarrollos de diferentes ramificaciones.
AWS recomienda que almacene la configuración de su canalización en *Jenkinsfile* y que la registre en un repositorio de código fuente. Esto permite realizar un seguimiento de los cambios en el código de canalización y se vuelve aún más importante cuando se trabaja con el complemento Pipeline Multibranch. AWStambién recomienda dividir su canalización en etapas. Esto agrupa lógicamente los pasos de la canalización y también permite que el complemento Pipeline Stage View visualice el estado actual de la canalización.
En la siguiente figura se muestra una canalización de ejemplo de Jenkins, con cuatro etapas definidas visualizadas por el complemento Pipeline Stage View.
![\[alt text not found\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Etapas definidas de la canalización de Jenkins visualizadas por el complemento Pipeline Stage View*