Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Descripción de CI/CD
La integración y entrega continuas (CI/CD) es el proceso de automatización del ciclo de vida de los lanzamientos de software. En algunos casos, la *D* de CI/CD también puede significar *implementación*. La diferencia entre la *entrega continua* y la* implementación continua* se produce cuando se publica un cambio en el entorno de producción. Con la entrega continua, se requiere aprobación manual antes de pasar cambios a producción. La implementación continua ofrece un flujo ininterrumpido en toda la canalización y no se requieren aprobaciones explícitas. Como esta estrategia analiza los conceptos generales de CI/CD, las recomendaciones y la información proporcionadas se pueden aplicar tanto a los enfoques de entrega continua como de implementación continua.
La CI/CD automatiza gran parte o la totalidad de los procesos manuales que tradicionalmente se requerían para pasar código nuevo de confirmación a producción. Una canalización de CI/CD abarca las etapas de origen, compilación, prueba, uso transitorio y producción. En cada etapa, las canalizaciones de CI/CD proporcionan cualquier infraestructura necesaria para implementar o probar el código. Al usar una canalización de CI/CD, los equipos de desarrollo pueden hacer cambios en el código, que luego se prueban automáticamente y se implementan.
Revisemos el proceso básico de CI/CD antes de analizar algunas de las formas en las que puede, desviarse de una CI/CD completa de forma consciente o inconsciente. En el siguiente diagrama se enumeran las etapas de CI/CD y las actividades de cada una.
![\[Las cinco etapas de un proceso de CI/CD y las actividades y entornos de cada una.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## Acerca de la integración continua
La integración continua se produce en un repositorio de código, como un repositorio de Git en GitHub. Se trata una sola rama principal como origen de información para el código base y se crean ramas de corta duración para el desarrollo de características. Una rama de características se integra en la rama principal cuando lo tiene todo listo para implementar la característica en los entornos superiores. Las ramas de características nunca se implementan directamente en los entornos superiores. Para obtener más información, consulte la sección [Enfoque basado en enlaces troncales](fully-cicd-process-differences.md#trunk-based-approach) de esta guía.
*Proceso de integración continua*
1. El desarrollador crea una nueva rama a partir de la rama principal.
1. El desarrollador hace cambios, compila y prueba de forma local.
1. Cuando los cambios estén listos, el desarrollador crea una [solicitud de extracción](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (documentación de GitHub) con la rama principal como destino.
1. Se revisa el código.
1. Cuando se aprueba el código, se fusiona con la rama principal.
## Acerca de la entrega continua
La entrega continua se produce en entornos aislados, como entornos de desarrollo y de producción. Las acciones que se producen en cada entorno pueden variar. Una de las primeras etapas se suele utilizar para llevar a cabo actualizaciones en la propia canalización antes de continuar. El resultado final de la implementación es que cada entorno se actualiza con los cambios más recientes. La cantidad de entornos de desarrollo para la creación y las pruebas también varía, pero le recomendamos que utilice al menos dos. En el proceso, cada entorno se actualiza por orden según su importancia y termina con el entorno más importante, el entorno de producción.
*Proceso de entrega continua*
La parte del proceso de entrega continua se inicia con la extracción del código de la rama principal del repositorio de origen y su traslado a la etapa de compilación. El documento de infraestructura como código (IaC) del repositorio describe las tareas que se llevan a cabo en cada etapa. Si bien el uso de un documento de IaC no es obligatorio, se recomienda encarecidamente utilizar un servicio o una herramienta de IaC, como [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) o [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html). Los pasos más comunes son:
1. Pruebas unitarias
1. Compilación de código
1. Aprovisionamiento de recursos
1. Pruebas de integración
Si se produce algún error o alguna prueba falla en alguna etapa de la canalización, la etapa actual vuelve a su estado anterior y la canalización termina. Los cambios posteriores deben comenzar en el repositorio de código y pasar por todo el proceso de CI/CD.
# Pruebas para canalizaciones de CI/CD
Los dos tipos de pruebas automatizadas a las que se suele hacer referencia en las canalizaciones de implementación son las *pruebas unitarias* y las *pruebas de integración*. Sin embargo, hay muchos tipos de pruebas que se pueden ejecutar en un código base y en el entorno de desarrollo. La [arquitectura de referencia para canalizaciones de implementación de AWS](https://pipelines.devops.aws.dev/application-pipeline/) define los siguientes tipos de pruebas:
+ **Prueba unitaria**: estas pruebas compilan y ejecutan el código de la aplicación para comprobar que funcione según las expectativas. Simulan todas las dependencias externas que se utilizan en el código base. Entre los ejemplos de herramientas de pruebas unitarias se incluyen [JUnit](https://junit.org/), [Jest](https://jestjs.io/) y [pytest](https://pytest.org/).
+ **Prueba de integración**: estas pruebas verifican que la aplicación cumpla con los requisitos técnicos mediante la prueba en un entorno de prueba aprovisionado. Entre los ejemplos de herramientas de pruebas de integración se incluyen [Cucumber](https://cucumber.io/), [vRest NG](https://vrest.io/), e [integ-tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) (para AWS CDK).
+ **Prueba de aceptación**: estas pruebas verifican que la aplicación cumpla con los requisitos del usuario mediante la prueba en un entorno de prueba aprovisionado. Entre los ejemplos de herramientas de pruebas de aceptación se incluyen [Cypress](https://cypress.io/) y [Selenium](https://selenium.dev/).
+ **Prueba sintética**: estas pruebas se ejecutan de forma continua en segundo plano para generar tráfico y verificar que el sistema esté en buen estado. Entre los ejemplos de herramientas de pruebas sintéticas se incluyen [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) y [Dynatrace Synthetic Monitoring](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/).
+ **Prueba de rendimiento**: estas pruebas simulan la capacidad de producción. Determinan si la aplicación cumple con los requisitos de rendimiento y comparan las métricas con el rendimiento anterior. Entre los ejemplos de herramientas de pruebas de rendimiento se incluyen [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/) y [Gatling](https://gatling.io/).
+ **Prueba de resiliencia**: también conocidas como *pruebas de caos*, estas pruebas inyectan errores en los entornos para identificar las áreas de riesgo. Los periodos en los que se producen los errores se comparan luego con los periodos sin errores. Entre los ejemplos de herramientas de pruebas de resiliencia se incluyen [AWS Fault Injection Service](https://aws.amazon.com/fis/) y [Gremlin](https://www.gremlin.com/).
+ **Prueba estática de seguridad de aplicaciones (SAST)**: estas pruebas analizan el código en busca de infracciones de seguridad, como una [inyección de código SQL](https://owasp.org/www-community/attacks/SQL_Injection) o el [scripting entre sitios (XSS)](https://owasp.org/www-community/attacks/xss/). Entre los ejemplos de herramientas de SAST se incluyen [Amazon CodeGuru](https://aws.amazon.com/codeguru/), [SonarQube](https://www.sonarqube.org/) y [Checkmarx](https://checkmarx.com/).
+ **Prueba dinámica de seguridad de aplicaciones**: estas pruebas también se conocen como *pruebas de penetración* o *pruebas de incursión*. Identifican vulnerabilidades, como la inyección de código SQL o el XSS, en un entorno de prueba aprovisionado. Entre los ejemplos de herramientas de DAST se incluyen [Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) y [HCL AppScan](https://www.hcltechsw.com/appscan). Para más información, consulte [Penetration Testing](https://aws.amazon.com/security/penetration-testing/).
No todas las canalizaciones de CI/CD completas ejecutan todas estas pruebas. Sin embargo, como mínimo, una canalización debería ejecutar pruebas unitarias y pruebas de SAST en el código base, así como pruebas de integración y aceptación en un entorno de pruebas.
# Métricas para canalizaciones de CI/CD
De acuerdo con la [arquitectura de referencia para canalizaciones de implementación de AWS](https://pipelines.devops.aws.dev/application-pipeline/), debería hacer un seguimiento, como mínimo, de las cuatro métricas siguientes para las canalizaciones de CI/CD:
+ **Plazo de entrega**: el promedio de tiempo que tarda una sola confirmación en llegar a la fase de producción. Le recomendamos que se centre en un plazo de entre 1 hora y 1 día, según corresponda a su caso de uso.
+ **Frecuencia de implementación**: el número de implementaciones de producción en un periodo de tiempo determinado. Le recomendamos segmentar las frecuencias de implementación entre varias veces al día y dos veces por semana, según corresponda a su caso de uso.
+ **Tiempo medio entre errores (MTBD)**: el promedio de tiempo entre el inicio de una canalización correcta y el inicio de una canalización con errores. Le recomendamos que opte por un MTBD lo más alto posible. Para más información, consulte [Increasing MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html).
+ **Tiempo medio de recuperación (MTTR)**: el promedio de tiempo que transcurre entre el inicio de una canalización con errores y el inicio de la siguiente canalización correcta. Le recomendamos que opte por un MTTR lo más bajo posible. Para más información, consulte [Reducing MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html).
Estas métricas ayudan a los equipos a hacer un seguimiento de su progreso para obtener una CI/CD completa. Los equipos deben mantener conversaciones abiertas con las partes interesadas de la organización sobre cuáles deberían ser los objetivos óptimos. Las situaciones y necesidades varían mucho de una organización a otra, e incluso de un equipo a otro.
Es muy importante recordar que los cambios rápidos y drásticos suelen aumentar el riesgo de que surjan problemas. Establezca objetivos para lograr mejoras pequeñas e incrementales. Un plazo de entrega óptimo habitual para canalizaciones de CI/CD completas es inferior a 3 horas. Un equipo que comience con un plazo de entrega de 5,2 días debería tener como objetivo una reducción de un día cada pocas semanas. Cuando este equipo cumpla un plazo de entrega de un día o menos, podrá permanecer allí durante varios meses y adoptar un plazo de entrega más agresivo solo si el equipo y las partes interesadas de la organización lo consideran necesario.