Dans le Libre : manger ce que l’on prépare

Dans le précédent article de cette série Dans le Libre : gratter ses propres démangeaisons, 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 important d’identifier les tâches qui pouvaient être automatisées, d’établir un plan d’action, puis de rechercher des solutions existantes avant d’éventuellement s’attaquer soi-même à écrire un programme pouvant régler le problème.

Nous verrons aujourd’hui pourquoi il est important d’utiliser soi-même son propre logiciel.

L’usage créé de nouveaux besoins

Ce faisant, il s’est avéré qu’utiliser notre propre programme levait peu à peu des nouveaux besoins. La première version de notre programme réglait le principal problème que nous avions, mais nous avons rapidement eu envie de rajouter des fonctionnalités pour répondre encore plus précisément à notre besoin et ce de manière complètement automatisée.

Manger ce que l’on prépare (Eat Your Own Dog Food en anglais, d’où l’image ci-dessous) – dans notre cas utiliser notre propre programme – nous a permis de mieux cerner le domaine des possibles et les évolutions futures à réaliser pour ce programme.

Un exemple de ce processus est l’application db2twitter, un logiciel capable de piocher des données dans une base de données SQL avant de créer des tweets avec et de les poster sur le réseau social Twitter.

Arrivé assez rapidement à une version 0.1, le besoin d’identifier les nouvelles entrées dans la base SQL et de tweeter en conséquence m’a rapidement poussé à écrire la 0.2. Puis le besoin de modifier la requête SQL à la source des interrogations vers la base m’a orienté vers une nouvelle fonctionnalité pour la version 0.3. La version 0.4 a apporté la possibilité de ré-émettre régulièrement des tweets déjà envoyés et ainsi de suite  jusqu’à la version actuelle 0.6.

Avec une description systématique des changements des nouvelles versions, l’histoire des besoins du projet est simple à suivre. L’usage de votre propre programme amène donc à des nouveaux besoins.

Tout est simple les premiers jours

Les premiers jours, tout est simple. Vous identifiez un nouveau besoin, vous mettez à jour vos sources dans votre dépôt, vous clonez  le code depuis votre compte Gitlab.com  sur votre serveur, une petite ligne dans la crontab et hop, c’est en production. C’est en effet le moment d’itérer très rapidement dans votre développement. Vous n’être pas encore ralenti par l’existant. Mais parfois aller trop vite peut vous jouer des tours. Quelques règles à retenir :

• vous n’avez pas créé dès la version 0.1 de votre projet un dépôt de sources pour rien.  Contraignez-vous à sortir de nouvelles versions complètes et pas seulement de pousser des nouveaux commits dans votre dépôt
• ouvrez systématiquement des rapports de bugs dès que vous avez une idée, quitte à fermer le rapport si vous trouvez ça inutile ensuite. Cela vous permet de suivre le développement de vos nouvelles fonctionnalités et de potentiellement communiquer dessus, en particulier auprès de vos utilisateurs ou potentiels utilisateurs
  
• lorsque vous souhaitez sortir une nouvelle version, générez une marque (tag) avec le numéro de la version en question, signez-le avec GPG éventuellement, puis poussez le vers votre dépôt
• au niveau du dépôt, avec la marque précédemment créée, générez une archive que vos utilisateurs pourront télécharger, facilitant ainsi la vie des empaqueteurs des différentes distributions intéressés par votre programme
• N’oubliez pas de définir une liste des changements qu’apporte la nouvelle version. Concentré dans un fichier appelé CHANGELOG, les nouveautés de votre nouvelle version peuvent prendre la forme d’un fichier dans vos sources ou vous pouvez remplir la description de la nouvelle version sur votre gestionnaire de sources. Attention toutefois si vous utilisez un service en ligne pour faire cela. Si le service s’arrête un jour, vous risquez de perdre cette liste des changements depuis la création de votre logiciel

• Communiquez autour de vos nouvelles versions ! Ces communications autour de vos nouvelles versions sont la ligne de vie de votre existence publique. Cela inclue une dépêche sur un ou plusieurs sites web communautaires, un billet sur votre blog, des communications sur les réseaux sociaux et contacter vos empaqueteurs des différentes distributions Linux et/ou BSD si vous en avez.

Si ces bonnes pratiques peuvent paraître un peu lourdes pour un projet dont vous êtes le seul utilisateur au début, elles vont vous donner un cadre de publication qu’il faudra impérativement respecter dans le futur sous peine de rater des publications, d’être incompris ou ignoré de vos éventuels utilisateurs.

Un excellent exemple de cette évolution est Retweet, un outil pour retweeter automatiquement selon de nombreux critères. Dès la première version, une marque a été utilisée pour marquer la sortie d’une nouvelle version, l’archive et le CHANGELOG étant générés via l’interface web du dépôt Github de Retweet. On peut ainsi fournir le maximum d’informations aux utilisateurs dans le temps, et éventuellement fournir des repères chronologiques pour une chasse aux bugs ou de l’aide à de nouveaux contributeurs.

… mais avec plusieurs instances d’installées en production, ça se complique

Vous avez maintenant plusieurs versions à votre actif et une dizaine d’instances installées sur deux ou trois serveurs. Le temps entre le développement d’une nouvelle fonctionnalité et son arrivée en production a augmenté. Vous devez en effet coder la nouvelle fonctionnalité, la publier, la mettre en place sur différents serveurs, donc dans différents contextes servant des buts différents.

Dans l’idée principale de cet article et toujours en suivant notre exemple, utiliser votre propre programme a amené à un besoin de flexibilité. Très certainement le besoin d’un fichier de configuration s’est fait sentir, pour s’adapter à différentes configurations. Un besoin de stockage avec la gestion de fichiers ou d’une base de données s’est ajouté à votre projet, pour stocker les informations d’une version à l’autre.

Prenons un exemple : le projet Feed2tweet, petit projet qui récupère un flux RSS pour l’envoyer vers Twitter, est en production sur le Journal du hacker mais aussi LinuxJobs.fr, ce blog et bien d’autres aujourd’hui. Il a donc été indispensable au bout d’un moment d’automatiser le déploiement de nouvelles versions. Il est important de comprendre qu’utiliser son propre produit créé de nouveaux besoins, mais qu’une fois satisfaits, les nouvelles fonctionnalités répondant aux différents besoins permettent de pousser la flexibilité et le confort d’utilisation et de toucher ainsi des nouveaux cas d’utilisation et un public plus large.

Manger ce que l’on prépare mène à tout automatiser

Comme nous l’avons vu, notre petit projet devient s’étoffe et devient de plus en plus complexe. Il couvre désormais différents cas d’utilisation. Il devient difficile de le tester manuellement et de prendre en cas tous les cas d’utilisation. Mais aussi d’assurer un système fiable de publication des nouvelles versions ainsi qu’un système de déploiement assurant un minimum d’impact sur nos différents systèmes désormais en production.

Pour nous protéger de tout ces risques et continuer à fournir le meilleur service tout d’abord à nous, mais aussi désormais aux différents contributeurs/utilisateurs de notre programmeur, il est nécessaire d’automatiser les différents points vus ci-dessus. Nous aborderons différents moyens d’y arriver dans le prochain article de notre série 😉

Et de votre côté ? Avez-vous amélioré votre propre programme par l’identification de nouveaux besoins en l’utilisant régulièrement ? N’hésitez pas à en parler dans les commentaires !