Pourquoi les développeurs déplacent-ils les exécuteurs CI, les registres et les bases de données de test hors de leurs ordinateurs portables ?

Les équipes déplacent ces services hors des ordinateurs portables afin de rendre les builds reproductibles, de garantir l’accès aux dépendances partagées, de pouvoir supprimer l’état des tests et de rendre les livraisons indépendantes de la batterie ou de l’espace de travail d’un développeur.

Le serveur n’est pas un ordinateur portable plus puissant. Un exécuteur CI exécute des instructions de projet non fiables, un registre stocke des artefacts de la chaîne d’approvisionnement et une base de données de test contient un état mutable. Les regrouper peut être efficace pour une petite équipe uniquement lorsque les identités, les réseaux, le stockage, les secrets, les quotas et la récupération sont séparés par rôle.

Commencez par l’échec du workflow

Une CI hébergée sur un ordinateur portable échoue lorsque son propriétaire dort, voyage, change de réseau, ferme le capot ou a besoin du processeur et de la mémoire locaux. Un registre local disparaît avec cette machine, tandis qu’une base de données de test accumule un état que seul un développeur comprend.

L’intégration continue repose sur une vérification fréquente et automatisée que tout le monde peut consulter. Les pratiques d’intégration continue de Martin Fowler mettent l’accent sur les builds avec auto-tests automatisés et les résultats visibles - des propriétés difficiles à garantir sur un ordinateur portable seulement disponible par intermittence.

Ne déplacez un rôle qu’après avoir identifié l’échec qu’il doit résoudre : délai dans la file d’attente, dérive de l’environnement, distribution des images, état d’intégration partagé ou concurrence pour les ressources de l’ordinateur portable.

Séparez la frontière de confiance de l’exécuteur

Considérez les tâches CI comme de l’exécution de code. Utilisez des conteneurs ou des machines virtuelles éphémères lorsque cela est possible, évitez de monter le socket Docker de l’hôte dans des tâches non fiables et attribuez des identifiants aux privilèges strictement limités par dépôt ou par pipeline.

Placez l’espace de travail des builds et les caches sous quotas. Une tâche en échec ne doit pas remplir le système de fichiers racine du serveur ni lire des identifiants de registre sans rapport avec son projet.

Définissez les labels des exécuteurs selon leur niveau de confiance et leurs capacités. N’envoyez pas le code d’une pull request provenant d’un contributeur inconnu vers un exécuteur pouvant accéder aux secrets de production ou au réseau domestique.

Faites du registre un rôle de distribution durable

Stockez les données et la configuration du registre sur un stockage persistant avec authentification, TLS sur les chemins non fiables, règles de rétention et fenêtres de collecte des déchets. Séparez les tags de versions immuables des images de branches jetables.

Sauvegardez la configuration, les métadonnées et tous les artefacts qui ne peuvent pas être reconstruits. Si les images sont reproductibles à partir du code source, documentez la durée de reconstruction et préservez le code source, les définitions de build et les dépendances externes au lieu de sauvegarder chaque couche de cache.

Surveillez la capacité avant le nettoyage. La collecte des déchets d’un registre peut être intensive en E/S et nécessiter un état de maintenance selon l’implémentation.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Gardez les bases de données de test jetables, mais représentatives

Attribuez à chaque pipeline ou branche un nom de base de données, un schéma, un conteneur ou une machine virtuelle isolé. Initialisez-le à partir de jeux de données de test versionnés ou d’un jeu de données nettoyé, exécutez automatiquement les migrations, puis détruisez-le après la période de rétention.

Ne copiez jamais de secrets de production ni de données personnelles non anonymisées dans le rôle de test. Limitez l’accès réseau afin qu’une tâche compromise ne puisse pas se déplacer de la base de données de test vers des services sans rapport.

Ne conservez que les journaux et les artefacts nécessaires au diagnostic des tests échoués. Des bases de données mystérieuses conservées à long terme recréent le problème de l’ordinateur portable sur une machine plus grande.

Construisez la topologie de serveur d’une petite équipe

Utilisez des comptes de service, des réseaux de conteneurs, des volumes, des quotas et des règles de sauvegarde distincts pour les rôles d’exécuteur, de registre et de base de données. Ce guide des plateformes NAS et Docker aide à déterminer si des conteneurs ou des machines virtuelles doivent assurer l’isolation.

Placez l’interface d’administration sur un réseau restreint. N’exposez l’interface du registre et celle de la CI qu’à l’équipe ou par l’intermédiaire d’une couche d’accès authentifiée. Consignez les mises à jour, la propriété et la restauration pour chaque service.

Testez la recréation d’un exécuteur, la restauration ou la reconstruction du registre, la réinitialisation de la base de données, une situation de disque plein et le redémarrage du serveur. Les développeurs doivent tout de même pouvoir travailler localement pendant la récupération des services partagés.

Vérification finale de la configuration

La migration est réussie lorsque les builds s’exécutent sans dépendre d’un ordinateur portable précis, que les environnements sont recréés à partir de définitions versionnées, que les artefacts du registre disposent d’un plan de rétention et de récupération, que les bases de données de test sont isolées et jetables, et qu’aucun exécuteur ne détient plus de secrets que ce que sa tâche exige.