Si ce blog affiche des opinions, il est à noter qu'elles n'engagent pas les personnes et entreprises avec lesquelles j'ai pu ou je travaille encore. Ces opinions reflètent une compréhension à un instant t, dans contexte donné et sont donc à nuancer.
Quand les tests sont verts en local et rouge en CI, on se retrouve dans une situation délicate ... ce serait dommage de commiter n fois en espérant mettre le doigt sur le problème, ou pire, dire que "ça marche sur mon poste !". 😅 Il peut être intéressant d'utiliser un outil pour envelopper le processus de build afin de se donner la capacité de le lancer en local, ainsi une erreur serait reproductible. Pour les projets construisant des artefacts comme des binaires, l'outil permettra en plus aux développeurs de les construire de manière iso sur leur poste !
La somme des intégrations de développeur que j'ai pu observer et les miennes m'ont permis de constater que parfois le sujet manquait de sérieux, non préparé, certains leads accueillent leur nouveau collègue sans matériel, sans trop savoir par où commencer, presque comme s'ils avaient oublié leur arrivée ... J'ai eu l'opportunité de m'impliquer dans l'accueil de développeur et nous (moi et les autres personnes responsables) avons fait en sorte de prendre le sujet sérieusement, je tente de vous retransmettre les éléments qui ont fonctionné pour nous 💪.
Je suis un grand fan des gestionnaires de versions pour gérer mes installations de languages : nvm, pyenv, goenv ... Je trouve cela plus pratique que de faire cela via docker, apt ou brew et en plus c'est souvent plus rapide à manipuler. Pour Php, on a phpenv. Malheureusement, il n'est pas simple à installer. Je propose de vous mâcher un peu le travail, et puis ça me servira de pense-bête 🐐.
Je cumule régulièrement des projets clonés depuis GitHub, Gitlab, voir la solution VCS du boulot ... J'avais pour habitude de tous les cloner dans un même répertoire. Cette méthode a pour inconvénients de nécessiter une configuration git locale pour chacun des projets s'ils n'utilisent pas les identifiants par défauts. Le ~/.gitconfig global cumulé avec des commandes git config unitairement ne m'a jamais plu, je ne me souviens jamais des commandes. On va parler de l'inclusion conditionnelle de configuration git, qui me simplifie la vie 🙃
Les tests sensibles au temps peuvent être une source de non-déterminisme. Il peut donc être difficile d'écrire un test autour de logique tel que des horaires d'ouverture, des planifications temporelles ... Fonction de l'instant ou le test est lancé, on risque de se retrouver avec une suite de tests par terre. Pour prévenir ces situations, on trouve des librairies pour mocker les fonctions de base des languages ou des appels système. Avec ces solutions, j'ai été confronté à certaines limitations et souvent je retombe sur cette citation : "You can't test what you don't own" (Impossible d'en retrouver l'auteur ...). Par conséquent, je préfèrerais une solution me permettant de maitriser la notion du temps dans la base de code.
Il y a quelque temps, j'ai suivi une formation "Advanced Unit Testing" sur Pluralsight. Mark Seeman y présente un pattern nommé "Fixture Object". Le but est simplement d'encapsuler les actions nous permettant d'écrire, exécuter un test. Je le trouvais assez peu utile, jusqu'à présent j'ai surtout écrit des tests dans des formats xUnit, avec une classe de tests me permettant de définir des attributs et méthode privée pour obtenir un test propre. Avec VueJS et Jest, on change de modèle, et son usage me semble évident. Je vous propose de l'implémenter en partant d'une suite de test brute de pomme 🍏.
Si vous avez à vous connecter sur beaucoup de machines distantes, que votre entreprise applique des pratiques comme ne pas utiliser le port 22 pour ssh ou autres, les commandes ssh peuvent être fastidieuses à taper. Évidemment, on a le ctrl+r pour fouiller dans l'historique, mais quand la commande n'est plus dans l'historique, on est perdu 😅. Le fichier ~/.ssh/config va permettre de tenir un annuaire des machines.
Après la découverte de Molecule et voulant gratter un peu plus loin le sujet des bonnes pratique Ansible, j'ai regardé la formation "Testing and Debugging Ansible Automation" sur Pluralsight. Je ne l'ai pas trouvé fofolle, jusqu'au chapitre "Using the Playbook Debugger" 😲. Je n'en avais jamais entendu parler ... Si vous non plus, je vous propose de regarder à quoi cela ressemble.
Suite à une installation de fail2ban, j'ai souhaité changer le numéro de port ssh. Cela implique donc de revoir la configuration de fail2ban, qui appliquera des restrictions basées sur le port par défaut, 22. En ouvrant la configuration /etc/fail2ban/jail.conf, on ne retrouve pas le port 22 ... Mais une variable ! Dommage de remplacer toutes les variables par le nouveau port en perdant son bénéfice ...
Jusqu'à présent, j'écrivais mes rôles Ansible en les testant sur une box Vagrant ce qui m'évitait de lancer un rôle potentiellement bogué sur une machine distante. Récemment, en faisant un peu de veille sur le sujet, je suis tombé sur un outil permettant de jouer un rôle Ansible sur un conteneur Docker, puis de lancer des tests : Molecule 😍.
Il y a deux ans, à force d'entendre parler de TDD, j'ai lu livre "Test Driven Development" de Kent Beck, puis j'ai adopté l'approche proposée par le livre, à savoir "Inside Out". En continuant de faire de la veille, j'ai vu qu'il y avait un débat assez vif sur les deux approches et que certaines personnes étaient très dogmatiques sur le sujet. On trouve différents termes pour expliquer ces notions, avec parfois des associations, des oppositions ... J'ai vraiment eu des difficultés à comprendre cette seconde approche "Outside In". Maintenant que c'est normalement réussi, je tente de le resituer ici.
Quand j'ai commencé à m'intéresser aux tests automatisés, je suis tombé sur la bonne pratique de découper un test en trois blocs "Arrange, Act, Assert". Sauf qu'une fois qu'on a dit ça, on regarde nos outils, et on se rend compte que ce n'est pas vraiment encouragé.
J’ai dû récemment travailler sur une rotation de fichier de logs. Donc forcement : logrotate. Si c’est plutôt simple pour les logs d’une application web, ça l’est un peu moins vis-à-vis des démons, genre consommateur ou serveur web. En effet, suite à une rotation, un démon garde le descripteur de l’ancien fichier en mémoire. Le démon ne log donc pas dans le nouveau fichier créé par logrotate.