バージョン管理とマルチユーザー開発
どのように Mendix マルチユーザー開発をサポートしますか?
Mendix Studio Proは、さまざまなスキルレベルのマルチユーザー開発を組み合わせます。詳細については、 アプリケーション開発.
プロジェクトの開始時に、すべてのチーム メンバーがバージョン管理リポジトリのメイン ラインで共同作業を行うことができます。 Mendix Studio Proユーザーはアプリのアップデートをチームの他のメンバーと共有できます 更新とコミットパターンを使用する バージョン管理リポジトリ経由。
バージョン管理はどのように機能するのか Mendix?
Mendix Gitをベースにした集中型バージョン管理リポジトリの使用をサポートしています。 Mendix チームサーバー. すべてのプロジェクトは Mendix プラットフォームには、Team Serverバージョン管理システムが付属しています。Team ServerはGitテクノロジーを使用しており、複数の開発者が同じプロジェクトで作業し、モデルの変更をバージョン管理リポジトリ内に保持されたリビジョンに継続的にマージすることができます。 Mendix 9以下、 Mendix Subversion (SVN) ベースのリポジトリもサポートします。
この図は、 Mendix バージョン管理アーキテクチャ:
開発者はリビジョンや競合を管理できるほか、必要に応じてメインラインブランチにマージできるブランチラインを作成することもできます。プラットフォームのすべての変更は記録され、他のリビジョンと比較され、競合を検出して更新を管理します。ユーザーは、 Mendix ポータル また、セキュリティ ロールが割り当てられ、Team Server に保持されているモデルへの適切なアクセス権が付与されます。
ユーザーストーリーとアプリケーション変更コミットを相互参照するにはどうすればよいですか?
Mendix チームサーバーのバージョン管理リポジトリ、アプリケーションプロジェクトダッシュボード、および Mendix Studio Proの統合により、 Mendix アプリプロジェクトダッシュボードとTeam Serverバージョンリポジトリの両方 Mendix Studio Pro には次のような大きな利点があります。
- チームメンバーに 要件を追跡する統合された方法 開発と配信サイクル全体を通して。アプリケーションの開発を始めるときは、 Mendix Studio Pro を使用して、現在のスプリントに計画されているユーザー ストーリーを確認し、作業を開始します。
- チームメンバーがアプリモデルの変更をチームサーバーにコミットすると、 Mendix Studio Proなら これまで取り組んできたユーザーストーリーを選択するチーム サーバーは、ユーザー ストーリーとモデルの変更の間にリンクを自動的に作成し、コミットから関連する要件に移動する方法を提供します。
- エンドユーザーは アプリのユーザーインターフェースから直接フィードバックを得るこのフィードバックはユーザー ストーリーに転送できます。開発者は、フィードバックのメタデータに記載されているフォームに直接アクセスして、要求された変更を実装できます。
- チームメンバーは 議論 アプリ内で実装された機能（ダッシュボードページやマイクロフローのビジネスロジックなど）について議論します。これらの議論から、新しいユーザーストーリーが作成され、実装されます。 Mendix Studio Pro。モデルコミットをユーザーストーリーにリンクすると、完全なフィードバックサイクルが準備され、相互参照も行われます。
自分のリポジトリを使用するにはどうすればいいですか？ Mendix チームサーバー?
デフォルトの中央の横 Mendix Team Serverのバージョン管理リポジトリを使用する場合は、代わりにオンプレミスのGitリポジトリをアプリのバージョン管理リポジトリとして構成することもできます。 Mendix 8 および 9 では、オンプレミスの SVN リポジトリもサポートされます。
セットアップの詳細については、 Gitオンプレミスバージョン管理サーバーの使用 会場は Mendix Studio Pro ガイド.
どのように Mendix ブランチとマージをサポートしますか?
開発プロジェクトは常に、メインラインと呼ばれる単一の開発ラインから始まります。これは、開発プロセス内で主導する開発ラインです。
メイン ラインからのデプロイメントには、アプリケーションの (リリースされた) すべての機能が含まれている必要があります。メイン ラインに加えて、プロジェクトには複数のブランチ ラインを含めることができます。ブランチは、特定のコミット (リビジョン) からメイン ラインまたはブランチ ラインに作成されます。ブランチを作成するということは、新しい開発ラインの開始リビジョンとして使用される、選択したリビジョンのコピーが作成されることを意味します。これにより、開発者は分離されたラインでモデルを変更できます。ほとんどの場合、ブランチ ラインは、メイン ラインで進行中の開発を継続しながら、アプリケーションのリリース済みバージョンの問題を解決するために使用されます。これにより、最終決定またはテストされていない機能をリリースすることなく、メイン ラインで新しい開発を行うことができます。ブランチを作成して問題を解決した後 (または新しい大きな機能を作成した後)、これらの変更をメイン ラインにマージできます。
おかげ Mendixのモデル駆動型開発アプローチでは、モデルのマージはコードのマージよりも高い精度で行われます。これは、 Mendix モデルの意味を理解します。これにより衝突が少なくなり、衝突が発生した場合でも、 Mendix Studio Pro は、上記の一貫性チェック メカニズムを通じてこれを実現します。
Mendix ブランチの作成とマージをサポートします Mendix Team Serverのバージョン管理リポジトリ。さらに、特定のリビジョンにリリースラベルをタグ付けすることもできます。これにより、チームはリリースブランチや機能ブランチなどの業界パターンを使用できます。デフォルトでは、 Mendix デプロイメント パイプラインでは、リビジョン タグ付けを使用して、特定のデプロイメント パイプラインの瞬間にバージョン リビジョンにラベルを付けます。これは、監査やバージョン ロールバックの目的で使用できます。
カスタム バージョン管理統合に使用できるバージョン リポジトリ API はどれですか?
この Mendix バージョン管理機能は、 Team Server リポジトリ内の API 他のプラットフォームサービスや外部アプリケーションから呼び出せるようにする。例えば、 最新のコミットを取得 アプリ プロジェクトの Team Server バージョン管理リポジトリ API を呼び出すと、プロジェクトの成果物の最新リビジョンが返されます。
アップデートを実行した後、他の開発者が行った変更を確認するにはどうすればよいですか?
新しいアップデートを取得する場合 Mendix チームサーバー Mendix Studio Proでは、開発者はどの変更を受け入れるか元に戻すかを完全に制御できます。更新後、すべての変更はローカルモデルにマージされます。開発者による変更と、 Mendix Team Server では、開発者はすべてのマージ競合の概要を受け取ります。この情報を使用して、ローカルの変更を使用するか、Team Server からの変更を使用するかを決定できます。
開発者は常に、どの変更とマージ競合を受け入れるか制御できます。最終バージョンを再度 Team Server にコミットする前に、変更を元のバージョンに戻すことができます。
どのように Mendix バージョン比較と競合解決をサポートしますか?
Mendix Studio Pro には、アプリケーション モデルに対する差分サポートが組み込まれています。つまり、開発者がすべてのアプリ ドキュメント (ページ、マイクロフロー、統合など) のバージョン管理リポジトリから変更を取得すると、両方のバージョンが比較されます。 Mendix Studio Pro は、競合する変更がないことを確認し、2 つのバージョンを自動的にマージします。最新バージョンをバージョン管理リポジトリに再度コミットする前に、結果の変更をいつでも確認できます。開発者はプロセスを完全に制御できます。
紛争解決能力とは Mendix スタジオプロ？
変更によって競合が発生した場合（たとえば、別の開発者によって削除されたページを変更する場合）、 Mendix Studio Pro は、まずこの競合を解決する必要があるというフィードバックを提供します。
Mendix Studio Pro では、ドキュメントの 2 つのバージョンの違いに関する詳細情報を表示することで競合を解決できます (たとえば、ページ上のリストを編集した後、チームの他のユーザーがそのページからリストを削除した場合など)。ドキュメントが競合としてマークされている場合は、競合の詳細な理由を確認し、きめ細かいバージョン解決メカニズムを使用できます。ドキュメント全体の中から選択する必要はありません。代わりに、ドキュメント内の個々の要素 (ウィジェット、エンティティ、属性、マイクロフロー アクションなど) のレベルで競合を解決できます。両側からの競合しない変更はすべて自動的に受け入れられます。競合解決の使用方法の詳細については、 きめ細かな競合解決を実現する新しいマージアルゴリズム 会場は Studio Pro ガイド.
Mendix Studio Pro は、アプリ レベルで競合を処理することもできます。アプリの競合は、「自分のバージョン」を選択するか、関連するドキュメントまたはフォルダーを削除することで解決できます。
これが2つの例です。
- ある開発者が文書を削除し、別の開発者がその文書に変更を加える
- 両方の開発者がドキュメントを移動しますが、ツリー内の異なる場所に移動します
フォルダー全体 (またはモジュール) が削除され、別の開発者がそのフォルダー内のドキュメントを変更した場合、フォルダーはローカルに復元され、競合としてマークされます。このように、そのフォルダーを削除することが意図されていたが、変更されたドキュメントのコンテキストを表示するために復元されたことがわかります。
Java クラス、ウィジェット、画像などの外部ファイル内の競合を解決するにはどうすればよいでしょうか?
デフォルトでは、 Mendix Studio ProはJavaクラスなどの外部ファイルの差分比較を実行します。新しいバージョンがある場合やファイルが削除されている場合は、直接処理されます。 Mendix Studio Pro 自体。
外部ファイルに対する追加の差分処理や競合解決には、Git および SVN 用の外部ビジュアル ツールとコマンドライン ツールを使用できます。