Integración continua, entrega contigua e implementación continua
Descubre las diferencias entre estas prácticas continuas
Sten Pittet
Escritor colaborador
CI y CD son dos acrónimos que se utilizan con frecuencia en las prácticas de desarrollo actuales y DevOps. “CI” son las siglas de “integración continua”, una práctica fundamental recomendada de DevOps en la que los desarrolladores fusionan con frecuencia los cambios de código en un repositorio central donde se ejecutan compilaciones y pruebas automatizadas. Sin embargo, “CD” puede significar “entrega continua” o “implementación continua”.
¿Qué diferencias hay entre la integración continua, la entrega continua y la implementación continua (CI/CD)?
Integración continua
Los desarrolladores que emplean la integración continua vuelven a fusionar sus cambios en la rama principal con la mayor frecuencia posible. Los cambios del desarrollador se validan creando una compilación y sometiéndola a pruebas automatizadas. Al hacerlo, se evitan los retos que supone la integración y que pueden surgir al esperar al día de la publicación para fusionar los cambios en la rama de publicación.
La integración continua hace especial hincapié en la automatización de pruebas para comprobar que la aplicación no genera errores cuando se integran nuevas confirmaciones en la rama principal.
Entrega continua
La entrega continua es una extensión de la integración continua, ya que implementa automáticamente todos los cambios de código en un entorno de pruebas o producción después de la fase de compilación.
Esto significa que, además de las pruebas automatizadas, cuentas con un proceso de publicación automatizado y puedes implementar la aplicación en cualquier momento haciendo clic en un botón.
En teoría, con la entrega continua puedes publicar cada día, cada semana, cada quincena o lo que se adapte a tus necesidades empresariales. Sin embargo, si realmente quieres aprovechar las ventajas de la entrega continua, debes implementar la producción lo antes posible para asegurarte de publicar lotes pequeños cuyos problemas sean fáciles de solucionar.
Ver la solución
Desarrolla y pon en marcha software con Open DevOps
Material relacionado
¿Qué es la canalización de DevOps?
Despliegue continuo
La implementación continua va un paso más allá que la entrega continua. Mediante esta práctica, los cambios que pasan por todas las fases de tu canalización de producción se publican para tus clientes. No hay intervención humana y solo una prueba fallida evitará implementar un nuevo cambio en la producción.
La implementación continua es una excelente manera de acelerar el ciclo de feedback con tus clientes y aliviar la presión del equipo, puesto que ya no hay un día de publicación. Los desarrolladores pueden centrarse en crear software y ver los resultados minutos después de haber terminado.
¿Cómo se relacionan las prácticas entre sí?
Dicho en pocas palabras, la integración continua forma parte tanto de la entrega continua como de la implementación continua. Además, la implementación continua es como la entrega continua, salvo en que las versiones que se publican de forma automática.
¿Cuáles son las ventajas de cada práctica?
What are the benefits of each practice?
Hemos explicado la diferencia entre integración continua, entrega continua e implementaciones continuas, pero aún no hemos visto los motivos por los que adoptarlas. La implementación de cada práctica tiene un coste evidente, pero las ventajas lo superan con creces.
Integración continua
Qué se necesita (coste)
- Tu equipo tendrá que escribir pruebas automatizadas para cada nueva función, mejora o corrección de errores.
- Se necesita un servidor de integración continua que pueda monitorizar el repositorio principal y ejecutar las pruebas automáticamente para las nuevas confirmaciones enviadas.
- Los desarrolladores deben fusionar sus cambios con la mayor frecuencia posible, al menos, una vez al día.
Qué se gana
- La producción recibe menos errores a medida que las pruebas automatizadas van capturando regresiones de forma anticipada.
- Como todas las incidencias de integración se han resuelto pronto, es fácil compilar la publicación.
- Menos cambio de contexto, ya que los desarrolladores reciben un aviso en cuanto se rompe la compilación y pueden trabajar en la resolución del problema antes de pasar a la siguiente tarea.
- Los costes de las pruebas se reducen drásticamente: el servidor de CI puede ejecutar cientos de pruebas en cuestión de segundos.
- Tu equipo de control de calidad dedica menos tiempo a las pruebas y puede centrarse en mejoras significativas de la política corporativa de calidad.
Entrega continua
Qué se necesita (coste)
- Necesitas una base sólida en integración continua y tu conjunto de pruebas debe cubrir lo suficiente de tu base de código.
- Las implementaciones deben automatizarse. El desencadenador sigue siendo manual, pero, una vez iniciada la implementación, no es necesaria la intervención humana.
- Lo más probable es que tu equipo tenga que adoptar marcas de función para que las funciones incompletas no afecten a los clientes en la producción.
Qué se gana
- Se ha eliminado la complejidad de implementar software. Los equipos ya no tienen que estar días preparándose para una publicación.
- Puedes publicar más a menudo, de modo que se acelera el ciclo de feedback con tus clientes.
- Hay mucha menos presión sobre las decisiones cuando se trata de cambios pequeños, lo cual facilita las iteraciones más rápidas.
Despliegue continuo
Qué se necesita (coste)
- Tu cultura de pruebas debe ser la mejor. La calidad de tu conjunto de pruebas determinará la calidad de tus versiones.
- Tu proceso de documentación deberá seguir el ritmo de las implementaciones.
- Las marcas de función se convierten en una parte inherente del proceso de publicación de cambios significativos para asegurar que puedes coordinarte con otros departamentos (soporte, marketing, RR. PP., etc.).
Qué se gana
- Puedes desarrollar más rápido al no tener que detener el desarrollo de las publicaciones. Las canalizaciones de implementaciones se desencadenan automáticamente con cada cambio.
- Las publicaciones son menos arriesgadas y más fáciles de corregir en caso de que surjan problemas al implementar pequeños lotes de cambios.
- Los clientes ven una corriente continua de mejoras, y la calidad aumenta cada día, en lugar de cada mes, trimestre o año.
Uno de los típicos costes asociados a la integración continua es el de la instalación y mantenimiento de un servidor de CI. Sin embargo, se puede reducir significativamente el coste que supone adoptar estas prácticas mediante el uso de un servicio en la nube como Bitbucket Pipelines, que aporta automatización a cada repositorio de Bitbucket. Con solo añadir un archivo de configuración en la raíz del repositorio, podrás crear una canalización de implementación continua que se ejecute por cada nuevo cambio que se envíe a la rama principal.
El cambio de la integración continua a la implementación continua
Si acabas de empezar en un nuevo proyecto que todavía no tiene usuarios, puede resultarte sencillo implementar cada confirmación en la producción. Incluso podrías empezar automatizando tus implementaciones y publicando tu versión alfa en una producción sin clientes. A continuación, puedes aumentar tu política corporativa de pruebas y asegurarte de aumentar la cobertura de código al compilar tu aplicación. Cuando ya puedas incorporar a usuarios, contarás con un gran proceso de implementación continua en el que se someten a pruebas todos los cambios nuevos antes de publicarlos automáticamente en la producción.
Sin embargo, si ya cuentas con una aplicación con clientes, debes frenar el ritmo y comenzar con la integración y la entrega continuas. Empieza implementando pruebas unitarias básicas que se ejecuten automáticamente sin tener que concentrarte aún en ejecutar pruebas de extremo a extremo complejas. En lugar de ello, debes probar a automatizar tus implementaciones lo antes posible y llegar a una fase en la que las implementaciones se realicen automáticamente en tus entornos de ensayo. El motivo es que, si cuentas con implementaciones automáticas, podrás centrar tu energía en mejorar las pruebas en lugar de tener que detener las cosas periódicamente para coordinar una publicación.
Una vez que puedas publicar software a diario, puedes revisar la implementación continua, pero debes asegurarte de que el resto de tu organización (documentación, soporte, marketing, etc.) también esté listo. Estas funciones tendrán que adaptarse a la nueva cadencia de publicaciones, y es importante que no se pierdan cambios significativos que puedan afectar a los clientes.
Lee nuestras guías
Read our guides
Encontrarás algunas guías más detalladas con las que podrás ponerte en marcha con estas prácticas.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
La comunidad de DevOps
Leer el blog
