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 fait partie d'une pratique plus générale appelée DevOps. Le DevOps crée une passerelle entre le développement (création de produits et services) et les opérations (publication et gestion de ces logiciels) et peut être appréhendé aussi bien comme une méthode de travail qu'un état d'esprit. Il repose sur les principes Agile pour aider l'entreprise en général, et les équipes de développement en particulier, à livrer plus rapidement des logiciels de qualité.

Lors de l'implémentation de vos pipelines de CI/CD, comprendre ce que signifie DevOps facilite les premières étapes. Il est utile de conserver les points suivants à l'esprit :

• Le DevOps souligne l'importance de la fédération autour d'un objectif de l'ensemble des personnes intervenant dans la création, la publication et la maintenance des logiciels, afin de produire des logiciels qui répondent aux besoins des utilisateurs.
• L'approche DevOps repose sur le concept de déplacement à gauche. Cela signifie que les problèmes sont identifiés aussi tôt que possible en amont, de façon à ne pas cumuler les retards en aval. C'est pourquoi les pipelines de CI/CD se concentrent sur des boucles de feedback régulières et rapides, afin de faciliter le déplacement vers la gauche.
• L'apport des compétences et de l'expertise des développeurs aux opérations permet d'automatiser des tâches, telles que la maintenance des infrastructures et l'actualisation des environnements.
• En exposant les équipes de développement au travail normalement géré par les équipes opérationnelles, les développeurs bénéficient d'une meilleure visibilité de l'ensemble du processus, ce qui leur permet d'anticiper les bugs et le feedback des utilisateurs.

Les pipelines de CI/CD permettent d'automatiser ce qui se produit depuis le commit des modifications jusqu'à la publication d'une nouvelle version de votre logiciel. L'automatisation de ces tâches accélère l'exécution et les feedbacks, ce qui permet d'apporter les corrections nécessaires plus tôt et de gagner ainsi un temps et des ressources précieux.

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.

TeamCity est une solution de CI/CD conçue pour une méthode de travail DevOps. Avec la prise en charge de tous les systèmes de contrôle de version, une large gamme d'outils de gestion de builds, de test et de gestion de package, ainsi que des plateformes populaires de gestion des machines virtuelles et des conteneurs, TeamCity vous aide à transformer vos processus existants en pipelines de CI/CD automatisés.

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 bâtir votre logique dans l'interface utilisateur graphique pendant l'exploitation de l'ensemble des avantages de la configuration en tant que code.

Grâce à la conception haute performances de TeamCity, un serveur de build unique permet de gérer des milliers de projets. Les options de déploiement sur site et cloud natives vous donnent la flexibilité indispensable pour exécuter vos pipelines où vous le souhaitez et évoluer à la demande. La parallélisation des tests et les résultats en temps réel raccourcissent encore plus les boucles de feedback, afin d'identifier les problèmes plus tôt et d'offrir une expérience de développement plus productive.