En busca del DevOps ideal

0
10
Custom Text

Devops ofrece una visión general de la actividad de las áreas de desarrollo y de operaciones y ayuda a que interactúen de manera más eficaz. Ese es el ideal conceptual, pero desde un punto de vista técnico, ¿existe una configuración ideal de DevOps? La respuesta es no, porque las exigencias de una startup de dos personas son completamente diferentes a las de una multinacional que se embarca en un proyecto de microservicios con cientos de personas implicadas en su cuidado y alimentación; no obstante, sí es posible describir un flujo idealizado de desarrollo que se adapta para absorber la creciente complejidad según sea necesario, y explicar cómo tecnologías como CI/CD, Docker y la computación en la nube encajan en este flujo.

El ‘bucle interno’ del desarrollo
Supongamos que somos un desarrollador que está haciendo cambios en el software; una vez que estamos satisfechos con estos, los enviamos al control de versiones. El control de versiones es el punto de unión entre el «bucle interno» del desarrollo de software y el «bucle externo» de DevOps.

El commit del desarrollador puede ir a una rama de desarrollo, a una rama de características o (en un entorno informal) directamente a la principal, pero lo ideal es que haya una ejecución automatizada de las pruebas unitarias. Esto puede ocurrir de varias maneras, pero el resultado es que el cambio de código no se aceptará en la rama a menos que pasen las pruebas unitarias.

Pruebas automatizadas
Una vez que se acepta el cambio de código, lo siguiente que debe suceder cae bajo el título de «prueba de integración», y este es el paso esencial en la integración continua; es decir, el código está siendo continuamente integrado en el sistema más grande (cualquiera que sea) y desplegado para las pruebas automatizadas y manuales en un entorno de ejecución.

Cuando se trata de pruebas automatizadas, el cielo es el límite. Todo está sobre la mesa, con todo tipo de herramientas automatizadas modernas disponibles para ‘martillear’ el software, desde pruebas automatizadas de interfaz de usuario al estilo de Selenium hasta sofisticadas suites de pruebas de carga. A menudo, algún tipo de prueba de humo automatizada garantiza que el software promovido para la prueba está funcionando. El mantra de las pruebas es que hay que detectar los problemas lo antes posible.

Pruebas manuales de validación
Ahora que el software ha superado los obstáculos de las pruebas unitarias y de integración automatizadas, está listo para las pruebas manuales. Normalmente, estas se realizan contra una etiqueta específica que captura un conjunto concreto de características y correcciones. La organización (ya sea una o 20 personas) se está tomando en serio el traslado de los cambios a la producción. Esto significa que el software se despliega (preferiblemente de forma automática) en un entorno que imita la producción, y permite interactuar manualmente con él, donde el departamento de control de calidad hará todo lo posible para romper las cosas. Si se encuentran problemas, se pueden incorporar correcciones.

Una vez que el equipo del departamento de control de calidad está satisfecho, el prometedor paquete puede ser promovido a la UA, o a las pruebas de aceptación del usuario. Esto puede ocurrir de varias maneras, pero el resultado final es que más personas (los analistas de negocio y otras partes interesadas) tienen la oportunidad de ver el software en funcionamiento. Una vez que lo aprueban, el software está listo para la producción.

Seguimiento de los cambios en producción
Dependiendo de la envergadura de los cambios en producción, hay más actividad de verificación que tiene lugar en ese entorno, pero también se afianza un nuevo aspecto: la supervisión. La monitorización y el registro son esenciales para controlar el rendimiento del sistema en general. Esta es otra área que ha visto grandes mejoras en la era de la nube. Existen multitud de herramientas de registro y monitorización.

En el ámbito de los microservicios, el despliegue a la producción es a veces un asunto más intrincado, ya que los elementos del microservicio pueden ser desplegados en fases, con el tráfico de red que se dirige de forma incremental a los nodos actualizados para verificar que están interactuando como se pretende con otros componentes.

Roles en Devops
Otra forma de considerar estos procesos es en términos de los roles que las personas desempeñan en ellos. Por roles me refiero a los ‘sombreros’ que llevan las personas, no necesariamente a sus títulos de trabajo. En el nivel más alto, se puede decir que hay tres funciones: las personas que modifican el código, las que verifican que las cosas funcionan correctamente y las que gestionan los sistemas en funcionamiento. Podríamos llamarlos desarrolladores, probadores y administradores.

A medida que profundizamos en los detalles, por supuesto, hay más diversidad. Por ejemplo, un ingeniero de control de calidad que prueba nuevos cambios de código es muy distinto de un analista de negocios que verifica los requisitos en un servidor de UA, y ambos son distintos de un ingeniero de desarrollo que configura monitores para validar que los sistemas de producción se ejecutan dentro de los parámetros especificados. Pero podemos decir que estas actividades caen bajo el amplio título de verificar que las cosas están funcionando como deberían.

Utilicemos esta perspectiva para hablar de algunas de las herramientas específicas que estos usuarios utilizan en su trabajo.

Contenedores: la bisagra entre desarrollo y operaciones
Quizá la más transversal de las tecnologías sea la contenerización, que en la práctica significa Docker. Esto se debe a que Docker permite componer el software de un desarrollador en trozos reutilizables que definen sus necesidades de tiempo de ejecución. Esto supone que los desarrolladores pueden dirigirse al contenedor, y los administradores pueden utilizar el contenedor como denominador común en todos los sistemas.

La unidad desplegable a nivel de contenedor es suficiente para sustentar incluso los requisitos más exigentes y de mayor volumen. Kubernetes se ha convertido en el sistema de gestión de clústeres de contenedores más popular, y aunque no es una tecnología sencilla, sus capacidades son impresionantes, con la posibilidad de gestionar grandes clústeres en múltiples regiones y servicios que interactúan.

Contenedores y desarrollo
Sin embargo, la contenerización no es una solución fácil para el «bucle interno» del desarrollador. Esto se debe a que los contenedores introducen una complejidad adicional en el ciclo de código, construcción y prueba. Por ello, sigue siendo más habitual que los desarrolladores utilicen un entorno de desarrollo «explotado», en el que ejecutan su código contra su entorno local sin contenerizar.

La prueba unitaria sigue siendo la primera línea de defensa del desarrollador en la calidad del código. Sin embargo, Docker puede hacer que algunos aspectos sean más sencillos para el desarrollador, por ejemplo, empaquetando una versión estandarizada de un almacén de datos como MongoDB o PostgreSQL, lo que permite ponerlo en marcha con facilidad para que los desarrolladores lo utilicen al codificar.

Contenedores y datos de prueba
Del mismo modo, los entornos de desarrollo pueden beneficiarse a menudo de la utilización de Docker y Docker Compose para poner en marcha bases de datos con datos de prueba.

Por lo tanto, aunque Docker es clave para unificar el panorama de las operaciones de desarrollo y ofrece ciertas ventajas a los desarrolladores, existe un desajuste de impedimentos cuando se trata de tareas de codificación reales.

Herramientas de canalización CI/CD
Consideremos ahora las herramientas que se pueden utilizar para conectar los diversos elementos en un proyecto de DevOps. Hay muchas.

IDG.es

Artículo anteriorAWS cierra su infraestructura vinculada a NSO Group
Artículo siguienteTambién Jeff Bezos cumplió exitosamente su misión espacial