Skip to content

Articles

Les avantages de l'utilisation d'un framework de build

26 novembre 2020 • 3 min de lecture

Les avantages de l'utilisation d'un framework de build

L’intégration continue (CI) et/ou la livraison continue (CD) est la norme sur les projets logiciels de nos jours. Il existe de nombreux serveurs de build tels que Azure DevOps, TeamCity, Jenkins et Cruise Control.Net. La plupart de ces serveurs utilisent des langages propriétaires pour définir les étapes de build. Mais est-ce une bonne chose de codifier vos étapes de build dans un langage propriétaire ?

Certaines applications sont simples, avec quelques étapes de build, d’autres sont plus complexes avec de nombreuses étapes de build. Lorsque vous définissez les étapes de build dans un langage propriétaire, plus les étapes de build sont complexes (en sophistication ou en nombre), plus vous devenez dépendant d’une plateforme de build. Cela devient un problème lorsque vous souhaitez changer de plateforme de build. Par exemple, vous utilisez TeamCity de JetBrain dans votre centre de données sur site, mais l’entreprise décide de migrer vers le cloud. Vous devez maintenant réécrire vos scripts de build car TeamCity n’est pas pris en charge sur la nouvelle plateforme cloud.

Au lieu d’écrire vos scripts de build dans un langage propriétaire, envisagez d’utiliser un framework de build.

Les frameworks de build ont deux avantages :

  1. Permettre la portabilité entre les plateformes de build.
  2. Vous permettre de versionner vos scripts de build aux côtés de votre code d’application.

La portabilité entre les plateformes vous donne la flexibilité de passer d’une plateforme de build à une autre avec un effort minimal. Il y aura toujours une certaine configuration sur une nouvelle plateforme de build, mais les frameworks de build maintiennent l’effort au minimum.

À mon avis, le plus grand avantage des frameworks de build est la possibilité d’archiver et de versionner vos scripts de build aux côtés de votre code d’application. Avoir la possibilité de récupérer du code à partir de n’importe quel point de l’historique de votre contrôle de source et d’avoir ce code compilé vaut bien tous les inconvénients d’un framework de build.

Il existe deux frameworks populaires dans l’espace .Net : Cake et Nuke Build. Les deux frameworks existent depuis un certain temps. J’ai utilisé Nuke Build et j’aime bien. J’ai entendu de très bonnes choses sur Cake et je vous encourage à l’examiner avant de décider quel est le meilleur framework pour votre projet.

Donc, la prochaine fois que vous créerez une nouvelle définition de build pour votre application, envisagez d’utiliser un framework de build et de l’archiver dans le contrôle de source avec votre application.

Auteur : Chuck Conway est un ingénieur IA avec près de 30 ans d’expérience en génie logiciel. Il construit des systèmes IA pratiques — pipelines de contenu, agents d’infrastructure et outils qui résolvent des problèmes réels — et partage ce qu’il apprend en chemin. Connectez-vous avec lui sur les réseaux sociaux : X (@chuckconway) ou visitez-le sur YouTube et sur SubStack.

↑ Retour en haut

Vous aimerez peut-être aussi