Voilà, c’est fait. Cela fait déjà un an que je travaille sans environnement de dev. Ce qui devait être temporaire, est finalement devenu mon quotidien.
Pour tout un tas de raisons maintenant, je n’ai plus d’environnement de dev pour faire tourner le monolithe sur lequel je travaille au quotidien. Il y a d’abord eu le fait qu’on me propose une façon de travailler qui ne me convenait pas (qui veut travailler à travers un client graphique de contrôle à distance d’un bureau en 2020 ?), des soucis de configuration suite au départ de certaines compétences de la boîte, une solution alternative pas vraiment adapté à la puissance de mon poste, une solution à venir finalement avortée, un projet à venir, et clairement un manque de motivation de ma part.
Un manque de motivation que j’explique par un quotidien fait de priorités différentes de celle de setup mon env de travail. D’isolement, de “devops fatigue” et très probablement de la fainéantise.
Cette application n’est pourtant pas extra ordinaire au niveau de sa stack : une application PHP/Symfony avec du MySQL, RabbitMQ, Redis et du ElasticSearch. Quelques vues Twig, un endpoint GraphQL, un front en React. Le tout hébergé chez AWS et orchestré par un Kubernetes avec Helm. Paradoxalement, cela tourne très bien chez AWS, mais de là à la faire tourner sur sa propre machine, un mbp i5 avec 16go qui doivent cohabiter avec un Slack et Zoom, c’est un brin plus compliqué.
Du coup mon quotidien de dev backend se passe sans environnement de dev. Sans visualiser dans un browser mon code ou avoir une application connectée à une base de donnée. Sur ma machine, l’application se résume à un dossier versionné contenant des fichiers.
Et est ce que cela est un tort ?
En fait, en tant que dev backend, on attend de moi les livrables classiques : les features demandées avec des tests automatisés et de la doc. Est ce que le temps que passe un dev à faire des refresh frénétiques en éditant du code (ou contempler son résultat) est un livrable ? Non.
Ce que l’on peut faire sans environnement de dev :
J’ai tout de même quelques outils sur ma machine, PHP 7.4 qui est la version de php requise par l’application, avec les extensions classiques, Composer et Redis. Pas de MySQL, de RabbitMQ, de ElasticSearch ou autre.
Pourtant un simple `bin/console` me permet de m’assurer que l’application arrive à builder le container et donc de résoudre toutes les dépendances et paramètres de l’application. Les “debug:router, debug:listener et debug:container” sont également parfaitement fonctionnels. J’ai également l’assurance que la définition des schemas GraphQL est valide et que les queries et mutations sont ok.
Les tests unitaires fonctionnent parfaitement avec juste PHP. Idem avec php-cs-fixer ou les différents outils d’analyses statiques.
Pour les tests fonctionnels, c’est un peu plus compliqué mais la CI gitlab me permet de valider que tout est ok.
Les inconvénients
Il m’est plus long de constater et reproduire un bug sur ma machine. Je peux faire des essais sur un environnement de staging, mais pas débugger et printer ce qui ce passe dans certaines parties du code. Cela n’est qu’un contre temps car lorsque bugfix il y a, un test qui permet de le fixer est toujours de rigueur dans la MR.
Les interventions sur les entités sont également plus délicates, dans la mesure ou je suis incapable d’auto-générer des migrations doctrine. Toutefois cela n’a jamais été vraiment un obstacle étant donné que je travaille sur une application qui a déjà quelques années et que les modifications sur les entités sont rares et peu compliquées.
Je pratique beaucoup moins tout ce qui tourne autour de la mouvance devops. K8S, Helm, etc… et du coup je m’exclus de certaines conversations de l’équipe.
Les avantages
Déjà ma machine tourne comme un charme. Je ne fais pas tourner de K8S ni de Docker for mac ou de Vagrant box. Seul Zoom, Chrome ou Slack sont les plus gros consommateurs de ressources. (Et on s’encombre pas d’un PhpStorm non plus).
Migration doctrine qui ne passe pas, pod indisponible, mise à jour de helm, souci de configuration, certificats expirés, tokens à régulièrement renouveler, etc… c’est de l’histoire ancienne, et avec du recul je suis surpris de voir à quel fréquence régulière ces sujets sont abordés lors des stand-ups, et affolé de voir le nombre d’échanges que cela représente sur Slack…
La réponse est dans le code. Au quotidien je cherche les réponses dans le code. Je ne cherche pas à constater ce qui ce passe dans tel ou tel cas dans chrome, je lis le code. On s’évite ainsi de déduire un comportement, alors qu’il y a un AB test ou d’autres règles métier dans le code. Et après des mois cela représente des heures supplémentaires à lire le code et naviguer dedans. On est carrément plus efficace.
Un appel à une base de donnée ou à un service http et je me retrouve avec un process en erreur et une belle stack trace. Et parfois elles ne sont pas censées se produire lors de l’exécution de code. Mais quand votre environnement de dev est capable d’executer correctement des requêtes SQL et que vous travaillez en mode cli, c’est pas évident de s’en rendre compte. Idem pour les ressources utilisées par le process php. Quand docker4mac est exclu de l’équation, on a plus du tout de latence aléatoire qui pourrait dissimuler un process gourmand en CPU.
Et à ce moment là, on redécouvre les tests. On arrête de faire des mocks verbeux qui procurent une fausse confiance en ce que l’on test. On ne mock pas l’implémentation, mais la fonctionnalité. On apprécie l’adage : “Don’t mock what you don’t own”. On utilise des doublures : Spy, Stubs, Dummy; et on alterne en fonction de ce que l’on teste. Les tests sont notre seule fenêtre sur l’application, et même si je ne rédige pas les tests avant l’implémentation, je considère tout de même que je fais du TDD (Test Driven Development).
Ma motivation est plus constante : je ne commence plus mes journées par des soucis d’environnement qui ne fonctionne plus. Ou je dois passer 2h à essayer de comprendre pourquoi le make-db-install ne fonctionne plus. A ne pas pouvoir commencer à travailler avant d’avoir décortiqué les logs de X services alors que je veux seulement modifier une ligne de code. Mon moral ne fait plus le yoyo et c’est vraiment un des meilleurs aspects.
J’ai bien conscience que ce “workflow” est un peu particulier et qu‘il est possible parce que l’environnement complet le permet (application déjà existante, tests déjà très nombreux, pas de frontend, CI déjà présente, etc…). Dans tous les cas je ne recommenderai pas cette “pratique” à un débutant ou quelqu’un qui n’est pas confortable avec les tests.
