この記事は、以前にここで公開されたステージ専用の多くの記事の続きです。
- 要件のステートメント
- 設計
- 実装。 サービス層
昨年の夏の半ばにプロジェクトが開始されて以来、Magentoコミュニティの開発者を巻き込んで開発プロセスを編成した方法と、先週行われた
General Availabilityリリースに近づく方法について説明します。
開発プロセス
プロジェクトのすべての作業は、Magentoコミュニティのプログラマーによって行われました。Magentoコミュニティーは、自発的に開発に参加し、プロジェクトのバックログから興味のある
タスクを
取得し、完了時にプルリクエストをGitHubに配置しました。
その結果、少なくとも1つのリクエストプールを作成した80人以上の人がいて、合計で800以上のリクエストプールを配置しました。
開発は、Magentoの世界では一般に「貢献の日」と呼ばれるハッカソンイベントで対面して行われ、プロジェクトのデモを開いて結果を表示したり質問をしたりする都合の良いときにリモートで作業したときに配布されました。
プログラマーが非常に簡単にプロジェクトに参加し、システムアーキテクトと問題を話し合い、手順を進めることができる「Contribution Day」形式のイベントは、コミュニティプログラマーがすばやく学習し、推奨事項とヒントを得るため、レビューコードが非常に人気になりました。システムを操作するコアエンジニアから、およびフレームワークによって提供されるメカニズムを使用して典型的な問題を解決する方法に関するスキルを獲得します。 システム自体に有用な改善を加えます。 このようなモデルのWin-Winの実践が示すように、貢献者としてプロジェクトに参加するプログラマーが働く代理店を含むプロセスのすべての参加者に適用されます。これらの代理店は、従業員が得た知識を将来のプロジェクトの競争上の優位性として使用できるからです。
たとえば、公式リリースの2週間前に、MSIプロジェクトのコードコントリビューションに積極的に参加したStrixは、Magento 2.3 + MSI Betaに基づくプロジェクトを既に開始しており
、ブログで共有され
ていました 。
2017年に15のそのようなイベントがあった場合、2018年には40を超えました。
そして、＃MageConf18カンファレンスの前の最近のキエフでのコントリビューションデイやバルセロナでのMagento Live EUコントリビューションデイなど、最も多くのイベントが100以上のコントリビューターを1か所に集めました。
開発者との迅速なコミュニケーションのために、350人以上の開発者で構成された通信用の個別のSlackチャネルを割り当てました。
Slackはインスタントメッセンジャーを置き換え、また、コミュニティからフィードバックを迅速に受け取るためのツールを提供しました。 これは、スラックのアンケートの標準ツールを使用して行いました。
長い間、プロジェクトのドキュメントの主なソースは
プロジェクトwikiでした。これには、すべての技術設計、ユーザードキュメント、Slackのコミュニケーションアーカイブ、グルーミングで行われた決定の説明、スタンドアップラリーが含まれます。
毎週金曜日、プロジェクトへのリクエストのプールを作成した貢献者、および何か改善する方法について質問/提案を持っている貢献者は、誰でもズームを介して接続できるオープンデモラリーで結果を示します：
そして、ラリーの時間がなかった人は全員、レコーディングを見ることができ
ます 。そのような各ラリーは、
YouTubeで記録されレイアウトされ
ているからです。 たとえば、これは最後のデモの記録です。RiccardoTempestaの寄稿者は、配達先住所と商品のある倉庫の住所間の距離に基づいて、配達する倉庫を最適に選択するためのソース選択アルゴリズムを示します。
このようなソフトウェア開発モデルで最も難しいのは、プロジェクトに常に熱心な人がいないことです。フィッティングの可用性を確保するための時間を計画し、フィッティングを提供できるタイミングを評価するため
の主要なメトリックの
スクラム速度と容量を決定します。 実際、1週間以内にプロジェクトに20-30時間を費やした貢献者は、彼の主な仕事で障害が発生するため、妻/女の子がjeしたり、他の状況を考慮したりするため、来週でも1時間を費やすことはできません面白くて面白くない。 サードパーティの開発者はプロジェクトに対して一切の義務を負わず、義務も負いません。 彼らは楽しさと新しい知識のために参加します。 そしてこれは、見返りに何も要求せずに彼らに与えなければなりません！
ZenHubで構築されたMilestone 2実装のグラフを焼き付けます。プロジェクト管理の理論では、通常、固定リソース条件が存在する場合、固定スコープまたは固定納期の2つのインジケーターのいずれかを修正しようとします。
コミュニティの開発者のみが参加するモデルの場合、固定リソースはなく、配信時間を修正する試みは非常に困難でした。
したがって、最終的には、
機能駆動開発（FDD）プロセスを選択して従うことにしました。 2〜3か月間のイテレーション（マイルストーン）の正式な十分な時間を修正します。 このマイルストーンのバックログを形成し、このバックログのタスクの優先順位付けを支援するコミュニティを再び引き付けることは、この開発モデルのもう1つの機能です。製品バックログの優先順位を独力で形成および設定するわけではないからです。 貢献者は、特に彼らが企業を代表している場合、多くの場合、現在または将来のプロジェクトによって決定される特定のタスクの独自の優先順位を設定します。 そのような貢献者は、主に彼らにとって興味深いものをプロジェクトリポジトリに提供することに興味があります。 マイルストーンの一部として、ストーリーの並行作業を行い、準備ができ次第、または反復時間に達したときにストーリーをリリースできます。 一部のストーリーが反復の一部として完了しなかった場合、次のマイルストーンに進みます。
そして最も重要なこと-メイン製品であるMagento 2のリリース日を廃止し、独立してリリースできるようになりました！ すべてのInventoryモジュールを参照する
composerメタパッケージと、メインリポジトリ（より正確には、メインリポジトリの
メタパッケージ）からの
メタパッケージ自体へのリンクを参照する理由は次のとおりです。
"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 "。
一方で、これは、Magento Core Bundle Extensions（CBE）と一般的に呼ばれるMSIのようなプロジェクトに十分な柔軟性を与えます。 このようなプロジェクトは個別のGitHubリポジトリにあり、独自のリリースの年表を持ち、他の同様のプロジェクトやMagento 2の主要製品から可能な限り分離されています。分離という点では、手順的には
Conwayの法則に従います。 そして世界的には、Magento 2内の新しいサービスとプロジェクトのこの開発アプローチは、Magento建築評議会が提示した
Service Isolationコンセプトに対応してい
ます 。 しかし、柔軟性が大きいほど責任が大きくなります（
大きな力には大きな責任が伴います）。 この場合、下位互換性のない変更を防ぎ、ユーザーのアップグレードを容易にするために、そのようなプロジェクトはセマンティックバージョニング（
SemVer ）に厳密に従う必要があります。
プロジェクト自体のバックログとすべての反復（完了したものを含む）は、
MSIロードマップページで入手できます。
たとえば、これはバックログマイルストーン3で、作業を開始したばかりです。
そして結論として、プロジェクトに参加し、GAリリース段階への移行を支援してくれた
すべての貢献者に改めて感謝したいと思います。 あなたなしでは成功しなかったでしょう！
