La organización actual del código y la configuración que describe está estructurada por las soluciones técnicas involucradas. Este es un mal diseño que agregará muchos gastos generales en nuestras actividades de mantenimiento y también agregará muchas trampas en nuestro camino. En cambio, esa organización debería estructurarse en torno a los artefactos que estamos implementando.
La razón de esto es que queremos considerar los artefactos ( por ejemplo, una imagen acoplable o un paquete de software) como los objetos de los siguientes verbos:
- construir
- prueba
- desplegar
considerar un conjunto mínimo de tareas automatizadas que queremos realizar. Si queremos cambiar algo sobre cómo se implementa el verbo de prueba, es fácil visitar la carpeta correspondiente a ese artefacto en el repositorio apropiado y luego descubrir los elementos de automatización específicos de jenkins que deben actualizarse. En cambio, si las recetas de automatización están estructuradas en torno a soluciones técnicas, entonces necesitamos averiguar de la nada que Jenkins está involucrado en los procedimientos de prueba y encontrar allí los elementos de automatización relacionados con el artefacto. En situaciones complejas, la organización en torno a las soluciones técnicas hace que las actualizaciones sean muy difíciles, porque tenemos que conocer a priori todas las soluciones técnicas involucradas en algún servicio para actualizarlas en consecuencia.
Por ejemplo, un repositorio que contiene el código de un sitio web y un microservicio "a" podría tener los siguientes subdirectorios dedicados a las operaciones:
./ops/website
./ops/micro-service-a
cada uno con tres guiones llamados build
, test
y deploy
. Ahora que la organización de los elementos de automatización se ha aclarado de alguna manera, volvamos nuestra atención a la configuración.
El deploy
verbo establece las principales condiciones y requisitos sobre la organización de la configuración cuando se aplica a un artefacto similar a un servicio. El deploy
verbo debe tener los siguientes parámetros:
- la versión del artefacto para desplegar,
- el objetivo de implementación del artefacto, que describe el entorno concreto donde se ejecutará el artefacto desplegado ( por ejemplo, un clúster y puntos finales con los que debería hablar)
- las credenciales que debe usar para conectarse a otros puntos finales ( por ejemplo, bases de datos)
- la configuración de tiempo de ejecución de (como cuánto tiempo deben permanecer las entradas de caché, etc.)
Desde la perspectiva operativa, este desglose de la parametrización coincide con los grados naturales de libertad del problema de implementación, aparte de las credenciales que podrían agruparse con la configuración de tiempo de ejecución, pero es mejor separarlas para evitar distribuirlas descuidadamente.