La mise en œuvre d'un flux de travail CI/CD pour le développement d'applications devient de plus en plus populaire. Dans le même temps, cependant, la mise à l'échelle et l'optimisation du CI/CD posent un défi.
Aujourd'hui, nous allons discuter de ce défi et explorer exactement comment nous pouvons faire évoluer et optimiser CI / CD. Alors, suivez-nous !
De nos jours, le développement d'applications se fait généralement en équipes composées de plusieurs développeurs. Chaque personne ou équipe a son rôle dans le projet en avançant sur sa partie dédiée.
On se retrouve alors à la fin du projet avec plusieurs morceaux de code à compiler. Selon les méthodes de travail de chacun, beaucoup de temps peut être perdu à gérer cette intégration.
CI/CD, intégration continue et livraison/déploiement continus sont une solution à ce problème et garantissent que les mises à jour sont publiées sans retards ni conflits inutiles. Comprenons ce processus.
Intégration continue
CI ou Intégration Continue regroupe des processus visant à publier en continu les modifications et ajouts de code dans une branche commune du projet. Il permet de tester le code et d'apporter des améliorations et des modifications en temps réel. Le but est de tester chaque élément à travers la création de tests.
Cette mesure permanente permet de ne pas tout vérifier d'un bloc à la fin et d'éviter de travailler sur trop d'éléments simultanément. Réaliser des tests unitaires est donc très utile pour s'en assurer. Ainsi, il est plus facile de détecter les erreurs en s'assurant que le code se compile bien et ne crée pas de régressions.
Livraison continu
La livraison continue ou CD regroupe l'intégration continue et vers les tests qui peuvent être regroupés dans des conteneurs et mis en production. C'est-à-dire qu'il rassemble ces codes et tests effectués et les met en production via l'automatisation.
Même s'il nécessite une action humaine, il s'automatise en mettant tout ce qui a été fait « à l'antenne » de manière intégrée et complète. Concrètement, avec la distribution continue, notre application est développée pour pouvoir être mise en production, n'importe quand.
Déploiement continu
Bien que les concepts de livraison continue et de déploiement continu soient similaires, il existe des différences. Si leur objectif est le même, c'est-à-dire le déploiement de l'application en production, les moyens pour y parvenir diffèrent. Ce qui sépare la livraison continue du déploiement continu, c'est la version.
En effet, le déploiement continu permet de déployer directement chaque modification qui traverse les différentes étapes de notre pipeline. En livraison continue, une étape de validation humaine est nécessaire pour que le déploiement ait lieu.
Scaling CI/CD
Lorsque le nombre de microservices augmente, il devient presque inévitable de faire évoluer votre CI/CD. L'augmentation du nombre de microservices entraîne la connexion de différents pipelines à un seul référentiel git, ce qui augmente la charge du serveur CI et réduit les performances.
Pour faire évoluer le CI/CD, il est nécessaire de créer un pipeline de développement standardisé et automatisé pour toutes les équipes et, à partir de là, d'assurer la qualité des livraisons individuelles des développeurs et des livraisons des équipes. Cela facilite également la gestion du pipeline.
La mise à l'échelle peut être réalisée en définissant un processus CI pour l'exécution tests unitaires et valider la qualité du code livré.
Suivi d'un processus CD pour construire les images et les déployer dans les environnements en continu et enfin définir un processus pour construire les images et les déployer dans l'environnement de production.
Steps to Scale CI/CD
La première étape consiste à aligner le pipeline avec les architectes, en impliquant les chefs d'équipe. Il suit le mapping des branches Git vers les environnements (develop -> development and master -> [homologation and production]). Vient ensuite le déclenchement du Job CI à chaque Pull Request et du Job CD à chaque changement dans les branches mappées.
Un flot de travaux peut être créé pour le CI et le CD à suivre.
Le Job Flow CI se développe en 7 étapes :
- Découvrez la branche source et destination de la Pull Request ;
- Vérifie si la fusion n'a pas de conflits nécessitant une résolution manuelle ;
- Exécuter des tests unitaires ;
- Construisez le package pour vérifier l'intégrité et que le code est compilable ;
- Validation de la qualité du code déclencheur ;
- Incrémenter et valider la version du projet dans la branche source ;
- Notifier le référentiel Pull Request Git du succès ou de l'échec via Webhook ou API Rest appel (dépôt Git).
Le flux de travail du CD suit le chemin suivant :
- La succursale notifiée est extraite.
- L'artefact est construit à l'aide de l'outil de construction spécifique du projet sur lequel on travaille.
- Après l'arrivée de l'artefact, les projets de bibliothèque sont envoyés au Nexus pour le stockage de l'artefact, et le flux est terminé.
Les actions suivantes sont réalisées :
Étape 1 : Une image Docker est créée pour l'artefact généré, en appliquant la version de l'artefact à l'image Docker.
Étape 2 : L'image est chargée dans le registre Docker.
Étape 3 : Déploiement via déploiement d'image via Kubernetes.
Pour les projets d'application qui se trouvent dans un environnement d'approbation/de production, suivez les étapes 1 et 2 ci-dessus, puis les étapes suivantes :
- Déployer via le déploiement d'image via Kubernetes dans l'environnement d'approbation ;
- Le travail prend une pause pour attendre que le déploiement soit approuvé pour la production ;
- Si elle est approuvée, l'image en cours d'approbation est promue pour la production ;
- Sinon, il annule l'image en approbation.
CI/CD Optimization
CI/CD améliore le cycle de développement d'applications et résout le problème causé par l'intégration de nouveau code et l'augmentation de la fréquence de livraison.
Voici comment optimiser davantage l'utilisation de CI/CD :
Donner la priorité à la réparation d'une version corrompue
Lorsqu'un build tombe en panne, le réparer doit être la priorité de l'équipe. Si la version ne peut pas être corrigée en quelques minutes, l'équipe doit décider de supprimer le code ou de désactiver l'indicateur de fonctionnalité.
L'idée derrière la réparation d'une version cassée est que la version produira toujours du code fonctionnel qui peut être publié.
Petits déploiements fréquents
Généralement, la stabilité de l'application est menacée chaque fois qu'un déploiement se produit. Nous avons donc tendance à éloigner les déploiements les uns des autres. Le problème de cette approche est que nous accumulons trop de changements. L'un de ces changements pourrait mal tourner, nous obligeant à annuler les autres qui fonctionnaient.
Appliquez le motif de l'étrangleur et décomposez les changements compliqués en petits changements simples. Si vous déployez plus fréquemment et travaillez par petits lots, le risque de déploiement est moindre.
Automatisez les tests d'assurance qualité pour atténuer les risques
Nous avons probablement tous été impliqués dans le scénario "travaillé sur ma machine locale" car les environnements de développement locaux diffèrent souvent. Il peut y avoir beaucoup de choses différentes entre votre environnement local et votre lieu de production. Vous pouvez optimiser CI/CD en automatisant les tâches d'assurance qualité (QA) telles que les tests de navigateur, atténuant ainsi le risque qu'un bogue n'atteigne l'application en direct.
Faites confiance aux tests automatisés
Pour valider lorsqu'un développeur intègre un nouveau code, CI s'appuie sur une suite de tests automatisée et fiable. Si vous avez besoin compiler du code, le premier test est qu'il compile. Ensuite, vous pouvez ajouter autant de tests que vous jugez critiques.
Combien de tests doivent être inclus ? Pour déterminer cela, rappelez-vous que l'objectif de CI est de fournir des commentaires aussi rapidement que possible. Si un développeur doit attendre une heure pour obtenir des commentaires, cela ne fonctionnera pas. Vous manquerez toujours des choses, mais lorsque vous repérez un bogue en production, créez un cas de test et incluez-le dans la boucle CI.
Pensez toujours à la sécurité
Tenez compte de la sécurité d'un outil CI/CD lorsqu'il s'intègre dans des configurations ou des environnements existants. CI/CD exige que tous les outils de test de sécurité soient appelés par programmation et leurs résultats agrégés en un seul endroit. Recherchez des outils dotés d'API pour les audits de chiffrement automatisés.
Benefits of Scaling and Optimizing CI/CD
Outre l'augmentation de l'efficacité des équipes de développement, la mise à l'échelle et l'optimisation du CI/CD présentent également d'autres avantages, dont certains sont :
Frais généraux réduits
Les heures de développement sont généralement facturables, mais qu'en est-il du temps passé à déployer manuellement du code ou des fichiers ? L'automatisation de grandes parties de votre flux vous fera gagner du temps pour le travail facturable, ce que tout le monde peut apprécier. Les tests automatisés vous permettent également d'échouer plus tôt plutôt que de trouver des erreurs dans l'AQ ou la production ou pire, le client les trouve. Plus de bugs corrigés dans le même laps de temps est une nette victoire.
Livraison avec moins de bugs et moins de risques
Vous détectez les bogues beaucoup plus tôt dans le processus de développement en publiant plus fréquemment des modifications mineures. Lorsque vous implémentez des tests automatisés à toutes les étapes du développement, vous ne risquez pas de déplacer le code défaillant à l'étape suivante, et il est plus facile d'annuler les modifications mineures si nécessaire.
Réagissez plus rapidement aux conditions du marché
Les conditions du marché changent constamment. Supposons que vous découvriez qu'un nouveau produit perd des revenus ou que plus de clients accèdent à votre site à partir de smartphones que d'ordinateurs portables. Dans ce cas, il est beaucoup plus facile d'effectuer un changement rapide si vous avez optimisé la livraison continue.
Confiance
Si vous avez optimisé CI/CD, ce qui signifie que vous disposez d'une suite de tests robuste, votre confiance dans le fait de ne pas soumettre de bogue augmente considérablement. Si vous êtes transparent avec votre processus et éduquez le reste de votre équipe et vos clients, leur confiance en vous en tant qu'équipe de développement augmente également.
Mot de la fin
CI/CD accélère vos intégrations et livraisons. Cependant, il est important de le mettre à l'échelle et de l'optimiser pour éviter que le processus ne devienne contre-productif en raison de la complexité croissante.
Vous pouvez également consulter certains des meilleurs outils CI.
