高度なブランチとマージ戦略 (パート 1/2)

Mendix
2016 年 10 月 21 日
分読み

この 2 部構成のブログシリーズでは、複雑な運用環境向けの高度なブランチおよびマージ戦略について説明します。これらの戦略は、複数のプロジェクトと並行した継続的なメンテナンスを行っている現在のクライアントおよび過去のクライアントでの私の個人的な経験に基づいています。

パート1では、ほとんどの人が使っていると思われる基本戦略について簡単に説明します。これは、 Mendix プロジェクトであり、以前の Mendix ブログとバージョン管理の概念に関するドキュメントを参照してください。その後、「トランクにジャンクを入れない」という原則に従った、ブランチとマージの高度な戦略の 1 つのバージョンについて説明します。2 番目の戦略は次のブログで紹介します。

読者はブランチとマージ、Subversion（SVN）と Mendixに記載されているように、 Mendix バージョン管理の概念に関するドキュメント。ただし、モデラーでブランチとマージを行う方法については簡単に説明します。

基本戦略（デフォルト）：メインラインをフィーチャー

この基本戦略は、ほとんどの Mendix メインラインは、すべてのプロジェクトのデフォルトの開始点であるため、プロジェクトでよく使用されます。このアプローチは、プロジェクトが大きくなり、すでに稼働している場合でも継続されることがよくあります。この戦略では、メインラインはほぼすべてのタイプの開発に使用されます。すべての変更はメインラインにコミットされ、デプロイメントはメインラインを使用してのみ行われます。変更は次々にコミットされ、通常は混在し、バグ修正はその上に再度コミットされます。その結果、変更は「パッケージディール」としてのみ提供され、すべてを受け入れるか、放棄するかのどちらかになります。

バージョンがデプロイされると、不適切なデプロイを修正するオプションは限られます。たとえば、1) 以前のモデルパッケージに戻す、2) 最新のコミットを元に戻して (作業内容は失われます) 新しいパッケージを生成する、3) 開発を続行して問題のある部分を修正する、などです。私の経験では、これまでのところ、後者のオプションが最も一般的に採用されています。最新のコミットをロールバックすることはそれ自体がリスクのあるオプションであり、その後も新しいモデルのテストとコミットが必要であることに注意してください。

一般的な善意のアドバイス: この基本戦略はできるだけ早く放棄してください。たとえば、安定したバージョンがテスト環境の 1 つにデプロイされたらすぐに、または遅くとも最初のリリースが本番環境に行われたらすぐに放棄してください。当然のことながら、次のような疑問が湧くかもしれません。代替案は何だろうか? 何をより良くできるだろうか? どこに改善の余地があるだろうか?

まず第一に、あなたは「トランクにゴミはありません。一般的には、それは次のことを意味します。

すべての開発はブランチで行われます（メインラインでは決して行われません）
メインラインは新しい支線の一般的な出発点です
完全にテストされた変更のみがメインラインにマージされます
メインラインへのマージ後、すべてのアクティブなブランチへのマージバックが必要です。ブランチでの開発が継続されている場合は、ソースブランチへのマージバックも必要です。これは、すべてのブランチが同期された状態を維持するために必要です。

メンテナンスとプロジェクトの戦略

「トランクにジャンクを入れない」という原則を適用すると、戦略 1 が実現します。これは、メンテナンスとプロジェクトを並行して行う戦略です。この戦略では、次のブランチを区別できます。

メインライン
継続的なメンテナンスブランチは、例えば、 メンテナンス or いつものようにビジネス （BAU）
オプションで プロジェクト 大きな変更のためのブランチまたは機能ブランチ
さらに、小規模な本番パッチ用のホットフィックスブランチが存在する可能性がある。

この戦略では、変更はブランチのみで行われます。主に メンテナンス (NAIST) と プロジェクト ブランチ。テスト環境へのデプロイメントは、それぞれのブランチから生成されたパッケージで行われます。テストが正常に完了すると、変更はメインラインにマージされます。その後、すべての同期を維持するために、コミットをすべてのアクティブなブランチにマージバックする必要があります。本番環境へのデプロイメントは、メインラインのバージョン管理されたパッケージから行われ、テスト済みのホットフィックスラインから行われる場合もあります。

この戦略の主なアクティビティを視覚的に表すと、下の図を参照してください。左から右に時間が経過するにつれて、1 つのブランチが水平線として示されます。メンテナンスブランチ、メインライン、プロジェクトブランチです。ブランチでコミットされた各変更は、そのライン上で円として示されます。2 つの一連の変更がメンテナンスブランチラインで実行され、コミットされました (3 と 4)。これらの変更は、最初にそのラインから直接生成されたデプロイメントパッケージを使用してテストされます。テストが完了して承認されると、変更はメインラインにマージされます。図では、マージは矢印で示されています。マージ後、変更がコミットされ (3)、次にプロジェクトブランチラインにマージされます (5)。最後に、XNUMX でコミットされた変更がメンテナンスブランチラインにマージされ (XNUMX)、すべてのラインが同期されていることを確認します。

プロジェクトの分岐とマージチャート

ブランチとマージを行う方法 Mendix モデラ

ブランチの使用を開始するには、どのプロジェクトでもチームサーバーが有効になっていることが前提条件となります。最も簡単な方法は、チームサーバーを使用してプロジェクトを開始することです。とにかく無料で実行してください。または、オプションを使用して後で実行することもできます。 チームサーバーにアップロード... に選出しました。 チーム メニュー。

分岐

メンテナンスラインの初期設定は一度だけ行う必要があります。プロジェクトが新しくなったりなくなったりするたびに、新しいブランチが必要になります。古いプロジェクトブランチをクリーンアップすることを忘れないでください。また、機能開発やホットフィックス用に新しいブランチが必要になることもあります。ブランチはメニューオプションを使用して作成できます。 支線を管理する… チーム メニュー項目。

メンテナンスまたはプロジェクトの新しいブランチラインの場合、選択するオリジンは通常、メインラインの最新バージョンになります。機能またはホットフィックスブランチの場合は、その目的によって異なります。このようなブランチは、単独で存在する場合もあれば、メンテナンスまたはプロジェクトのサブブランチになる場合もあります。

いずれにしても、すべてのブランチラインは、変更と少なくともメンテナンスとプロジェクトを配信する必要があります。ブランチラインは同期を維持する必要があり、ここでマージが必要になります。機能ブランチラインは長期間存在する場合があり、その場合は機能ブランチラインも同期を維持する必要がある場合があります。ブランチラインを同期しないと、遅かれ早かれ複雑なバージョン競合が発生します。

マージ

マージは、 ここで変更をマージします… 内のオプション チーム メニュー。すぐに 3 つのオプションが表示されるので、最初は不安になるかもしれません。しかし、注意深く読んでください (実際には、無効なオプションは無効になるため、ここで間違えることはありません)。

マージウィンドウ

プロジェクトまたはメンテナンスブランチからブランチラインへの変更のマージは、多くの場合、 ポートの修正 or 機能ブランチをマージする オプション。 修正を移植する オプションでは、1つまたは複数のリビジョンをマージすることを選択できます。 ポート機能ブランチ オプションはそれを許可せず、以前にマージされなかったすべてのリビジョンをマージします。

ポートの修正 ウィンドウを使用して入力ファイルを追加します。

ポート機能ブランチ ウィンドウを使用して入力ファイルを追加します。

分岐ラインの1つを開いた状態でモデラーを使用すると、最初の2つのオプションは表示されなくなり、 高度なマージ オプション。ここで、マージ元のブランチラインと、マージに含める開始リビジョンと終了リビジョンを選択する必要があります。マージに必ずしもすべてを含める必要はないため、リビジョンの選択は非常に便利です。

最後に、すべてのマージ（および他のすべてのSubversionアクション）は、Windows用のTortoise SVNクライアントで実行できることに留意してください。Tortoise SVNでは、特別なオプションを使用して再統合マージまたはマージバックも簡単に実行できます。すべてのバージョンが互換性があるわけではないことに注意してください。 Mendix SVNの設定。 Mendix Tortoise の使用に興味がある場合は、正しいバージョンのリファレンスガイドを参照してください。

個人的には、ブランチとマージはすべて Mendix モデラー。Windowsエクスプローラーに表示されるアイコン用にTortoiseをインストールしているので、プロジェクトフォルダの状態を直接確認できます。また、Tortoiseには、 Mendix Java ファイルの異なる（競合する）バージョンを比較できるモデラー。これは、場合によっては非常に役立ちます。

結論

では、これまでのところ、この戦略について私が経験したことは何でしょうか。うまく機能しており、変更とバージョンを管理するための良い一歩であると言わざるを得ません。これは優れたモデルであり、シンプルで、必要なものを提供します。ただし、この戦略は時間の経過とともにいくつかの課題をもたらします。

機能や修正の変更が開発ブランチラインに積み重なって、すべてまたは何もないパッケージディールになることがあります (これについては次のブログで詳しく説明します)
プロジェクトとメンテナンスブランチラインの両方からの変更をテスト環境に展開するためのブランチを組み合わせることは困難であり、時には不可能になることもあります（多くの競合が発生した場合）。

最後に、これらの戦略の適用性と、それらを使用してきた期間に学んだ教訓を振り返ってみましょう。上記の戦略は、次のような状況で役立ちます。

メンテナンスとプロジェクトの作業を分離したい場合
複数の機能と修正を別々に開発するリリースの場合
高リスクと低リスクの変更トラック

提示された戦略に対する最終的な判断は、これは優れたモデルであるということです。これは実際にうまく機能し、理解しやすいものです。私たちはこの戦略を 1 年以上にわたってうまく使用していましたが、その制限により深刻な問題に遭遇しました。これについては、このブログのパート 2 で詳しく説明します。

ここでパート2を読んでください

感謝

種を蒔いてブランチとマージの改善について考えさせてくれたリチャードに感謝します。また、改善を続けるよう後押ししてくれたレイノウト、ソジェティの同僚のエドゾとルイ、そして Mendix 建設的なコメントをくださった査読者の方々に感謝します。彼らがいなければ、最終結果は同じにはならなかったでしょう。

デイヴィッド・デ・グルートについて

現在ソジェティで働くデイビッドは、 Mendix 長年にわたり、認定上級開発者として活躍しています。オランダや海外のさまざまな企業で、主に保守およびサポートのコンサルタントとして働いてきましたが、時折、プロジェクトや新規ビルドにも携わっています。David は、Oracle および PL/SQL 開発の経験があり、人工知能の理学修士号を取得しています。