Acertadamente. Cómo organizar el control de los paquetes desde repositorios externos y delegar el control a los equipos de productos

Hoy en día, muchas empresas operan sin la capacidad de controlar directamente la composición de los paquetes en repositorios externos, incluso si utilizan duplicación, proxy y almacenamiento en caché. Esto lleva al hecho de que el entorno de ejecución cambia constantemente, en particular, la composición de las imágenes de la ventana acoplable cambia con más frecuencia de lo que requiere la producción.



Hay situaciones en las que cambios no deseados contenidos en dependencias externas pueden afectar la composición del producto que se está desarrollando. Esto es especialmente cierto durante la certificación de productos. Como resultado, retrasos en la certificación, pruebas nocturnas y fallas en las pruebas de integración, fallas en la producción local (un entorno de producción ubicado en los recursos propios de la organización) cuando se lanza una revisión, etc. En un nuevo artículo, describimos un enfoque para evitar tales problemas.

Lo que queríamos lograr

Antes de comenzar a describir el enfoque, unas palabras sobre las tareas que queríamos resolver:

• Obtenga un control total sobre la composición de los paquetes externos en el lanzamiento (previsibilidad).
• Corrija las composiciones de los repositorios externos para la implementación rápida de revisiones con un mínimo de pruebas adicionales (velocidad).
• Proporcione soportes de control de calidad de productos con un entorno fijo, predecible y repetible (repetibilidad).
• Independencia de la presencia de un canal de comunicación externo (autonomía).
• Cambio instantáneo a repositorios oficiales en caso de falla (tolerancia a fallas).
• Validación garantizada de claves para repositorios externos en ensambles pipelines (confianza).
• Y lo más importante, transferir la gestión y el control de la composición de los paquetes externos a las manos de los equipos de productos y los gestores de versiones (autogestión).

Análisis del ciclo de vida de la creación de funciones

Nuestro enfoque resuelve el problema de arreglar la composición de repositorios externos para una fecha específica, para un lanzamiento o una característica. El siguiente diagrama ilustra la gestión de la versión, la creación de funciones y el ciclo de vida de la revisión.



Tomemos el repositorio condicional Debian Stretch como ejemplo. Este enfoque es aplicable a los repositorios de Docker, SaltStack, etc. Se registraron tres cortes en la línea de tiempo para las fechas T1, T2 y T3.







Hemos tabulado el contenido del repositorio externo de Debian Stretch para construir las distribuciones Feature1, Feature2 y Feature3. En la tabla puede ver que la composición del repositorio externo está controlada por cada rama de forma independiente. Hemos llegado a un acuerdo para nosotros mismos para asignar la rama maestra para Debian Stretch diariamente y etiquetar cada segmento en formato AAAAMMDD, por ejemplo, 2020304 para el segmento del 4 de marzo de 2020. La tabla resume las instantáneas del repositorio externo utilizado para la distribución en cada rama en tres momentos diferentes y la composición en el asistente para Debian Stretch. El equipo de cada función o de cada versión actualiza la composición de los repositorios externos a su discreción y de acuerdo con su ciclo de desarrollo.



Utilizando Feature1 como ejemplo: el equipo de producto comienza a desarrollar una nueva función y corrige la composición del repositorio externo en los archivos de configuración a partir de la fecha 20200228 (consulte el diagrama anterior).



Cambiar a 20200228

deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free



Durante el desarrollo, debido a la aparición de nuevos paquetes, es necesario actualizar la base de datos de paquetes a la fecha 20200304. Cambiar el repositorio de trabajo a la fecha deseada.



Cambiar a 20200304

deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free



A continuación, otro cambio de la base del paquete tiene lugar en la fecha 20200501.



Cambiar a 20200501

deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free



Si ahora dibujamos segmentos de tiempo, veremos que en los momentos T1 y T2 el desarrollo de Feature1 está en la base del paquete, "congelado" el 4 de marzo de 2020. Y en el corte T3, el desarrollo ya está en marcha en una nueva base de paquetes para el 1 de mayo de 2020.

Gestión de dependencias de múltiples versiones de productos

Ahora veamos la gestión de dependencias para varias versiones de productos activos. Hay tres versiones de soporte, 2.5, 2.6 y 2.7.



En la tabla, vemos la correspondencia de lanzamientos y fechas para las que se realizó la instantánea del repositorio. Muestra qué instantánea de la composición del repositorio externo se utilizó para crear una versión específica de la distribución.







En lugar de nombrar segmentos por fechas AAAAMMDD, también usamos nombres de etiquetas en el formato <ProjectName.ReleaseVersion> (release_name.release_version del producto, por ejemplo name.2.2) o <ProjectName-FeatureNumber> (agregue un número de función, por ejemplo 3).



Instantánea para 2.5 a partir de 20200301

deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301



Por lo tanto, durante el desarrollo de la versión 2.5, el equipo corrige la composición de los repositorios dependientes a partir de 20200301. En algún momento de abril, el equipo inicia una nueva versión 2.6 y decide utilizar la composición de los paquetes de repositorios externos de la 2.5. Cree una nueva instantánea 2.6 a partir de la instantánea 2.5. En el futuro, los repositorios para las versiones 2.5 y 2.6 podrían divergir fácilmente. Hemos creado nuestra etiqueta debian-stretch-projectname-2.6 para 2.6.



Instantánea para 2.6 a partir de 20200301

deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301



En el caso de la versión 2.7, el equipo puede comenzar el desarrollo desde la rama maestra, una instantánea diaria del repositorio original.



Instantánea para 2.7 a partir de 20200404

deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404

Gestión de la dependencia de varios productos

Veamos la gestión de la dependencia de varios productos utilizando el ejemplo de dos productos con diferentes ciclos de lanzamiento y sus propios equipos de productos: Stealth e Infiniti.







Comentemos en la mesa qué pasa y cuándo.



1. Que el desarrollo de la versión 2.2 del proyecto Stealth comience el 1 de marzo de 2020, para ello se creó una instantánea de la composición de la base de datos del paquete para la fecha actual. El lanzamiento de la versión 2.2.124 se realiza con la base del paquete del repositorio externo de 20200301.



Stealth 2.2

deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301



2. En el quinto día, la base del paquete se actualiza. El repositorio de trabajo debian-stretch-stealth-2.2 cambia instantáneamente a la fecha deseada, el lanzamiento de las versiones 2.2.131 y 2.2.162 se realiza con los paquetes del repositorio externo de 20200305. Sin manipulaciones adicionales en el entorno, todos los 100500 microservicios del producto recibieron inmediatamente un nuevo entorno en el proceso de ensamblaje 20200305 ...



Sigilo 2.2

deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305



3. Paralelamente al tercer día, se inicia el desarrollo del proyecto Infiniti versión 4.0 y se crea una porción del repositorio para la fecha 20200303. Las versiones 4.0.235 y 4.0.241 se lanzan con los paquetes del repositorio externo para 20200303.



Infiniti 4.0

deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303



4. Después del lanzamiento de la versión 4.0.241, el equipo decide actualizar la composición del repositorio a 20200308 y lanzar una nueva versión con una nueva composición de paquetes externos. La versión 4.0.250 está disponible con paquetes para 20200308.



Infiniti 4.0

deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308



Dos opciones para cambiar entre los estados de los repositorios le permiten elegir un enfoque que sea conveniente para el proceso de desarrollo. En el primer caso, cambiamos al estado deseado especificando una instantánea de los repositorios en una fecha específica. En el segundo caso, para productos multicomponente, usamos un segmento con nombre y lo movemos a la fecha deseada. Este mecanismo proporciona una conmutación de corte única en todos los componentes del producto 100500.



Gestionamos los cortes de cada repositorio externo en un contenedor Docker separado, por lo que en cualquier momento podemos cambiar un repositorio específico para descargar de la red externa en caso de algún accidente.



Descarga una lista de todos los repositorios

# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.list

Creación automática de porciones de repositorios externos

Los repositorios se actualizan todas las noches de acuerdo con el programador de GitLab. Cuando se agrega un nuevo repositorio, los cambios se aplican automáticamente al servidor.







En el momento de hacer commit de una nueva porción del repositorio externo se comprueba su certificado, si difiere del que guardamos con nosotros, entonces no se realiza la actualización y recibimos un mensaje de error.

Salir

1. Preparar una nueva versión de un kit de distribución para la certificación ya no es un dolor de cabeza. Durante el período de certificación, arreglamos la composición de la distribución y, si necesita arreglar algo rápidamente, es muy probable que no haya errores en la revisión publicada debido a cambios en el entorno.
2. Todas las compilaciones de funciones obtienen el estado administrado de los repositorios externos.
3. La implementación de revisiones y la verificación a través de QA se aceleran con un resultado predecible, rápido y exitoso.
4. Feature- , .
5. .

Tenga en cuenta que Debian tiene un recurso oficial snapshot.debian.org con instantáneas diarias y grandes profundidades de almacenamiento. Esto es suficiente para determinadas tareas.



Gracias a Sergey Smirnov y la comunidad por una excelente herramienta para administrar la composición de los repositorios externos de Aptly. De nosotros: una pequeña contribución a las mejores prácticas de uso de esta útil herramienta en transportadores de producción.



En los próximos artículos hablaremos sobre el paquete Aptly + Simple-CDD para la preparación de imágenes ISO de distribuciones, delegando la gestión de dependencias externas a equipos de producto y los problemas de utilizar Aptly en el proceso de gestión de dependencias externas.



Autores : Nikita Drachev , Alexander Pazdnikov , Timur Gilmullin