Warehouse management system using CQRS and Event Sourcing. Development Process
This article is a continuation of a number of articles published here earlier and devoted to the stages:
It describes how we organized the development process involving developers from the Magento community since the start of the project in the middle of last summer and with which we approached the General Availability release made last week.
Development process
All the work on the project was carried out with programmers from the Magento community, who joined the development on a voluntary basis, took tasks from the project backlog, which they were interested in and performing them put Pull Requests on GitHub.
As a result, there were more than 80 such guys who made at least one pool of requests, and in total they delivered more than 800 pools of requests.
The development was carried out both in person at events of the hackathon format, which in the Magento world is called “Contribution Day”, and distributed when the guys worked on the project remotely at a convenient time coming to the open project demos to show the results and ask questions.
The events of the “Contribution Day” format, where programmers can come, and it is very easy to enter the project, as well as discuss the problem with the system architects and go through the procedure. Review code has become very popular, as community programmers quickly learn how to receive recommendations and advice. from core system engineers, and also get skills on how to solve typical tasks using the mechanisms provided by the framework; at the same time making useful improvements for the system itself. As the Win-Win practice has shown, such a model applies to all participants in the process, including agencies in which programmers who work as contributors to the project work, because these agencies can use the knowledge gained by their employees as a competitive advantage in their future projects.
For example, 2 weeks before the official release, the company Strix, which actively participated in Code Contribution for the MSI project, has already launched its project based on Magento 2.3 + MSI Beta and shared on its blog .
And if there were 15 such events in 2017, then already in 2018 there were more than 40.
And the most numerous events gathered 100+ contributors in one place, such as the recent Contribution Day in Kiev before the conference # MageConf18 or Magento Live EU Contribution Day in Barcelona:
For quick communication with developers, we have identified a separate Slack channel for communication, which now has more than 350 developers.
Slack replaced any instant messengers, and also provided tools for quickly receiving feedback from the community with the product and technical solutions that we were just about to implement. We did this with the help of standard tools of questionnaires in Slak.
The main source of documentation for the project for a long time served as a project wiki , which includes all technical designs, user documentation, communication archives on Slack, descriptions of decisions made at Grooming and Stand-up rallies.
Every Friday, contributors who made a pool of requests to the project, as well as those who have questions / suggestions how to improve something, show their results at an open demo rally to which anyone can connect through Zoom:
And all those who did not have time for the rally, can watch the recording, since each such rally is recorded and laid out on YouTube . For example, this is the record of the last demo, where contributor Riccardo Tempesta demonstrates the Source Selection Algorithm for the optimal choice of warehouses for delivery based on the distance between the delivery address and the addresses of the goods stores
The most difficult in such a software development model, in which there are no constantly allocated people on the project, is planning the fit time and determining the Scrum Velocity & Capacity of the main metrics for assessing when some fitcha can be supplied. In fact, the contributor who invested 20-30 hours into the project in the next week may not be given an hour next week, since his main job will be a blockage, the wife / girl will be jealous or in mind any other circumstances, because trite to stop being interesting. There are no third-party developers, and there can be no commitment to the project. They participate for fun and new knowledge. And this we must give them without demanding anything in return!
Burn down the Milestone 2 implementation chart built using ZenHub .
In project management theory, they usually try to fix one of the two indicators Fixed Scope or Fixed Delivery Time, if the condition Fixed Resources is present.
In the case of the model, when only community developers are involved, we do not have Fixed Resources and any attempts to fix the delivery time were very hard.
Therefore, we ultimately decided to select and follow the process of Feature-driven development (FDD). Fixing a rather formal time for an iteration (milestone) for 2-3 months. And forming the backlog of this milestone, again involving the community to help with prioritizing the tasks in this backlog - this is another feature of this development model, since we do not single-handedly form and set the product backlog priorities. Contributors, especially if they represent companies, often set themselves their own priorities for certain tasks, which are dictated by their current or future projects. Such contributors are interested in delivering to the project repository first of all what is interesting to them. Within the framework of mailstone, we are working in parallel on stories (stories), and we can release them as soon as they are ready, or after reaching the end time of the iteration.
And most importantly - we got rid of the release date of the main product - Magento 2 and now we can be released regardless of it! For which we selected the composer meta package , which refers to all Inventory modules and the link to the meta package itself from the main repository (more precisely from the main package meta package ) looks like this:
"magento/inventory-composer-metapackage": "^1.0.3"those. to indicate the version of the package, the ^ character is used .
Similarly, references to all versions of project modules inside the package are indicated with the addition of the ^ symbol:
{
"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"
}
}The ^ operator exists for maximum compatibility while writing code, so we can make internal releases of MSI until we bring back incompatible changes to the project " > = 1.0.3 <2.0.0 ".
On the one hand, this gives enough flexibility for projects like MSI, which Magento is called Core Bundle Extensions (CBE). Such projects are located in separate GitHub repositories, have their own release history and are as isolated as possible both from other similar projects and from the core Magento 2 product. In terms of isolation, this is procedurally similar to following Conway's Law . Globally, this development approach for new services and projects within Magento 2 corresponds to the conceptService Isolation presented by Magento Architectural Council. But with more flexibility comes a greater responsibility ( with a great power comes a great responsibility ), because in this case, such projects should strictly follow semantic versioning ( SemVer ) in order to prevent backward incompatible changes and ensure ease of upgrades for users.
The backlog of the project itself, as well as all iterations (including completed ones) are available on the MSI Roadmap page .
For example, Milestone 3 backlog looks like this, on which we are just starting work:
And in conclusion, I would like to thank once again all the contributors.who joined the project and helped bring it to the GA release stage. Without you, we would have failed!
