La entrega continua es la práctica de implementar (o estar listo para implementar) en producción cualquier tipo de cambio, que incluye:
Esta implementación se realiza en frecuente, automática, repetible, de confianza y auditable camino. Cuando estos cambios pasan directamente a la producción, estamos haciendo estrictamente Despliegue continuo. Si hay un paso de aprobación manual antes de la implementación, entonces decimos que lo estamos haciendo Entrega continua.
Al practicar la CI/CD, hay varios aspectos que creemos que deben tenerse en cuenta para una implementación exitosa:
La práctica hace al maestro, por lo que cuanto más difícil sea algo para nosotros, más debemos ejercitarlo. Con frecuencia, es difícil empezar a implementar una canalización de CI/CD, especialmente para un sistema existente. El consejo es abordarlo para un nuevo proyecto totalmente nuevo y hacerlo de forma gradual. Es decir, podríamos crear otras etapas o cambiar la canalización más adelante, pero al menos deberíamos poder implementarlas en un entorno de pruebas incluso antes de añadir cualquier línea de código. Implemente un hola mundo programa mediante el uso de un hola pipeline.
Por supuesto, esto se puede hacer para los sistemas existentes, pero es necesario evaluar otros aspectos, como si tiene sentido cortar o refactorizar el código de antemano, qué tan buenas son las pruebas automáticas (si las hay), etc. Un tema para otra publicación.
A medida que el proyecto crece y se implementan más funciones, también lo hace la cartera. Al igual que el código, debemos mantenerlo simple y ceñirnos al propósito: crear, probar e implementar en producción. Sencillo. Si necesitamos añadir etapas adicionales que no contribuyan a esos objetivos, si necesitamos añadir scripts de construcción y prueba complejos (por ejemplo, con muchas líneas o bifurcaciones), si necesitamos pasos de aprobación adicionales, es probable que tengamos problema de diseño en nuestro sistema. Este es un indicador de que debemos dar un paso atrás y analizar por qué se necesita tanta complejidad en trámite.
Además, intenta no añadir una lógica que compruebe el estado de los sistemas externos (incluidas otras canalizaciones). Nuestra canalización debería poder funcionar en cualquier momento independientemente de otros sistemas. Una vez más, si este no es el caso, podría ser un síntoma de un mal diseño de arquitectura.
Un conjunto de pruebas automáticas es imprescindible para implementar correctamente una canalización de CI/CD. En otras palabras, no es posible practicar la entrega continua sin pruebas automáticas. Además, se necesitan pruebas de alta calidad y bien redactadas para garantizar la exactitud de cada cambio que se implemente en la producción y ganar confianza en el proceso. Es decir, si pasa las pruebas, es probable que no estemos rompiendo nada en la nueva versión.
La forma de escribir estas pruebas está fuera del alcance de esta publicación, pero aquí hay algunos consejos que debes tener en cuenta:
Es obvio que para implementar la entrega continua primero necesitamos implementar con éxito la integración continua. Y eso implica:
Todo es código. Aplicamos prácticas de código limpio a nuestro código y deberíamos hacer lo mismo con nuestras pruebas (consulte #3), los archivos de configuración, los datos y la infraestructura. Cualquier aspecto configurable de nuestro sistema debe tener el código fuente controlado para cada entorno en el que lo implementemos. Esto incluye nuestro software y la infraestructura subyacente necesaria para ejecutar nuestro software. En el caso de los datos, debemos controlar el código fuente de todos los cambios en el esquema, así como los datos no generados por el usuario (por ejemplo, los datos constantes).
Se recomienda encarecidamente la infraestructura como código (IASC). No es necesario reinventar la rueda, ya que puede aprovechar las funciones de iASC que ofrecen los proveedores de la nube (por ejemplo, Terraform, Cloud Formation, CDK, etc.).
Lo ideal es que un repositorio contenga todo lo necesario para ejecutar el sistema: el código, las pruebas, las configuraciones, los datos y la infraestructura (incluida la canalización). Puede haber excepciones en las que podría tener sentido separar el iASC del código en sí, pero asegúrate de tener una buena razón para hacerlo.
Si utilizamos iASC de un proveedor de nube, la posibilidad de realizar despliegues azul/verdes es gratuita, ya que se puede configurar. Esto normalmente se implementa con un cambio en el DNS o en el balanceador de cargas, según lo que usemos. En cualquier caso, podemos ir tan lejos como instalar un nuevo servidor azul y destruir el servidor verde actual, o viceversa, sin problemas en cada confirmación y cada pocos segundos, sin ninguna intervención manual y con la plena confianza de que romper algo es realmente insignificante.
Para ganar aún más confianza, podemos usar las versiones canarias y la opción de alternar funciones, dos técnicas que se complementan entre sí y con las implementaciones azul/verde, que funcionan muy bien juntas.
Poner en marcha cada confirmación no significa lanzar una nueva función a los usuarios cada vez. El código que implementa (total o parcialmente) la función podría estar activo y, por lo tanto, integrado, pero no necesariamente expuesto. En otras palabras, puede ocultarse detrás de una palanca y solo pueden acceder a ella quienes la tengan activada. La palanca se puede implementar simplemente codificando un si entonces en el código (recuerda que todas las confirmaciones pueden publicarse, por lo que podemos eliminar el interruptor codificado con cualquier confirmación futura). El conmutador también se puede implementar mediante la configuración o de forma tan sofisticada como usar un sistema externo con su propia interfaz y canalización. Una vez más, favorezca las soluciones simples y evite la complejidad cuando sea posible.
Las versiones de Canary implican lanzar la función a un número reducido de usuarios. Esto no es obligatorio para lograr la entrega continua, pero podría ser muy útil para detectar posibles problemas y minimizar el impacto. Por otro lado, no es conveniente tener varias versiones implementadas para diferentes usuarios, ya que esto puede ser un verdadero quebradero de cabeza para la administración. Así pues, los canarios salen a la venta y en poco tiempo, si no se detecta ningún problema, el lanzamiento recibe todo el tráfico. Prepárate técnicamente para dirigir el tráfico de esa manera, incluso cuando no utilices canarios.
Por último, pero no por ello menos importante, otro aspecto crucial para poder implementar la entrega continua es la rapidez con la que el equipo puede reaccionar ante los problemas y resolverlos. Los problemas surgirán y no se trata de evitarlos (algo que sería imposible de hacer) sino de minimizar el impacto y solucionarlos lo antes posible.
Los cambios pequeños y frecuentes son buenos porque nos permiten tener un control total y aislar el problema fácilmente. Pero aún necesitamos detectarlos, por lo que es aquí donde entran en juego las alertas y la supervisión de nuestro sistema.
Además, queremos anticiparnos a los posibles problemas: en lugar de descubrir que nuestro sistema no funciona porque algunos usuarios se han quejado, queremos que nos avisen cuando no se cumplen ciertas métricas, por ejemplo, si una cola supera un tamaño determinado, el tiempo medio de una solicitud ha tardado demasiado en los últimos 5 minutos o acabamos de recibir unos 500.
En cualquier caso y para lo que tenga sentido en nuestro proyecto, queremos que nos avisen de cualquier problema o posible problema. La sugerencia es abordarlo desde el principio del sistema y mantenerlo evolucionando con el tiempo. Un buen panel de control en el que podamos ver de un vistazo el estado de nuestro sistema y unas buenas métricas en las que podamos recibir alertas en caso de desviaciones son imprescindibles.
La entrega continua es la práctica de implementar (o estar listo para implementar) en producción cualquier tipo de cambio, que incluye:
Esta implementación se realiza en frecuente, automática, repetible, de confianza y auditable camino. Cuando estos cambios pasan directamente a la producción, estamos haciendo estrictamente Despliegue continuo. Si hay un paso de aprobación manual antes de la implementación, entonces decimos que lo estamos haciendo Entrega continua.
Al practicar la CI/CD, hay varios aspectos que creemos que deben tenerse en cuenta para una implementación exitosa:
La práctica hace al maestro, por lo que cuanto más difícil sea algo para nosotros, más debemos ejercitarlo. Con frecuencia, es difícil empezar a implementar una canalización de CI/CD, especialmente para un sistema existente. El consejo es abordarlo para un nuevo proyecto totalmente nuevo y hacerlo de forma gradual. Es decir, podríamos crear otras etapas o cambiar la canalización más adelante, pero al menos deberíamos poder implementarlas en un entorno de pruebas incluso antes de añadir cualquier línea de código. Implemente un hola mundo programa mediante el uso de un hola pipeline.
Por supuesto, esto se puede hacer para los sistemas existentes, pero es necesario evaluar otros aspectos, como si tiene sentido cortar o refactorizar el código de antemano, qué tan buenas son las pruebas automáticas (si las hay), etc. Un tema para otra publicación.
A medida que el proyecto crece y se implementan más funciones, también lo hace la cartera. Al igual que el código, debemos mantenerlo simple y ceñirnos al propósito: crear, probar e implementar en producción. Sencillo. Si necesitamos añadir etapas adicionales que no contribuyan a esos objetivos, si necesitamos añadir scripts de construcción y prueba complejos (por ejemplo, con muchas líneas o bifurcaciones), si necesitamos pasos de aprobación adicionales, es probable que tengamos problema de diseño en nuestro sistema. Este es un indicador de que debemos dar un paso atrás y analizar por qué se necesita tanta complejidad en trámite.
Además, intenta no añadir una lógica que compruebe el estado de los sistemas externos (incluidas otras canalizaciones). Nuestra canalización debería poder funcionar en cualquier momento independientemente de otros sistemas. Una vez más, si este no es el caso, podría ser un síntoma de un mal diseño de arquitectura.
Un conjunto de pruebas automáticas es imprescindible para implementar correctamente una canalización de CI/CD. En otras palabras, no es posible practicar la entrega continua sin pruebas automáticas. Además, se necesitan pruebas de alta calidad y bien redactadas para garantizar la exactitud de cada cambio que se implemente en la producción y ganar confianza en el proceso. Es decir, si pasa las pruebas, es probable que no estemos rompiendo nada en la nueva versión.
La forma de escribir estas pruebas está fuera del alcance de esta publicación, pero aquí hay algunos consejos que debes tener en cuenta:
Es obvio que para implementar la entrega continua primero necesitamos implementar con éxito la integración continua. Y eso implica:
Todo es código. Aplicamos prácticas de código limpio a nuestro código y deberíamos hacer lo mismo con nuestras pruebas (consulte #3), los archivos de configuración, los datos y la infraestructura. Cualquier aspecto configurable de nuestro sistema debe tener el código fuente controlado para cada entorno en el que lo implementemos. Esto incluye nuestro software y la infraestructura subyacente necesaria para ejecutar nuestro software. En el caso de los datos, debemos controlar el código fuente de todos los cambios en el esquema, así como los datos no generados por el usuario (por ejemplo, los datos constantes).
Se recomienda encarecidamente la infraestructura como código (IASC). No es necesario reinventar la rueda, ya que puede aprovechar las funciones de iASC que ofrecen los proveedores de la nube (por ejemplo, Terraform, Cloud Formation, CDK, etc.).
Lo ideal es que un repositorio contenga todo lo necesario para ejecutar el sistema: el código, las pruebas, las configuraciones, los datos y la infraestructura (incluida la canalización). Puede haber excepciones en las que podría tener sentido separar el iASC del código en sí, pero asegúrate de tener una buena razón para hacerlo.
Si utilizamos iASC de un proveedor de nube, la posibilidad de realizar despliegues azul/verdes es gratuita, ya que se puede configurar. Esto normalmente se implementa con un cambio en el DNS o en el balanceador de cargas, según lo que usemos. En cualquier caso, podemos ir tan lejos como instalar un nuevo servidor azul y destruir el servidor verde actual, o viceversa, sin problemas en cada confirmación y cada pocos segundos, sin ninguna intervención manual y con la plena confianza de que romper algo es realmente insignificante.
Para ganar aún más confianza, podemos usar las versiones canarias y la opción de alternar funciones, dos técnicas que se complementan entre sí y con las implementaciones azul/verde, que funcionan muy bien juntas.
Poner en marcha cada confirmación no significa lanzar una nueva función a los usuarios cada vez. El código que implementa (total o parcialmente) la función podría estar activo y, por lo tanto, integrado, pero no necesariamente expuesto. En otras palabras, puede ocultarse detrás de una palanca y solo pueden acceder a ella quienes la tengan activada. La palanca se puede implementar simplemente codificando un si entonces en el código (recuerda que todas las confirmaciones pueden publicarse, por lo que podemos eliminar el interruptor codificado con cualquier confirmación futura). El conmutador también se puede implementar mediante la configuración o de forma tan sofisticada como usar un sistema externo con su propia interfaz y canalización. Una vez más, favorezca las soluciones simples y evite la complejidad cuando sea posible.
Las versiones de Canary implican lanzar la función a un número reducido de usuarios. Esto no es obligatorio para lograr la entrega continua, pero podría ser muy útil para detectar posibles problemas y minimizar el impacto. Por otro lado, no es conveniente tener varias versiones implementadas para diferentes usuarios, ya que esto puede ser un verdadero quebradero de cabeza para la administración. Así pues, los canarios salen a la venta y en poco tiempo, si no se detecta ningún problema, el lanzamiento recibe todo el tráfico. Prepárate técnicamente para dirigir el tráfico de esa manera, incluso cuando no utilices canarios.
Por último, pero no por ello menos importante, otro aspecto crucial para poder implementar la entrega continua es la rapidez con la que el equipo puede reaccionar ante los problemas y resolverlos. Los problemas surgirán y no se trata de evitarlos (algo que sería imposible de hacer) sino de minimizar el impacto y solucionarlos lo antes posible.
Los cambios pequeños y frecuentes son buenos porque nos permiten tener un control total y aislar el problema fácilmente. Pero aún necesitamos detectarlos, por lo que es aquí donde entran en juego las alertas y la supervisión de nuestro sistema.
Además, queremos anticiparnos a los posibles problemas: en lugar de descubrir que nuestro sistema no funciona porque algunos usuarios se han quejado, queremos que nos avisen cuando no se cumplen ciertas métricas, por ejemplo, si una cola supera un tamaño determinado, el tiempo medio de una solicitud ha tardado demasiado en los últimos 5 minutos o acabamos de recibir unos 500.
En cualquier caso y para lo que tenga sentido en nuestro proyecto, queremos que nos avisen de cualquier problema o posible problema. La sugerencia es abordarlo desde el principio del sistema y mantenerlo evolucionando con el tiempo. Un buen panel de control en el que podamos ver de un vistazo el estado de nuestro sistema y unas buenas métricas en las que podamos recibir alertas en caso de desviaciones son imprescindibles.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.jpeg)
