Integración Continua y Entrega Continua (CI/CD)

In julio 2, 2018

Uno de los objetivos de DEVOPS es reducir los tiempos de cada ciclo de desarrollo, es decir, reducir el tiempo necesario para que cada uno de los requisitos solicitados por los usuarios finales llegue a sus manos. Para que esto pueda ocurrir tiene que pasar por todas las etapas del ciclo de vida de la aplicación, es decir, debe realizar el análisis y diseño de la solución, se debe codificar y probar de forma aislada, se tiene que integrar con el resto de modificaciones, se tiene que implantar en los distintos entornos para que se realicen las pruebas oportunas hasta que finalmente es validado y liberado a Producción.

Para reducir el tiempo necesario en cada uno de estos pasos, DEVOPS propone la máxima automatización de cada uno de ellos, de forma que la intervención humana sea mínima y cuando realmente sea necesaria. En este sentido hay que destacar las técnicas de desarrollo en paralelo, integración continua, entrega continua y despliegue continuo.

Desarrollo en paralelo

El desarrollo en paralelo aporta a los equipos de desarrollo la posibilidad de aislar una versión con todas las fuentes permitiendo realizar modificaciones a esta sin alterar otras versiones que puedan estar siendo desarrolladas también en ese momento.

Es interesante tener en cuenta que el uso de entornos virtuales y “cloud” ha eliminado o minimizado una de las limitaciones históricas en este sentido ya que este enfoque requiere múltiples entornos de desarrollo (compartido), no el entorno local de cada desarrollador, de cara a realizar las pruebas iniciales.

Integración continua

Es un modelo propuesto por Martin Fowler que se basa en compilar, realizar el análisis de código estático y ejecutar pruebas automáticas de todo el proyecto lo más a menudo posible de cara a la detección temprana de errores.

El proceso se ejecuta de forma periódica, o bien según ciertos disparadores, y suele ser de la siguiente forma:

→Se descarga del control de versiones las últimas fuentes con los cambios implementados a un directorio de trabajo
→Se realiza la compilación de estas fuentes
→Se lanza el análisis estático y de cobertura de las fuentes
→Se instala en el entorno (compartido) de Desarrollo
→Se lanzan las pruebas automáticas
→Se generan los informes

Si alguno de estos pasos falla se da por errónea la ejecución y se notifica a los responsables oportunos.

Este enfoque permite la identificación temprana de errores ya que no se ha salido de la propia fase de desarrollo cuando se están encontrando posibles fallos o carencias en el código, por lo que es mucho más sencillo proceder a la subsanación de estos y se evita los cambios de última hora antes de la entrega.

Entrega continua y despliegue continuo

El objetivo es facilitar a los usuarios finales lo antes posible las modificaciones que ha realizado el desarrollo en la aplicación. Por lo que la entrega continua y el despliegue continuo pueden interpretarse como aplicar el concepto de integración continua al despliegue de aplicaciones.

Es importante tener en cuenta, que la entrega continua no consiste en desplegar en Producción cada cambio lo antes posible, sino que cada cambio debe de estar disponible para ser desplegado en cualquier momento.

Comienza una vez que la aplicación está construida y hay que implantarla en los siguientes entornos del ciclo de vida. Por ejemplo, entregar la nueva versión de la aplicación para QA para que pueda realizar las pruebas y finalmente entregarla a Operaciones para que pueda hacer su implantación en Producción.

El paradigma tanto de la entrega continua como del despliegue continuo es automatizar al máximo todas las acciones necesarias para implantar una nueva versión de la aplicación y todas las tareas necesarias para validar esa nueva versión. Por lo que cada vez que se obtiene una nueva versión de la aplicación desde la integración continua se validan los criterios de liberación para el siguiente entorno y así sucesivamente.

La diferencia principal entre la entrega continua y el despliegue continuo es que el primero requiere de una aprobación manual antes de implanta en Producción, mientras que el segundo,  incluso la puesta en producción, se realiza de forma automática una vez que se cubren todos los criterios definidos para la entrada en Producción para una aplicación.

Conclusiones

El uso adecuado de estas técnicas ofrecen la máxima flexibilidad ya que por un lado permite desarrollar cualquier necesidad de forma independiente para posteriormente integrarla con otras funcionalidades, construir, validar el código, desplegar en los distintos entornos intermedios, realizar las pruebas y finalmente implantar en Producción, poniendo en manos de los usuarios finales en el menor tiempo posible y con la mayor calidad, las nuevas funcionalidades implementadas y garantizando las funcionalidades anteriores.


En Altcomp somos Especialistas, Consultores e integradores de TI con 28 años de experiencia y proveemos infraestructura, herramientas, aplicaciones y servicios que facilitan a las empresas efectuar su transición del actual al nuevo paradigma computacional.

¡Concierte su cita con nosotros y con mucho gusto le asesoramos!

Fuente: DEVOPSTI

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.