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

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

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

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

Mendix Studio を使用してチームコラボレーション用のブランチを割り当てると、Mendix Studio で行われる変更をコントロールできます。

たとえば、ビジネス側の開発者がMendix Studio を使用して新しいPageや関連アセットを作成する場合、新しいアプリバージョンをブランチラインで共有します。その後、ビジネスユーザー（ビジネスアナリストなど）は、Mendix Studio を使用してアプリのコンテンツを確認したり変更します。変更が終了したら、ビジネス開発者から依頼されて、IT側の開発者がMendix Studio Pro を使ってブランチをマージします。これにより、IT側の開発者はビジネス開発者のモデル変更内容を把握しコントロールすることができます。チームの経験豊富な開発者は、ブランチからマージされるモデルをコントロールできます。

詳細については、Mendixドキュメントの「共同開発」を参照してください。

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

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

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

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

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

Mendixは、Team Server バージョニングリポジトリ、アプリケーションプロジェクトダッシュボード、Mendix Studio 、Mendix Studio Pro の統合開発を提供します。Mendix Team Server バージョンリポジトリとアプリケーションプロジェクトダッシュボード、Mendix Studio Pro の統合には次の重要な利点があります。

• 開発や配信サイクル全体を通して、チームメンバーが要件を追跡できるようにします。アプリケーションの作業を開始すると、Mendix Studio Pro を起動し、現在の Sprint で計画されている User storyを確認し、作業を開始します。
• チームメンバーは、Mendix Studio Pro から Team Server にアプリモデルの変更をコミットする時に、どの User story に関する変更かを選択できます。 Team Server は、 User story とモデル変更とのリンクを自動的に作成し、コミットに関連する要件にナビゲートできるようにします。
• エンドユーザーは、アプリから直接フィードバックを提供することができ、そのフィードバックを User story に変換することができます。開発者はMendix Studio Pro を起動し、フィードバックのメタデータに記載されているフォームを直接表示して実装することができます。
• チームメンバーは、Mendix Studio やプロジェクトのBuzzを使って、実装された機能（ダッシュボードページや Microflow のビジネスロジックなど）についてディスカッションすることができます。

これらのディスカッションから、新しい User story を作成してMendix Studio Pro で実装できます。モデルをリンクしてその User story に関してコミットすると、完全なフィードバックサイクルが用意され、相互参照されます。

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

Mendix Team Server バージョン管理をする際に、デフォルトのバージョン管理リポジトリの代わりに、独自のオンプレミスSVNリポジトリを選択することができます。

セットアップの詳細については、Mendixのドキュメントの「オンプレミスバージョン管理サーバーの使用方法」を参照してください。

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 からのアップデートしたモデルの間に競合がある場合、すべての競合情報が表示されます。この情報を使用して、ローカルの変更を使用するか、 Team Server からの変更を使用するかを選択することができます。

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

9. Mendix Studio Pro の競合解決機能とは何ですか？

Mendix Studio Pro は、2つのバージョンの違いについて詳細な情報を表示することにより、競合解決をサポートします（たとえば、 Page のリストを編集し、チームの他の開発者がそのPageからリストを削除していた場合）。競合としてマークされている場合、Mendix Studio Pro で競合の理由を確認することができます。この詳細情報に基づいて、「my version」または「their version」のどちらを使用するか選択して競合を解決できます。

Mendix Studio Pro はプロジェクトレベルで競合を解決することもできます。プロジェクトの競合を解決するには、「my version」を選択するか、関連するドキュメントまたはフォルダーを削除します。

以下に競合の例を示します。

• 1人の開発者がドキュメントを削除し、別の開発者がそのドキュメント内で変更を行います
• 2人の開発者がドキュメントを移動しますが、それぞれプロジェクトツリーの別の場所に移動します

フォルダー（またはモジュール）全体が削除され、別の開発者がそのフォルダー内のドキュメントを変更すると、フォルダーはローカルに復元され、競合としてマークされます。これにより、そのフォルダは削除され、変更されたドキュメントを表示するために復元されたことがわかります。

10. Javaクラス、ウィジェット、画像などの外部ファイルの競合を解決するにはどうすればよいですか？

基本的に、Mendix Studio とMendix Studio Pro は、Javaクラスなどの外部ファイルの差分比較も行います。新しいバージョンやファイルが削除された場合、Mendix Studio Pro によって差分比較が直接行われます。

外部ファイルの差分解決や競合解決には、Tortoise SVNなどの外部SVNツールを使用することができます。

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