CI/CD a gagné en popularité et est probablement l’un des sujets les plus abordés par les novices en DevOps. Avec la disponibilité des outils CI/CD disponibles sur le marché, la configuration et l’exploitation d’un pipeline CI/CD sont devenues beaucoup plus faciles qu’il y a 5 à 6 ans. À l’époque, il n’y avait pas de conteneurs et le seul outil CI/CD qui dominait la sphère était Jenkins. Jenkins vous a fourni un exécuteur de tâches, afin que vous puissiez définir vos tâches pour qu’elles s’exécutent séquentiellement ou en parallèle.
Aujourd’hui, le scénario est différent. Nous avons de nombreux outils CI/CD disponibles sur le marché, ce qui nous offre des fonctionnalités et des fonctionnalités supplémentaires par rapport à Jenkins. L’un de ces outils CI/CD renommés est GitLab CI et c’est précisément ce que nous allons couvrir dans cet article.
Dans cet article, nous allons configurer un pipeline CI/CD avec GitLab CI/CD et exécuter des tests Selenium dessus via LambdaTest.
Bases de CI/CD
CI/CD est un ensemble de meilleures pratiques suivies pour garantir que vous fournissez des mises à jour de produit à votre application Web de manière cohérente et fiable. Votre application Web est appelée à se développer à chaque sprint intégré à un nouveau cycle de publication. Au départ, vous pouvez avoir une petite équipe responsable des changements de code dans votre application Web. Dans de tels cas, cela ne vous dérangerait pas de tout faire directement, vous construisez le code, vous le testez vous-même et le déployez en production.
Cependant, à mesure que votre équipe grandit, il y aura de nombreux points d’interaction et la probabilité d’erreur augmente lorsque vous essayez de migrer toutes les modifications de code d’un environnement de staging à un autre. C’est là que le pipeline CI/CD joue un rôle central.
Toute entreprise prospère fonctionnant en ligne dépend fortement de la configuration de ses pipelines CI/CD. Selon la haute évolutivité :
Uber est désormais présent dans 400 villes et 70 pays. Ils comptent plus de 6 000 employés, dont 2 000 ingénieurs. Il y a seulement un an et demi, il n’y avait que 200 ingénieurs. Ces ingénieurs ont produit plus de 1000 microservices qui sont stockés dans plus de 8000 référentiels git.
Si vous observez à quelle vitesse une entreprise peut se développer, vous pouvez imaginer les défis qu’Uber pourrait avoir à relever pour se coordonner avec 10 ingénieurs plus tard, en seulement un an et demi, s’ils n’avaient pas intégré un pipeline CI/CD. Dans le monde d’aujourd’hui, il serait extrêmement difficile d’imaginer une application Web évolutive en termes de vitesse et de cohérence sans suivre les meilleures pratiques CI/CD. Maintenant, qu’est-ce que CI et CD ? CI fait référence à l’intégration continue et CD implique la livraison continue. La combinaison des deux peut permettre un déploiement continu. Voyons ce qu’ils signifient.
Qu’est-ce que l’intégration continue ?
Dans les modèles SDLC traditionnels, les développeurs feraient migrer les nouvelles fonctionnalités dans un environnement, une par une, de manière isolée. Cela a créé des problèmes lorsque plusieurs développeurs travaillent sur plusieurs fonctionnalités. L’intégration continue est une pratique qui garantit que les développeurs sont en mesure d’apporter de nombreuses modifications à la branche principale de votre application Web via un référentiel partagé, de manière systématique. En tirant parti de la pratique de l’intégration continue, vos développeurs peuvent intégrer du code autour de correctifs, d’améliorations de produits, etc., dans un référentiel partagé, plusieurs fois par jour. De cette façon, votre lancement global de mise sur le marché peut s’accélérer, ce qui vous permet d’être agile.
Si vous avez accordé un accès en modification au référentiel GitHub aux développeurs de votre équipe, il vous suffit de vous assurer que les développeurs suivent les meilleures pratiques, le style de code et, plus important encore, que les cas de test n’échouent pas. Tant que ces conditions sont remplies, vous ne devez interdire à personne d’enregistrer votre code. Cela aidera votre entreprise à évoluer en permanence.
Qu’est-ce que la livraison continue ?
La livraison continue ne se produit qu’après l’exécution du CI. Comme son nom l’indique, la pratique de la livraison continue garantit que vous disposez d’un pipeline automatique configuré pour déployer les modifications de code d’un environnement intermédiaire à un autre.
La livraison continue comprend toutes les étapes nécessaires pour rendre votre logiciel déployable. Cela comprend l’exécution de tests complets, l’assurance qualité à l’aide d’outils de test, l’exécution de versions, la signature de code, la documentation et le déploiement dans des environnements de pré-production ou d’acceptation par les utilisateurs.
Ne confondez pas la livraison continue avec le déploiement continu
Considérez la livraison continue comme tout sauf le déploiement. Vous préparez le déploiement mais vous ne le déployez pas réellement sur les serveurs de production. Vous laissez le soin aux étapes d’intervention humaine qui garantiront quand et où se déployer. La livraison continue convient aux équipes où le déploiement continu n’est pas requis. Cependant, le déploiement continu est une pratique qui ne peut être mise en œuvre que si vous disposez d’un système de migration bien défini, ce qui le rend irréalisable pour les organisations ayant moins d’employés à bord. Ce qui nous amène à notre prochaine question.
Qu’est-ce que le déploiement continu ?
Le déploiement continu suit en fait la livraison continue. C’est une extension de la livraison continue. Cela amène la livraison continue à un stade où le déploiement de la nouvelle version de la version sur la production est effectué automatiquement.
La seule exigence pour un déploiement continu est que le processus, les vérifications et les tests mis en place garantissent une expérience sans plantage. Maintenant, comme il s’agit d’un système entièrement automatisé, il est impératif que vous passiez plus de temps à développer des cas de test très stricts car, ici, vous n’avez aucune chance de revoir manuellement votre migration. Une fois qu’il est parti; c’est parti.
C’est pourquoi le déploiement continu n’est pas réalisable pour toutes les entreprises. Le déploiement continu doit avoir les règles les plus strictes possibles avant de déployer le code car le processus est un système entièrement automatisé sans aucune intervention humaine.
Étant la dernière étape de la chaîne de production automatisée du pipeline, il est impératif que les contrôles et les tests, à ce niveau, soient les plus stricts et tout ce qui est inférieur à 100% doit être rejeté sans aucune marge de manœuvre.
Malgré tous les avantages du déploiement continu, une équipe doit valider les exigences et n’adopter le déploiement continu que si l’environnement de développement, la sensibilité de la production et le système de test permettent une adoption transparente.
Gardez à l’esprit que si les systèmes en place ne sont pas suffisamment matures, le déploiement peut s’avérer catastrophique pour n’importe quelle équipe. C’est pourquoi la plupart des équipes optent uniquement pour la livraison continue et il n’y a aucun mal à cela. Cela dépend totalement de ce que vous construisez et de son degré d’importance. Il n’y a pas de règle absolue selon laquelle vous devez utiliser le déploiement continu.
Qu’est-ce que GitLab CI/CD ?
GitLab propose une excellente offre CI/CD pour les projets hébergés sur GitLab et d’autres fournisseurs git. En utilisant GitLab CI/CD, vous pouvez intégrer les trois étapes dont nous avons parlé :
- Intégration continue
- Livraison continue
- Déploiement continu
Ce qui rend GitLab CI/CD puissant, c’est qu’il vous permet d’héberger votre référentiel Git sur l’un des autres fournisseurs Git, tels que GitHub, et vous pouvez toujours exploiter son système CI/CD. Vous n’avez même pas besoin de changer de fournisseur Git pour utiliser GitLab CI/CD. La seule exigence pour exécuter CI/CD est la présence d’un fichier de configuration GitLab CI YAML spécial. Le fichier GitLab CI YAML contient toutes les instructions et données nécessaires pour exécuter différents pipelines CI/CD.
De nombreuses options de personnalisation sont disponibles pour façonner les pipelines en fonction des besoins personnalisés.
Note: .gitlab-ci.yml est sous contrôle de version et placé dans le référentiel. Cela permet aux anciennes versions de votre référentiel de se construire avec succès, ce qui facilite l’adoption de la pratique CI par votre équipe. La raison étant que si le GitLab CI YAML est placé dans le référentiel lui-même, cela signifie que vous avez maintenant mis la logique de CI/CD dans votre référentiel. Vous libérant des soucis que votre système CI/CD pourrait tomber en panne et que vous pourriez perdre vos données. Désormais, quel que soit l’endroit où se trouve un code, votre CI/CD y est présent, ce qui simplifie le passage d’un environnement d’hébergement à un autre, tant qu’il utilise le même pipeline. De cette façon, votre équipe peut facilement utiliser les branches CI comme différents pipelines et travaux spéciaux et vous disposez d’une source unique de vérité pour tous les pipelines CI/CD.
Que sont les variables d’environnement GitLab CI/CD ?
Les variables Env sont des valeurs nommées dynamiquement qui peuvent être utilisées pour rendre les pipelines CI/CD complètement dynamiques et paramétrables. En général, il est toujours préférable de continuer à supprimer les valeurs codées en dur et d’utiliser des variables d’environnement pour rendre les tâches portables et indépendantes du fournisseur.
Plus précisément, GitLab dispose d’une énorme liste de variables prédéfinies qui peuvent aider à créer des pipelines CI/CD robustes et flexibles.
Les variables les plus couramment utilisées et les plus importantes comprennent :
CI_COMMIT_REF_NAMECI_COMMIT_BRANCHCI_COMMIT_TAGCI_EXTERNAL_PULL_REQUEST_IID
Ces variables permettent de façonner le pipeline en fonction des différentes branches git et de l’IMO. Cela offre une grande flexibilité dans la différenciation des tâches en fonction des environnements. Il est toujours préférable d’utiliser autant de variables d’environnement que possible pour rendre vos tâches personnalisables et flexibles.
Que sont les dépendances en cache de GitLab ?
Chaque tâche CI/CD nécessite une sorte de phase de construction où la cible la plus appropriée est construite à l’aide de dépendances tierces. En fonction de la pile, ces dépendances sont récupérées à l’aide de gestionnaires de plug-ins, d’importateurs de modules, etc. Imaginez que vous fassiez ce processus plus d’une centaine de fois par jour pour plusieurs projets et calculez le temps et le gaspillage de ressources qu’il entraîne. Pas une image agréable, non?
S’il existait un moyen de mettre en cache ces dépendances construites et d’utiliser ces dépendances mises en cache pour plusieurs pipelines, cela rendrait la construction CI beaucoup plus rapide et réduirait le gaspillage de bande passante et débloquerait les pipelines CI afin que la même Infra puisse être utilisée pour beaucoup plus de constructions. Les dépendances en cache de GitLab vous permettent de le faire exactement dès la sortie du .gitlab-ci.yaml déposer.
C’est aussi simple que…