Descargo de responsabilidad . Kostis Kapelonis: defensor del desarrollador Codefresh, la primera plataforma CI / CD para Kubernetes y contenedores, para defender y defender los principios del desarrollo de software. La misión de Codefresh "Automatizar y simplificar todo, desde el código hasta la nube". Como ingeniero de software, Kostis tiene muchos años de experiencia en aplicaciones de contenedores, construcción de canalizaciones de CI / CD y desarrollo de aplicaciones Java. Vive en Grecia y le encanta el patinaje sobre ruedas.
Como dice el refrán, "si algo causa dolor, hágalo con más frecuencia". La integración continua es, en esencia, una repetición del paso de integración con alta frecuencia para aliviar el "dolor" que causa. Este artículo trata sobre esto, sobre el "dolor" del desarrollo y cómo reducirlo.
Hay mucha información sobre la integración continua (CI) y la entrega continua (CD). Las publicaciones de blog usan términos técnicos para explicar qué significan las metodologías de CI / CD, qué hacen y cómo pueden ayudar a su empresa. Desafortunadamente, a menudo ambas metodologías están asociadas con herramientas específicas o incluso con proveedores de software. Una conversación típica sobre este tema en una empresa es:
- ¿Utiliza la integración continua en su equipo?
- Sí, por supuesto, ¡utilizamos la herramienta X!
Déjame contarte un pequeño secreto. La integración continua y la entrega son dos enfoques para el desarrollo de código que no tienen relación alguna con una herramienta o proveedor en particular. A pesar del hecho de que existen herramientas y soluciones que pueden ayudarlo en ambos casos (por ejemplo, Codefresh), en realidad, una empresa puede practicar CI / CD utilizando solo scripts de bash y scripts de línea única de Perl. Esto no es muy práctico, pero ciertamente es bastante posible.
Por lo tanto, en lugar de caer en la trampa general de explicar la esencia de CI / CD utilizando herramientas y términos técnicos, explicaremos en qué se basan estas metodologías en el factor más importante en el proceso de desarrollo: ¡las personas!
La historia de las personas: integración de software en tiempos difíciles
Conoce a Alice, Bob, Charlie, David y Elizabeth, todos trabajan para SoftwareCo Inc. sobre crear la aplicación SuperBigProject. Alice, Bob y Charlie son desarrolladores. David es ingeniero de pruebas y Elizabeth es gerente de proyectos de equipo.
La forma tradicional de desarrollar una aplicación es la siguiente: Alice, Bob y Charlie trabajan en tres funciones diferentes en su estación de trabajo. Cada desarrollador escribe y prueba el código individualmente. Utilizan largas ramas de funciones que existen durante varias semanas o incluso meses antes de combinarlas en un producto final.
En algún momento, la gerente de proyecto Elizabeth reúne a todo el equipo y dice: "Gente, ya tenemos que lanzar un lanzamiento, ¡así que intenten!"
Después de eso, Alice, Bob y Charlie intentan integrar las tres funciones en una sola rama. Este es un momento muy estresante porque estas características nunca se han probado juntas. Muchos errores y problemas aparecen de la nada, debido a suposiciones incorrectas o problemas con el entorno, porque, si recuerdas, hasta este punto todas las funciones se han probado simplemente en diferentes estaciones de trabajo, aisladas unas de otras.
Tan pronto como termine la "fiebre de la integración", el resultado combinado se transfiere a David, quien realizará pruebas manuales y automáticas adicionales. Este período también lleva mucho tiempo, porque es David quien puede aprobar o bloquear el lanzamiento, dependiendo de cuántos errores críticos se encuentren. Todos observan de cerca a David mientras él hace su parte, ya que probarlo puede revelar problemas serios que podrían retrasar el lanzamiento del producto.
Finalmente, la prueba se ha completado y Elizabeth anuncia con alegría que el producto de software está listo para su empaque y envío.
Entonces, ¿cómo se siente la gente en esta historia imaginaria pero muy realista?
- Los desarrolladores Alice, Bob y Charlie no están contentos porque siempre se enteran de los problemas de integración justo antes del lanzamiento. El período de integración es similar a un tiroteo en el que las balas llegan simultáneamente desde todos los lados.
- El probador David está constantemente nervioso debido a la naturaleza "nerviosa" de su trabajo: hay períodos tranquilos en los que solo espera hasta que los desarrolladores terminen de trabajar en las funciones, y hay una fase de prueba en la que simplemente está abrumado por el trabajo y debe lidiar con scripts de prueba inesperados, para Además, en este momento, el equipo de desarrollo literalmente lo respalda.
- Elizabeth, como gerente de proyectos, tampoco está contenta. La fase de integración es un enlace crítico en el proyecto. Este es un período ocupado, ya que cualquier problema inesperado empuja el lanzamiento del producto. Elizabeth sueña con un lanzamiento de software sin sorpresas, pero en la práctica esto nunca sucede. El "éxito" de la etapa de integración en la línea de tiempo planificada del proyecto es siempre un juego de adivinanzas.
En general, todos los miembros del equipo están descontentos. Por cierto, si su empresa todavía está desarrollando dicho software, intente comprender que este proceso de desarrollo es perjudicial para la moral de su equipo.
Entonces, aquí el único y principal problema es la fase de integración, que ocurre con cada lanzamiento del producto de software. Este es un punto de dolor en el flujo de trabajo que no permite que un equipo de programadores se libere de la situación estresante asociada con el lanzamiento del programa.
Añadiendo continuidad a la integración
Ahora que hemos visto lo que significa "integración", es muy fácil entender lo que significa "integración continua". Como dice el refrán, "si algo causa dolor, hágalo con más frecuencia". La integración continua es, en esencia, una repetición del paso de integración con alta frecuencia para aliviar el "dolor" que causa.
La forma más obvia de hacer que el proceso sea menos doloroso es integrarse con más frecuencia después de cada fusión, en lugar de esperar el lanzamiento oficial.
Cuando un equipo practica la integración continua, entonces:
- Todos los objetos se fusionan directamente en la rama principal.
- Los desarrolladores trabajan juntos, no de forma aislada. Todas las funciones se desarrollan desde la línea principal.
- Una función se considera desarrollada si la línea principal está completamente operativa y funciona en cualquier máquina, y no solo en una estación de trabajo separada.
- Las pruebas se realizan automáticamente tanto a nivel de elementos individuales u objetos de código, como a nivel de línea principal.
Esta es la esencia de la integración continua. Por supuesto, hay otros matices de esta metodología, hay un libro completo sobre este tema, pero lo principal es que, en lugar de un solo período estresante de integración, cuando todo se fusiona y se prueba al mismo tiempo, la integración ocurre todo el tiempo de manera continua.
La integración continua en el proceso de desarrollo de software es superior a la integración convencional porque:
- Reduce el número de sorpresas que aparecen al fusionar objetos de código.
- Resuelve el problema "el programa solo funciona en mi máquina".
- Divide el período de prueba en varios períodos, donde cada objeto de código se fusiona gradualmente con la línea principal, en lugar de fusionar todos los objetos a la vez.
Como resultado, el equipo que usa CI no se siente como una montaña rusa cuando los períodos tranquilos de desarrollo se entremezclan con liberaciones estresantes. Además, tiene la oportunidad de evaluar con seriedad cuán cerca está el proyecto de completarse, en lugar de adivinar las fechas de lanzamiento. El uso de CI es uno de los pilares del desarrollo moderno de software. Hoy este método está muy bien documentado y bien conocido. Por lo tanto, no puede haber justificación para el hecho de que su empresa todavía no practica CI en el desarrollo de proyectos de software.
Tiempos difíciles de entrega de software
Ahora que hemos analizado el historial de integración regular y cómo funciona la integración continua, podemos llevar esto al siguiente nivel del proceso de desarrollo: entrega continua. Si volvemos a nuestra historia original, veremos una imagen similar al proceso de integración normal:
El lanzamiento del producto fue esencialmente un evento similar al Big Bang. Después de que el software se consideró probado, alguien tuvo que completar el proceso de minimizar e implementar software desde contenedores. La implementación de software en producción también fue un período muy ocupado y tradicionalmente incluía muchos pasos manuales y procedimientos de seguimiento. Los despliegues eran muy raros, e incluso hoy en día hay empresas que realizan este procedimiento no más de una vez cada seis meses. Solo en casos extremos, el despliegue se realizó a la vez, cuando se usaba el modelo en cascada de desarrollo de software (cascada).
La entrega de software solo después de la fecha límite crea los mismos problemas que las integraciones regulares e infrecuentes:
- El entorno de producción suele ser diferente del entorno de prueba, que requiere una configuración adicional en el último minuto.
- Las funciones que funcionaron normalmente en un entorno de prueba se rompen en el entorno de trabajo.
- Las funciones que no estaban listas en el momento del lanzamiento, nunca se proporcionan a los clientes, o su refinamiento empuja el lanzamiento aún más.
- En este sentido, los lanzamientos crean tensión entre los desarrolladores que desean agregar nuevas funciones para expandir la funcionalidad del software y los operadores que desean estabilidad y no desean implementar demasiadas funciones nuevas a la vez.
La solución a este problema es la misma plantilla que en el caso de la integración. Si podemos aliviar el dolor del proceso de integración haciéndolo más frecuente, entonces podemos hacer lo mismo en el proceso de entrega de software.
Añadir continuidad a la entrega
La entrega continua es la práctica de empaquetar en contenedores y preparar el software como si se enviara a producción, con la mayor frecuencia posible. Y el método de entrega más extremo es después de cada fusión.
De esta manera, CD lleva a CI un paso más allá. Después de fusionar cada función con la rama de línea principal, la aplicación no solo se verifica para su corrección, sino que también se empaqueta y se implementa en un entorno de prueba que coincide perfectamente con el entorno de trabajo. Todo esto sucede en un modo totalmente automático: preste atención a la ausencia en la figura de los pequeños hombres que indican procedimientos manuales.
También tenga en cuenta que cada nueva característica es un candidato potencial para el lanzamiento a producción. En la práctica, no todos los candidatos son enviados a producción. Dependiendo de la organización del proceso, la decisión de desplegarse en la producción a veces requiere la intervención de una persona responsable que decida si lanzar la liberación a producción o no, pero no participa personalmente en la preparación de la liberación. En este punto, la versión ya está empaquetada, probada e implementada en un entorno de prueba.
La entrega continua (CD) es un poco más complicada que la integración continua (CI). La razón es que, dado que cada candidato de lanzamiento puede potencialmente lograr la producción, el ciclo de vida completo debe automatizarse:
- Las asambleas deben ser repetibles y deterministas.
- Todos los pasos deben ser automatizados, lo cual es bastante difícil de poner en práctica.
- Toda la configuración y los archivos relacionados deben existir en el sistema de control de versiones, y no solo en el código fuente.
- Cada característica / versión debe probarse en su propio entorno de prueba creado dinámicamente y destruido dinámicamente.
- Todos los conjuntos de pruebas deben ser automatizados y relativamente rápidos, lo que tampoco es una tarea fácil.
Aunque una "nube" ciertamente puede ayudar a cumplir con todos estos requisitos, un equipo de programadores, tanto desarrolladores como operadores, necesita un cierto nivel de disciplina que realmente asegure el proceso de entrega continua de software.
Después de la introducción de lanzamientos de CD se convierte en una rutina, como si se llevara a cabo con un simple clic de un botón. Cada miembro del equipo, no solo el gerente del proyecto, puede ver el candidato de lanzamiento actual. Es posible que este candidato no tenga algunas funciones requeridas o que no satisfaga completamente todos los requisitos, pero esto no es absolutamente importante hasta que afecte el proceso de lanzamiento en sí.
El hecho importante es que la versión está completamente probada, empaquetada y lista para ser enviada a producción si es necesario. Al mismo tiempo, cualquier participante del proyecto debería poder dar luz verde y lanzar inmediatamente el software para la producción.
Si usa un CD, el ciclo de vida del software se puede representar de la siguiente manera:
Cada candidato de liberación siempre está preparado de antemano. La persona decide si el candidato a la liberación también será nominado para la producción. Los candidatos de lanzamiento que no alcanzan la producción continúan almacenándose como artefactos en caso de que necesiten ser utilizados en el futuro.
Para su información, sobre la entrega continua, así como sobre la integración continua, también se ha escrito un libro completo del que puede encontrar los detalles de esta metodología.
Bonificación: Despliegue continuo
La letra "D" en el CD puede significar implementación de implementación, no entrega de entrega. Este enfoque del proceso de desarrollo se basa en la entrega continua y esencialmente elimina la intervención humana. Cualquier candidato para el lanzamiento, que pasará todas las pruebas y controles de calidad y será reconocido como listo, es enviado inmediatamente a producción.
Es cierto que solo un número muy pequeño de empresas pueden operar de esta manera. La promoción a la producción sin participación humana no debe tomarse a la ligera, ya que al momento de escribir este artículo, muchas compañías ni siquiera practican la entrega continua, sin mencionar el despliegue continuo.
Debe comprender que cada enfoque posterior al proceso de desarrollo se basa en la implementación del enfoque anterior.
Antes de avanzar por el camino de la mejora, su empresa debe asegurarse de que cada uno de los fundamentos del proceso sea realmente sólido. En Codefresh vimos a muchas compañías que tenían la intención de cambiar a tecnologías en la nube, tratando de reequipar sus tecnologías optimizadas para su uso en centros de datos en tuberías de CI / CD, sin darse cuenta de que algunas de estas tecnologías están desactualizadas hoy en día. Intentar implementar una implementación continua sin abarcar completamente la entrega continua está condenada al fracaso.
La siguiente figura muestra qué etapas del proceso de desarrollo e implementación de software de Alice, Bob, Charlie, David y Elizabeth cubren CD e IC.
Asegúrese de abordar cada paradigma de desarrollo de software en el orden correcto. Cree que la introducción de la entrega continua es un objetivo muy realista, para cuya implementación existen todas las herramientas necesarias.
Un poco de publicidad :)
Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos,
VPS en la nube para desarrolladores desde $ 4.99 , un
descuento del 30% para usuarios de Habr en un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 Núcleos) 10GB DDR4 240GB SSD 1Gbps desde $ 20 o ¿cómo compartir un servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato? ¡Solo tenemos
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?