Avec justesse. Comment organiser le contrôle des packages à partir de référentiels externes et déléguer le contrôle aux équipes produit

De nombreuses entreprises travaillent désormais sans avoir la possibilité de contrôler directement la composition des packages de référentiels externes, même si elles utilisent la mise en miroir, le proxy et la mise en cache. Cela conduit au fait que l'environnement d'exécution est en constante évolution, en particulier, la composition des images docker change plus souvent que la production ne l'exige.



Il existe des situations où des modifications indésirables contenues dans des dépendances externes peuvent entrer dans la composition du produit en cours de développement. Cela est particulièrement vrai lors de la certification du produit. En conséquence, des retards de certification, des tests nocturnes et des échecs de tests d'intégration, une panne de la production sur site (un environnement de production situé sur les propres ressources de l'organisation) lors du déploiement d'un correctif, etc. Dans un nouvel article, nous avons décrit une approche pour éviter de tels problèmes.

Ce que nous voulions réaliser

Avant de procéder à la description de l'approche, quelques mots sur les tâches que nous voulions résoudre:

• Obtenez un contrôle total sur la composition des packages externes dans la version (prévisibilité).
• Corrigez les compositions des référentiels externes pour un déploiement rapide des correctifs avec un minimum de tests supplémentaires (vitesse).
• Fournir aux stands d'assurance qualité des produits un environnement fixe répétable, prévisible (répétabilité).
• Indépendance par rapport à la présence d'un canal de communication externe (autonomie).
• Passage instantané aux référentiels officiels en cas de panne (tolérance aux pannes).
• Validation garantie des clés pour les référentiels externes dans les pipelines d'assemblage (confiance).
• Et surtout, transférer la gestion et le contrôle de la composition des packages externes entre les mains des équipes produit et des responsables des versions (autogestion).

Analyse du cycle de vie de la création de fonctionnalités

Notre approche résout le problème de la fixation de la composition des référentiels externes pour une date précise, pour une release ou une fonctionnalité. Le diagramme suivant illustre la gestion du cycle de vie de la version, de la création de fonctionnalités et du correctif.



Prenons le dépôt conditionnel Debian Stretch comme exemple. Cette approche est applicable aux référentiels Docker, SaltStack, etc. Trois tranches ont été enregistrées sur la chronologie pour les dates T1, T2 et T3.







Nous avons tabulé le contenu du référentiel externe Debian Stretch pour la construction des distributions Feature1, Feature2 et Feature3. Dans le tableau, vous pouvez voir que la composition du référentiel externe est contrôlée par chaque branche indépendamment. Nous avons conclu un accord pour nous engager quotidiennement dans la branche principale de Debian Stretch et étiqueter chaque tranche au format AAAAMMJJ, par exemple 2020304 pour la tranche du 4 mars 2020. Le tableau résume les instantanés du référentiel externe utilisé pour la distribution dans chaque branche à trois moments différents et la composition dans l'assistant de Debian Stretch. L'équipe de chaque fonctionnalité ou de chaque version met à jour la composition des référentiels externes à sa discrétion et en fonction de son cycle de développement.



En utilisant Feature1 comme exemple: l'équipe produit commence à développer une nouvelle fonctionnalité et corrige la composition du référentiel externe dans les fichiers de configuration à partir de la date 20200228 (voir le schéma ci-dessus).



Basculer vers 20200228

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



Lors du développement, en raison de l'apparition de nouveaux packages, il devient nécessaire de mettre à jour la base de données des packages à la date 20200304. Basculez le référentiel de travail à la date souhaitée.



Passer à 20200304

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



Ensuite, un autre basculement de la base de packages à la date 20200501 a lieu.



Passer à 20200501

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



Si nous dessinons maintenant des tranches de temps, nous verrons qu'aux moments T1 et T2, le développement Feature1 est sur la base de packages, "gelé" le 4 mars 2020. Et dans la coupe T3, le développement est déjà en cours sur une nouvelle base de paquets pour le 1er mai 2020.

Gestion des dépendances multi-versions des produits

Examinons maintenant la gestion des dépendances pour plusieurs versions de produit actives. Il existe trois versions de support, 2.5, 2.6 et 2.7.



Dans le tableau, nous voyons la correspondance des versions et des dates pour lesquelles l'instantané du référentiel a été créé. Il montre quel instantané de la composition du référentiel externe a été utilisé pour construire une version spécifique de la distribution.







Au lieu de nommer les tranches par dates AAAAMMJJ, nous utilisons également la dénomination des balises au format <ProjectName.ReleaseVersion> (release_name.release_version du produit, par exemple name.2.2) ou <ProjectName-FeatureNumber> (ajoutez un numéro de fonction, par exemple 3).



Snapshot pour 2.5 à partir de 20200301

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



Ainsi, lors du développement de la version 2.5, l'équipe corrige la composition des référentiels dépendants à partir de 20200301. Quelque part en avril, l'équipe lance une nouvelle version 2.6 et décide d'utiliser la composition des packages de référentiels externes à partir de 2.5. Créez un nouvel instantané 2.6 à partir de l'instantané 2.5. À l'avenir, les référentiels des versions 2.5 et 2.6 pourraient facilement diverger. Nous avons créé notre balise debian-stretch-projectname-2.6 pour la version 2.6.



Instantané pour 2.6 à partir de 20200301

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



Dans le cas de la version 2.7, l'équipe peut démarrer le développement à partir de la branche principale - un instantané quotidien du référentiel d'origine.



Instantané pour 2.7 à partir de 20200404

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

Gestion des dépendances multi-produits

Examinons la gestion des dépendances multi-produits en utilisant l'exemple de deux produits avec des cycles de sortie différents et leurs propres équipes de produits: Stealth et Infiniti.







Commentons ce qui se passe et quand.



1. Que le développement de la version 2.2 du projet Stealth commence le 1er mars 2020, pour cela un instantané de la composition de la base de données de packages pour la date actuelle a été créé. La version 2.2.124 est faite avec la base de paquets du référentiel externe de 20200301.



Stealth 2.2

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



2. Le cinquième jour, la base de paquets est mise à jour. Le référentiel de travail debian-stretch-stealth-2.2 passe instantanément à la date souhaitée, la publication des versions 2.2.131 et 2.2.162 est réalisée avec les packages de référentiel externe de 20200305. Sans manipulations supplémentaires dans l'environnement, tous les 100500 microservices du produit ont immédiatement reçu un nouvel environnement dans le pipeline d'assemblage 20200305 ...



Furtif 2.2

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



3. Parallèlement au troisième jour, le développement du projet Infiniti version 4.0 démarre et une tranche du référentiel pour la date 20200303 est créée pour celui-ci. Les versions 4.0.235 et 4.0.241 sont publiées avec les packages de référentiel externe pour 20200303.



Infiniti 4.0

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



4. Après la sortie de la version 4.0.241, l'équipe décide de mettre à jour la composition du référentiel à 20200308 et de publier une nouvelle version avec une nouvelle composition de packages externes. La version 4.0.250 est publiée avec des packages pour 20200308.



Infiniti 4.0

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



Deux options pour basculer entre les états des référentiels vous permettent de choisir une approche qui convient au processus de développement. Dans le premier cas, on passe à l'état souhaité en spécifiant un instantané des référentiels à une date précise. Dans le second cas, pour les produits multicomposants, nous utilisons une tranche nommée et la déplaçons à la date souhaitée. Ce mécanisme fournit une commutation de coupure unique dans tous les 100500 composants du produit.



Nous gérons les tranches de chaque référentiel externe dans un conteneur Docker distinct, nous pouvons donc à tout moment basculer un référentiel spécifique à télécharger depuis le réseau externe en cas d'accident.



Téléchargez une liste de tous les référentiels

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

Création automatique de tranches de référentiels externes

Les référentiels sont mis à jour chaque nuit selon le planificateur GitLab. Lorsqu'un nouveau référentiel est ajouté, les modifications sont automatiquement appliquées au serveur.







Au moment de la validation d'une nouvelle tranche du référentiel externe, son certificat est vérifié, s'il diffère de celui enregistré chez nous, alors la mise à jour n'a pas lieu et nous recevons un message d'erreur.

Résultat

1. Préparer une nouvelle version d'un kit de distribution pour la certification n'est plus un casse-tête. Pour la période de certification, nous corrigeons la composition de la distribution, et si vous devez corriger quelque chose rapidement, avec une forte probabilité, il n'y aura pas d'erreurs dans le correctif publié en raison de modifications de l'environnement.
2. Toutes les versions de fonctionnalités obtiennent l'état géré des référentiels externes.
3. Le déploiement des correctifs et la vérification via l'assurance qualité sont accélérés avec un résultat prévisible, rapide et réussi.
4. Feature- , .
5. .

Notez que Debian a une ressource officielle snapshot.debian.org avec des instantanés quotidiens et un stockage en profondeur. Pour certaines tâches, cela suffit.



Merci à Sergey Smirnov et à la communauté pour cet excellent outil de gestion de la composition des référentiels externes d'Aptly. De notre part - une petite contribution aux meilleures pratiques d'utilisation de cet outil utile dans les convoyeurs de production.



Dans les articles suivants, nous parlerons du bundle Aptly + Simple-CDD pour la préparation d'images ISO des distributions, de la délégation de la gestion des dépendances externes aux équipes produit et des problèmes d'utilisation d'Aptly dans le processus de gestion des dépendances externes.



Auteurs : Nikita Drachev , Alexander Pazdnikov , Timur Gilmullin