Данная статья является продолжением ряда статей опубликованных здесь ранее и посвященных этапам:
В ней описано каким образом мы организовали процесс разработки привлекая разработчиков из собщества Magento с момента старта проекта в середине прошлого лета и с чем мы подошли к General Availability релизу сделанному на прошлой неделе.
Процесс разработки
Вся работа над проектом велась с программистами из сообщества Magento, которые присоединялись к разработке на добровольной основе, брали задачи из беклога проекта, которые были им интересны и выполняя их ставили Pull Requests на GitHub.
В итоге таких ребят, которые сделали как минимум один пул реквест, оказалось больше 80, и суммарно они поставили больше 800 пул реквестов.
Разработка велась как очно на ивентах формата хакатона, которые в мире Magento принято называть «Contribution Day», так и распределенно, когда ребята работали над проектом удаленно в удобное время приходя на открытые демо по проекту, чтобы показать результаты и задать вопросы.
Ивенты формата «Contribution Day», где программисты могут прийти, и очень легко войти в проект, а также обсудить задачу с архитекторами системы и пройти через процедуру код ревью стали очень популярны, так как программисты из сообщества (Community) быстро обучаются получая рекоммендации и советы от core инженеров по работе с системой, а также получают навыки как нужно решать типичные задачи пользуясь механизмами предоставляемыми фреймворком; при этом делают полезные улучшения для самой системы. Как показала практика Win-Win такой модели распространяется на всех участников процесса включая агенции, в которых работают программисты, участвующие в проекте как контрибьюторы, потому что эти агенции могут пользоваться знаниями, добытыми их сотрудинками, как конкурентным преимуществом в своих будущих проектах.
Например, еще за 2 недели до официального релиза, компания Strix, которая активно участвовала в Code Contribution для проекта MSI, уже сделала запуск своего проекта на основе Magento 2.3 + MSI Beta о чем поделилась в своем блоге.
И если таких ивентов в 2017 году прошло 15, то уже в 2018 их было больше 40.
А самые многочисленные ивенты собирали 100+ контрибьюторов в одном месте, как например, недавний Contribution Day в Киеве перед конференцией #MageConf18 или Magento Live EU Contribution Day в Барселоне:
Для быстрого общения с разработчиками мы выделили отдельный Slack канал для коммуникации, в котором сейчас состоит больше 350 разработчиков.
Slack заменил любые instant меcсенжеры, а также предоставил инструменты для быстрого получения фидбека он сообщества на продуктовые и технические решения, которые мы только собирались внедрять. Мы делали это с помощью штатных инструментов опросников в слаке.
Основным источником документации для проекта долгое время служила проектная wiki, которая включает в себя все технические дизайны, пользовательскую документацию, архивы общения в Slack, описания решений принятых на Grooming и Stand-up митингах.
Каждую пятницу контрибьюторы, которые сделали пул реквесты в проект, а также те у кого возникли вопросы/предложения как можно что-то улучшить демонстрируют свои результаты на открытом демо митинге, к которому может подключиться любой желающий через Zoom:
А все те, кто не успел на митинг, могут посмотреть запись, так как каждый такой митинг записывется и выкладывается на YouTube. Например, это запись последнего демо, где контрибьютор Riccardo Tempesta демонстрирует Source Selection Algorithm для оптимального выбора складов для доставки на основании расстояний между адресом доставки и адресами складов с товарами
Самым сложным в такой модели разработки программного обеспечения, в которой нет постоянно выделенных людей на проекте, это планирование времени готовности фитчей и определение Scrum Velocity & Capacity основных метрик для оценки когда какая-то фитча может поставляться. Фактически, контрибьютор, который в течение одной недели инвестировал в проект 20-30 часов, на следующей неделе может не выделить ни часу, так как на его основной работе будет завал, жена/девушка начнет ревновать или в виду любых других обстоятельств, ведь человеку может банально перестать быть интересно. У сторонних разработчиков нет, и не может быть никаких обязательств перед проектом. Они участвуют ради фана и новых знаний. И это мы им должны давать ничего не требуя взамен!
Burn down график по выполнению Milestone 2 построенный с помощью ZenHub.
В теории управления проектами обычно стараются фиксировать один из двух показателей Fixed Scope или Fixed Delivery Time, при наличии условия Fixed Resources.
В случае модели, когда участвуют исключительно разработчики из сообщества, у нас нет Fixed Resources и любые попытки зафиксировать время доставки давались очень тяжело.
Поэтому в конечном счете мы решили выбрать и следовать процессу Feature-driven development (FDD). Закрепляя достаточно формально время на итерацию (milestone) 2-3 месяца. И формируя беклог этого майлстоуна, опять же привлекая сообщество для помощи с приоретизацией задач в этом беклоге — это еще одна особенность такой модели разработки, так как мы не единолично формируем и устанавливаем приоритеты беклога продукта. Контрибьюторы, особенно если они представляют компании, зачастую выставляют для себя собственные приоретет определенных задач, который продиктован их проектами текущими или будущими. Такие контрибьюторы заинтересованы доставить в репозиторий проекта в первую очередь то, что интересно им. В рамках майлстоуна мы работаем параллельно над историями (stories), и можем релизить их по мере готовности, либо же по достижению времени окончания итерации. Если какие-то истории не были закончены в рамках итерации — они переходят на следующий Milestone.
А самое главное — мы отвязались от даты релизов основного продукта — Magento 2 и теперь можем релизиться независимо от него! Для чего мы выделили composer meta package, который ссылается на все модули Inventory и ссылка на сам метапакет из основного репозитория (точней из метапакета основного репозитория) выглядит следующим образом:
"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".
C одной стороны это дает достаточную гибкость для проектов вроде MSI, которые в Magento принято называть Core Bundle Extensions (CBE). Такие проекты расположены в отдельных GitHub репозиториях, имеют свою хронологию релизов и максимально изолированы как от других подобных проектов, так и от основого продукта Magento 2. В плане изоляции процессуально это похоже на следование закону Конвея (Conway's Law). А глобально такой подход разработки для новых сервисов и проектов в рамках Magento 2 соответвует концепту Service Isolation представленному архитектурным советом Magento. Но c большей гибкостью приходит и большая ответсвенность (with a great power comes a great responsibility), т.к. в этом случае такие проекты должны четко следовать семантическому версионированию (SemVer), чтобы предотвратить обратно несовместимые изменения и обеспечить легкость апгрейдов на для пользователей.
Беклог самого проекта, а также все итерации (включая завершенные) доступны на странице MSI Roadmap.
Например так выглядит беклог Milestone 3, над которым мы только начинаем работу:
И в заключении хотелось бы еще раз поблагодарить всех контрибьюторов, которые присоединились к проекту и помогли довести его до стадии GA релиза. Без вас бы у нас ничего не получилось!
