使用CQRS和事件采购的仓库管理系统。 开发过程

本文是先前在此处发布的，涉及该阶段的许多文章的延续：

1. 要求说明
2. 设计方案
3. 实现。 服务层

它描述了自该项目于去年夏季中期开始以来，我们如何通过Magento社区的开发人员参与来组织开发过程，并以此接近了上周发布的General Availability版本 。

开发过程

该项目的所有工作都是由Magento社区的程序员完成的，他们自愿加入了开发，从项目积压中提取了他们感兴趣的任务 ， 并在完成任务后将Pull Requests放到GitHub上。



结果，有80多个这样的人至少创建了一个请求池，总共放置了800多个请求池。



开发是在黑客马拉松活动（在Magento世界中通常称为“贡献日”）中面对面进行的，并在伙计们在方便的时候远程进行该项目的工作时进行分发，以打开该项目的演示以显示结果并提出问题。



在“贡献日”格式的事件中，程序员可以非常轻松地进入并进入项目，并与系统架构师讨论问题并通过该过程，随着社区程序员快速学习并获得建议和技巧，代码审查变得非常受欢迎。来自与系统合作的核心工程师，并获得了如何使用框架提供的机制解决典型问题的技能； 同时对系统本身进行有益的改进。 如这种模型的双赢实践所示，它适用于流程中的所有参与者，包括雇用参与项目的程序员的机构作为贡献者的机构，因为这些机构可以将员工获得的知识用作未来项目的竞争优势。

例如，在正式发布前2周，积极参与MSI项目代码贡献的Strix已经启动了基于Magento 2.3 + MSI Beta的项目，该项目已在其博客上共享。

如果2017年有15个此类事件，那么2018年将有40多个。



最多的活动将一个地方的100多位贡献者聚集在一起，例如最近在＃MageConf18会议之前在基辅举行的贡献日或在巴塞罗那举行的Magento Live EU贡献日：



为了与开发人员进行快速沟通，我们分配了一个单独的Slack渠道进行沟通，该渠道现已包含350多名开发人员。



Slack取代了所有即时通讯工具，并提供了工具，可通过我们即将实施的产品和技术解决方案快速接收社区的反馈。 我们借助松弛的问卷的标准工具来完成此任务。

长期以来，该项目的主要文档来源是项目Wiki ，其中包括所有技术设计，用户文档，Slack中的通信档案，对修饰和站立聚会的决策描述。



每个星期五，对项目提出要求的贡献者，以及对如何改进某事有疑问/建议的参与者，都会在公开的演示集会上展示其结果，任何人都可以通过Zoom与之联系：



所有没有时间参加集会的人都可以观看录音，因为每个这样的集会都被录制并布置在YouTube上 。 例如，这是最后一次演示的记录，Riccardo Tempesta的撰稿人演示了“货源选择算法”，用于根据送货地址和带有货物的仓库地址之间的距离来优化选择要送货的仓库




在这样的软件开发模型中，最困难的事情是没有专人从事项目工作，这是规划配件可用时间并确定主要指标的Scrum速度和容量以评估何时可以交付特定配件。 实际上，在一周之内在该项目中投入了20-30个小时的贡献者下周可能甚至不会花一个小时，因为在他的主要工作上会遇到障碍，妻子/女孩会开始嫉妒或考虑到其他任何情况，因为一个人可能平庸的停止有趣。 第三方开发人员没有，也没有任何义务。 他们参加是为了获得乐趣和新知识。 我们必须在不要求任何回报的情况下给予他们！


记录使用ZenHub构建的Milestone 2实现的图表。

在项目管理理论中，他们通常尝试在存在“固定资源”条件的情况下固定“固定范围”或“固定交付时间”两个指标之一。

在只有社区中的开发人员参与的模型中，我们没有固定资源，并且很难确定交付时间。

因此，最后，我们决定选择并遵循功能驱动开发（FDD）过程。 正式修复迭代（里程碑）所需的时间为2-3个月。 形成这个里程碑的待办事项列表，再次吸引社区成员来帮助在此待办事项列表中确定任务的优先级，是此开发模型的另一个功能，因为我们不会一手创建和设置产品待办事项列表的优先级。 贡献者（尤其是代表公司的贡献者）通常会为自己确定某些任务的优先级，这取决于其当前或将来的项目。 此类贡献者有兴趣主要将对他们感兴趣的内容传递到项目存储库。 作为里程碑的一部分，我们并行处理故事，我们可以在准备就绪时或在迭代结束时尽快发布它们。 如果某些故事未作为迭代的一部分完成，则它们将继续进行下一个里程碑。

最重要的是-我们摆脱了主要产品的发布日期-Magento 2，现在我们可以独立发布它！ 我们为什么要选出composer meta包 ，它指向所有Inventory模块，并且从主存储库（更确切地说，从主存储库的metapackage）到metapackage本身的链接看起来像这样：

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

即 ^字符用于指示软件包版本。
同样，指向包中所有项目模块版本的链接都带有^符号：

 { "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" } } 

存在^运算符是为了在编写代码时获得最大的兼容性，因此我们可以进行内部MSI发布，直到对项目“ > = 1.0.3 <2.0.0 ”进行向后不兼容的更改为止。
一方面，这为MSI等项目提供了足够的灵活性，这些项目通常称为Magento Core Bundle Extensions（CBE）。 这样的项目位于单独的GitHub存储库中，具有自己的发行年表，并且与其他类似项目以及Magento 2主产品尽可能地隔离，从程序上来讲，就像遵循Conway法则 。 在全球范围内，这种针对Magento 2中新服务和项目的开发方法与Magento建筑委员会提出的服务隔离概念相对应。 但是，更大的灵活性带来更大的责任感（ 强大的力量带来更大的责任感 ），因为 在这种情况下，此类项目应严格遵循语义版本控制（ SemVer ），以防止向后不兼容的更改并确保用户易于升级。

MSI路线图页面上提供了项目本身的待办事项以及所有迭代（包括已完成的迭代）。

例如，这是积压的里程碑3，我们正在此基础上开始工作：



最后，我要再次感谢所有加入该项目并将其带入GA发布阶段的贡献者 。 没有您，我们不会成功！