Lorsque nous parlons d'un pipeline de CI/CD, nous faisons référence au processus qui fait passer le code de votre environnement de développement par différentes étapes, telles que le test et la préproduction, avant de le livrer aux utilisateurs.

Tout l'intérêt de cette approche réside dans l'exécution régulière de ce processus, plusieurs fois par jour, voire par heure. Il est donc essentiel d'automatiser le pipeline de CI/CD autant que possible. Si une étape se termine correctement, elle doit déclencher la suivante automatiquement. Par contre, si elle échoue, ce retour doit être rapidement communiqué pour résoudre le problème.

L'automatisation de vos pipelines de CI/CD non seulement accélère le processus global de création, de test et de déploiement de logiciels, mais elle garantit également que chaque étape s'exécute de façon cohérente et fiable.

La première étape de l'implémentation de l'intégration continue consiste à transférer l'ensemble de votre base de données dans un système de contrôle de version ou VCS (également appelé gestion du contrôle de code source ou SCM), tel que Git, Mercurial ou Perforce. Ensuite, vous devez amener tous les membres de votre équipe à effectuer fréquemment des commits de leurs modifications. Chaque commit sur le processus principal déclenche une exécution du pipeline d'intégration continue : le code est compilé et testé pour vous fournir un retour rapide sur les dernières modifications.

Bien que les commits fréquents constituent une pratique importante dans le pipeline de CI/CD, si vous travaillez sur une fonctionnalité plus importante qui prend plusieurs jours ou semaines à terminer, envoyer périodiquement des commits pendant ce processus peut paraître contre-productif.

D'une part, la réalisation d'un push de votre modification dans le pipeline par paliers réguliers permet de disposer de feedbacks rapides. Cela permet également de réduire la probabilité de conflits de fusion complexes par rapport à l'attente de la fin de la fonctionnalité.

D'un autre côté, pousser des fonctionnalités incomplètes dans le pipeline peut ne pas être idéal. Partager un travail partiel avec les autres utilisateurs, y compris dans les environnements de préproduction, peut ne pas être souhaitable non plus.

Les indicateurs de fonctionnalités et les branches de fonctionnalité permettent de contourner ce problème. Les indicateurs de fonctionnalités vous permettent de spécifier les environnements dans lesquels vous souhaitez que votre code soit visible. Vos modifications sont toujours enregistrées dans la branche principale et visibles par votre équipe, mais c'est vous qui décidez quand la fonctionnalité devient disponible en préproduction et en production.

Les branches de fonctionnalité vous permettent de développer votre fonctionnalité dans une branche distincte, sans perdre les avantages du build et des tests automatisés. En déclenchant le pipeline de CI/CD à chaque commit sur une branche de fonctionnalité (comme pour un commit sur la branche principale), vous obtenez des retours rapides sur votre projet.

Pour que les résultats de vos tests automatisés soient fiables, vous devez vous assurer qu'ils s'exécutent de manière cohérente.

Idéalement, vos environnements de test doivent être configurés de manière à être aussi similaires que possible à l'environnement de production, et ils doivent être réinitialisés entre les tests pour éviter que les incohérences environnementales ne perturbent les résultats de vos tests.

Les machines virtuelles (VM) sont depuis longtemps un choix populaire pour l'exécution des environnements de test, car vous pouvez programmer l'environnement pour qu'il se réinitialise à chaque nouveau build.

Cependant, arrêter et lancer de nouvelles machines virtuelles prend du temps, et vos scripts doivent inclure une configuration pour chaque environnement virtuel afin de fournir toutes les dépendances nécessaires à l'exécution du logiciel. Lorsque de nouvelles dépendances sont ajoutées, les scripts d'environnement doivent être mis à jour. Attention à ne pas oublier ce point, car cela peut empêcher l'exécution du build.

Vous pouvez éviter ces problèmes en intégrant votre code dans un conteneur lors de l'étape initiale de build. Un conteneur comprend toutes les dépendances dont le logiciel a besoin pour fonctionner, ce qui lui confère une grande portabilité et facilite son déploiement dans différents environnements.

Si vous hébergez vos pipelines de CI/CD sur votre propre infrastructure, des machines virtuelles seront toujours nécessaires pour y déployer les conteneurs, mais la préparation de l'environnement de test nécessite moins d'efforts. Si vous exécutez votre pipeline dans le cloud, vous pouvez tirer parti de l'infogérance en utilisant des conteneurs et externaliser la gestion de l'infrastructure en la confiant à votre fournisseur cloud.

Le nombre d'environnements de test et de préproduction dans l'architecture de votre pipeline dépend de votre produit et des exigences des parties prenantes de votre organisation. Par exemple, il peut s'agir de tests exploratoires, d'analyses de sécurité, de recherches relatives aux utilisateurs, de démonstrations de vente, d'environnements de formation et de sandboxes permettant au personnel chargé de l'assistance de reproduire les problèmes des clients.

L'automatisation de la création et du déploiement dans ces environnements est plus efficace que leur actualisation manuelle. Vous pouvez également configurer différents déclencheurs de pipeline pour différents environnements.

Par exemple, alors que vos environnements de test peuvent être mis à jour à chaque build, vous pouvez décider d'actualiser les environnements intermédiaires moins fréquemment (éventuellement une fois par jour ou par semaine avec le dernier build réussi).

Lorsque vos modifications de code ont réussi toutes les étapes précédentes du pipeline, elles sont prêtes pour la mise en production. Cette étape finale peut être manuelle ou automatique.

La publication manuelle (livraison continue) est utile si :

• Vous souhaitez maîtriser la date de disponibilité des nouvelles fonctionnalités.
• Votre processus de déploiement prévoit des périodes d'inactivité pour vos utilisateurs.
• Les utilisateurs doivent installer votre produit et vous souhaitez regrouper les modifications conformément à un échéancier de publication.

Avec le déploiement continu, la publication est automatique. Les modifications qui satisfont toutes les étapes précédentes sont mises en production. Pour les grandes équipes qui réalisent souvent des commits, cela peut se traduire par plusieurs dizaines de déploiements quotidiens de mises à jour, un exploit impossible à réaliser en l'absence de pipeline automatisé.

L'approche CI/CD est une pratique DevOps qui utilise l'automatisation pour fournir des retours rapides à chaque étape du cycle de vie de développement logiciel. L'identification des problèmes introduits par vos dernières modifications de code rend le développement logiciel plus efficace. En opérant un déplacement vers la gauche (en avançant les interactions pour obtenir un feedback plus rapidement), les problèmes sont identifiés plus rapidement et la création d'un pipeline automatisé met ces techniques en œuvre.

Lorsque vous concevez votre propre processus de CI/CD, il est intéressant de le développer par étapes, en commençant par l'intégration continue. Les étapes exactes du pipeline et la logique qui détermine à quel moment chaque étape est déclenchée dépendent de votre produit et de votre organisation.

Choisir une plateforme de CI/CD qui vous offre la souplesse nécessaire pour configurer votre pipeline en fonction de vos besoins, tout en étant facile à gérer, vous aidera à mettre en place un processus de publication fiable et à améliorer la qualité de vos logiciels.

Notre solution TeamCity Pipelines permet d'automatiser vos processus de CI/CD.

Avec la prise en charge de tous les principaux systèmes de contrôle de version et d'intégration avec des outils populaires de build, de test et de gestion de paquets, TeamCity Pipelines permet de transformer vos workflows de développement en pipelines automatisés et efficaces.

Des options de déclenchement flexible et un éditeur de pipeline visuel facilite la configuration des pipelines quel que soit le workflow. Les configurations sont stockées automatiquement sous forme de code, ce qui vous donne la liberté de créer et de gérer vos pipelines dans l'interface graphique tout en profitant des avantages de la configuration en tant que code.

Les options de déploiement sur site et cloud natives de TeamCity vous donnent la flexibilité indispensable pour exécuter vos pipelines où vous le souhaitez et évoluer à la demande. Des fonctionnalités telles que la parallélisation des tests et les retours en temps réel permettent d'identifier les erreurs rapidement pour une expérience de développement plus productive.