Mon expérience de CTO chez Spacefill de 2019 à 2023
J’ai rejoint Spacefill parmi les tout premiers employés. En tant que CTO, j’étais responsable des choix techniques, du recrutement et du management des développeurs, le tout en étroite collaboration avec le CPO — cofondateur.
J’ai commencé par développer une marketplace de stockage en entrepôt, ensuite une web application de type OMS (Order Management System) et une Web API publique.
Cette Web API publique permettait de communiquer avec des applications de l’univers logistique, du type WMS, OMS, TMS, ERP.
J’ai travaillé sur l’implémentation et de déploiement de nombreuses intégrations dites “EDI”, concrètement des programmes (de type worker) de transfert d’information d’un système à un autre — lecture de données via Web API ou via des fichiers exposés par le protocole FTP, puis transformation de ces données et pour finir, écriture de ces données sur une Web API ou à nouveau dans des fichiers via le protocole FTP.
Quelques-unes de mes activités de manageur :
- Recrutement : rédaction et publication des fiches de postes, définition des critères de rémunérations, sourcing de candidats, tenue d’entretiens de recrutement , suivi d’“onboarding” des nouvelles recrues…
- Discussion 2 fois par mois en tête-à-tête avec chaque membre de l’équipe tech et produit — généralement sous la forme de walking meeting — afin de garder du lien, recevoir du feedback, comprendre le ressenti de chaque personne, partager ma vision, répondre aux questions, partager des conseils.
- Proposer des mises à jour des process de développement ou de management produit… pour répondre aux besoins du produit, aux difficultés et aux idées des développeurs. Mon objectif était de créer une direction commune tout en essayant d’atteindre un certain niveau de consensus.
Voici ce à quoi ressemblaient mes activités de développeur :
- Coder en React et un peu en Node.JS ;
- Écriture de query et mutation GraphQL ;
- Faire évoluer la base de données PostgreSQL :
- modélisation des données (tables) ;
- écriture de migration de données ;
- écritures de triggers en pgSQL.
- Écriture de fonctions PL/pgSQL pour implémenter des Queries ou Mutations GraphQL customs ;
- Rédiger, améliorer et commenter des issues ;
- Prendre soin de mes Merge Requests afin de les pousser le plus rapidement possible en production ;
- Faire de la revue de code ;
- Écrire des spécifications techniques et parfois participer aux specifications produits ;
- Guider les nouveaux développeurs ;
- Améliorer continuellement la documentation du projet ;
- Écrire des tests UI ;
- Des interventions ponctuelles DevOps (Terraform / Ansible) ;
- Écrire, faire évoluer quelques scripts Python.
Technologies utilisées :
- Backend :
- PostgreSQL 12, utilisation de :
- du langage PL/pgSQL ;
- des Trigger Functions ;
- des extensions :
- PostGraphile (Extensible high-performance automatic GraphQL API for PostgreSQL) ;
- graphile-worker (Job queue for PostgreSQL running on Node.js).
- PostgreSQL 12, utilisation de :
- Frontend :
- React JS (State Hook) :
- react-router ;
- Apollo GraphQL ;
- Leaflet ;
- Un maximum de composants “headless” couplés avec TailwindCSS (avant cela mineral-ui et Emotion) ;
- React Hook Form (avant cela Formik) ;
- …
- Utilisation de storybook.
- React JS (State Hook) :
- Testing :
- Infra As Code :
- Terraform ;
- Ansible.
- Hosting on AWS et Scaleway Dedibox ;
- Ubuntu ;
- Docker ;
- Sentry ;
- GitLab (pour les Git repository et pour les issues et merge requests) ;
- GitLab Review App pour toutes les Merge Requests ;
- GitLab-CI.
Quelques informations supplémentaires concernant le fonctionnement du backend :
L’API GraphQL était auto-générée par Postgraphile, qui est un serveur OpenSource écrit en NodeJS et se connecte “au-dessus” de PostgreSQL.
Cela ressemble à Hasura, Supabase ou Firebase.
Les paramétrages, adaptations pouvaient se faire soit via des commentaires sur des ressources PostgreSQL (tables, champs), soit via la création de Views ou de functions PostgreSQL.
Les tâches qui ne pouvaient pas être effectuées par PostgreSQL, comme par exemple l’envoi de mails, la génération de PDF… sont effectuées par un “service worker”, avec du code NodeJS “classique”.
Méthode de travail
Nous essayions autant que possible de suivre la méthode Scrum.
Ce qui était mis en place :
- Sprints : 2 semaines ;
- Daily Scrum : entre 5 et 15 minutes tous les matins E
- Sprint Retrospective + Sprint Planning : une après-midi en fin de Sprint ;
- Session de Planning poker ;
- Scrum Team : entre 3 et 6 personnes organisées en Feature Team ;
- Definition of Done : un template de Merge Request de GitLab contient la checklist de notre “définition of done” ;
- Une journée de « Spike and learn ».
Nous utilisions GitLab pour :
- la gestion des issues ;
- le suivi des sprints, via les fonctions milestones et boards.
Tout changement dans le code ou la documentation passait par une Merge Request avec un process de review.