Salut Je m'appelle Valery Laptev, responsable du développement LM en Russie. Pendant deux ans, j'ai eu besoin d'élever un énorme département, et ce fut une expérience assez intéressante.
Le fait est que Leroy Merlin est présent dans de nombreux pays. La société mère en France s'appelle ADEO. Ils écrivent du code pour la France, l'Italie, l'Espagne et la Russie. Nos modèles économiques sont différents: si nous gardons les prix les plus bas sur le marché russe (en dessous de tous les concurrents en monitoring), alors en Europe tout est différent. En fait, la mer est différente - des caractéristiques de la localité à une autre législation. Il y a des caractéristiques de l'infrastructure de la Russie (les mêmes très grands retards à Khabarovsk) et un autre cycle de vie pour passer une commande. Tout cela donne naissance à un code infernal composé d'énormes blocs IF:
Il y a deux ans, nous avions 60 magasins et de nombreuses fonctionnalités de liste de souhaits. Ils ont roulé en six mois environ et pas toujours correctement. La dernière goutte après un tas de fonctionnalités rejetées par faible priorité était une demande pour entrer un champ de ligne dans l'ordre, afin que nous puissions l'analyser plus tard. Cela était nécessaire pour les caractéristiques de livraison en Russie, car le pays est plus grand que les autres pays de présence de LM. Ils nous ont refusé cela, ou plutôt, ils ont dit que ce serait quelque part dans sept à huit mois.
Le cycle semestriel de la maison mère tranquillement ne nous convenait pas. Naturellement, nous avons suggéré d'écrire notre propre code, de le soumettre à la révision et d'attendre l'implémentation ... Vrai, rien de bon n'est sorti de cela.
Pourquoi les fonctionnalités ont-elles été mises en œuvre lentement?
L'histoire est très simple: malgré nos dizaines de magasins, nous ne sommes pas les premiers au monde. Il y a les besoins de la France (où se trouve l'organisation mère), il y a les besoins des autres pays. Ils sont hiérarchisés en fonction d'une éventuelle réduction de profit ou de coût pour un groupe de sociétés et sont exécutés dans cet ordre. Autrement dit, nos fonctionnalités sont faites presque jamais, sauf très chanceuses et dans une sorte de sprint, quelqu'un terminera sa partie plus tôt et ira démonter le bas de l'arriéré.
La deuxième fonctionnalité est que lorsque vous intégrez une fonctionnalité dans la branche principale (ici dans ce code IF-IF-IF hérité), vous devez vérifier son comportement dans d'autres pays. Permettez-moi de citer
441869 de Bash:
Programmeur: Eh bien, imaginez que vous êtes écrivain et que vous soutenez le projet "Guerre et paix". Vous avez des savoirs traditionnels - écrivez un chapitre sur la façon dont Natasha Rostova a marché dans le parc sous la pluie. Vous écrivez - "il pleuvait", sauvez, le message d'erreur s'envole: "Natasha Rostova est décédée, la poursuite est impossible." Pourquoi est-elle morte? Vous commencez à comprendre. Il s’avère que les chaussures glissantes de Pierre Bezukhov, il est tombé, son arme a touché le sol et a tiré sur un poteau, et la balle du pilier a ricoché sur Natasha. Que faire Charger l'arme au ralenti? Changer de chaussures? Nous avons décidé de retirer le pilier. Nous recevons le message: "Le lieutenant Rzhevsky est mort." Il s'avère que dans le chapitre suivant, il s'appuie sur un pilier qui n'est plus ...
En général, lorsque nous introduisons quelque chose pour le box-office russe, quelque part au Brésil, quelqu'un peut rebondir.
Cela signifie une très large couverture des tests, de longues procédures de pré-version et généralement une réticence à maintenir un code qui croît rapidement. Par conséquent, moins il y a de fonctionnalités, mieux c'est. Mais vous vous accrochez.
La position dans son ensemble est très compréhensible, et je le ferais sur le site de la société mère. Parce que c'est rationnel.
Résolution de problèmes
La première approche était sur le front: nous avons suggéré d'ouvrir un code pour que nous puissions y faire des requêtes. On supposait qu'il y aurait une dizaine de développeurs qui coderaient rapidement et rapidement les fonctions critiques de l'entreprise, les confieraient aux Français, et ils testeraient selon leur propre procédure, et tout irait bien.
En fait, ces personnes l'étaient déjà: nous étions engagés dans la suppression de la logique commerciale supplémentaire que nous avons obtenue d'autres pays, comme les diverses remises cumulatives et les stocks inhabituels (qui sont tout simplement impossibles avec notre modèle commercial), et avons mis des mannequins à cet endroit.
Les Français d'ADEO voulaient un cycle de sortie pour lancer et installer de nouvelles versions par eux-mêmes. Accepté notre offre sur une branche pour les expériences.
Accès donné, a commencé à prendre le code pour l'examen. Cela s'est avéré lent de toute façon. Déploiements sur plusieurs mois - ce n'est pas le cas. Eh bien gagné quelques semaines, mais le processus ne convenait toujours pas.
Puis, pendant six mois, une fonctionnalité importante pour nous dans la partie contenu (la gestion des données produit que le client voit) n'est pas sortie. Nous nous sommes assis pendant six mois sans libération. Soit leur fonctionnalité n'a pas fonctionné, soit les tests n'ont pas réussi, alors ils n'ont pas réalisé exactement ce dont nous avions besoin. En conséquence, nous nous sommes assis sur un système clé pendant longtemps sans mises à jour. Il y avait NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular à l'avant. Dans le code, en raison d'un certain nombre de couches archéologiques, des choses ont été rencontrées, telles que l'utilisation abusive de la base de données SQL et de la base de données non relationnelle. Dans l'un des endroits, une énorme quantité de données de base a été prise, insérée dans un champ de la base de données SQL, puis divisée en entités dans la base de données NoSQL. Sur une page du site avec l'affichage des marchandises, il y avait des dizaines et des centaines de telles demandes. Avec la lecture de cet héritage, les cheveux sur différentes parties du corps ont commencé à bouger. Nous avons compris les particularités de la superposition héritée à laquelle la section de tête est confrontée.
Développement personnel
La première idée était de faire des fonctionnalités ensemble. Sur place, c'est-à-dire en France. Nous sommes allés tous les quatre en France et avons commencé à nous asseoir à côté de nos collègues pour tout comprendre ensemble et faire ce dont nous avions besoin.
Ça n'a pas marché. Tout de même, tout a été très lent.
La deuxième idée était de bifurquer tout ce qui existe déjà et de le finir progressivement. Nous nous sommes assis devant le comité d'architecture, avons évalué les perspectives, calculé les plans de développement approximatifs et réalisé que nous devions choisir une méthode différente. Plus précisément, oui, pour bifurquer, mais pas pour développer le code existant, mais pour diviser le monolithe en parties et mettre les microservices là où c'est nécessaire.
Autrement dit, nous avions prévu de réécrire des blocs entiers de logique sous la forme de notre code. Et pour cela, ils ont commencé à transférer une partie des services vers ce qui pourrait être fait avec nous. Nous avons commencé à recruter des développeurs. Ensuite, nous avons complètement suivi la pile de la société mère - Java, Spring et tout est à proximité, au lieu de Couchbase était Mongo (c'est une base NoSQL similaire).
Au fur et à mesure que le projet se développait, nous avons réalisé que nous devions faire beaucoup de choses à notre manière (parce que c'est plus rapide et plus facile afin de ne pas prendre en charge l'héritage dont nous n'avons pas besoin, en particulier), et nous avons commencé à nous étendre à d'autres technologies. Ensuite, il y avait Java 7, Wildfly (anciennement JBoss) et SVN. Nous avons demandé pourquoi ils ne migraient pas vers Java 8, GIT et Tomcat. Il s'est avéré que cela ne les dérangerait pas, mais après quelques années. En attendant, chers amis, écrivez sur l'ancienne pile. Nous avons donc mot pour mot et décidé de nous séparer complètement. L'entreprise a résolu la question, quels sont les avantages et les inconvénients, et l'a entièrement soutenue.
Presque immédiatement a jeté environ 30 pour cent du code, a écrit beaucoup de leurs microservices autour. Du fait qu'ils n'ont pas touché, c'est presque tout le cœur de la transaction des processus d'affaires pour de l'argent.
Naturellement, la première chose à laquelle nous avons pensé était de savoir comment distinguer les domaines de développement. Je parlerais également de cela séparément, mais en termes généraux, le schéma est le suivant:
L'horizontale est un domaine d'activité. Par exemple, tout ce qui touche à la relation client (la première cellule verte) est un domaine, et il y a un ensemble d'applications d'un département. Cette séparation de la fonction objectif crée plusieurs doublons du code à différents endroits et nécessite un bon bus d'entreprise (encore une fois, une histoire distincte), mais elle vous permet de trouver clairement les fins et de résoudre le problème jusqu'au résultat. En regardant cela après près de trois ans, je peux dire que l'architecture a été choisie correctement, mais si je savais ce que je sais maintenant, j'apporterais quelques changements.
Nous sommes maintenant arrivés à la conclusion que dans la structure générale, il existe de nombreuses équipes de fonctionnalités qui composent de grandes équipes de produits. Dans le même temps, l'équipe produit comprend non seulement les développeurs eux-mêmes, mais également les concepteurs et les représentants commerciaux. Étant donné que l'objectif ultime de tout service informatique d'une entreprise est soit d'augmenter la vitesse de développement commercial, soit de réduire les coûts dus à l'automatisation, nous avons besoin de représentants commerciaux au sein de ces équipes. La vente au détail est une question d'informatique. Il n'y a pas un seul processus qui pourrait être qualifié de "inaccessible".
Une équipe technique est un petit groupe de personnes (généralement un analyste, un testeur, un développeur back-end et un développeur front-end, ops). L'analyste joue généralement le rôle du propriétaire du produit ou une personne de l'entreprise vient à cet endroit. Le propriétaire a un carnet de commandes, une priorité, des tâches. Il dicte leur développement. Le développeur choisit lui-même l'option d'implémentation, discutant en équipe de ce qui sera fait et comment. Nous n'avons pas de chef d'équipe pour l'évaluation des tâches, le codage et la prise de décision. Tout le monde fait tout. Habituellement, les membres de l'équipe plus expérimentés donnent des opinions sur lesquelles beaucoup sont prêts à se fier. Mais n'importe qui peut prendre une décision. Bien sûr, il y a des conflits lorsque deux développeurs ne parviennent pas à s'entendre sur la mise en œuvre d'une fonctionnalité. Si le conflit s'est transformé en personnalité - vous avez besoin d'une escalade vers la tête. Mais l'essentiel est le choix d'une solution de mise en œuvre. Ensuite, tout le monde se lève et s'approche du tableau jusqu'à ce qu'il trouve une option qui convient à tout le monde. Habituellement, cela se révèle rapidement, mais il y a eu des cas où ils se sont disputés toute la journée. Lorsque l'argument est au point mort, l'arbitre est souvent appelé - une personne d'une autre équipe dont tout le monde fait confiance. Ils expliquent l'essence du problème, résout-il. Même un juin ou un stagiaire peut participer en théorie à ce différend, mais je ne connais que quelques-uns de ces cas - généralement, les joons ont un mentor qu'ils écoutent.
Un exemple d'une équipe de fonctionnalités: nous avons une plateforme de service qui vous permet d'acheter un service avec un entrepreneur avec des marchandises. Par exemple, j'ai acheté une porte - vous pouvez immédiatement mettre le panier et l'installation, de sorte qu'un maître indépendant vienne et fasse selon notre norme. Nous allons vérifier et payer, donner une garantie. Ainsi, cette équipe fabrique un produit, pour cela, elle écrit des solutions informatiques et prend des décisions commerciales, change les processus dans les magasins. D'accord avec les entrepreneurs. Là - le propriétaire du produit de l'entreprise, le commis des magasins, l'architecte, les développeurs, les analystes et le testeur. Ils utilisent immédiatement notre plate-forme API d'entreprise pour fournir toutes les données dans les deux sens et écrire un microservice. Une telle approche - immédiatement opérationnelle et professionnelle en collaboration avec les développeurs et une petite équipe - vous permet de créer rapidement un produit. Mais je pense que c'est mieux qu'ils vous disent eux-mêmes plus tard à quoi ça ressemble de l'intérieur.
Au départ, nous ne voulions pas faire de testeurs séparés: il y avait une tendance que le développeur devrait soit suivre la méthodologie TDD, soit tester son code jusqu'au bout lui-même. En fait, ce n'était pas très efficace. Au début, tout s'est bien passé: a écrit - vous répondez. Vous avez besoin de tests pour que votre application fonctionne correctement. Mais alors, plus les tâches et les applications étaient nombreuses, plus c'était difficile. Certaines applications ont disparu, d'autres sont allées au prod et n'ont pas changé pendant des mois. Il est devenu difficile d'écrire des tests, de les maintenir, etc. Les analystes d'équipe ont changé. Relativement récemment, ils ont convenu qu'ils avaient tort: des testeurs sont nécessaires. Mais les développeurs n'arrêtent pas d'écrire des tests et - parfois - de faire du TDD. Nous avons réalisé par nous-mêmes que les tests qui vérifient la fonctionnalité (l'application fonctionne correctement) et les tests qui vérifient que l'application fonctionne dans des situations problématiques doivent être effectués par différentes personnes. Et pour le second, des testeurs sont nécessaires, car ils couvrent d'éventuels cas étranges non seulement avec des tests unitaires.
Il y a maintenant 60 développeurs purs - arrière, avant, piles complètes. Il y a aussi des analystes, des testeurs et du support. Et plus sept devops supplémentaires. Mais encore, 200 personnes prévues pour le titre ne sont pas recrutées, nous recherchons donc maintenant de nouvelles personnes, car le champ de travail est immense. Il y a des postes vacants dans
Mon cercle , si cela. Autrement dit, du développement, nous en avons maintenant 74 sur environ 200.
InnerSource
Étant donné que nous avons de nombreuses équipes indépendantes uniquement en Russie et qu'il existe encore des équipes qui ont vu quelque chose de similaire dans de nombreux autres pays, nous nous dirigeons vers l'
innsource . C'est très similaire à l'open source au sein d'un groupe limité de personnes.
Au sein du groupe ADEO de toutes les divisions nationales, tout le code se trouve dans le cloud github. Le projet est élaboré selon des règles de conception uniformes. Il n'y a aucune restriction sur le style, la technologie et les outils. Lorsque vous disposez d'un code source ouvert et de règles de conception claires, tout développeur de la pile peut contribuer. Pour vous copier dans le code, vous devez lire le dock, cloner le référentiel, effectuer une modification, envoyer une demande d'extraction.
Actuellement, le Brésil, la Russie et la France utilisent très activement cette base commune.
Nous essayons maintenant de transférer l'intégralité du code des entrepreneurs (et nous en avons beaucoup dans des directions différentes) vers InnerSource. Dans l'analyse, nous avons créé une carte sur deux axes: la complexité technique du transfert vers le mode du cercle intérieur sur un axe et le deuxième axe, combien le transfert vers le cercle intérieur est généralement utile. Si le code est unique et n’est nécessaire qu’en un seul endroit, vous n’avez peut-être même pas besoin de le toucher. Mais si de nombreuses équipes utilisent ce site - c'est absolument nécessaire.
Tout cela améliore généralement la culture du développement. Et cela accélère la vitesse de plusieurs équipes, car vous pouvez écrire une demande de fusion pour n'importe quelle fonctionnalité dont vous avez besoin. Il sera approprié par l'équipe propriétaire et testé par celui qui est le contributeur. L'une des conditions importantes est la disponibilité des autotests et des descriptions de tout code dans le référentiel.
Quelques nuances supplémentaires
Quand ils ont commencé, il n'y avait rien du tout. En parallèle avec les développeurs, ils ont recruté des devops. Désormais, les devobservices sont fournis en tant que service (pour ceux qui en ont besoin), ou l'équipe produit a ses propres opérations, qui déterminent déjà quoi et comment.
L'assemblage se fait dans Jenkins, le code est exécuté dans Sonar (plus précisément, déjà SonarQube). Sonar a échoué - aucune version. Les testeurs écrivent des autotests, les propriétaires de code - des tests fonctionnels. La base de données est fournie en tant que service par des ingénieurs d'infrastructure. Le test de charge à part entière est effectué dans de rares cas, car la structure de la base de test et la base principale sont différentes: sur le préprod, nous avons des données chaotiques et non des données réelles anonymisées (c'est l'une des étapes à venir), vous devez donc les faire rouler doucement et pas toutes à la fois.
Bientôt, nous devrions aller à Kubernetes (et certains des nouveaux produits comme le
marché sont déjà là au départ), dès que nous élaborons le plan de transition et convenons de tous les détails de l'infrastructure.
Mes collègues et moi continuerons à discuter de la façon dont la partie du travail est organisée, car presque partout, vous pouvez continuer à l'infini. Eh bien, vous pouvez suivre notre émission de téléréalité (parce que tout se construit et change rapidement) et parier que nous le fassions ou non.