Système de gestion d'entrepôt utilisant CQRS et Event Sourcing. Processus de développement

Cet article est la suite d'un certain nombre d'articles publiés précédemment et dédiés aux étapes:

1. Énoncé des exigences
2. La conception
3. Implémentations. Couche de service

Il décrit comment nous avons organisé le processus de développement en impliquant les développeurs de la communauté Magento depuis le début du projet au milieu de l'été dernier, et avec lequel nous avons abordé la version de disponibilité générale faite la semaine dernière.

Processus de développement

Tout le travail sur le projet a été effectué avec des programmeurs de la communauté Magento, qui ont rejoint le développement sur une base volontaire, ont pris des tâches de l'arriéré du projet qui les intéressaient et, quand ils les ont terminés, ont mis des demandes de pull sur GitHub.



En conséquence, il y avait plus de 80 de ces types qui ont fait au moins un pool de requêtes, et au total, ils ont mis plus de 800 pools de requêtes.



Le développement a été réalisé en face à face lors d'événements de hackathon, qui sont communément appelés «Contribution Day» dans le monde de Magento, et distribué lorsque les gars ont travaillé sur le projet à distance à un moment opportun pour ouvrir des démos sur le projet pour montrer les résultats et poser des questions.



Événements du format «Contribution Day», où les programmeurs peuvent venir et entrer très facilement dans le projet, ainsi que discuter du problème avec les architectes système et passer par la procédure, les revues de code sont devenues très populaires, car les programmeurs communautaires apprennent rapidement et reçoivent des recommandations et des conseils. d'ingénieurs principaux travaillant avec le système, ainsi que d'acquérir des compétences sur la façon de résoudre des problèmes typiques en utilisant les mécanismes fournis par le cadre; en même temps apporter des améliorations utiles au système lui-même. Comme le montre la pratique de Win-Win, un tel modèle s'applique à tous les participants au processus, y compris les agences où travaillent les programmeurs, participant au projet en tant que contributeurs, car ces agences peuvent utiliser les connaissances acquises par leurs employés comme un avantage concurrentiel dans leurs futurs projets.

Par exemple, 2 semaines avant la sortie officielle, Strix, qui a activement participé à Code Contribution pour le projet MSI, avait déjà lancé son projet basé sur Magento 2.3 + MSI Beta, qui était partagé sur son blog .

Et s'il y avait 15 événements de ce type en 2017, alors en 2018 il y en avait plus de 40.



Et les événements les plus nombreux ont réuni plus de 100 contributeurs en un seul endroit, comme la récente journée de contribution à Kiev avant la conférence # MageConf18 ou la journée de contribution Magento Live EU à Barcelone:



Pour une communication rapide avec les développeurs, nous avons alloué un canal Slack distinct pour la communication, qui compte désormais plus de 350 développeurs.



Slack a remplacé tous les messagers instantanés et a également fourni des outils pour recevoir rapidement les commentaires de la communauté avec des produits et des solutions techniques que nous allions juste mettre en œuvre. Nous l'avons fait à l'aide d'outils standard pour les questionnaires en mou.

Pendant longtemps, la principale source de documentation pour le projet était le wiki du projet , qui comprend toutes les conceptions techniques, la documentation utilisateur, les archives de communication dans Slack, les descriptions des décisions prises lors des rallyes de toilettage et de stand-up.



Chaque vendredi, les contributeurs qui ont fait un pool de demandes pour le projet, ainsi que ceux qui ont des questions / suggestions sur la façon d'améliorer quelque chose, démontrent leurs résultats lors d'un rallye de démonstration ouvert, auquel tout le monde peut se connecter via Zoom:



Et tous ceux qui n'ont pas eu le temps pour le rallye peuvent regarder l'enregistrement, car chacun de ces rallyes est enregistré et présenté sur YouTube . Par exemple, il s'agit d'un enregistrement de la dernière démo où le contributeur Riccardo Tempesta démontre l'algorithme de sélection de la source pour la sélection optimale des entrepôts pour la livraison en fonction des distances entre l'adresse de livraison et les adresses des entrepôts de marchandises




La partie la plus difficile dans un tel modèle de développement logiciel, dans lequel il n'y a pas de personnes constamment dévouées au projet, est de planifier le temps pour la disponibilité des raccords et de déterminer la vitesse et la capacité Scrum des principales mesures pour évaluer quand une sorte de fitcha peut être livrée. En fait, le contributeur, qui a investi 20 à 30 heures dans le projet en une semaine, ne passera peut-être même pas une heure la semaine prochaine, car à son emploi principal il y aura un blocage, la femme / fille commencera à être jalouse ou en raison de toute autre circonstance, car l'arrêt banal étant intéressant. Les développeurs tiers n'ont pas et ne peuvent avoir aucune obligation envers le projet. Ils participent pour le plaisir et de nouvelles connaissances. Et cela, nous devons leur donner sans rien exiger en retour!


Gravez un graphique de l'implémentation de Milestone 2 construit avec ZenHub .

Dans la théorie de la gestion de projet, ils tentent généralement de fixer l'un des deux indicateurs Fixed Scope ou Fixed Delivery Time, en présence de la condition Fixed Resources.

Dans le cas du modèle, lorsque seuls les développeurs de la communauté participent, nous n'avons pas de ressources fixes et toute tentative de fixer le délai de livraison a été très difficile.

Par conséquent, nous avons finalement décidé de choisir et de suivre le processus de développement piloté par les fonctionnalités (FDD) . Fixation formellement assez de temps pour l'itération (jalon) pendant 2-3 mois. Et former le backlog de cette étape, attirer à nouveau la communauté pour aider à la hiérarchisation des tâches dans ce backlog est une autre caractéristique de ce modèle de développement, car nous ne créons pas et ne définissons pas à eux seuls les priorités du backlog de produit. Les contributeurs, surtout s'ils représentent des entreprises, se fixent souvent leur propre priorité de certaines tâches, dictée par leurs projets actuels ou futurs. Ces contributeurs sont intéressés à fournir au référentiel de projet principalement ce qui les intéresse. Dans le cadre du jalon, nous travaillons en parallèle sur les histoires, et nous pouvons les publier dès que nous sommes prêts, ou dès qu'elles atteignent l'heure de fin de l'itération. Si certaines histoires n'ont pas été terminées dans le cadre de l'itération, elles passent au jalon suivant.

Et surtout - nous nous sommes débarrassés de la date de sortie du produit principal - Magento 2 et maintenant nous pouvons être libérés indépendamment de lui! Pourquoi avons-nous choisi le méta-package composer , qui fait référence à tous les modules d'inventaire et le lien vers le métapaquet lui-même à partir du référentiel principal (plus précisément, à partir du métapaquet du référentiel principal) ressemble à ceci:

"magento/inventory-composer-metapackage": "^1.0.3" 

c'est-à-dire le caractère ^ est utilisé pour indiquer la version du package.
De même, les liens vers toutes les versions des modules de projet à l'intérieur du package sont indiqués par l'ajout du symbole ^:

 { "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } } 

L'opérateur ^ existe pour une compatibilité maximale lors de l'écriture de code, nous pouvons donc effectuer des versions internes de MSI jusqu'à ce que nous apportions des modifications incompatibles en amont au projet " > = 1.0.3 <2.0.0 ".
D'une part, cela donne une flexibilité suffisante pour des projets comme MSI, qui sont communément appelés Magento Core Bundle Extensions (CBE). Ces projets sont situés dans des référentiels GitHub distincts, ont leur propre chronologie des versions et sont aussi isolés que possible des autres projets similaires et du produit principal de Magento 2. En termes d'isolement, procéduralement, c'est comme suivre la loi de Conway . Et globalement, cette approche de développement de nouveaux services et projets au sein de Magento 2 correspond au concept Service Isolation présenté par le conseil d'architecture de Magento. Mais avec une plus grande flexibilité vient une plus grande responsabilité ( avec une grande puissance vient une grande responsabilité ), parce que dans ce cas, ces projets doivent suivre strictement le versionnage sémantique ( SemVer ) afin d'éviter des modifications incompatibles en amont et d'assurer la facilité des mises à niveau pour les utilisateurs.

Le backlog du projet lui-même, ainsi que toutes les itérations (y compris celles terminées) sont disponibles sur la page MSI Roadmap .

Par exemple, voici le backlog Milestone 3, sur lequel nous commençons à peine à travailler:



Et en conclusion, je tiens à remercier encore une fois tous les contributeurs qui ont rejoint le projet et contribué à le porter au stade de la sortie de l'AG. Nous n'aurions pas réussi sans vous!