Cómo funciona la integración continua y la entrega continua (CICD).

Si ha oído hablar de CICD y se pregunta qué significa o cómo funciona todo el proceso, este artículo lo ayudará a comprenderlo.

Si también siempre se encuentra en esa situación incómoda en la que no hay una demostración funcional para presentar ante un cliente listo para comprar, o se tarda una eternidad en lanzar actualizaciones para los usuarios finales, respire tranquilo, hay algo que se ha estado perdiendo llamado Integración continua y entrega continua.

La integración continua simplemente se refiere al proceso de enviar cambios de código a un repositorio central varias veces al día.

La entrega continua simplemente se refiere al proceso de trasladar los pequeños cambios integrados a los entornos de producción (el producto tal como lo utilizan los clientes).

Si usted es el gerente de negocios|producto de un equipo de desarrollo de software, probablemente debería hacer un paseo lunar por toda la habitación, porque CICD reduciría el tiempo de comercialización de cualquier característica que pretenda incorporar en su producto.

CICD tiene como objetivo eliminar los problemas en el ciclo de vida del desarrollo de software, incluido el control de versiones y el aumento de la velocidad de entrega de actualizaciones a los usuarios finales.

¿Qué quiero decir en realidad? La mayoría de los equipos que crean software sin CICD tienen dificultades comunes, especialmente con la integración de actualizaciones al software en vivo. Las cosas se ponen realmente complicadas, pueden surgir errores y puede ser difícil rastrear y resolver, puede ocurrir un comportamiento inesperado que deja a los desarrolladores sin idea y todo se reduce a una mala experiencia del cliente, rechazan su aplicación y continúan con sus vidas pacíficas.

La integración continua y la implementación continua crean una forma conveniente de mover el código de la computadora de un desarrollador al servidor en vivo que sirve a la aplicación con la que interactúan los usuarios finales. Ahora permítame desglosarlo por usted.

Imaginemos todo el CICD como un patrón que tiene algunos pasos, ahora también pintemos un escenario para enfatizar el funcionamiento interno de todo el proceso.

Por ejemplo, tenemos un equipo de desarrollo de software compuesto por 4 desarrolladores que tienen la intención de crear una aplicación de venta de automóviles. El primer paso sería revisar el documento de requisitos comerciales y crear historias de usuario para cubrir todos los casos de uso. A continuación, los desarrolladores pueden llegar a una conclusión sobre el(los) lenguaje(s) de programación a utilizar en la construcción de todo el proyecto. A continuación, si se trata de una aplicación PHP, los desarrolladores pueden optar por Laravel o Falcon. Hasta ahora, se han creado las historias de usuario y se ha establecido el marco, todo se ve muy bien.

A continuación, el equipo crea un repositorio en Github y realiza una confirmación inicial con una nueva instalación de su aplicación Laravel recién descargada. Fácil como la brisa, CICD sigue funcionando bien.

Ahora las historias aparecen en una herramienta de seguimiento y asignación de tareas como Pivotal tracker, Asana o Trello. Los desarrolladores se apresuran y recogen historias, la codificación ha comenzado.

oído hablar de la palabra TDD ¿antes de? Si es un acrónimo que te ha confundido en el pasado, me disculpo sinceramente por el golpe, no fue intencional. Test Driven Development (TDD) en palabras simples significa que la integridad de su código es examinada por alguna unidad o prueba de integración que ha escrito incluso antes de comenzar a escribir el código principal para esa función. Implica escribir primero una prueba unitaria para validar una cosa en particular antes de escribir el código principal para hacer esa cosa en particular. TDD se puede explicar fácilmente en comparación con la validación de formularios. Cuando se ingresa una entrada no válida o se ingresan credenciales incorrectas, el formulario se niega a enviar y el usuario nunca inicia sesión. En el desarrollo basado en pruebas, escribe validaciones para su código en forma de pruebas unitarias y si la implementación de su código real está fallando en las pruebas. , las confirmaciones de los desarrolladores nunca se implementarán en los servidores.

¿Por qué me tomé el tiempo para explicar TDD? Es porque sirve como una columna vertebral importante en el ciclo de vida de CICD. La calidad de sus pruebas y el nivel de cobertura de su prueba sirven como el guardián de la integración del código, y si su prueba es deficiente, el código con errores aún podría integrarse.

Ahora que tenemos TDD fuera de nuestro pecho, podemos continuar con nuestro flujo de CICD. Para estar seguro, permítanme reiterar, hasta ahora, cada uno de los 4 desarrolladores puede comprometerse con el mismo repositorio, también cumplen con TDD ya que escriben pruebas de calidad antes de escribir la implementación real.

A continuación, debemos integrar un servidor de compilación de CI (Integración continua), que pueda ejecutar automáticamente todas las pruebas que los desarrolladores han escrito desde que comenzaron a trabajar en el proyecto. Las aplicaciones de control de versiones como Github y Bitbucket pueden integrarse con varios servidores de integración continua como Circle CI, Travis Ci, Drone o bitbucket pipelines, por mencionar algunos. No olvide que los servidores de CI nos ayudan a ejecutar la prueba directamente en el repositorio y requieren que coloquemos un archivo .yml especial en el directorio raíz del repositorio del proyecto. Este archivo .yml contiene instrucciones sobre cómo el servidor de CI compilaría la aplicación y probaría el código. La configuración del archivo .yml depende del servidor de CI que se utilice, pero por lo general son similares en algunos aspectos, solo lea su documentación.

Ahora, con las mejores prácticas de TDD y un servidor de integración continua conectado directamente con nuestro repositorio, necesitaríamos asignar nuestras sucursales a varios entornos.

¿Has oído hablar de los entornos de producción, puesta en escena y desarrollo? Si no lo has hecho, no fue mi intención golpearte de nuevo. No se asuste, simplemente significa que la misma aplicación que está creando el equipo se ha implementado en 3 lugares diferentes con diferentes URL.

Por ejemplo:

http://development.carsales.com (Entorno de desarrollo)

http://staging.carsales.com (Entorno de puesta en escena)

http://carsales.com (Entorno de producción)

En su repositorio de Github, tendría que crear 3 ramas separadas, por ejemplo, desarrollar, preparar, dominar.

La asignación se realizaría en el archivo .yml, cada servidor de CI tiene documentación sobre cómo configurar el archivo .yml. Pero, por lo general, generalmente le brindan la capacidad de escribir instrucciones para cualquier cantidad de ramas en su repositorio.

Ejemplo:

rama: **desarrollar:

-ejecutar prueba

-empujar el código al servidor de desarrollo

sucursal: **escenario:

-ejecutar prueba

-empujar el código al servidor de ensayo

rama: **maestro:

-ejecutar prueba

-empujar el código al servidor de producción

La mayoría de las veces funciona, cada vez que se inserta código en cualquiera de las ramas especificadas en el archivo .yml, se ejecuta el script de compilación para esa rama y, si la compilación es exitosa, significa que el código es compatible y se puede ejecutar de forma segura. integrado. Después de lo cual, el código se implementaría automáticamente en el servidor especificado en la rama.

También tenga en cuenta que es una buena práctica que estas ramas especiales estén restringidas del empuje directo y permitan solo la fusión. Esto proporcionaría un enfoque estructurado de cómo se implementa su código en cualquiera de los entornos.

Por ejemplo:

La rama de desarrollo se fusionaría con staging, luego staging se fusionaría con master. Ninguno de los desarrolladores en ningún momento podría ingresar directamente a ninguna de estas 3 ramas especiales, sino que crean otras ramas y se fusionan en desarrollo. Desarrollar se convierte en la única fuente de verdad que sería promovida a las otras ramas.

Cuando el equipo de calidad realiza una prueba de aceptación del usuario en el entorno de prueba y lo encuentra estable, puede aprobar y las confirmaciones se fusionarán para dominar los cambios/nuevas características que se implementarán a los usuarios finales.

CICD es un salvavidas, la velocidad de implementación es insuperable, los errores se pueden rastrear y resolver fácilmente. Ahora que sabe cómo funciona, intente adoptarlo en su práctica de desarrollo de software. Salud

Similar Posts

Leave a Reply

Your email address will not be published.