Modèles CI / CD et anti-modèles. Partie 1

Bonjour à tous! Chers amis, le dernier jour de l'hiver, nous lancerons un nouveau volet sur le cours «Pratiques et outils DevOps» . En prévision du début du cours, nous partageons avec vous la première partie de l'article: «Patterns CI / CD et Anti-Patterns».



La tâche de pipeline de déploiement comprend trois parties:

• Visibilité: tous les aspects de la chaîne d'approvisionnement - création, déploiement, test et publication - sont visibles pour les membres de l'équipe et facilitent la collaboration.
• Commentaires: les membres de l'équipe découvrent les problèmes dès qu'ils surviennent, afin qu'ils puissent être résolus dès que possible.
• Déploiement continu: à l'aide d'un processus entièrement automatisé, vous pouvez déployer et publier n'importe quelle version de logiciel dans n'importe quel environnement.

Dans le diagramme de pipeline de déploiement ci-dessus, tous les modèles ont un contexte. Certains modèles couvrent plusieurs étapes de ce pipeline, j'ai donc choisi l'étape à laquelle ils sont le plus souvent utilisés.

1.1 Gestion de la configuration - Modèles et anti-modèles

1.1.1 Logiciel tiers personnalisé

• Modèle: évaluer et utiliser des logiciels tiers qui peuvent être facilement configurés, déployés et automatisés.
• Anti-pattern: logiciel qui ne peut pas être configuré en externe. Logiciel sans API ni interface de ligne de commande qui nécessite une commande pour utiliser une interface graphique.

1.1.2 Répertoire de configuration

• Modèle: prise en charge d'un catalogue de tous les paramètres de chaque application, des façons de modifier ces paramètres et de l'emplacement de stockage de chaque application. Création automatique de catalogue dans le cadre du processus de construction.
• Anti-patterns: les paramètres de configuration ne sont pas documentés. Le catalogue de toutes les applications et autres actifs est un «folklore» local indescriptible.

1.1.3 Ligne principale

• Modèle: Minimiser les fusions, contrôler le nombre de lignes de code actives en travaillant sur la ligne principale.
• Anti-patterns: plusieurs branches par projet.

1.1.4 Fusion quotidienne

• Schéma: les modifications validées dans la ligne principale sont appliquées à toutes les succursales au moins tous les jours.
• Anti-patterns: fusionnez toutes les itérations une fois par semaine ou moins d'une fois par jour.

1.1.5 Configuration sécurisée

• Modèle: stockage des informations de configuration dans un endroit sécurisé et accessible à distance, par exemple, dans une base de données, un répertoire ou un registre.
• Anti-modèles: mots de passe de texte ouverts et / ou un ordinateur ou une ressource partagée.

1.1.6 Référentiel

• Modèle: tous les fichiers source - code exécutable, configuration, environnement hôte, données - sont téléchargés dans le référentiel avec contrôle de version.
• Anti-modèle: certains fichiers sont zippés, d'autres, par exemple, les configurations d'environnement ou les modifications de données, ne le sont pas. Les fichiers binaires qui peuvent être recréés pendant le processus de génération ou de déploiement sont archivés.

1.1.7 Branches de courte durée

• Schéma: Les branches doivent être de courte durée, idéalement, plusieurs jours et pas plus d'une itération.
• Anti-motifs: Branches vivant plus longtemps que l'itération. Branches pour la fonctionnalité du produit, vivant après la sortie.

1.1.8 Environnement d'équipe

• Modèle: consultez le référentiel de projet avec contrôle de version et exécutez une seule commande pour créer et déployer l'application dans n'importe quel environnement disponible, y compris le développement local.
• Anti-pattern: obliger le développeur à définir et configurer les variables d'environnement. Forcer le développeur à installer de nombreux outils de build / déploiement.

1.1.9 Une façon de fonctionner

• Schéma: gestion de la configuration de l'ensemble du système - sources, configuration, environnement, données. Toutes les modifications peuvent être suivies jusqu'à une révision spécifique dans le système de contrôle de version.
• Anti-patterns: Certaines parties du système n'ont pas de version. Impossible de revenir au paramètre de logiciel système précédent.

1.2 Intégration continue CI - Modèles et anti-modèles

1.2.1 Seuil de construction

• Motif: l'assemblage se bloque lorsque les règles du projet sont violées. Par exemple, violations d'architecture, tests lents, violation des normes d'écriture de code.
• Anti-patterns: révision manuelle du code. Détecter les problèmes de qualité du code dans les dernières étapes du cycle de développement.

1.2.2 Commissions fréquentes

• Schéma: Chaque membre de l'équipe est régulièrement enregistré - au moins une fois par jour, mais idéalement après chaque tâche pour activer le système CI.
• Anti-patterns: les fichiers source sont validés moins d'une fois par jour en raison du nombre de modifications apportées par le développeur.

1.2.3 Rétroaction continue

• Modèle: Envoi automatique de commentaires du système CI à tous les membres de l'équipe interfonctionnelle.
• Anti-modèles: les notifications ne sont pas envoyées; les notifications sont ignorées; le système CI envoie des informations à tous ceux qui ne peuvent pas être utilisés.

1.2.4 Intégration continue

• Modèle: l'assemblage et les tests du logiciel se produisent après la validation de toute modification du référentiel de projet avec contrôle de version.
• Anti-patterns: Assemblages planifiés, assemblages nocturnes, assemblages périodiques, assemblages exclusivement sur la machine du développeur, absence totale d'assemblage.

1.2.5 Le principe de la «ligne d'arrêt»

• Modèle: Réparez tous les bogues de livraison de logiciels dès qu'ils se produisent; "Arrêtez la ligne". Personne ne vérifie un assemblage cassé, car le réparer a la plus haute priorité.
• Anti-pattern: les assemblys restent cassés pendant longtemps, empêchant ainsi les développeurs de vérifier le code de travail.

1.2.6 Assemblée indépendante

• Modèle: les scripts de construction sont écrits séparément de l'EDI. Ces scripts sont exécutés par le système CI afin que l'assemblage soit effectué à chaque modification.
• Anti-patterns: les builds automatiques dépendent de la configuration IDE. Impossible de démarrer l'assemblage à partir de la ligne de commande.

1.2.7 Tableaux de bord visibles

• Schéma: Il est possible de voir toutes les informations sur votre système de livraison. Fournir des commentaires d'équipe interfonctionnels en temps réel de haute qualité.
• Anti-Patterns: les alertes ne sont envoyées que par e-mail. Les commentaires ne sont pas publiés pour toute l'équipe.

La fin de la première partie.

Voici un tel matériau. Vous pouvez lire la suite de la traduction ici , et maintenant nous attendons vos commentaires et nous vous invitons à un webinaire ouvert , qui se tiendra ce soir.