Nous avons exploré l’écosystème des modèles de repos dans notre précédente série d’articles. Nous avons partagé sa définition, ses mythes et ses pratiques chez d’autres acteurs. Cela n’est pas encore suffisant pour sélectionner un modèle de repo.
Nous pouvons vouloir aller trop rapidement vers des solutions, dangereuses sans avoir posé le problème à résoudre. Un problème de repo qui n’est pas uniquement technique, et qui commence par l’entreprise.
Cet article vise à guider votre décision de modèle de repo en utilisant une perspective et un processus de quality engineering holistique.
Commencez par le pourquoi, puis pour qui
Il vaut la peine d’investir du temps en premier lieu pour clarifier le «pourquoi» de votre initiative. Pourquoi envisagez-vous la question de votre repo de code? Pourquoi cela serait-il nécessaire pour votre entreprise? Quels sujets sacrifiez-vous en travaillant sur la question du repo?
Le premier cas trivial concerne une start-up. Les premières lignes de code ont besoin de stockage et, idéalement, d’une structure appropriée dès le départ. Lorsque vous partez de zéro, un monorepo est généralement la voie à suivre. Certaines exceptions peuvent exister en commençant par une équipe grande ou un nombre de composants plus important.
L’évaluation du coût d’opportunité d’un changement de repo pour une entreprise existante est plus difficile. La valeur ajoutée se situe principalement à moyen terme, et durant le projet, vous pouvez ralentir la livraison des fonctionnalités. Cela signifie que votre initiative aura un impact sur vos parties prenantes, d’où l’importance de les considérer.
Mono ou multirepo: Commencez par «Pourquoi», puis «Pour qui».
Antoine Craske
«Pour qui» est la deuxième question structurante après le «Pourquoi». L’identification des parties prenantes est la première étape pour travailler sur l’empathie. Vous devez clarifier « Qu’est-ce que cela m’apporte? » pour chacun des acteurs. Leur perception de la valeur est à la base de l’acceptation potentielle de l’initiative. Vous les menacez si votre initiative est uniquement perçue comme un ralentissement de l’évolution du produit.
La citation «Quality is value to someone» prend tout son sens dans ce contexte. Le sujet des repos est risqué quand abordé uniquement à partir d’un prisme technologique; la perception de la valeur de vos parties prenantes est vitale. Nous avons besoin d’une approche plus holistique de notre entreprise et de son écosystème pour évaluer le modèle de repository.
Aligner une perspective holistique de Quality Engineering
Nous devons combiner différentes perspectives pour obtenir une vision plus large. L’ordre dans lequel nous analysons notre écosystème structure notre raisonnement. Nous pouvons appliquer ce modèle de quality engineering en itérant sur l’architecture d’entreprise (y compris business), le produit, le système organisationnel et l’engineering.
Nous devons gérer nos repos tant que l’entreprise existe. Les organisations actuent suivant des cycles de naissance, croissance, maturité et de déclin. Ces cycles s’appliquent au secteur dans lequel votre entreprise agit et à l’entreprise elle-même. Un cycle typique pour une entreprise dure de 3 à 5 ans. Votre entreprise peut être à n’importe quelle étape et même en phase de transition. L’étape dans laquelle nous nous trouvons donne des indices sur le comportement de l’entreprise ainsi que sur les produits et services proposés.
Nous arrivons à une gestion des produits axée sur la valeur, traduisant les priorités du business en livrables pour nos clients. Pourquoi devrions-nous nous soucier de la gestion des produits pour notre repository? Les produits se traduisent par des exigences logicielles que nos organisations devront fournir et, plus précisément, itérer. Notre modèle de repository doit permettre des itérations plus rapides de création de valeur, quels que soient les produits que nous devons construire. L’organisation est un élément clé.
Notre modèle de repository doit permettre des itérations plus rapides de création de valeur.
Antoine Craske
Notre système organisationnel soutiendra les objectifs de notre entreprise en utilisant ses capabilities. Nous devons comprendre notre état actuel, futur et à venir pour divers points. La structure organisationnelle, les interactions et la culture sont des éléments cruciaux à clarifier. Certaines questions typiques se posent autour du nombre d’équipes, de leurs objectifs et de leurs priorités. Le modèle doit être aligné sur votre organisation; il n’y a pas de réponse correcte ni universelle. Google est, par exemple, une organisation centralisée en réseau, alors que Netflix a opté pour un modèle plus décentralisé. Gardez à l’esprit que l’organigramme n’est pas tout, les interactions sont clés dans la vie de l’organisation.
Nous pouvons passer à l’ingénierie une fois que nous savons quoi faire, pour qui et par qui. Notre système d’ingénierie doit clarifier son style architectural, son organisation de base de code, ses choix technologiques, etc. Votre décision de repo peut être spécifique à chaque contexte. Par exemple, vous pouvez avoir un écosystème différent entre le front et le back-office. Vous pouvez même découvrir que le modèle de repos n’est pas le principal sujet à traiter, ce qui vous permet de travailler sur la bonne priorité.
Vous devez avoir une image très claire de l’état actuel, étant la base pour dessiner des possibles cibles et transitions. Vous aurez probablement besoin d’itérations entre architecture, produit, organisation et ingénierie. Nous avons également des choix à faire quel que soit le modèle de repo que nous déciderons.
Décidez ce qui doit l’être, indépendamment du repo
Votre repo n’est pas tout, même s’il est structurant. Vous pouvez consulter cet article pour plus de détails sur les mythes du repo. Les éléments interdépendants doivent être clarifiés pour améliorer notre décision de modèle de repo.
Votre repo est structurant, mais n’est pas tout.
Antoine Craske
Des choix s’imposent. Comme nous le verrons plus tard, toute option est sujette à des compromis; il n’y a pas de solution parfaite. Notre «Pourquoi» guidera nos décisions, en évitant un tableau de comparaison interminable d’avantages et des inconvénients. Nous devons nous concentrer sur les principaux facteurs différenciants qui articulent notre système.
Les éléments importants de nos repos résident dans nos flux de communication, la gestion des dépendances et le style architectural. Les interactions balancent entre centralisation et décentralisation. Votre curseur doit être ajusté en fonction de votre système organisationnel. Des dépendances existent dans tous les cas; nous devons choisir comment les gérer. De même, on peut s’appuyer sur un modèle centralisé (ex: bibliothèques partagées) ou décentralisé (ex: duplication de code nécessitant une gestion).
Notre style architectural est le dernier élément à intégrer. Il doit s’aligner sur notre perspective de quality engineering, ainsi que sur ses interactions et ses dépendances. Je suggère fortement d’être clair sur les anti-patterns et les pièges du style architectural avant de décider. Nous pouvons d’ailleurs nous retrouver avec une architecture différente pour différents contextes.
La valeur de ce processus est de nous concentrer sur le «right product» avant d’essayer d’obtenir le «product right». À ce stade, nous sommes prêts à équilibrer les options possibles pour notre modèle de repo.
Être clair sur les compromis de chaque option
Les compromis s’appliquent également aux décisions d’ingénierie et donc à notre décision de repository. Notre objectif n’est pas de réaliser la matrice de comparaison la plus exhaustive mais de sélectionner l’option la plus appropriée à notre contexte. Les avantages et inconvénients doivent être cernés, tout en gardant une flexibilité d’évolution.
Nous avons normalement besoin de trois bonnes raisons pour choisir un modèle de repo plutôt qu’un autre. De mon point de vue, les principaux points d’inflexion proviennent de l’étape précédente: quelle entreprise nous voulons (architecture), pour livrer quoi (produit), organisée de quelle manière (organisation), itérant sur des incréments logiciels (ingénierie).
Trois bonnes raisons orientent notre modèle de repo.
Antoine Craske
Les bonnes raisons pour un monorepo sont la communication centralisée, la gouvernance, la gestion des dépendances, l’intégration au plus tôt et une meilleure homogénéisation. Ce que nous gagnons avec monorepo a un coût : nous devons gérer un outillage central complexe pour le build et le déploiement.
Nous pouvons essayer de concilier certains compromis en mettant en œuvre un modèle de split-repo, mais cela revient à compenser le problème. Avec une base de code croissante, nous bénéficierons d’une vue centralisée, facilitant le refactoring at scale, si nous investissons dans les solutions de stockage, recherche, de versioning, de révision et de refactoring. Sinon, nous pouvons être à la recherche d’un modèle en multirepo.
Les multirepos ont du sens pour une organisation qui a tendance à décentraliser la communication, l’intégration et le déploiement. Les équipes à la recherche d’itérations plus rapides bénéficieront de référentiels séparés. Une pizza team aura plus d’autonomie dans le processus de construction, de publication et de déploiement. Mais des compromis sont également présents, en particulier à moyen terme.
Les équipes cloisonnées auront tendance à optimiser leur contexte; c’est naturel dans les systèmes. Le problème est quand cela a un impact sur nos objectifs d’entreprise initiaux. Imaginez un multi-repo pouvant atteindre 100 instances, ayant chacun une stack technologique, logging, API, langage propre. Cela peut arriver avec un monorepo, mais beaucoup plus probablement avec un monorepo. L’équilibre est essentiel pour tirer parti de ce modèle. Nous devons accélérer la vitesse de l’équipe tout en garantissant la réplicabilité des processus et la maîtrise de la dette technique.
Notre choix de référentiel est fondamental car nous allons brancher d’autres applications sur ce système. Flexibilité, évolutivité et maintenabilité sont donc des exigences structurantes. Si vous ne trouvez pas de preuves claires vers une option, il est préférable de démarrer par un monorepo plus facile à diviser par la suite, plutôt que de regrouper des repos construits pour être indépendants.
Notre modèle de repo n’a encore que peu de valeur tant qu’il n’est pas compris par nos parties prenantes.
Partager, aligner les options et obtenir l’engagement
Créer l’engagement avec nos parties prenantes est une clé de concrétisation de notre initiative de repo. Nous devons travailler de manière transverse au sein de l’organisation pour obtenir le soutien du sponsor et des équipes. Dès le début, nous pouvons capitaliser sur nos réponses au «Pour qui».
Nous avons des ressources limitées pour échanger avec les parties prenantes. Construire un plan en utilisant une matrice de parties prenantes permet d’équilibrer nos efforts. De cette façon, nous clarifions le niveau d’investissement requis en échange et relationnel.
Notre initiative de repo impacte l’ensemble de la chaîne de valeur de l’ingénierie, par qui commencer? Tous les individus et équipes ne sont pas égaux. Le pouvoir ne vient pas seulement d’un titre de poste; connaître votre organisation est essentiel pour identifier les véritables influenceurs en plus des rôles de vice-président, senior et C-level impliqués. Pour les équipes, la meilleure candidate sera celle pour laquelle votre proposition résoudra un véritable défi auquel elle est actuellement confronté.
La combinaison de ces individus et équipes est la base de votre guiding coalition. Cette unité est nécessaire pour mener à bien votre initiative, en soutenant vos capacités organisationnelles. La mise en œuvre ne se fera pas du jour au lendemain. Cela prendra du temps, des itérations et de la persévérance.
Itérer horizontalement, puis verticalement
Votre initiative de changement de repo initiera un nouveau cycle dans votre organisation. Même si nous considérons ce cycle comme une seule courbe, l’implémentation sous-jacente consiste en une série d’itérations. Chaque étape incrémentale doit valider ou invalider les hypothèses de création de valeur et de scalabilité.
Quel que soit le modèle de repo, nous devons rapidement tester nos hypothèses à partir de ce que j’appelle une «perspective horizontale», en nous concentrant sur une intégration de bout en bout. Notre équipe candidate doit être utilisée à ce stade, en se concentrant sur la création de valeur plutôt que les activités réalisées. Une fois que nous avons validé l’apport de valeur, nous pouvons aborder la question de la scalabilité.
Notre repo est comme une startup, il doit trouver ses premiers utilisateurs, puis se développer.
Antoine Craske
Notre perspective horizontale doit passer à une perspective verticale, en regardant globalement le repo. Son objectif est généralement de permettre la croissance de la base de code. La scalabilité est donc essentielle, ainsi qu’une automatisation appropriée. Un processus manuel mal conçu et inefficace l’est encore plus lorsqu’il est automatisé. C’est là que vous devez tirer parti de votre guiding coalition pour élargir votre modèle.
Le reste du déploiement est la gestion de projet traditionnelle en dehors de la portée de cet article. Gardez à l’esprit que vous êtes dans un cycle qui évolue et, à un moment donné, peut changer.
Votre repo est un actif de l’entreprise, d’aujourd’hui et de demain
Notre repo héberge un actif vital de l’organisation, sa base de code, au cœur de la création de ses produits numériques. Son alignement avec les objectifs business, l’architecture, les produits, l’organisation et le système d’ingénierie est essentiel. Au moins durant le cycle dans lequel vous aurez aligné votre choix.
Nous pouvons être soumis à une réévaluation de notre modèle de repo. Nous pouvons décider de nous y tenir, de l’améliorer ou de le changer. Du point de vue d’un repository de code, cela signifie que vous pouvez évoluer entre monorepo, multi repo et ses possibles variations. Nous ne pouvons pas le changer chaque année en raison de ses impacts, d’où la valeur de ce processus pour un alignement à moyen terme.
Une chose à retenir est que notre repo est structurant mais pas tout, en anglais “our repo is structuring but is not everything”. Soyez clair sur les compromis pour éviter la frustration tout en utilisant votre guiding coalition pour mener à bien votre initiative.
Une initiative qui n’apportera de la valeur, que si elle est valorisée par quelqu’un.
Références
The Lean Startup, Eric Ries. https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898