Pourquoi les développeurs déplacent-ils les runners 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 pour rendre les builds reproductibles, permettre l’accès aux dépendances partagées, rendre l’état des tests jetable et assurer la livraison indépendamment de la batterie ou de l’espace de travail d’un développeur.

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

Commencez par le problème du flux de travail

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 des vérifications fréquentes et automatisées, visibles par tous. Les pratiques d’intégration continue de Martin Fowler mettent l’accent sur des builds qui s’auto-testent automatiquement et des résultats visibles, des propriétés difficiles à garantir avec un ordinateur portable parfois disponible.

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

Séparer le périmètre de confiance des runners

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

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

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

Faire du registre un rôle de distribution pérenne

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 plages horaires de collecte des déchets. Séparez les tags de version immuables des images de branche jetables.

Sauvegardez la configuration, les métadonnées et les artefacts qui ne peuvent pas être reconstruits. Si les images peuvent être reproduites à partir du code source, documentez le délai de reconstruction et conservez le code source, les définitions de build et les dépendances externes plutôt que de sauvegarder chaque couche de cache.

Surveillez la capacité avant le nettoyage. Le ramasse-miettes du registre peut solliciter fortement les entrées-sorties et, selon l’implémentation, nécessiter un mode de maintenance.

Featured

NAS cloud personnel et domestique ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Gardez les bases de données de test éphémères, mais représentatives

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

Ne copiez jamais de secrets de production ni de données personnelles non expurgées dans le rôle de test. Limitez l’accès réseau afin qu’une tâche compromise ne puisse pas pivoter 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. Les bases de données durables et obscures recréent le problème de l’ordinateur portable, mais sur une machine plus puissante.

Concevoir la topologie du serveur pour 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 de runner, de registre et de base de données. Ce guide des plateformes NAS et Docker vous aide à déterminer si les conteneurs ou les machines virtuelles doivent assurer l’isolation.

Placez l’interface de gestion sur un réseau à accès restreint. N’exposez le registre et l’interface CI qu’à l’équipe ou via une couche d’accès authentifiée. Consignez les mises à jour, les responsabilités et les procédures de retour arrière pour chaque service.

Testez la recréation d’un runner, la restauration ou la reconstruction du registre, le réamorçage de la base de données, le cas d’un disque plein et le redémarrage du serveur. Les développeurs doivent pouvoir continuer à travailler localement pendant le rétablissement 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 conservation et de récupération, que les bases de données de test sont isolées et éphémères, et qu’aucun runner ne détient plus de secrets que ne l’exige sa tâche.