[:es]

Comencemos definiendo qué es CI/CD. La Integración Continua (CI) y la Implementación/Entrega Continua (CD) son prácticas que automatizan los pasos que se deben realizar para lanzar nuevas versiones de software con las siguientes ventajas:

1. La entrega de software a los clientes se puede lograr de manera más rápida y eficiente.
2. Reducir el tiempo para publicar las aplicaciones en el entorno de producción.
3. Se puede mejorar la calidad del código al incluir pruebas automáticas y herramientas de análisis de código estático.

Pero, ¿cómo sucede esto?

La Integración Continua reduce el riesgo de problemas de integración y mejora la calidad del código. Los desarrolladores envían sus cambios al repositorio de código de manera regular y comprueban si el repositorio de código sigue funcionando cuando otros desarrolladores están contribuyendo. Más que un componente técnico, la Integración Continua es un componente cultural donde los desarrolladores aprenden buenas prácticas para integrar sus cambios con frecuencia.

Por lo tanto, hemos integrado GitFlow en nuestro flujo de trabajo de desarrollo de software. Nos ha ayudado a aplicar buenas prácticas para trabajar colectivamente, mantener el historial de nuestros repositorios coherente y reducir significativamente el riesgo de problemas de integración e introducción de errores.

Estas son algunas herramientas que necesitas para aplicar los principios de CI:

1. Un sistema de control de versiones para almacenar tu código base.
2. Scripts de compilación automatizados.
3. Pruebas automatizadas.
4. Infraestructura (máquinas virtuales) para ejecutar tus pruebas y compilaciones.

Un servidor de CI tiene las siguientes misiones:

1. Monitorear tu repositorio en busca de cambios publicados por los desarrolladores.
2. Ejecutar pruebas automatizadas, si las pruebas no pasan, los cambios no se fusionarán en el código base.

¿Es la entrega continua el siguiente paso?

Después de completar todos los pasos de la Integración Continua, entra en juego la Entrega Continua. Esta práctica automatiza algunos de los pasos necesarios para entregar nuestras soluciones al entorno de producción.

La entrega continua integra un conjunto de procesos, herramientas y una cultura de colaboración y retroalimentación continua para cumplir con la misión. Un cambio de mentalidad de tu equipo es importante para:

1. Comprender que tu nueva característica no está completa cuando el otro equipo se encarga de ella.
2. La característica está completa cuando se ha lanzado en producción. Crear prácticas para comprender mejor lo que se necesita para entregar nuevas características a los usuarios a través del ciclo de vida de desarrollo de software.
3. Mantener una comunicación abierta con otros equipos, la colaboración y la retroalimentación son muy importantes.

Implementar un pipeline requiere identificar los puntos problemáticos y cuellos de botella que podrían afectar el proceso de entrega, e implementar prácticas para detectar errores temprano es relevante. Después de identificar estos elementos, piensa en cuáles se pueden automatizar (no es obligatorio automatizar todos ellos), es muy relevante gestionar algunos escenarios manualmente. Esto es lo que llamamos puertas manuales, algunos de ellos pueden ser cuestionables, mientras que otros pueden ser legítimos.

Pero, ¿qué es un escenario legítimo o cuestionable?

Escenario legítimo:

• Permite al equipo comercial tomar una decisión de lanzamiento de último minuto.
• Como ejemplos tenemos: han detectado que alguna característica importante muestra fallas, alertas de monitoreo de entornos de desarrollo o puesta en escena.
• El equipo comercial toma la decisión final de lanzar el producto a los clientes, con todas las aprobaciones requeridas.

Escenario cuestionable:

• Simplemente no apliques el enfoque de todo o nada, esto se relaciona con subsistemas que construyen un sistema. Esto significa que cuando falla la implementación de un subsistema, debes revertir la implementación del sistema completo.

Otro paso importante para la entrega continua es definir una etapa casi igual a la producción para validar las configuraciones del entorno y realizar pruebas manuales. Esto ayuda a avanzar con la auditoría de seguridad, encontrar vulnerabilidades y detectar errores temprano. Tendrás mucho espacio para mejorar.

¿Y qué hay de la implementación continua?

La última práctica que se puede aplicar es la implementación continua, donde la integración continua y la entrega continua se llevan al extremo, haciendo que este proceso sea completamente automatizado.

El código enviado por los desarrolladores se prueba, compila e implementa automáticamente sin intervención manual. Grandes empresas han adoptado esta práctica, incluyendo elementos para validar las versiones en producción con la ayuda de sus usuarios y evitar posibles indisponibilidades de servicios:

• Despliegues en canarios: limitan la implementación de nuevo código a algunos usuarios. Esto es importante para detectar fallas, recibir comentarios y obtener métricas como el uso y el consumo de recursos.
• Despliegues Azul/Verde: El nuevo código se ejecuta en paralelo con la versión anterior, luego se comparan las métricas y el comportamiento con la línea de base y se toma la decisión de implementar por completo la nueva versión o revertir al código anterior.

¿Cuáles son las herramientas recomendadas para CI/CD?

No queremos crear un ranking o algo así, a lo largo de los años hemos visto proyectos que han implementado soluciones con estas herramientas:

• Gitlab
• Jenkins
• Github Actions
• AWS CodePipeline
• Travis CI
• Circle CI

Conclusión

No es tan importante conocer todos los detalles o la semántica de las diferencias entre la integración continua, la entrega continua y la implementación continua. En este punto, deberías poder identificar los conceptos, pasos, prácticas y beneficios de comenzar con la implementación de esta cultura en tus proyectos.

Finalmente…

Esta publicación ha sido escrita con el apoyo y la colaboración de Fernanda Jaramillo e  Ihann Pascuas Ihann Pascuas. Gracias a  Ayté y TBBC  por proporcionar las herramientas y proyectos para validar estas ideas.

Todo lo mejor, no dudes en contactarnos si tienes preguntas.

Esteban Cerón

[:en]

Let’s start by defining what CI/CD is. Continuous Integration (CI) and Continuous Deployment/Delivery (CD) are practices that automate the steps that must be performed to release new versions of software with the following advantages:

1. The software delivery to the clients can be achieved faster and efficiently
2. Reduce the time to publish the applications to the production environment
3. The code quality can be improved by including automatic tests and static code analysis tools

But, how does this happen?

Continuous Integration reduces the risk of integration issues and improves code quality. Developers commit their changes to the codebase regularly and check whether the codebase still works when other developers are contributing. More than a technical component, Continuous Integration is a cultural component where developers learn good practices to integrate their changes frequently.

Therefore, we have integrated GitFlow in our software development workflow. It has helped us to apply good practices to work collectively, keep the history of our repositories consistent and reduce significantly the risk of integration issues and bugs introduction.

These are some tools you need to apply the principles of CI:

1. A source or version control system to store your codebase
2. Automated build scripts
3. Automated tests
4. Infrastructure (Virtual Machines) to run your tests and builds

A CI server has the following missions:

1. Monitor your repository looking for changes published by developers
2. Run automated tests, if tests don’t pass the changes won’t be merged into the code base

Is continuous delivery the next step?

After all steps of Continuous Integration have been completed, Continuous Delivery takes place. This practice automates some of the steps required to deliver our solutions to the production environment.

Continuous delivery integrates a set of processes, tools and a culture of collaboration and continuous feedback to accomplish the mission. A change of mentality of your team is important to:

1. Understand that your new feature is not done when the other team takes care of it. The feature is done when it has been released in production
2. Create practices to better understand what is needed to deliver new features to users through the software development lifecycle
3. Maintaining open communication with other teams, collaboration and feedback is very important

Implementing a pipeline requires the identification of pain points and bottlenecks that could affect the delivery process, and implementing practices to detect bugs early is relevant. After you have identified these items, think about which ones can be automated (it is not mandatory to automate all of them), it is very very relevant to manage some scenarios manually. This is what we call manual gates, some of them might be questionable, whereas some could be legitimate.

But what is a legitimate or questionable scenario?

Legitimate scenario:

• Allows the business team to make a last-minute release decision. As examples we have: They have detected that some important feature is showing failures, monitoring alerts from dev or staging environments
• The business team makes the final decision to release the product to the customers, with all the approvals required

Questionable scenario:

• Just don’t apply the all-or-none approach, this is related to subsystems building a system. This means that when a subsystem deployment fails you have to roll back the deployment of the entire system

Another important step for continuous delivery is the definition of one stage almost equal to production to validate environment configurations and execute manual testing is helpful to advance with the security audit, find vulnerabilities and detect bugs early. You are going to have a lot of space to improve.

What about continuous deployment?

The final practice you can apply is continuous deployment where continuous integration and continuous delivery are taken to the extreme making this process entirely automated.

The code pushed by developers is automatically tested, built and deployed without any manual intervention. Big companies have adopted this practice including elements to validate the releases in production with help of their users and avoid potential unavailability of services:

• Canary deployments: limits the deployment of new code to some users. This is important to detect failures, receive feedback and obtain some metrics like usage and resources consumption
• Blue/Green deployments: The new code runs in parallel with the previous version, then you compare the metrics and behavior with the baseline and take the decision of completely deploying the new version or rolling back to the previous code

What are the recommended tools for CI/CD?

We don’t want to create a ranking or something like that, thru the years we’ve seen projects that have implemented solutions with these tools:

• Gitlab
• Jenkins
• Github Actions
• AWS CodePipeline
• Travis CI
• Circle CI-

Conclusion

It is not All-important to know every detail or the semantics about the differences between continuous integration, continuous delivery and continuous deployment. At this point you should be able to identify the concepts, steps, practices and benefits of starting with the implementation of this culture in your projects.

Finally…

This post has been written with the support and collaboration of Fernanda Jaramillo and Ihann Pascuas, Thanks to Ayté and TBBC for providing the tools and projects to validate these ideas.

All the best, don’t hesitate to contact us if you have questions.

Esteban Cerón

[:]