Entrega continua
La entrega continua (CD) consiste en automatizar la publicación de software en iteraciones breves
¿Qué es la entrega continua?
La entrega continua constituye un enfoque en el que los equipos publican productos de calidad con frecuencia y de forma predecible desde repositorios de código fuente hasta la producción de forma automatizada.
Algunas organizaciones publican productos de forma manual al pasarlos de un equipo a otro, como puedes ver en el siguiente gráfico. Normalmente, los desarrolladores se encuentran en el extremo izquierdo de este espectro, y el personal de operaciones se encuentra en el extremo receptor. Esto produce un retraso en cada entrega, lo que provoca la frustración de los equipos y la insatisfacción de los clientes. El producto acaba publicándose mediante un proceso tedioso y propenso a errores que retrasa la generación de ingresos.
Figura 1: Publicación manual de productos para los clientes
Ahora echa un vistazo a la canalización de entrega continua que se muestra a continuación. Verás que los desarrolladores escriben código en sus portátiles y confirman esos cambios en un repositorio de código fuente, como Bitbucket. Con "código" nos referimos a los sistemas en fase de prueba, las pruebas en sí y la infraestructura que se usará para implementar y mantener el sistema. Bitbucket Pipelines puede lanzar el producto de la fase de pruebas al entorno de ensayo y a la producción, y así ayudar a los clientes a obtener estupendas funciones nuevas.
Figura 2: Canal de entrega continua haciendo publicaciones automatizadas
¿Cómo funciona la entrega continua?
Un canal de entrega continua puede tener una puerta manual antes de la producción. Una puerta manual requiere intervención humana, y pueden darse situaciones en tu organización que requieran puertas manuales en los canales. Algunas puertas manuales pueden plantear dudas, pero otras pueden ser legítimas. Una situación legítima permite que el equipo empresarial tome decisiones de publicación de última hora. El equipo de ingeniería mantiene preparada una versión que se puede lanzar del producto después de cada sprint, y el equipo empresarial toma la decisión final de publicar el producto para todos los clientes, para un conjunto transversal de la población o para gente que vive en una ubicación geográfica concreta.
La arquitectura del producto que fluye por el canal es un factor clave que determina la anatomía del canal de entrega continua. La arquitectura de un producto muy vinculado genera un complejo patrón de canal gráfico en el que se podrían entrelazar diversos canales antes de llegar a la producción.
La arquitectura del producto también influye en las diferentes fases del canal y en los artefactos que se producen en cada fase. El canal compila componentes en primer lugar (las unidades del producto distribuibles y que se pueden probar más pequeñas). Por ejemplo, una biblioteca compilada por el canal se puede denominar "componente". Esta es la fase de los componentes.
Los componentes poco vinculados conforman los subsistemas: las unidades implementables y ejecutables más pequeñas. Por ejemplo, un servidor es un subsistema. Un microservicio ejecutado en un contenedor es también un ejemplo de subsistema. Esta es la fase de los subsistemas Al contrario que los componentes, los subsistemas se pueden extraer y probar.
Se podría enseñar a la canalización a ensamblar un sistema a partir de subsistemas poco vinculados en aquellas instancias en las que todo el sistema debe publicarse como una unidad. Es la fase de sistemas.
Desaconsejamos este modelo, en el que varios subsistemas se montan en uno solo. Puedes ver un ejemplo en la figura 3.
Figura 3: Subsistemas combinados en un sistema
Este enfoque de todo o nada provoca que los subsistemas más rápidos funcionen al ritmo del más lento. Usamos el dicho "una cadena es tan fuerte como su eslabón más débil" para advertir a los equipos que caen presos de este patrón arquitectónico.
Una vez que se haya validado, el sistema montado se enviará a producción sin ninguna modificación posterior; esta es la última fase, la fase de producción.
Ten en cuenta que estas fases son más un concepto lógico que físico, y solo se crean para desglosar un problema de mayor tamaño en problemas secundarios más pequeños. Puedes tener más o menos fases en función de la arquitectura y los requisitos.
A nuestros clientes no les sirve la velocidad si no hay calidad. La realización continua de pruebas es una técnica en la que se integran pruebas automatizadas en la canalización de entrega de software y se validan todos los cambios que transcurren por ella. Las pruebas se realizan en cada fase de la canalización para validar los artefactos producidos en dichas fases. Las pruebas de unidades y los análisis de código estático validan componentes en la fase de componentes de la canalización. Las pruebas funcionales, de rendimiento y de seguridad validan subsistemas en la fase de subsistemas. Las pruebas de integración, rendimiento y seguridad validan los sistemas en la fase de sistemas. Por último, las pruebas de humo validan el producto en la fase de producción.
Las pruebas automatizadas se integran con la canalización
Una arquitectura monolítica o una gran bola de lodo puede provocar una avalancha de pruebas. Recomendamos invertir en microservicios, como artefactos que puedan implementarse de forma independiente y circular por las canalizaciones sin necesitar un entorno altamente integrado para la certificación. Asimismo, los artefactos que pueden implementarse de forma independiente permiten que los equipos más lentos no ralenticen a los equipos más rápidos.
El valor de la entrega continua
La canalización de entrega de software es un producto por sí mismo que debe ser prioritario para la empresa; de lo contrario, no se deben enviar productos que generen ingresos a través de ella. La entrega continua aporta valor de tres maneras, ya que mejora la velocidad, la productividad y la sostenibilidad de los equipos de desarrollo de software.
Velocidad
Cuando hablamos de velocidad, nos referimos a velocidad responsable, no mortal. Las canalizaciones están diseñadas para lanzar productos de calidad para los clientes. A menos que se imparta disciplina en los equipos, las canalizaciones pueden enviar código erróneo a la producción mucho más rápido. Con las canalizaciones automatizadas de entrega de software, las organizaciones pueden responder mejor ante los cambios del mercado.
Productividad
Cuando las tareas tediosas, como enviar una solicitud por cada cambio que pasa a producción, pueden realizarlas las canalizaciones en lugar de las personas, se produce un aumento en la productividad. De esta forma, los equipos de scrum pueden centrarse en productos que sorprendan a la gente, en lugar de tener que invertir su energía en los aspectos logísticos. Además, hace que los miembros del equipo estén más contentos y comprometidos con su trabajo y que quieran permanecer más tiempo en él.
Sostenibilidad
La sostenibilidad es la clave de todos los negocios, no solo del tecnológico. Decir que el software está devorando el mundo no es cierto: ya lo ha hecho. Todas las empresas, en mayor o menor instancia, ya sean sanitarias, financieras, de comercio minorista o de otros sectores, usan la tecnología para destacar entre la competencia y superarla tácticamente. La automatización ayuda a reducir y a eliminar las tareas manuales repetitivas y propensas a errores, lo que permite a las empresas colocarse en una posición en la que pueden innovar para satisfacer las necesidades de sus clientes mejor y más rápido.
¿Quién debe adoptar la entrega continua y cuándo?
Si te preguntas cuándo es un buen momento para adoptar la entrega continua, la respuesta es fácil: ayer.
Los equipos necesitan un único backlog priorizado donde:
- Se haya adoptado la entrega continua en lugar de quedar relegada a un segundo plano.
- Los criterios de aceptación de las historias de usuario mencionen de forma explícita enfoques de entrega de software automatizada en lugar de manual.
- La definición de "terminado" del sprint impida que los equipos finalicen sprints si el producto se lanza manualmente.
La entrega continua es el concepto más adecuado y, en ocasiones, requiere el apoyo de expertos para impulsar la transformación. A la larga, cuando están bien diseñadas, las canalizaciones de entrega continua se amortizan solas.
Entonces, ¿quiénes están implicados?
Algunas organizaciones seleccionan a personas sin experiencia para diseñar e implementar canalizaciones de entrega continua, y aprenden por las malas dónde se encuentran las complicaciones. Designar a miembros nuevos confiere un mensaje equivocado a los equipos, ya que implica que la entrega continua es una prioridad más baja. Recomendamos encarecidamente asignar la tarea a un arquitecto experimentado con un amplio conocimiento de la tecnología y la empresa.
Más allá de la entrega continua
Independientemente de en qué parte de la transformación al método "continuous Everything" (integración, realización de pruebas, entrega, implementación o análisis) nos encontramos, esto no se trata de una checklist ni de un destino: la mejora continua es el centro de estas actividades.
Tarde o temprano, todos en la organización reciben una llamada cuando se están construyendo canalizaciones de entrega continua. Ejecutivos, personal de ingeniería, de gestión de productos, de control, de riesgo, de conformidad, de InfoSec, de operaciones, del departamento legal y de todo lo que tengas. Las canalizaciones abren paso entre unidades aisladas y derriban los muros. De un modo u otro, todos formamos parte de esta transformación y continuamente constituimos la nueva normalidad.
Primeros pasos de IC y EC
Para practicar la CI/CD, puedes utilizar herramientas que automaticen el desarrollo, la implementación y las pruebas. Algunas herramientas ofrecen integración, otras proporcionan desarrollo e implementación, mientras que otras ofrecen pruebas.
Atlassian ofrece la solución Open DevOps con procesos de DevOps integrales, incluida CI/CD. Los equipos pueden usar diversas herramientas de CI/CD, como Bitbucket Pipelines, un servicio de CI/CD integrado en Bitbucket. Con él puedes compilar, probar e incluso implementar tu código automáticamente de acuerdo con un archivo de configuración en tu repositorio. Open DevOps también se integra con otras herramientas de CI/CD, como Harness, GitLab, JFrog, Codefresh y CircleCI.
Veamos más detenidamente nuestras integraciones de Open DevOps. También puedes echar un vistazo a nuestros tutoriales de CI/CD de DevOps.