Vers une livraison continue : les stratégies et bonnes pratiques pour concevoir une usine logicielle CI/CD performante

24 juin 2024

Pascal Ly

Consultant Senior Architecture

Le défi de l’usine logicielle

La mise en place d’une usine logicielle CI/CD (intégration et déploiement continu) est un élément clé pour les équipes DevOps. Cependant, il existe un débat sur la meilleure approche pour atteindre cet objectif : construire en interne ou acheter une solution sur le marché.

Dans les 2 cas, un investissement initial est nécessaire, mais indispensable pour obtenir des résultats probants sur la durée.

Toutefois, les options sont nombreuses et variées. Dès lors, toutes les possibilités offertes sur le marché peuvent rapidement dépasser une entreprise.

La transition vers le DevOps implique un changement culturel et une collaboration étroite entre développeurs (Dev) et exploitants (Ops). Cette évolution repose sur le choix judicieux et la mise en œuvre efficace d’une chaîne d’outils adaptée.

Quels sont les éléments à prendre en considération pour construire un écosystème DevOps à la fois agile et performant ?

Quelles sont les étapes pour mener à bien cette réflexion ?

L’usine logicielle : l’outil indispensable pour une approche DevOps réussie

Une usine logicielle (UL) permet d’automatiser les processus liés au développement de logiciels avec une approche structurée. L’usine logicielle tire son inspiration des pratiques de Toyota dans les années 70, avec des processus de fabrication automatisée.

Les objectifs auxquels répond ce type de plateforme sont multiples :

Réduire les pertes de temps et gagner en efficacité
Maintenir une qualité du code tout au long de la chaîne de production
Livrer des fonctionnalités à forte valeur ajoutée
Détecter les régressions applicatives immédiatement grâce aux tests et obtenir rapidement le feedback utilisateur sur les risques commerciaux
Améliorer et développer le logiciel de façon continue

Les développeurs réduisent les risques lors des déploiements en utilisant une plateforme commune pour le contrôle de version, l’analyse de code, et les tests.

L’orchestration et l’automatisation de ces activités fiabilisent ainsi les mises en Production. Elles assurent une livraison continue du produit tout en restant conforme à l’évolution du marché.

Il est désormais incontestable que les entreprises qui adoptent la culture DevOps bénéficient d’un retour sur investissement significatif. Pour plus d’informations, consultez notre article les 6 bonnes raisons afin de vous convaincre de franchir le pas !

Travailler avec une architecture de référence

Pour commencer, utilisez une architecture de référence pour guider la construction d’un système de développement et de livraison automatisé.

Une plateforme DevOps est constituée d’outils nécessaires à l’industrialisation du développement. Ces outils peuvent être regroupés sous 5 grandes familles d’activités :

Réaliser : Ensemble des capacités nécessaires à la construction, l’assemblage et aux tests du code en continu
Livrer : Ensemble des capacités visant à déployer les applications et leurs infrastructures en continu
Orchestrer : Ensemble des capacités de coordination et de l’automatisation de tâches
Superviser et Exploiter : Ensemble des capacités à surveiller et à assurer la disponibilité de la Production
Planifier et Collaborer : Ensemble des capacités de simplification du partage et de communication entre les équipes de réalisation

Chaque famille comprend plusieurs fonctions qui ne sont pas destinées à être toutes implémentées, et encore moins au même moment. Ainsi, vous pouvez réaliser les tests de non-régression en dehors du pipeline et les intégrer dans un deuxième temps.

La création d’une usine logicielle nécessite une vision à court, moyen et long terme. Elle nécessite l’application des bonnes pratiques dès le début, et une réflexion sur le niveau d’intégration souhaité.

Définir sa stratégie de déploiement et d’organisation UL

Combien de chaînes DevOps à mettre en place ? Pour quels besoins ?

La définition de l’architecture de référence n’est que la première étape de votre démarche.

Avant de commencer à construire des pipelines de livraison de logiciels, il est crucial de définir les utilisateurs de ces usines.

L’usage doit être étudié sous plusieurs aspects :

par technologie : l’UL est construite en fonction du langage de programmation : python, java, framework .NET… Elle sera utilisée par les équipes et applications qui développent suivant ces technologies
par criticité de l’application : l’UL regroupe une ou plusieurs applications en fonction de sa criticité au sein de l’entreprise
par département : l’UL est considérée au niveau du département/direction. Les applications d’une même branche d’activité sont intégrées au sein de cette UL. Toutefois, il est possible de rationaliser les applications de plusieurs départements au sein d’une seule UL.
par type de plateforme et d’infrastructure : l’UL est utilisée par les applications se trouvant uniquement sur une infrastructure On-premise. Une autre UL est créée pour les applications hébergées dans le Cloud

Mettre en place plusieurs pipelines n’implique pas une totale autonomie de chaque équipe en matière de choix technologiques et de stratégie globale.

Avant de créer une UL, il est essentiel que les équipes coopèrent, partagent leurs décisions et alignent leurs savoir-faire pour le déploiement et le partage des connaissances : You build it, You run it (celui qui conçoit est aussi celui qui déploie), and You share it (et partage ses connaissances à travers des communautés de pratiques pour aligner les savoir-faire).

Par choix stratégique de l’entreprise, il arrive souvent que des applications fusionnent pour ne former qu’un seul et même outil. Si une seule usine logicielle ne gère pas initialement les applications, réévaluez le choix de l’usine pour réaliser les tests et se conformer aux risques de sécurité des différentes parties.

En revanche, il n’est pas nécessaire d’administrer plusieurs outils de gestion du code source sur le(s)quel(s) seraient raccordés le(s) pipeline(s).

Les possibilités sont nombreuses et la conception ne s’arrête pas à ces perspectives. Certains découpages seront plus favorables à l’entreprise en fonction de la maturité des équipes, de l’homogénéité des solutions, du budget, ou encore des enjeux métiers.

Pipeline CI/CD : Make or buy ?

Vaut-il mieux acheter une solution du marché, payer à l’usage, ou se créer sa propre pile technologique ?

Le choix relève d’une décision stratégique et est porté suivant plusieurs axes de réflexion :

La maturité de l’équipe DevOps : quel est le niveau d’expérience de l’équipe DevOps en place ?
Le nombre potentiel d’utilisateurs : vaut-il le coût de construire une UL pour une application à faible fréquentation ?
Les coûts de revient : combien l’UL va-t-elle coûter à l’année en termes d’infrastructure, de maintenance et d’exploitation ? Quel est le gain apporté en contrepartie ?
La compatibilité entre les outils pour une UL custom : un développement spécifique peut être nécessaire pour faire communiquer les outils entre eux
La capacité des logiciels et technologies à s’inscrire dans le temps

Ne sous-estimez pas l’effort et le coût nécessaire pour construire et maintenir un pipeline basé sur des logiciels open source (ex: GIT, Jenkins, SonarQube, Maven) : l’open source ne signifie pas nécessairement que c’est gratuit, mais que vous avez la possibilité de modifier et customiser le code source à votre convenance.

L’avantage d’utiliser une plateforme externalisée en mode PaaS ou SaaS (ex: Azure Devops, AWS CodePipeline, Google Cloud Build, GitLab) est de pouvoir immédiatement en tirer de la valeur. Certes, un outil propriétaire générera des coûts de licence ou d’utilisation, mais vous pourrez vous concentrer à 100% sur l’essentiel : délivrer de la valeur pour les métiers.

De plus, une solution orientée « As A Service » propose une chaîne d’outils “Tout-en-Un” et s’affranchit des risques d’obsolescence. Les mises à jour sont généralement transparentes pour les utilisateurs.

Les différences entre les logiciels open source et propriétaires vont bien au-delà de l’accessibilité du code source. Elles incluent également des éléments cruciaux tels que l’assistance technique, l’UX/UI, l’innovation, la sécurité et les coûts.

La réussite d’une organisation DevOps repose en grande partie sur une vision partagée à long terme et des ressources humaines et financières allouées à sa mise en place : auditez vos équipes et votre organisation !

Hébergement de l’UL : comment choisir entre On-Premise et Cloud ?

Pour identifier les applications de votre entreprise et celles éligibles à une automatisation, commencez par les localiser.

Selon la cartographie que vous établirez, une stratégie envisageable consisterait à mettre en place :

Une infrastructure DevOps On-premise pour déployer des applications hébergées sur site
Une infrastructure DevOps dans le Cloud pour déployer des applications également hébergées dans le Cloud

Cette option a notamment pour avantage de limiter la gestion des routes et des flux réseau.

Certains éditeurs proposent des solutions clé-en-main et gèrent la maintenance de l’UL à la place du client.

Même s’il peut y avoir des avantages à utiliser une plateforme “As A Service”, il faut néanmoins rester vigilant avant de se lancer. En effet, certaines peuvent couvrir plusieurs langages ou sont compatibles avec plusieurs fournisseurs Cloud, alors que d’autres vont chercher à vous verrouiller avec un fournisseur en particulier.

Aussi bien d’un point de vue de l’infrastructure que du logiciel, une étude est à mener et plusieurs éléments sont à prendre en considération.

Pour un outil propriétaire :

Veillez à la maturité de l’éditeur et de ses produits sur le marché, les services proposés, la couverture du support, le mode de licence et de tarification

Pour un outil open source :

Vérifiez leurs années d’existence, la communauté derrière ces logiciels et son degré d’investissement, la facilité pour monter de version et la stabilité des versions majeurs (fréquence de montée de version)

Pour les 2 types :

Contrôlez les systèmes d’exploitation supportés, la facilité d’installation et d’utilisation au quotidien (interface ‘user-friendly’), l’intégration avec les autres logiciels propriétaires ou open source, le type d’hébergement accepté (On-premise et/ou Cloud), l’accessibilité à l’UL par les différentes équipes internes et/ou externes

Organisez un REX : renseignez-vous auprès de votre réseau professionnel, mais également au sein de votre direction ou département. Il se pourrait qu’une autre entité de votre entreprise ait déjà installé une UL et qui corresponde à votre besoin ! Un retour d’expérience est une mine d’information qui pourra conforter ou orienter les décisions, évitant ainsi quelques études complémentaires à l’implémentation.