PROJET AUTOBLOG


Le Blog de Genma

source: Le Blog de Genma

⇐ retour index

Lifechaking - Gitlab, outil idéal ?

jeudi 1 janvier 1970 à 01:00

Depuis quelques années, je suis adepte du lifehacking et nombreux sont les articles que j'ai écrit sur le sujet. Des Todo j'en ai fait des tas, sur toutes les formes...Je suis familier de toutes les techniques organisationnelles projets comme les RIDA, RACI et autres... J'avais essayé de trouver un formalisme sous forme de tableau pour avoir un suivi des tâches, au sein de nombreuses itérations. Avec de nombreuses colonnes : projet, acteur, date de début, de fin, échéance, priorité, remarques... Mais quelque soit la mise en forme, la façon de faire (un onglet par projet ou autre), cela était toujours aussi peu flexible.

Gitlab

Au sein de mon entreprise, comme nous faisons du développement logiciel, nous avons une instance Gitlab auto-hébergée de la version communautaire. Parmi les fonctionnalités de Gitlab, au delà de l'aspect forge logicielle / hébergement de code, il y a différentes fonctionnalité que nous utilisons de plus en plus et ce pour chaque projet, dans le cadre de notre industrialisation. Dans le présent billet, je voudrais donc faire un retour d'expérience des différents outils.

Le Kanban

Le Kanban est probablement l'outil que j'utilise le plus. J'avais déjà fait des Kanban sur base de post-it dans une mission en AGIL dans une vie antérieure, j'avais un mur chez moi pour la gestion des mes projets personnels avec des post-it de différentes couleurs... Mais cela n'est pas pratique pour un partage, pour un travail à plusieurs et n'a pas de solution pour un usage en mobilité...

Les locaux actuels sont vitrés, les équipes avec lesquelles je travaille sont réparties au sein de différents services... J'ai besoin d'avoir une vision sur les différents projets et de pouvoir la partager.

La solution a donc été la généralisation de la mise en place d'un projet par service avec l'activation du Kanban pour chacun de ces projets. Et un Kanban pour les sous-projets. Je travaille encore avec une todo-liste que j'ai dans un bloc de papier dans lequel je note ma liste de choses à faire, que je raye au fur et à mesure de la journée. Toute tâche qui nécessite plus de détail, de suivi, d'être déléguée est si besoin rayée de la liste et mise dans le Kanban.

Avec le Kanban, j'ai un suivi des actions sur plusieurs jours ou plusieurs semaines, je suis sûr de ne rien oublier. En un ticket, j'ai un numéro de suivi si besoin, un acteur, je peux ajouter des dates. Et sur le ticket, je peux faire un suivi, commenter, ajouter des précisions, des liens vers le wiki et faire vivre l'action. Comme tout est électronique et au sein d'un navigateur web, c'est accessible, partageable. Les commentaires et le suivi sur un ticket sont cachés par défaut mais permettent d'avoir un suivi, de copier coller des échanges par mail, de mettre des liens vers d'autres tickets, des documents, des pages wiki... J'ai l'état d'avancement. Chacun peut commenter le ticket, ajoute des liens vers les pages wiki en cours de rédaction. On sait qui a quelle tâche. On voit l évolution. Il est possible de taguer un fichier avec plusieurs mots clefs chacun associés à une couleur. Il est possible pour chaque ticket de définir des dates de fin, un nombre de jours de réalisation, un "milletsone".

Dans les conseils que je donnerai il y a celui de prêter attention au nom des tickets qui doivent être autoporteur. Il ne doit pas être nécessaire d'ouvrir le fil du discussion du ticket mais il ne faut pas trop détailler non plus dans le titre. Un équilibre se trouve assez facilement au final.

Bref, j'ai trouvé dans le Kanban de Gitlab tout ce que j'avais cherché en essayant de structurer mes suivis d'action dans des fichiers avec colonnes...

En Kanban, j'avais auparavant testé l'usage de celui de Nextcloud (Deck) et celui de Kanboard. Mais celui de Gitlab, au delà de son intégration dans l'écosystème Gitlab, a de suite eu mon adhésion définitive. Un design plus moderne, plus riche, intégré avec tout un écosystème d'outils complet que je présente dans la suite de ce billet.

Le wiki

Pour chaque projet, Gitlab permet de créer un wiki dédié au projet. Chaque page est une page texte au format Markdown, qu'il est possible d'éditer au sein du navigateur même (avec une fonction de prévisualisation). Les fichiers étant des fichiers textes, ils sont suivis dans une branche dédiée par Git, avec toute la puissance niveau historisation que cela peut avoir.

Le wiki est récupérable en local en tant que projet Git, la bonne pratique est donc que chacun clone le wiki comme projet en local. Il n'y a pas de fork d'implémenter au sein même de Gitlab, on ne peut donc pas faire des forks et ensuite des branches etc. Tout le monde travaille donc sur un même dépôt qu'est le wiki ; cela nécessite donc de s'astreindre à certaines règles : mise à jour régulière du serveur vers le local et ce avant toute modification. Remontée rapidement sur le serveur les ajouts fait au wiki localement.

Pour l'édition, comme je le disais, le format est le format Markdown. On peut éditer au sein de l'interface web ou en local. C'est et ça reste du fichier texte. Nous avons mis en place un tutoriel utilisant l'éditeur Atom qui permet l'édition et la prévisualisation du Markdown (pratique pour avoir du WYSIYG) et un plugin Git pour pousser les modifications depuis Atom sur le serveur. Cela facilite la vie pour l'édition du wiki. Je pense que mettrai ce tutoriel en ligne sur ce blog pour le rendre accessible à tous.

La wikification : ce que j'appelle wikification c'est le fait de tracer dans le wiki toute information pertinente qu'il est nécessaire de garder, de conserver, au sein d'une base de connaissances. Nous généralisons, traçons, mettons à jour les procédures, les astuces etc. Tout ce que l'on peut attendre d'un wiki, nous le faisons au sein des wikis des différents projets de Gitlab.

Nous sommes d'ailleurs en train de reverser peu à peu les informations pertinentes en les mettant à jour d'un ancien wiki qui était sous Media Wiki dans le nouveau wiki. Un chantier long et fastidieux, mais nécessaire. L'ancien wiki était peu pratique, devenu lourd avec le temps, rédigé par des générations successives de collaborateurs sans suivi d'un formalisme particulier. Repartir sur une base saine et souvent le mieux à faire et nous le faisons.

L'espace fichier

Initialement prévu pour stocker du code source, nous utilisons cet espace pour stocker une arborescence définie de fichier. Avant il y avait un Intranet mais un simple partage de fichiers (nous n'avons pas de GED), mais avec le temps et l'accumulation des fichiers, c'est un peu devenu un fourre-tout inutilisable et inexploitable.

Nous utilisons donc pour chaque nouveau projet l'espace de fichier pour y stocker les fichiers de travail (fichier de configuration, documentation, procédures) dont nous avons besoin d'avoir une historisation, une centralisation et qui ne sont pas wikifiables.

Dans les pistes en cours d'étude il y a le fait que nous cherchons à pouvoir convertir des notes saisies en Markdown en documentation livrable au client, dans un format LibreOffice Writer avec un template de fichier défini (avec des codes couleurs précis). Un projet comme Pandoc pour la conversion avec ensuite application d'une feuille de style particulière sera à creuser.

Organisation des projets

Un service donne lieu à un projet, un projet donne lieu à un projet en lui-même dans Gitlab. Les pages wiki et la documentation sont mises au sein du projet pour lequel c'est le plus pertinent. Dans les autres wikis des autres projets, des liens sont fait vers les pages wiki et documentation de références. On utilise ainsi la puissance du web.

Pour faire un suivi à la hiérarchie, lors des réunions hebdomadaires, il suffit de présenter deux planches : une capture d'écran du Kanban prise en semaine N-1 et un une capture du Kanban de la semaine en cours. On peut alors visuellement voir l'avancement avec les tickets déplacés, les tickets en cours...

Bref, Gitlab est devenu un outil incontournable, efficace et indispensable pour moi.

Non intuitif pour les non informaticien.ne.s

Comme nous industrialisons nos projets, tout nouveau projet quel-qu'il soit est désormais créé dans Gitlab. Et le constat a été fait rapidement que dès que l'on sort d'une population purement d'informaticien, Gitlab nécessité des améliorations de son interface graphique pour pouvoir permettre une appropriation de l'outil en particulier dans la partie gestion des fichiers et suivi des modifications, qui restent avant tout pensé comme du "diff de code".

Et je ne suis pas seul à avoir saisi à la fois la puissance de Gitlab et le fait que ce n'est pas adapté aux non-informaticien.ne.s. En effet, dans le cadre de sa campagne Contributopia de Framasoft, dans la partie "Éducation populaire - Inspirer les possibles", il y a un projet Git à la portée de tou·te·s dont la description est la suivante : Git est un outil qui permet de collaborer collectivement sur du code. La manière dont il a été conçu ouvre une magnifique porte d'entrée vers les méthodes, pratiques et états d'esprits de la contribution. Comment faire pour que les personnes qui ne codent pas puissent profiter de la philosophie d'un tel outil ? Comment adapter git, son jargon, son interface, etc. afin que tout le monde puisse co-construire et collaborer sur des textes ou d'autres communs contributifs ? Des projets existent et c'est avec eux que Framasoft désire étudier des solutions.

Conclusion(s)

Au bout de quelques jours, Gitlab est devenu comme une révélation, un peu comme si je venais de trouver l'outil miracle. Nombreux sont les avantages que j'ai trouvé (me demandant même comment je faisais avant). Dans les autres avantages à avoir toute ma gestion au sein d'un même outil c'est que c'est pratique pour faire les sauvegardes.

Dans les autres petites choses que j'aimerai avoir et sur lesquelles il faut que je me penche, il y a celles d'avoir des métriques ou des statistiques en utilisant le temps de réalisation des tickets. Ce sera sûrement le sujet d'un autre billet, quand j'aurai pris le temps de me pencher sur ce sujet. Hop, c'est ajouté au backlog dans le kanban.

Lucifer - la série

jeudi 1 janvier 1970 à 01:00

Synopsis

Fatigué d'être le « Seigneur des Enfers », Lucifer Morningstar abandonne son royaume et s'en va à Los Angeles où il est propriétaire d'une boîte de nuit appelée « Lux ». Lucifer a reçu le don de contraindre les gens à révéler leurs désirs les plus profonds. Un soir, Lucifer assiste au meurtre d'une chanteuse pop devant son club. Il décide donc d'aller à la recherche du coupable et croise sur son chemin une policière nommée Chloe Decker, qui résiste à son don et lui met des bâtons dans les roues. Pendant que Lucifer Morningstar et Chloe Decker font équipe pour trouver le meurtrier, Dieu envoie l'ange Amenadiel sur Terre pour convaincre Lucifer de régner à nouveau sur l'Enfer.

La critique de Genma

Découverte un peu par hasard sur conseil d'un couple d'ami, j'ai commencé à regarder la série Lucifer sur Netflix et j'ai accroché à tel point que je suis on ne peut plus à jour sur la diffusion de la série.

J'ai beaucoup aimé le personnage de Lucifer. Il a pour principe de ne jamais mentir. De fait quand il parle de sa condition d'ange, de son père, Dieu, de l'Enfer, tout le monde pense qu'il utilise des métaphores, qu'il se crée un personnage de part son prénom insolite... Le décalage et les quiproquo sont de fait nombreux et apporte de l'humour.

L'humour : il est présent régulièrement, avec des personnages intéressants, attachants, dont le background est développé épisode après épisode. Les personnages évoluent, changent, gagnent en profondeur et leurs relations évoluent. Et les rapprochements, la complicité augmentant avec le temps, l'humour est de plus en plus présent dans des remarques, des traits d'esprits. On n'est pas dans le mode "punch line à la Tony Stark comme dans un film de Marvel" mais plus dans des traits d'esprits. Et même de nombreuses références à la pop culture Geek : Lucifer est un geek, à n'en pas douter. J'ai ri jusqu'à plusieurs fois par épisodes.

Lucifer joue aussi de son charisme et de son charme, des nombreuses conquêtes qu'il cumule, de son personnage qu'il crée comme pour se protéger de la souffrance. Le tout sur fond de sa relation avec Chloe, mi amour, mi amie, cette ambiguïté permanente, lié à un fil rouge de la saison 2... Lucifer est un personnage complexe, qui évolue. Lucifer, de part sa condition d'être surnaturel, n'est pas à l'aise avec les comportements humains et les codes humains, il dit toujours la vérité. De fait, il heurte les sensibilités des gens mais quand il blesse les gens qui lui sont chers, il souffre. Il apprend à devenir humain, il devient humain. Et je me reconnais dans cette évolution, cette torture de vouloir bien faire et de faire souffrir des gens qu'on aime...

Le fil rouge des différentes saisons est sympathique et facile quand on a vu l'arc des anges de Supernatural (saison 7 et suivantes). Pas de complexité particulière et de volonté de faire un scénario tordue. C'est distrayant, plaisant. Mais efficace.

La musique... Que dire de la musique. Lucifer joue au piano et des parties de chansons et scènes sur fond de musiques sont mémorables. J'ai commencé à revoir des extraits en vidéo sur Youtube. Certaines sont des spoils donc à revoir uniquement quand on a va vue la série. Mais la scènes de reprise au piano de Sinnerman de Nina Simonne ou encore de Unforgiven de Metallica... Elles m'ont données et me donnent encore des frissons à chaque revisionnage.

Évolution et relation des personnages, les acteurs, les scénarios des épisodes, la musique... Définitivement j'adore cette série. Tout me plaît. A recommander.

Supergirl de Reamonn

jeudi 1 janvier 1970 à 01:00

A l'été 2000, comme tous les étés, je passais mes vacances en Pologne, dans un tout petit village dans un coin paumé. J'ai sympathisé avec un gars qui est venu passé quelques jours chez sa grand-mère et du coup, nous passons nos après-midi à discuter de tout et de rien, et surtout à regarder la télévision. Car la seule distraction, c'est la télévision par satellite avc un accès à différentes chaînes gratuites. Parmi ces chaînes, des chaînes allemandes et les chaînes musicales VIVA. Ayant appris l'Allemand en 1ère langue depuis le collège, en 2000, je comprends encore assez bien et je peux suivre une émission de télé sans soucis (j'ai beaucoup perdu depuis par manque de pratique). J'ai donc passé des après-midi entier à regarder des clips. L'une des deux chaines, VIVA 2, donne déjà dans le nostalgique avec des clips classiques des années 80.

Dans ces années là, les musiques et les hits du top 50 en Allemagne ne sont pas les mêmes que celles que l'on a en France, je découvre donc des nouveaux groupes, dont des groupes Allemand. Hit du moment, Supergirl de Reamonn passe en boucle plusieurs fois par jour. La page Wikipedia (uniquement en anglais) confirme que ce single n'a été diffusé que dans des pays de l'Est de l'Europe ou Germanophone (Suisse).

Quelques années plus tard, à l'heure de gloire de Kazaa et du modem 56k, j'ai pu retrouvé des fichiers au format mp3 du groupe (ouh le vilain pirate), avant de finir par trouver le CD en import dans une Fnac Parisienne. En 2017, fini le mP3, on est passé au streaming en vidéo avec Youtube et le clip de la chanson est disponible en ligne. Si vous souhaitez le voir, cliquer ici Reamonn - Supergirl (Official Video HQ) sur Youtube

Un clip d'époque, qui alterne des images du groupe en train de jouer et un mini-film qui raconte une sorte d'histoire. Comme beaucoup de clip de cette époque. Ca a sûrement vieilli, ce n'est pas Thriller de Mickael Jackson niveau réalisation, mais quand je le revois, je repense à cette époque, à mes souvenirs. Ca s'appelle de la nostalgie.

Du même groupe, deux autres chansons sorties en single "Star" et "Josephine", que j'écoute là encore avec nostalgie de la fin des années 90 et de mon adolescence...

Une autre fois, je vous parlerai peut être de ce groupe de rock gothic finlandais, à l'origine du Love Metal, HIM. Avec son symbole de l'Heartgram (un pentagramme en forme de coeur) et ses deux albums phare au titre évocateur "Greatest Lovesongs Vol. 666" et "Razorblade Romance".

Cachet

jeudi 1 janvier 1970 à 01:00

L'objectif de Cachet est d'avoir sur une page partagée de façon publique et sous une URL du type status.monsite.com un affichage de l'état de son infrastructure selon différents éléments comme : panne majeur, partielle, une maintenance, un historique.

Plutôt qu'un long discours un bon exemple de mise en oeuvre est la page https://status.framasoft.org qui liste pour les différents services fournis par Framasoft dans le cadre du projet Degooglisons l'état du dit services, les opérations de maintenance ou les problèmes rencontrés.

De plus en plus de service en ligne et d'entreprises proposent une page de ce type. La plupart ont recours au service payant Status.io.

Un logiciel libre exisste, Cachet : The Open Source Status Page System cachethq.io et c'est d'ailleurs sur ce logiciel que repose le système de status de Framasoft.

Parmi ces fonctionnalités, Cachet propose donc :
- de lister les différents services
- de lister et reporter les différents incidents
- l'interface et l'aspect sont personnalisables via un éditeur de feuille de style
- le langage Markdown est supporté pour l'édition des messages
- il y a une API en JSON
- disponible dans différents langues
- il est possible de souscrire / s'abonner par mail pour recevoir des messages quand un statut ou un incident est saisi.

Pourquoi Cachet ?

Au delà du fait que ce soit un logiciel libre, il y a le soucis de transparence et de communication vis à vis des clients. Et c'est là,à mon avis un très bonne pratique qui permet de consolider la relation client en créant une relation de confiance : oui il peut y avoir des erreurs, des soucis, des indisponibilités, mais on est transparent (et on suite à l'incident on fait un retour d'expérience, on cherche à comprendre et apprendre pour que l'erreur rencontrée ne se représente pas ; mais c'est là un autre sujet).

Recevoir des notifications

Il est donc possible de s'abonner par mail ou via un fil RSS/Atom que l'on ajoutera à son agrégateur préféré. La configuration du serveur d'envoi de mail se faisant dans le fichier de configuration au moment de l'installation.

Mise en place

Pour installer, il suffit de suivre la documentation https://docs.cachethq.io/docs/installing-cachet

Il existe également un paquet pour Yunohost https://github.com/YunoHost-Apps/cachet_ynh.

Les petites choses que j'aime bien

C'est assez facile à mettre en place et à utiliser (encore plus dans le cadre du paquet YunoHost). Il est possible de définir des modèles de messages que l'on utilisera selon les besoins. Facile et pratique pour communiquer sur une maintenance régulière par exemple. C'est assez léger (ça reste une page web HTML avec un CSS), c'est simple et efficace et intuitif à l'usage. C'est personnalisable pour avoir le logo de son entreprise et les couleurs / styles du site web si nécessaire.

Prochaine étapes

Dans les prochaines étapes il y a :
- l'installation sur Plesk (l'installation nécessite l'accès aux commandes php & composer, un tutoriel sera donc fait pour expliquer tout ça dès que je l'aurai fait.
- utiliser l'API : pour avoir des modifications automatisées et non plus à la main. Pour cela il existe des modules pour être utilisé avec un service de monitoring (Centreon, Zabbix). Exemple https://github.com/qk4l/zabbix-cachet

Borg comme outil de sauvegarde

jeudi 1 janvier 1970 à 01:00

Les sauvegardes sont quelque chose de fondamental (Sauvegarde la règle des 3-2-1) et j'en parle régulièrement sur ce blog.

L'importance c'est aussi de pouvoir restaurer Sauvegarde et restauration et je cherche depuis un moment un outil simple, fiable, sécurisé qui permet d'automatiser un peu.

Dans sa conférence au JRES 2017, Luc Didry aka Framasky, administrateur système de l'association Framasoft a fait une conférence très intéressante sur le sujet de Quelle infrastructure pour dégoogliser Internet ?. Le fichier pdf complet de la conférence est disponible en ligne ici JRES 2017 - Luc Didry - Quelle infrastructure pour dégoogliser Internet ?

Je cite la partie concernant les sauvegardes et plus particulièrement sur l'outil Borg :
En ce qui concerne les services à forte volumétrie tels l'hébergement de fichiers (Framadrive, Framadrop) ou l'hébergement d'images (Framapic), nous avons préféré recourir à une autre solution. En effet, ces sauvegardes représentent plusieurs téraoctets de fichiers et nécessitent énormément de temps, ce qui bloquerait les sauvegardes des autres serveurs via Backuppc (car celui-ci n'effectue qu'un petit nombre de sauvegardes en parallèle afin de ne pas surcharger le serveur de sauvegarde).

Borg a pour avantages d'être facile à utiliser au sein de scripts shell et de n'effectuer que des sauvegardes par déduplication (aucune sauvegarde complète n'est faite si ce n'est la première). De même, les commandes sont simples et très bien documentées, proposant ainsi une barrière d'entrée relativement faible pour les non-techniciens.
Si Borg utilise la méthode push (envoi des fichiers sauvegardés à l'initiative du serveur sauvegardé) pour effectuer les sauvegardes, celle-ci ne souffre pas du problème habituel de cette méthode : le risque d'effacement des anciennes sauvegardes par un attaquant s'étant rendu maître de la machine sauvegardée.

En effet, les dépôts de sauvegardes peuvent être configurés pour n'autoriser que l'ajout de sauvegardes. Un cript sur la machine hébergeant les dépôts pourra faire sauter ce verrou dans le fichier de configuration pour effectuer la suppression des sauvegardes puis remettre le verrou.

Les sauvegardes de Borg peuvent être chiffrées, fonction que nous avons activée : ces sauvegardes sont stockées sur une storage box de notre hébergeur, une offre ne proposant que de l'espace de stockage avec un rapport volumétrie/prix que nous ne pouvons atteindre en louant des serveurs.

Luc présent également Borg de cette façon :
- il est très simple d'usage ;
- les données sont dédupliquées ;
- les sauvegardes peuvent être compressées ;
- les sauvegardes peuvent être effectuées en local ou à distance ;
- les sauvegardes peuvent être montées (et donc utilisées) comme un système de fichiers classiques.

Les commandes sont du type

borg create -v --stats ./::{now} /home/ #teaser

La syntaxe est simple à s'approprier.

Ce qui me plait c'est que les sauvegardes sont effectivement incrémentales, c'est rapide, léger, ça se monte comme système de fichier pour ensuite récupérer / restaurer à base de rsync si on veut, et les sauvegardes sont chiffrées. Que demander de plus ?

Le site officiel https://borgbackup.readthedocs.io est assez riche et permet déjà de s'approprier la solution.

Des tutoriels pour apprendre et s'approprier Borg :
- BorgBackup, borg pour les intimes
- Monter un serveur de sauvegardes avec BorgBackup

Et un script qui repose sur Borg comme outil de Backup Concierge - Set of tools to help system administrator with maintenance and security of Debian systems

A noter qu'il est possible de faire du Borg avec du Ansible.