- Partage d’un cas d’application efficace des concepts de DevOps, de staff engineering et de platform engineering dans un environnement startup
- Le conférencier, Chad McElligott, est Senior Staff Engineer chez Smartrr, une entreprise qui fournit des services d’abonnement et de fidélité basés sur Shopify
- Proposition de méthodologies d’ingénierie adaptées à la culture et aux exigences propres aux startups
[Concepts clés]
DevOps
- La définition de DevOps varie selon les personnes : pour certains, c’est un poste, pour d’autres, une manière de travailler
- Le concept de "DevOps as No Ops" conduit les software engineers à prendre eux-mêmes en charge l’ensemble des tâches liées aux Ops
- DevOps consiste à livrer rapidement de la valeur au client grâce à un état d’esprit collaboratif, à l’automatisation des tâches répétitives et manuelles (toil) et à l’usage d’outils modernes
- Au-delà des aspects techniques comme l’usage du cloud, l’infrastructure as code ou la mise en place de pipelines CI/CD, l’essentiel est de faire tomber les barrières de communication et de collaboration pour obtenir de meilleurs résultats
Platform engineering
- Le Platform Engineering est une approche technique visant à réduire la charge cognitive des développeurs
- Son objectif est d’augmenter à la fois la vitesse de développement produit et la stabilité du système, en fournissant les composants de base qui soutiennent l’activité des développeurs
- De plus en plus de grandes entreprises mettent en place des équipes de platform engineering pour gagner en efficacité et améliorer la developer experience
- Le concept a été popularisé par le livre Team Topologies de Manuel Pais et Matthew Skelton, et de nombreux médias présentent des exemples de renforcement des capacités d’ingénierie
Staff engineering
- Le Staff Engineering n’est ni un état d’esprit particulier ni une compétence spécifique, mais un rôle occupé par un software engineer au sein d’une organisation
- Il s’agit d’une étape de carrière après Senior Software Engineer, que l’on peut aussi décrire comme le servant leadership du software engineering
- Les ingénieurs Staff+ étendent leur responsabilité au-delà de leur travail individuel à l’ensemble de l’organisation, et collaborent avec les managers ou les VP pour apporter exécution concrète et perspective
- Dans son livre Staff Engineer, Will Larson décrit le rôle de Staff à travers quatre archétypes : Architect, Right Hand, Tech Lead et Fixer
[Culture startup]
- Les startups financées par le capital-risque dépensent souvent plus qu’elles ne gagnent afin de soutenir leur croissance
- Elles utilisent les capitaux levés comme une "runway" pour viser une croissance rapide, et doivent atteindre croissance et rentabilité avant d’avoir épuisé cette runway
- Cet environnement crée deux caractéristiques culturelles essentielles
- Pas de temps à perdre
- Dans une startup, perdre du temps est particulièrement critique
- Les équipes de développement doivent rester focalisées sur les objectifs stratégiques de l’organisation et exécuter dans les limites de la runway
- Chaque membre de l’équipe doit vérifier régulièrement si son activité est alignée avec les objectifs, et se réajuster si nécessaire
- Même si une expérimentation échoue, ce n’est pas du gaspillage si une structure d’apprentissage est en place et que les enseignements attendus en ont été tirés
- Tout le monde porte plusieurs casquettes
- Dans une petite organisation, il y a beaucoup à faire mais peu de personnes pour le faire
- Par exemple, un développeur frontend peut aussi faire office de product designer, technical writer, product manager, QA ou responsable des intégrations tierces
- Lorsqu’une nouvelle idée émerge pour améliorer l’expérience client, la personne qui l’a proposée peut aussi se retrouver responsable de son prototype ou de sa mise en œuvre
- Ces caractéristiques culturelles déterminent les compétences nécessaires aux groupes de développement produit, et en particulier aux leaders du software engineering
- Elles donnent aussi des indications sur la manière dont DevOps, le Platform Engineering et le Staff Engineering doivent s’adapter à l’environnement startup
[Appliquer mes principes d’ingénierie (Tenets) à la culture startup]
DevOps dans les startups
- Dans une startup, il est facile de changer les processus.
- Comme il y a peu de personnes, il existe peu d’obstacles majeurs à l’adoption de nouvelles façons de travailler
- Ajuster les processus en fonction des outils donne les meilleurs résultats
- Maintenir des processus rigides fait perdre du temps, car cela oblige à personnaliser les outils ou à développer des logiciels supplémentaires
- Il faut éviter autant que possible les outils sur mesure
- Il est préférable de s’appuyer sur des infrastructures serverless, des outils SaaS ou des bibliothèques open source
- Il faut suivre le courant général de la technologie et éviter de la personnaliser lorsqu’elle n’apporte pas d’avantage concurrentiel différenciant
- Voir aussi : Utility vs Strategic Dichotomy de Martin Fowler
- Il faut choisir des "technologies ennuyeuses"
- Il ne faut pas prendre de gros risques avec des solutions que l’équipe ne maîtrise pas ou qui ont peu de communauté
- En cas de problème, il faut choisir des technologies pour lesquelles on peut facilement trouver des solutions en ligne
- Dan McKinley détaille cette idée dans sa conférence sur boringtechnology.club
Platform Engineering dans les startups
- Mention faite par Rebecca Murphey dans le podcast Engineering Unblocked :
- "La developer experience d’une entreprise est un produit, qu’elle ait été conçue comme tel ou non"
- Même à l’échelle d’une startup, il faut toujours du monitoring, du déploiement, du suivi d’erreurs, de la consultation de logs et des feature flags
- La vraie question est : "Ces tâches sont-elles pénibles ?"
- Le Platform Engineering est un rôle à temps partiel dans les startups
- Au début, un environnement de test intégré peut être nécessaire, mais il peut ensuite perdre en priorité
- Le rôle de platform engineering n’est donc exercé qu’en fonction des besoins
- Il n’y a pas de marge pour mener de longs projets de plateforme
- À la place, il faut mettre en œuvre des éléments utiles par petits lots de travail
- Il est important de partager la vision d’ensemble avec l’équipe, tout en lui faisant comprendre comment les petits morceaux s’articulent
- Le travail de plateforme en startup consiste à ouvrir de nouvelles voies en matière de productivité et d’approche
- Le plus souvent, il ne s’agit pas de migrer depuis un logiciel existant vers des outils modernes, mais de construire à partir de rien des éléments qui n’existaient pas
- Plus que ce qu’il est possible de faire, il est important de décider ce qu’il faut faire
- Il faut se concentrer sur les travaux qui résolvent les problèmes actuels de l’organisation ou ceux du futur proche
- Il faut identifier les besoins à partir de l’expérience terrain, des échanges avec les ingénieurs, des retours de rétrospective et de l’analyse des métriques du SDLC (cycle de vie du développement logiciel)
- Il peut parfois être préférable de repousser les travaux de plateforme pour se concentrer sur d’autres besoins
- La clé est d’adopter une approche souple
Staff Engineering dans les startups
- Le rôle de Staff Engineer est bien adapté à l’environnement startup
- Une expertise technique approfondie, une volonté d’avoir un impact large et une attitude consistant à intervenir là où c’est nécessaire pour résoudre des problèmes business correspondent bien aux startups
- Dans les grandes organisations, on dit parfois qu’il faut "savoir où est enterrée la dette technique"
- Le Staff Engineer identifie les personnes qui détiennent cette connaissance, la structure, puis en tire des décisions pour avancer
- Dans les startups, la dette technique et les problèmes sont clairement visibles
- Un Staff Engineer peut avoir un fort impact en mettant de l’ordre dans ce chaos et en construisant des solutions utiles à long terme pour l’organisation
- Dans une startup, un Staff Engineer ne peut pas rester dans un seul archétype
- Comme l’organisation est petite, il doit mener des activités variées, y compris l’exécution directe
- Il doit non seulement concevoir l’architecture, piloter des projets et réaliser des tâches tactiques, mais aussi faire émerger lui-même des idées d’amélioration et les mettre en œuvre
- La souplesse et le sens des responsabilités proactif sont des qualités indispensables pour les ingénieurs Staff+ en startup
- L’un des rôles importants des ingénieurs Staff+ est le mentorat et le sponsoring
- Ils apportent en particulier un soutien et une orientation essentiels aux talents juniors des startups
- Grâce à cet accompagnement, le Staff Engineer favorise la croissance de l’équipe et renforce les capacités de l’organisation
[Appliquer le staff engineering moderne dans les startups]
Histoire 1 sur 2 - "Improving DevEx by Removing a Merge Freeze"
Problème
- Processus QA existant :
- mise en place d’un "merge freeze" pendant 2 à 3 jours avant la release, pendant lesquels l’équipe QA effectuait des tests de régression manuels
- les bugs détectés étaient corrigés immédiatement puis fusionnés dans la branche main
- les développeurs construisaient de nouveaux patchs, mais devaient reporter leurs demandes de fusion jusqu’après la release
- Inconvénients :
- les tests de régression manuels sont lents et imprévisibles
- les retards de fusion augmentent la fréquence des merge conflicts
- la productivité et la collaboration des développeurs en pâtissent
Solution
- Intégration du code d’infrastructure dans un monorepo
- intégration des projets Terraform dans le même dépôt que le code applicatif
- connexion à des outils automatisés de linting et de gestion des dépendances pour permettre aux développeurs de manipuler plus facilement l’infrastructure
- Gestion de tous les environnements avec Terraform
- gestion avec Terraform non seulement des nouveaux environnements, mais aussi des environnements existants de staging et de production
- maintien de la cohérence entre les environnements en appliquant des variables différentes à une même définition d’infrastructure
- Simplification du processus CI/CD
- les templates GitLab Auto DevOps existants étaient devenus complexes à cause d’un grand nombre de personnalisations
- suppression d’Auto DevOps et définition claire d’un nouveau fichier
.gitlab-ci.yml
- déplacement de la plupart des commandes dans un Makefile afin de permettre aussi une exécution manuelle
- Amélioration de la gestion des secrets
- migration des secrets applicatifs vers Google Cloud Secrets Manager afin de réduire le couplage avec GitLab
- modification des scripts de déploiement pour mettre à jour automatiquement les Kubernetes ConfigMap
- Travaux exclus du périmètre
- l’application, de structure monolithique, s’exécute sur Kubernetes
- cette configuration a été conservée, car la modifier aurait pu entraîner des délais et des risques
- aucun pipeline d’automatisation Terraform n’a été mis en place
- les changements d’infrastructure étant relativement rares, le processus manuel a été maintenu
- l’approche native de Kubernetes pour l’accès aux secrets a également été mise en attente
Résultats et impacts
- déploiement d’un nouvel environnement de test permettant à l’équipe QA d’effectuer les tests de régression de manière indépendante
- suppression du merge freeze, permettant aux développeurs de fusionner librement leurs changements dans la branche main
- simplification du processus de release et amélioration de la vitesse de l’ensemble de l’équipe
Principes appliqués
- Principes de Staff Engineering
- pilotage du projet en collaboration avec différentes équipes
- prise en charge du rôle de "Tech Lead" pour mener le projet à son terme
- amélioration de la compréhension et de l’accessibilité pour l’équipe grâce aux évolutions de CI/CD et d’infrastructure
- Principes de Platform Engineering
- élargissement d’un projet DevOps en projet de plateforme
- gestion de toute l’infrastructure sous forme de code pour garantir la cohérence entre les environnements
- ajustement du périmètre du projet grâce à des trade-offs réalistes
- Principes DevOps
- gestion de l’infrastructure sous forme de code pour exploiter l’infrastructure cloud de manière cohérente
- amélioration du processus de release et accélération du développement grâce à de nouveaux outils
- adoption du format de document RFC (Request For Comment) pour renforcer l’inclusivité dans la prise de décision
Conclusion
- l’équipe QA peut désormais exécuter des tests automatisés dans un environnement plus stable
- les développeurs peuvent poursuivre un développement continu sans merge freeze, ce qui renforce la collaboration
- la productivité de l’organisation s’est améliorée grâce à de meilleurs outils et processus
- il serait souhaitable d’ajouter ensuite des initiatives comme la mise en place d’environnements de preview ou l’automatisation des tests de régression
Histoire 2 sur 2 - "Iterating Towards a Productive Engineering Process"
Problème
- Processus existant :
- tous les membres de l’équipe travaillaient sur un seul board et partageaient leur avancement chaque jour
- beaucoup restaient en mode "checkout" et perdaient leur concentration lorsque ce n’était pas leur tour
- la responsabilité du développement des fonctionnalités était dispersée, et il arrivait souvent que le chef de produit porte la responsabilité finale
- il manquait aussi une compréhension claire de l’architecture technique
- Objectif :
- mener diverses expérimentations pour mettre en place une meilleure collaboration et un meilleur processus de développement logiciel
- Expérience 1 : équipes fonctionnalité temporaires (Short-lived Feature Teams)
- Objectif : donner aux ingénieurs un véritable sens des responsabilités sur l’ensemble du cycle de vie d’une fonctionnalité
- Méthode :
- désignation d’un responsable pour chaque fonctionnalité et constitution d’équipes réunissant backend, frontend, QA, etc.
- Résultat :
- le sens des responsabilités des membres s’est amélioré, mais tout le monde n’était ni adapté ni intéressé par un rôle de leader
- passage ensuite à un "modèle d’équipes fixes" avec des "Squads", chaque équipe menant sa propre planification et ses propres rétrospectives
- Expérience 2 : Epic Kickoff Documents
- Objectif : clarifier les exigences et obtenir un alignement de l’équipe sur le périmètre et l’approche du projet
- Méthode :
- tous les membres de l’équipe rédigeaient le document en réunion à l’aide du modèle fourni
- Résultat :
- amélioration de la communication de l’équipe et meilleure collaboration dès le début des projets
- les membres ont estimé que cette réunion constituait un temps utile
- Expérience 3 : revue de code en groupe (Group Code Review)
- Objectif : réduire le temps consacré aux revues de code, stimuler les discussions autour du code et favoriser le partage technique entre ingénieurs
- Méthode :
- organisation de sessions de revue de code de 1 heure, deux fois par semaine, via Slack Huddle
- les développeurs partageaient leur écran pour présenter leurs PR, et les participants fournissaient leurs retours
- Résultat :
- réduction significative du temps nécessaire aux revues de code, avec maintien d’un état Inbox 0
- les discussions autour du code ont fait émerger une culture où les développeurs apprennent les uns des autres et se respectent mutuellement
- au-delà de la revue de code, les avantages du pair programming ont aussi été introduits dans l’équipe
Principes appliqués
- Principes de Staff Engineering
- leadership sur l’amélioration des processus en l’absence d’un engineering manager
- introduction dans l’équipe d’une culture d’amélioration continue, renforçant la collaboration autonome grâce à des processus agiles
- accompagnement de l’équipe pour sortir de processus figés et trouver de meilleures façons de faire
- Principes de Platform Engineering
- considération du processus comme une composante de la plateforme, et pas seulement des outils
- amélioration essentielle des processus inefficaces, car ils nuisent à la productivité de l’équipe
- les changements de processus visant à éliminer le gaspillage peuvent avoir autant d’impact que l’amélioration des outils
- Principes DevOps
- principe CALMS : collaboration (Collaboration), automatisation (Automation), lean (Lean), mesure (Measurement), partage (Sharing)
- un processus lean permet d’éliminer le gaspillage et de délivrer rapidement de la valeur
- sensibilisation de l’équipe à l’amélioration continue via des processus agiles
Conclusion
- l’amélioration expérimentale des processus de l’équipe a fortement renforcé la productivité et la collaboration
- des améliorations peu coûteuses et très efficaces ont amélioré l’expérience de développement de toute l’équipe
- il est vivement recommandé d’examiner ses propres processus de manière critique afin d’identifier des pistes d’amélioration
[Conclusion]
- En travaillant dans un environnement startup, on peut mobiliser à la fois son expertise et sa passion pour résoudre des problèmes variés et concrétiser des solutions
- Comme le temps est limité, c’est une excellente occasion de développer une approche pragmatique, tout en ayant un fort impact dès les premières étapes de l’entreprise
- Il est possible de poser les bases du succès de l’entreprise en appliquant des approches modernes de l’ingénierie logicielle
-
Staff Engineering et startups
- Un Staff Engineer doit avoir à la fois de la largeur et de la profondeur dans son expérience
- Les startups offrent aux ingénieurs Staff+ l’opportunité d’élargir leurs connaissances techniques et d’explorer de nouveaux domaines
- Exemple : un ingénieur backend peut apprendre des technologies comme React ou BigQuery
-
Platform Engineering et startups
- Le Platform Engineering dans une startup varie selon la taille de l’entreprise
- Grâce à une communication en tête-à-tête, on peut identifier les points de douleur des développeurs et améliorer l’expérience développeur (DevEx) avec de petits projets
- Il faut mettre en place des boucles de feedback rapides pour améliorer le processus de développement et aider les développeurs à résoudre eux-mêmes les problèmes à l’avenir
- Il est important de couvrir les bases du cycle de vie du développement logiciel (SDLC) avec des outils et des pratiques standard du secteur
- Dans une startup, le Platform Engineering n’est pas une fonction dédiée, mais une approche technique appliquée selon les besoins
- Il faut garder à l’esprit que « l’expérience développeur de l’entreprise est un produit » et consacrer du temps à sa conception
-
DevOps et startups
- DevOps joue aussi un rôle très important dans les startups
- L’essentiel est d’apporter plus rapidement de la valeur aux clients grâce à la culture, aux processus et aux outils, tout en créant un meilleur environnement de travail
- Améliorer l’efficacité de l’entreprise et ancrer une culture de la collaboration grâce au DevOps est une démarche très gratifiante
- Dans une startup, un ingénieur passionné par le DevOps peut apporter une contribution majeure grâce à ses compétences et à son expérience
- L’environnement startup est rempli de nouveaux défis et d’opportunités d’apprentissage, permettant aux ingénieurs de grandir davantage et d’obtenir des résultats porteurs de sens
3 commentaires
Éloge funèbre de DevOps
Les ingénieurs plateforme qui gagnent plus que les ingénieurs DevOps
Qu’est-ce qu’un ingénieur staff ?
J’ai l’impression que cela définit bien les rôles d’ingénierie dont les startups auront besoin à l’avenir. Cela semble aussi bien structurer des activités d’ingénierie qui, auparavant, se faisaient sans distinction claire. Chacun pourra probablement mieux comprendre de façon concrète de quel type d’ingénierie il se charge et dans quoi il souhaite progresser à l’avenir. Les startups pourront ainsi aussi mettre en place une ingénierie mieux structurée et recruter plus efficacement les ingénieurs dont elles ont besoin.