No hay otro sitio en el que la los problemas de DevOps sea más visibles que cómo implementan los equipos la Gestión de Releases. Ni siquiera los equipos pueden ponerse de acuerdo sobre lo que es desplegar las cosas.
Los equipos ágiles suelen indicar que la Gestión de Releases consiste en “implementar continuamemte y lanzar bajo demanda”, aunque no suelen estar muy contentos sobre el proceso de enviar los desarrollos a producción que siguen las mismas prácticas de toda la vida.
Esto además se complica con todos los procesos buscando la prevención de ataques de seguridad. A continuación intentaremos definir lo que bajo nuestro punto de vista se necesita conocer para gestionar la convergencia entre los procesos tradicionales y los nuevos, obteniendo lo mejor de ambos mundos.
¿De qué estamos hablando?
En primer lugar, algunas palabras sobre terminología: el despliegue normalmente significa poner algo a disposición, ya sea una aplicación o una función, para quien lo solicite.
Si no se encuentra en un entorno de DevOps, entonces una organización de desarrollo está “entregando” lo que creó al equipo de operaciones. Si se encuentra en un entorno de DevOps o si piensa en lanzamientos desde la perspectiva de los consumidores finales de una solución digital, entonces un despliegue es cuando el equipo de operaciones hace que la aplicación, el servicio o la función estén disponibles.
Un equipo de DevOps normalmente hablará de “implementación” como el proceso de pasar del ciclo de desarrollo al ciclo de operaciones. La persona de DevOps no llamaría a esto liberación. Para esa persona, la liberación se produce después del despliegue; es cuando los usuarios se incorporan a las nuevas funciones que se implementaron.
Muchos de los conflictos que vemos se deben a que los dos puntos de vista anteriores no se entienden ni aprecian. La siguiente imagen ilustra la diferencia.
En la gestión de versiones clásica, existe un control estricto entre el desarrollo y las operación. Todo lo que las operaciones han implementado en producción está implícitamente disponible para los consumidores del servicio, y cualquier problema se resuelve a través del soporte.
Por el contrario, en DevOps, el mismo equipo maneja tanto el desarrollo como las operaciones, por lo que el despliegue es solo una de las muchas actividades del equipo, y lse realiza de forma continua. Sin embargo, el equipo de DevOps planificará cuidadosamente cómo hacer que las nuevas funciones estén disponibles y, si hay algún problema, se restringirá el número de usuarios hasta que se haya resuelto todos los problemas.
Los beneficios del control de releases
El objetivo principal de la función de control de versiones es garantizar el “ajuste para el propósito” de todo lo que se envía a producción, ya sea una nueva funcionalidad, parches simples o sistemas completamente nuevos.
Por lo general, los equipos de operaciones se preocupan por estas preguntas:
- ¿Estamos rompiendo la funcionalidad que ya se está ejecutando?
- ¿Están las operaciones listas para gestionar el lanzamiento?
- ¿Será segura la liberación?
- ¿Están listos el rendimiento y todos los demás aspectos no funcionales del lanzamiento?
- ¿Están todos los artefactos asociados, como el entrenamiento, documentados y se entienden los errores conocidos?
Los beneficios del despliegue bajo demanda
Esto es lo que está haciendo el equipo de DevOps con lo que los equipos de operaciones tradicionales suelen pelear: lanzar nuevas funciones de manera controlada. El objetivo es que las nuevas funciones se prueben y se desplieguen para todos únicamente una vez que se demuestre que funcionan. De hecho, es probable que esto únicamente sea posible si existe un vínculo estrecho entre el desarrollo y las operación, ya que la capacidad de realizar despliegues controlados para los usuarios depende de las capacidades del código desarrollado.
Los beneficios son enormes, como puede afirmar cualquiera que haya intentado gestionar una actualización de software con una gran base de usuarios. No hay ninguna cantidad de pruebas en preproducción o de aceptación de usuarios que puedan encontrar todos los defectos que eventualmente puedan aparecer en producción.
El mejor enfoque: uso de agile y automatización
Los equipos de DevOps bien implementados pueden ser mucho más más productivos y ofrecer un producto de mayor calidad que las configuraciones de TI tradicionales donde el desarrollo está separado de las operación. Sin embargo, si no es una empresa o un equipo totalmente nuevos, esto representa un cambio cultural significativo y, además, muchas aplicaciones heredadas no se pueden convertir fácilmente en este nuevo paradigma.
Normalmente, la gente de operaciones dirá: “Necesito un mecanismo de control de liberación entre lo que hace el desarrollador y lo que yo hago”. Esta es una señal de falta de confianza. Utilicemos esto como una oportunidad para que los programadores puedan automatizar la mayor cantidad posible de controles de versiones tradicionales, no desecharlos. Y si el desarrollador quiere llamarlo “controles de implementación” o “puntos de control de flujo”, está bien, es lo mismo.
Pero las los equipos de operaciones también podrían enseñar algunos trucos, incluido cómo se pueden usar los catálogos de servicios como una forma de exponer nuevas funciones para controlar el lanzamiento a los consumidores. Los equipos de operaciones tienen mucha experiencia en el manejo de catálogos de servicios, suscripciones de servicios y soporte basado en contratos. En realidad, esto se puede usar para mejorar la práctica actual de DevOps, donde el despliegue se controla según las banderas de lanzamiento, etc.
Se está construyendo esta forma de combinar lo mejor de ambos mundos en el próximo estándar IT4IT, con nuevas corrientes de valor que gestionan la implementación y el lanzamiento por separado. Esto se ilustra simplemente en las flechas azules del flujo de valor a continuación:
Hay otra razón por la que es importante mantener algunas de las propiedades existentes del control de versiones cuando se pasa a un enfoque más ágil: automatizar y documentar el conocimiento tácito.
Es fundamental se capaces de poder reconstruir algo y saber cuál es el contenido de una versión determinada, porque luego también se puede hacer una auditoría y controlar los controles de seguridad. Es por eso que los despliegues deben ser centralizados y administrados, no solo por el equipo de DevOps sino por la organización de TI en su conjunto.
Se necesita comprender qué entra en producción. Si no se hace por IT, entonces la empresa puede arriesgarse a tener un riesgo de seguridad.
Finalmente, si una versión no está bien documentada y estandarizada, no podrá recrear fácilmente a un equipo de DevOps años después, cuando un producto o servicio que ha estado con poco mantenimiento durante mucho tiempo necesita nuevas actualizaciones.
Mejores prácticas de buena gestión de versiones
Entonces, ¿cuál es el enfoque correcto? Ciertamente, pasar al lanzamiento continuo es hacia donde nos dirigimos como industria, pero hay áreas grises en el mundo real, y la solución que debemos tomar debe adaptarse a ambas cosas.
A veces, los sistemas se encuentran en un estado estable, pero es posible que necesiten ajustes menores. Sin embargo, cuando surgen problemas, alguien debe hacer algo al respecto.
Por eso es importante saber qué puso en producción el equipo anterior y tener una gestión centralizada. Si cada equipo de DevOps tiene su propio workflow y métodos para administrar las operaciones, es casi imposible que un equipo nuevo pueda administrar algo existente sin introducir errores.
Se debe administrar la transición de desarrollo a operaciones de la siguiente manera:
- Asegurarse de que todo lo implementado en producción (y potencialmente, también la preproducción y la prueba del sistema, si es relevante en su configuración) esté bien definido y reproducible a lo largo del tiempo.
- Se debe proporcionar una buena gestión de registros sobre artefactos de releases / implementación como binarios, notas de la release, scripts de configuración y una recopilación de errores conocidos. A menudo, la reproducción de conjuntos completos de activos se basa en el conocimiento tácito.
- Verificar la cadena de suministro: ¿Están certificados los elementos de la versión compilada? (Es decir, garantizado que fue entregado por el proveedor esperado. Esto generalmente se logra mediante la firma del código y buenos procesos).
- Protegerse contra errores de liberación maliciosos o negligentes. Hay que asegurarse de que siempre haya más de una persona involucrada en nuevas implementaciones para protegerse contra amenazas internas.
- Hay que asegurarse de que el código haya sido escaneado antes de su publicación, preferiblemente, de manera “shift-left” para que no sea un proceso de bloqueo de último minuto.
- Ejecutar pruebas funcionales y no funcionales automatizadas con puntuación de riesgo automática. De esta manera, se puede evaluar de manera eficiente y continua la release candidate.
Ceñirse a los principios propios, pero automatizar
No hay que lanzarse a la piscina sin flotador. Hay que conservar todos los principios del control de versiones clásico en la gestión de TI. Aprender de ellos, porque muchos siguen siendo válidos. Dicho esto, los equipos de DevOps deben asegurarse de automatizar tanto como sea posible.