バージョン管理とチーム開発

1. Mendixはチーム開発をどのようにサポートしますか？

Mendix Studio Pro は、様々なスキルレベルのメンバーがいるマルチユーザー開発をサポートします。チームメンバーは、ニーズに応じてMendix Studio またはMendix Studio Pro を選択できます。詳細は、アプリケーション開発をご覧ください。

プロジェクトの開始時には、すべてのチームメンバーがバージョン管理リポジトリのメインラインで一緒に作業することができます。Mendix Studio Pro の利用者は、バージョン管理リポジトリにあるモデルをアップデートやコミットし、アプリの更新をチーム内のメンバーと共有できます。

2. Mendixでのバージョン管理の仕組みは？

Mendixは、Mendix Team Server と呼ばれるGitをベースとしたバージョン管理リポジトリをサポートしています。Mendixプラットフォームを使用して構築されたすべてのプロジェクトには、Team Server バージョン管理システムが付属しています。Team Server はSVNのテクノロジーを使用し、複数の開発者が同じプロジェクトで作業し、バージョン管理リポジトリ内に保持されているリビジョンにモデルの変更を継続的にマージできるようにします。
Mendix 9以下のアプリでは、Subversion（SVN）ベースのリポジトリもサポートしています。

この図は、Mendixバージョン管理アーキテクチャを表しています。

開発者は、リビジョンやコンフリクトを管理したり、ブランチラインを作成できます。ブランチラインは、必要に応じてメインラインにマージできます。プラットフォームのすべての変更が記録され、他のリビジョンと比較してコンフリクトを検出したり更新を管理します。プロジェクトメンバーは、Developer Portal でアプリのプロジェクトに招待され、セキュリティロールが割り当てられます。それにより、Team Server に保存されているモデルへのアクセス権が付与されます。

3. User storyとアプリケーションの変更コミットを相互参照するにはどうすればよいですか？

Mendix は、Team Server バージョン管理リポジトリ、アプリ Project Dashboard、Mendix Studio Pro の間で統合された開発エクスペリエンスを提供します。Mendix Team Server バージョンリポジトリとアプリ Project Dashboard および Mendix Studio Pro の統合には、次のような大きなメリットがあります。

• Mendix Studio Pro は、開発および納品サイクル全体を通して要件を追跡する統合された方法をチームメンバーに提供します。アプリケーションの作業を開始するときは、Mendix Studio Pro を開くだけで、現在のスプリントで計画されているユーザーストーリーを確認し、作業を開始できます。
• チームメンバーは、Mendix Studio Pro 内からチームサーバーにアプリモデルの変更をコミットする際、作業していたユーザーストーリーを選択することができます。チームサーバーは、ユーザーストーリーとモデル変更の間に自動的にリンクを作成し、コミットから関連する要件にナビゲートする方法を提供します。
• エンドユーザーはアプリのユーザーインターフェイスから直接フィードバックを提供することができ、このフィードバックはユーザーストーリーに転送することができます。開発者としては、フィードバックのメタデータに記載されているフォームに直接アクセスして、要求された変更を実装することができます。
• チームメンバーは、実装された機能（例えば、ダッシュボードページやマイクロフロー内のビジネスロジック）について、アプリBuzzでディスカッションを開始することができます。これらのディスカッションから、新しいユーザーストーリーを作成し、Mendix Studio Proで実装することができます。モデルのコミットをユーザーストーリーにリンクすると、完全なフィードバックサイクルが準備され、相互参照もできます。

4. Mendix Team Server の代わりに独自のSVNリポジトリを使用するにはどうすればよいですか？

デフォルトのMendix Team Server中央バージョン管理リポジトリに加え、独自のオンプレミスGitリポジトリをアプリのバージョン管理リポジトリとして設定できます。Mendix 8と9では、オンプレミスのSVNリポジトリもサポートしています。

セットアップの詳細については、Mendix Studio Pro Guide の Working with Git On-Premises Version Control Server を参照してください。

5. Mendixはブランチとマージをどのようにサポートしますか？

開発プロジェクトは常に、メインラインと呼ばれる単一の開発ラインから始まる。これは開発プロセスの中で主導権を握る開発ラインである。

メインラインからのデプロイメントには、アプリケーションのすべての（リリースされた）機能が含まれていなければなりません。メインラインに加えて、プロジェクトは複数のブランチラインを持つことができます。ブランチは、特定のコミット（リビジョン）からメインラインまたはブランチラインに作成されます。ブランチを作成するということは、選択したリビジョンのコピーが作成され、新しい開発ラインの開始リビジョンとして使用されることを意味します。これにより、開発者は孤立したラインでモデルを変更することができます。ほとんどの場合、ブランチラインは、メインラインで進行中の開発を継続すると同時に、リリースされたバージョンのアプリケーションの問題を解決するために使用されます。こうすることで、メインラインでは、最終決定やテストが行われていない機能をリリースすることなく、新しい開発を行うことができます。ブランチを作成し、問題を解決した (または新しい大規模な機能を作成した) 後、これらの変更をメインラインにマージすることができます。

Mendixのモデル駆動開発アプローチのおかげで、モデルのマージはコードのマージよりも高い精度で行われます。これは、Mendixがモデルのセマンティクスを理解しているためです。その結果、コンフリクトは少なくなり、もしコンフリクトが発生しても、Mendix Studio Proで前述の整合性チェックメカニズムによって解決することができます。

Mendixは、Mendix Team Serverのバージョン管理リポジトリでのブランチの作成とマージに対応しています。これに加えて、特定のリビジョンにリリースラベルを付けることができます。これにより、チームは、リリースブランチや機能ブランチのような業界パターンを使用することができます。デフォルトでは、Mendix デプロイメントパイプラインもリビジョンタギングを使用して、特定のデプロイメントパイプラインモーメントでバージョンリビジョンにラベルを付けます。これは、監査やバージョンロールバックの目的で使用できます。

このビデオでは、Mendix Studio Pro でブランチを管理する方法を紹介します。

このビデオでは、変更をマージする方法を紹介します。

6. カスタムバージョン管理統合に使用できるバージョンリポジトリAPI

Mendixのバージョン管理機能は、 Team Server リポジトリのAPIで公開されているため、他のプラットフォームサービスや外部のアプリケーションから呼び出すことができます。たとえば、アプリプロジェクトの Team Server バージョニングリポジトリAPIへの最新コミットの取得を呼び出すと、最新リビジョンの成果物を返します。

7. Mendixはどのようにバージョンの違いをサポートしますか？

Mendix Studio Pro には、アプリケーションモデルの差分を提供する機能が組み込まれています。つまり、開発者がアプリドキュメント（ Page 、 Microflow 、統合など）の変更をバージョン管理リポジトリから取得すると、バージョンが比較されます。Mendix Studio Pro は、競合する変更がないことを確認し、2つのバージョンを自動的にマージします。最新バージョンをバージョン管理リポジトリに再度コミットする前に、変更をいつでも確認できます。

変更によって競合が発生した場合（たとえば、別の開発者が削除した Page を変更した場合）、Mendix Studio Pro は、この競合を解決する必要があるというフィードバックを提供します。競合解決機能の詳細については、下記の「9. Mendix Studio Pro の競合解決機能とは何ですか？」セクションを参照してください。

8. アップデートの実行後に他の開発者によって行われた変更を確認するにはどうすればよいですか？

Mendix Studio ProでMendix Team Serverから新しいアップデートを取得する際、開発者はどの変更を受け入れるか、または戻すかを完全に制御できます。更新後、すべての変更がローカルモデルにマージされます。開発者が行った変更とMendix Team Serverからの更新の間にマージ競合がある場合、開発者はすべてのマージ競合の概要を受け取ります。この情報は、ローカルの変更を使用するか、チームサーバーからの変更を使用するかを決定するために使用できます。

開発者は常に、どの変更とマージ競合を受け入れるかを管理できます。最終バージョンをチームサーバーに再度コミットする前に、変更を元のバージョンに戻すことができます。

9. Mendixはどのようにバージョン差分と競合解決をサポートしていますか？

Mendix Studio Pro には、アプリケーションモデルの diff サポートが組み込まれています。これは、開発者がすべてのアプリドキュメント（ページ、マイクロフロー、統合など）のバージョン管理リポジトリから変更を取得するときに、両方のバージョンが比較されることを意味します。Mendix Studio Proは、競合する変更がないことを確認し、2つのバージョンを自動的にマージします。バージョン管理リポジトリに最新バージョンを再度コミットする前に、結果の変更を常に確認することができます。開発者は、このプロセスを完全にコントロールできます。

10. Mendix Studio Proのコンフリクト解決機能とは？

変更の結果、コンフリクトが発生した場合（たとえば、他の開発者が削除したページを変更した場合）、Mendix Studio Proは、このコンフリクトを最初に解決する必要があることをフィードバックします。

Mendix Studio Proは、文書の2つのバージョン間でどのような違いがあるかについての詳細情報を表示することで、コンフリクトの解決を提供します（たとえば、あるページのリストを編集した後、チームの他の誰かがそのページからリストを削除した場合など）。文書がコンフリクトとマークされた場合、コンフリクトの詳細な理由を確認し、きめ細かなバージョン解決メカニズムを使用することができます。文書全体を選択する必要はありません。代わりに、ドキュメント内の個々の要素（ウィジェット、エンティティ、属性、マイクロフローアクションなど）のレベルで競合を解決できます。双方からの競合しない変更は、すべて自動的に受け入れられます。 コンフリクト解決の使用方法の詳細については、『Studio Pro Guide』の「New Merge Algorithm with Fine-Grained Conflict Resolution」を参照してください。

Mendix Studio Proは、アプリのレベルでも競合を処理できます。自分のバージョン」を選択するか、関係するドキュメントやフォルダを削除することで、アプリの競合を解決できます。

以下に2つの例を示します：

ある開発者がドキュメントを削除し、別の開発者がそのドキュメント内で変更を加えた。
両方の開発者がドキュメントを移動したが、ツリーの異なる場所に移動した。
フォルダ (またはモジュール) 全体が削除され、別の開発者がそのフォルダ内のドキュメントを変更した場合、そのフォルダはローカルに復元され、コンフリクトとしてマークされます。こうすることで、そのフォルダを削除するつもりだったが、変更されたドキュメントのコンテキストを表示するために復元されたことがわかります。

11. Javaクラス、ウィジェット、画像などの外部ファイルの競合を解決するには？

デフォルトでは、Mendix Studio Pro は、Java クラスのような外部ファイルの diff 比較を実行します。新しいバージョンがある場合やファイルが削除された場合は、Mendix Studio Pro自体が直接処理します。

外部ファイルの追加差分や競合の解決には、GitやSVN用の外部ビジュアルツールやコマンドラインツールを使用できます。

翻訳元：https://www.mendix.com/evaluation-guide/app-lifecycle/version-control