Cómo conseguir una implementación continua

En esta guía, daremos por sentado que tu flujo de trabajo de integración continua y entrega continua ya está implementado y que tu siguiente paso es configurar tu canalización de entrega continua.

Sten Pittet Sten Pittet

Echa un vistazo a nuestro tutorial sobre cómo ponerte en marcha con la implementación continua en Bitbucket Pipelines.

"Que nadie mueva un dedo en la producción: ¡estoy a punto de publicar!"

Puede que esa frase te resulte familiar. La implementación en la producción puede ser una tarea arriesgada y costosa para la que, a veces, hay que suspender todo el desarrollo. Esto ralentiza los ciclos de publicación y hace que los cambios se estanquen en el entorno de desarrollo. Es el comienzo de un círculo incómodo (y vicioso) en el que cuantas más confirmaciones se lleven a cabo en el repositorio, más riesgos se introducirán en la siguiente implementación en la producción, y menos probable será que tu equipo lleve a cabo esa publicación.

La implementación continua se encarga de solucionar este problema lanzando automáticamente cada cambio enviado al repositorio principal en la producción. Se trata de un enfoque radical (muy diferente al de pasar días preparando y controlando cada versión), pero la implementación continua ofrece varias ventajas:

  • Las publicaciones se vuelven más pequeñas y más fáciles de entender.
  • Nadie tiene que dejar lo que está haciendo para realizar una implementación, ya que todo está automatizado.
  • El ciclo de feedback con tus clientes es más rápido: las nuevas funciones y mejoras entran directamente en la producción cuando están listas.

Puede resultar bastante abrumador pasar de versiones aprobadas a la implementación continua, pero para eso está esta guía: para ayudarte en dicha transición. Trataremos los principios básicos para que puedas ponerte en marcha lo antes posible y empezar a acelerar tu ciclo de lanzamiento.

Comparación entre implementación continua y entrega continua

Si deseas implementar una canalización de implementación continua, lo mejor es comenzar con la entrega continua. Estas dos prácticas son similares, pero difieren en sus enfoques de implementaciones de producción. En la entrega continua, cada cambio enviado al repositorio principal está listo para lanzarse, pero el proceso de publicación de la producción aún requiere la aprobación humana. En la implementación continua, la publicación en la producción se realiza automáticamente para cada cambio que supera el conjunto de pruebas.

Comparación entre entrega continua e implementación continua

Antes de empezar a lanzar los cambios automáticamente en la producción, se debe contar con una buena política corporativa con respecto a la integración continua (CI), y es muy recomendable comenzar con la entrega continua. Puedes leer más acerca de ambas prácticas en los siguientes artículos:

De la entrega continua a la implementación continua

Haz hincapié en una política corporativa de integración continua

En el centro de la implementación continua se encuentra la excelente cultura de la IC. La calidad de tu conjunto de pruebas determinará el nivel de riesgo de tu versión, y tu equipo deberá dar prioridad a la automatización de pruebas durante el desarrollo. Esto supone implementar las pruebas para cada nueva función, así como añadirlas para cada regresión detectada después del lanzamiento.

También debe ser una prioridad corregir una compilación dañada para la rama principal. De lo contrario, te expondrás a los mismos riesgos a los que te enfrentaste antes de adoptar la implementación continua: los cambios se acumulan en el entorno de desarrollo y los desarrolladores no pueden estar seguros de que su trabajo haya finalizado, ya que no saben si sus cambios han superado las pruebas de aceptación.

Asegúrate de tener una buena cobertura de pruebas (¡y unas buenas pruebas también!)

Empieza a usar herramientas de cobertura de pruebas para asegurarte de que tu aplicación se ha evaluado adecuadamente. Un buen objetivo que ponerse es la cobertura del 80 %.

Procura no confundir la “buena cobertura” con las “buenas pruebas”. Podrías tener una cobertura del 100 % con pruebas que realmente no desafían tu base de código. Asegúrate de dedicar tiempo, durante las revisiones de código, a comprobar cómo se escriben las pruebas y no dudes en informar de lagunas en la cobertura o pruebas débiles. Tu conjunto de pruebas hace las veces de puerta de entrada a la producción, por lo que debe ser sólida.

Adopta la supervisión en tiempo real

Si vas a implementar todas las confirmaciones automáticamente en la producción, deberás asegurarte de que puedes recibir avisos si algo va mal. Un nuevo cambio no tiene por qué detener la producción inmediatamente, pero sí hará que tu CPU o consumo de memoria pase a un nivel peligroso. Por ello, resulta útil implementar la supervisión en tiempo real en tus servidores de producción para poder rastrear las irregularidades en tus métricas.

Herramientas como Nagios o servicios como New Relic pueden ayudarte a realizar un seguimiento de las métricas básicas de rendimiento y avisarte siempre que se produzca una alteración en tus sistemas.

Revisión de las pruebas tras la implementación

Después de cada implementación en la producción, debes ejecutar unas sencillas pruebas de humo para garantizar que la aplicación está en marcha.

Asegúrate de que estas pruebas hacen más que simplemente entrar en una página estática y esperar una respuesta de éxito. Una buena práctica es contar con una prueba que requiera que todos tus servicios de producción (base de datos, microservicios, terceros...) funcionen correctamente.

Nuevos desafíos para tu equipo de control de calidad

Como ahora cada confirmación va directamente a la producción, no existe el típico paso intermedio en que el equipo de control de calidad revisa y aprueba las nuevas funciones. En cambio, debe trabajar estrechamente con el gestor de productos y el equipo de desarrollo para definir los riesgos asociados a las nuevas mejoras.

Esta es una gran oportunidad para el equipo de control de calidad, ya que, con el tiempo, esto supondrá una mejor calidad para las publicaciones. Con la implementación continua, tu equipo se inclinará, por naturaleza, por una buena cobertura de pruebas de la base de código. No hacerlo acarrea frecuentes interrupciones debido a la aparición de errores que no se manifiestan hasta la producción, que es cuando los detectan los usuarios.

Deja las notas de publicación tradicionales

La implementación continua te dificulta el mantenerte al día con las publicaciones, ¡y eso es bueno! Tu objetivo debería ser tener implementaciones diarias en la producción, incluso varias implementaciones al día. Pueden ser correcciones de errores, pequeñas mejoras, nuevas funciones... lo que sea. En cuanto un desarrollador termina su trabajo, dicho trabajo debería ejecutarse en la producción en cuestión de minutos.

En este nuevo mundo, ya no es posible escribir notas de publicación que tus clientes reciban con cada nueva versión. En cambio, adopta este nuevo flujo y limita tus anuncios a las funciones clave que más importen a tus clientes. Los informes de errores y las solicitudes de pequeñas mejoras se pueden gestionar simplemente en tu sistema de tickets: Jira, por ejemplo, puede actualizar todos los interesados de un ticket en cuanto lo cierras o lo actualizas.

Un enfoque diferente para nuevos proyectos: implementación en la producción antes de la codificación

Hay algo interesante que puedes hacer si estás empezando a usar una nueva base de código de marca. Puedes comenzar creando tu canalización de implementación continua antes de tener a cualquier cliente y cualquier función listos (similar al desarrollo basado en pruebas). Al principio, lanzarás una plataforma vacía. Luego, a medida que avanza el desarrollo, las nuevas capacidades irán apareciendo automáticamente. Solo tienes que mantener cerrado el entorno de producción hasta que estés listo para abrirlo a tus clientes.

Al principio, este enfoque puede parecer contradictorio. No obstante, es una forma sencilla de eliminar el estrés de pasar de una aprobación de publicación manual a la implementación continua en la producción. Asimismo, es una excelente manera de garantizar que tienes una buena cobertura de pruebas y una política corporativa de integración continua en el lanzamiento, ya que son condiciones necesarias para la implementación continua.

¡Desarrolla tus conocimientos y comparte tus experiencias!

Se entiende que resulta difícil dar el salto y cambiar a una implementación continua. De repente, se abre la veda y el código va directo a los clientes en cuestión de minutos u horas. (¡Guau!) Por lo tanto, es importante invertir en las pruebas y automatizaciones que te dan seguridad en tus compilaciones. Esto será fácil si tu base de código es nueva, pero es posible que sea necesario adoptar una estrategia diferente para una compleja base de código heredada.

Empieza poco a poco y desarrolla tus conocimientos y experiencia en la implementación continua. Cuando estés en un proyecto y lo consigas, será fácil replicar tu éxito en otras partes de tu organización.