Dans le précédent article de cette série Dans le Libre : manger ce que l’on prépare soi-même, nous avons vu pourquoi dans une démarche de Libriste visant à régler un problème par l’utilisation ou l’écriture d’un programme, il était crucial pour améliorer et rendre plus flexible ledit programme de l’utiliser soi-même autant que faire se peut.
Nous verrons aujourd’hui pourquoi il est important d’automatiser autant que possible les différentes actions du cycle de développement et de la mise en production de son propre projet logiciel.
Les erreurs humaines sont inévitables
Dans un processus aussi compliqué la mise au point, la publication puis le passage en production d’un nouveau logiciel, les erreurs humaines sont quasi-inévitables. En effet les manipulations manuelles sont légions.
Les erreurs humaines sont inévitables dans une chaîne manuelle de production de logiciel
Et si bien sûr autant on peut considérer normal tout l’artisanat de la phase de conception du programme (la programmation en elle-même), autant il est utile d’avoir dès cette phase puis de manière exponentielle dans les phases suivantes de l’automatisation, pour fiabiliser l’ensemble de la chaîne de production du logiciel par la réduction au maximum des actions manuelles. Mais détaillons.
Automatisation durant la phase de conception
Dès l’étape de la phase de conception, il est bon d’automatiser certaines manipulations, à savoir :
- outil de détection d’erreur de syntaxe et de qualité de code (par exemple l’excellent outil pylint dans le monde Python)
- outil de lancement d’un série de tests unitaires (dans le monde Python le module unittest, pytest)
- outil d’intégration continue à coupler à votre dépôt de sources pour les tests fonctionnels (Jenkins avec le plugin Git par exemple)
Jenkins, un outil d’intégration continue complet et facilement extensible via ses nombreux plugins
L’idée est de fiabiliser tout ce qui est autour de l’écriture du code lui-même, comme la détection des erreurs de syntaxe et vos tests après une modification même mineure de votre code sans y perdre 5 minutes à chaque fois. Vous vous concentrez ainsi sur l’essentiel et ne perdez pas de temps et d’énergie sur des tâches ennuyantes.
Automatisation durant la phase de publication
Votre nouvelle version est prête. Vous avez placé une étiquette dans votre dépôt de sources pointant sur le dernier commit avant la publication de votre nouvelle version. Les voyants des résultats des tests unitaires et fonctionnels sont au vert. Là encore il est possible d’automatiser, pour par exemple :
- utiilser un script de publication pour automatiser la publication de cette nouvelle version, avec par exemple un job Jenkins permettant la création de l’archive de votre nouvelle version et sa mise à disposition dans votre forge logicielle.
- utiliser un autre script afin de télécharger la nouvelle version puis l’installant sur un système avant d’effectuer une nouvelle série de tests fonctionnels, dans le but de s’assurer que le processus de publication n’a rien cassé.
La réalisation de ces scripts et leur intégration au sein de votre chaîne de création de votre logiciel vont aider à produire des versions publiques qui soient réellement utilisables par le grand public, la mise à disposition de vos sources étant nettement insuffisante pour vous attirer une base d’utilisateurs conséquente. Produire des archives utilisables et facilement installables pour chacune de vos nouvelles versions va aider à la diffusion de votre logiciel (par exemple par l’intervention d’empaqueteurs officiels de différentes distributions GNU/Linux, comme Debian) et ainsi à toucher un public plus large.
Industrialisation de votre logiciel
Comme nous l’avons vu, vous avez désormais un dépôt d’archives publiques avec chacune des versions de votre programme, au côté de votre dépôt de sources. Cela va nous permettre de passer à la dernière étape de notre chaîne d’industrialisation, à savoir la mise en place de votre nouveau programme sur le serveur. Pour cela nous pouvons identifier les étapes suivantes :
- produire à partir de l’archive réalisée un paquet pour un système d’exploitation, par exemple un paquet Debian pour un système Debian et ses dérivées (encore une fois en utilisant un job Jenkins, lui-même lié aux jobs précédents).
- pousser le nouveau paquet Debian dans votre dépôt local de paquets Debian (par exemple propulsé par Aptly, un gestionnaire très flexible de dépôts de paquets Debian), vous permettant ainsi un déploiement ultra-simple et sécurisée de l’application au sein de vos différents serveurs de production.
- déployer le nouveau paquet en conservant ou modifiant la configuration existante, par exemple à l’aide d’un gestionnaire de configuration comme Ansible.
Aptly, un gestionnaire très flexible de dépôts de paquets Debian
Avec une infrastructure qui se complexifie rapidement, il est simple de se laisser déborder par l’existant et la difficulté à le faire évoluer. L’industrialisation permet de rationaliser l’évolution de votre infrastructure, de sécuriser les évolutions et la disponibilité des services.
Tout automatiser mène à gratter ses autres démangeaisons
Nous l’avons vu, en automatisant au maximum les différentes étapes de votre chaîne de création de logiciel, vous apportez fiabilité et rapidité à votre cycle. Envisager des livraisons rapides et fiables de nouvelles versions devient possible.
Et pour en revenir à l’exemple de notre logiciel qui nous accompagné durant ces trois articles, nous sommes arrivés au bout de notre démarche, avec un beau projet logiciel répondant à notre principal besoin et aux petits besoins qui s’étaient crées autour. Le projet ronronne et vous n’allez assurer que des améliorations mineures et corrections de bugs dans les mois à venir.
C’est donc le moment de gratteur une autre démangeaison, de passer au projet suivant dans votre liste de choses à faire et de tâches à accomplir. En écrivant un programme pour répondre à votre besoin, puis en utilisant ce logiciel vous-même, démarche complétée par l’automatisation d’une grande partie de la chaîne de production, vous avez ainsi libéré le temps nécessaire pour vous occuper d’autres projets.
Automatiser a un coût
Ceux qui sont intervenus sur des projets informatiques réalisés à la va-vite, bâti de bric et de broc laborieusement dans le temps, dont on ne retrouve ni la documentation ni les sources, qui ne tournent que sur un serveur de production dont on ne retrouve plus les informations de connexion, comprendront l’inégalable sécurité qu’apporte l’automatisation en grande partie de la chaîne de réalisation d’un logiciel.
Mais ce confort a un coût. Nous avons donné au long de cet article des axes d’automatisation qui s’avèrent payants sur le moyen ou long terme à mettre en place. Mais ces efforts d’automatisation ont un coût, qui avant d’être financier va être humain. Écrire des tests unitaires prend du temps. Mettre en place une usine d’intégration continue prend du temps. Écrire des tests fonctionnels ou des tests d’infrastructure prend encore du temps. Définir les politiques de style de votre code maison et les matérialiser par un fichier de configuration de votre outil de vérification de style de code prend du temps. Et ce temps, on l’a rarement.
Il faut donc garder en tête que la priorité reste au produit, à sa délivrance et à son amélioration, mais que l’absence d’automatisation finira immanquablement par vous poignarder dans le dos à un moment ou à un autre. Donc attention au phénomène du « I’m too busy to improve » car vous finirez forcément dans une situation d’interbloquage où votre charge vous empêchera d’automatiser, mais où on vous demander de délivrer plus vite qu’il vous est humainement possible.
Attention donc à bien garder l’automatisation en vue dans le développement de votre projet personnel ou de votre système d’information, car plus l’infrastructure devient lourde et les « hot fixes » nombreux, plus il sera dur d’automatiser, ce processus demandant un maximum d’uniformisation au niveau de votre infrastructure.
Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.
