Using Team Server - Version Control チームサーバー バージョン管理 を使用する 目次 1 Team server チームサーバー... 2 2 Concepts 概念... 2 2.1 Team server Access チームサーバーへのアクセス... 2 2.2 Repository レポジトリ... 3 2.3 Revision リビジョン... 3 2.4 Working copy 作業コピー... 3 2.5 Download from Team Server チームサーバーからダウンロードする... 4 2.6 Upload to Team Server チームサーバーをアップロードする... 4 2.7 Status & change dock ステータスと Change ドック... 4 2.8 Commit changes 変更をコミットする... 6 2.9 Update 更新... 7 2.10 Conflicts 競合... 8 2.11 History 履歴... 9 3 4 Development lines 開発ライン... 10 3.1 Main line vs. Branch line メイン ラインとブランチ ライン... 10 3.2 Development lines 開発ライン... 10 3.3 Merge 統合... 11 3.4 Best practices ベスト プラクティス... 12 Related content 関連するコンテンツ... 13 Using Team Server - Version Control 1
1 Team server チームサーバー Mendix プラットフォームには モデルとリソースの両方が含まれる一元管理レポジトリが備 えられています プロジェクトに従事するメンバーは 各自のローカル環境にモデルとリソー スのコピーを保持します ローカルで行った変更をレポジトリにコミットしたり レポジトリ から他のメンバーが行った変更を読み取る 更新 ための明示的なアクションがあります これ らのアクションを このような作業スタイルに対応している Subversion の上に構築していま す そ の 人 気 成 熟 度 また 確 か な Windows 対 応 か ら Subversion が 選 ば れ て いま す Subversion の上に構築するとは 変更の送受信に信頼できるプロトコルが継承されることを 意味します Subversion には ブランチや統合など 高度な機能に対応するためのオペレー ションが多数備えられています Mendix Modeler は Subversion コマンドの上にレイヤー を提供することでこれらを簡素化します すべての共通オペレーションは Mendix Modeler から直接実行できます 2 Concepts 概念 2.1 Team server Access チームサーバーへのアクセス チームサーバー プロジェクトにアクセスするには 2 つの条件を満たす必要があります アプリ プロジェクトのチームメンバーでなければならない モデル編集権限を持つロールを持っている 別のチームメンバーからの招待を介してチームメンバーになることができます このため ま だプロジェクトのメンバーでなければ 現チームメンバーに招待してもらってください このロールは プロジェクト セキュリティ/ロール設定によって決まります デフォルトでは Scrum master と Business Engineer ロールがチームサーバーにアクセスできます プ ロジェクトの Scrum master は この設定を変更できます ロールに開発手順の 編集 権限 が与えられると そのロールを持つチームメンバーはモデルをダウンロードし これを変更し Using Team Server - Version Control 2
て新規リビジョンをコミットできるようになります View とは そのチームメンバーがレポジ トリに含まれるチームサーバー リビジョンの一覧を閲覧できることを意味します 2.2 Repository( レポジトリ ) レポジトリとは プロジェクトやその履歴が完全に保存されている一元管理場所です 各プロ ジェクトがレポジトリに該当します Mendix チームサーバーは 任意の数のレポジトリをホ ストできます 2.3 Revision( リビジョン ) レポジトリ内のリビジョンは ある時点のプロジェクトの完全な状態です リビジョンには モデル (.mpr ファイル ) とすべてのリソース (Java カスタム ウィジェットなど) が含まれています 誰かが一連の変更をコミットするたびに 新しいリビジョンが作成されます リビジョンには 1 から始まる番号が振られます リビジョン番号を使うことで ある時点のプロジェクトを個別に区別することが可能になります たとえば レポジトリの最新リビジョンが 20 だとしましょう 誰かが変更をコミットすると リビジョン 21 が作成されます リビジョン 20 は 変更がコミットされる前のプロジェクトの状態で リビジョン 21 は変更後のプロジェクトです 2.4 Working copy( 作業コピー ) Using Team Server - Version Control 3
作業コピーは ローカルで保持されるプロジェクトのコピーです このローカルで持つコピーに作業を行い あらゆる変更を施します チームサーバー レポジトリからあるリビジョンをダウンロードして作業コピーを作成します ダウンロードするリビジョンを作業コピーのオリジナルと呼びます (Subversion では ベース と呼ばれます ) ローカル コピーに作業を行うと オリジナルから枝分かれしたバージョンが出来上がります ローカル コピーに行った作業は レポジトリに反映されていません 変更に満足し それらをコミットした時点で レポジトリに新規リビジョンが作成されます レポジトリからリビジョン 35 をダウンロードしたとしましょう これが 貴方にとってのオリ ジナルです 作業コピーに変更を施し それをコミットします すると リビジョン 36 が作成 され 貴方の作業コピーがオリジナルのリビジョンとなります 2.5 Download from Team Server( チームサーバーからダウンロードする ) チームサーバー プロジェクトの作業を始めるには お使いのコンピューターにプロジェクトをダウンロードする必要があります Mendix Business Modeler では App Project 開発ライン 作業コピーをローカル保存するディスク領域を選択します Modeler では 単純にプロジェクトを開けば チームサーバー プロジェクトをダウンロードできます 2.6 Upload to Team Server( チームサーバーをアップロードする ) チームサーバー レポジトリに何も含まれていない ( モデリングを開始していない ) プロジェクトが存在し バージョン管理を始めたいという場合 このプロジェクトをチームサーバーにアップロードする必要があります 新規のオンライン アプリ プロジェクトにアップロードするか チームサーバー対応であるものの実際に Modeler プロジェクトをまだ保存していない既存プロジェクトを選択することができます 新規プロジェクトをアップロードすると Mendix App Project も作成されます 2.7 Status & change dock( ステータスと Change ドック ) プロジェクトのステータスとは 作業コピーに施されたオリジナルからの全変更内容の概要で す Modeler は Project Explorer と新規 Changes ドックでステータスを表示します 変 Using Team Server - Version Control 4
更内容は様々なアイコンで表示されます アイコン 意味 この項目は一切変更されていません オリジナルからの変更はありません この項目を修正しました ( 例 : 文書 フォルダー またはモジュール ) この項目を追加しました この項目をプロジェクトツリーの別の場所に移動しました この項目を削除しました この項目は競合しています 後で競合を確認します Project Explorer では 何らかの変更が施された項目 ( 文書 フォルダー モジュール ) の前に アイコンが表示されます アイコンは 1 つしか表示できません 文書が修正の上 移動されて いる場合は 修正されたものとして表示されます 上記のスクリーンショットでは Account_NewEdit の文書が修正されたことを確認できます また Flow という新規フォルダーが追加され すべてのマイクロフローがそのフォルダーに移動されています 変更が含まれるフォルダーとモジュールには 小さな黄色のマルが表示されていることに注目してください これにより プロジェクト内で変更が施された場所を直 Using Team Server - Version Control 5
ぐに識別できます Changes ドックには 項目に施された各変更内容が 1 行で表示されます 文書が修正の上 移 動されている場合は その文書に 2 行が表示されます ドックはまた 削除された項目につい ても表示します これは Project Explorer では表示されない内容です 2.8 Commit changes( 変更をコミットする ) レポジトリに変更を送ることを コミットする と言います レポジトリに小規模の一貫した作業をコミットするということです たとえば 新機能の実装やバグ修正です プロジェクトにエラーが存在する場合 Modeler はコミット時に警告を発行します レポジトリ内のリビジョンは つねに一切エラーが存在していないことが理想です コミットすると レポジトリに新規リビジョンが出来上がります コミット時 以下の情報を 新規作成されたリビジョンに添付することができます A textual message( テキスト メッセージ ) コミットする際 Modeler にテキスト メッセージを入力することができます これは施した 変更の概要説明であるべきです A list of userstories( ユーザーストーリー一覧 ) コミットに関連付けられているストーリーです また プラットフォームで文書化されます コミットは小規模単位で行うことを推奨します つまり 1 回のコミットでは 1 つのストーリーを関連付けるべきです Modeler は 現在 Running のステータスにあるストーリーを表示するだけで ストーリーのステータスは変更しません ステータスを Done に設定するのは チームの責任であり Done の定義によって変わってきます Using Team Server - Version Control 6
また Modeler は自動的に一部の情報を添付します 記述者 ( コミットした人物 ) コミット日時 変更した文書 / フォルダー / モジュールの一覧と変更タイプ ( 修正 追加 削除など ) コミットに使用した Modeler のバージョン Java ソース コードの変更 ウィジェットの追加 またはその他のプロジェクト ファイル以 外のファイルに影響のある変更も同時に行っている場合は どのディスク変更がコミットされ るかを示す Changes on disk タブページも表示されます コミットは 作業コピーがそのレポジトリの最新版である場合に限り認められます 前回の更新から他のメンバーが変更をコミットしている場合は まず更新を行う必要があります 貴方のコミットで作成されるリビジョンに 貴方が行った変更と 別のメンバーが行った変更を統合しなければならないからです 更新することで レポジトリ内の最新の変更が貴方の変更内容と統合されます 結果を確認の上 あらゆる問題を修正したら 再度コミットを行うことができます 2.9 Update( 更新 ) 更新とは レポジトリから最新の変更内容を読み取るプロセスです 読み取る変更数が少なく なるように 更新は頻繁に行うことが推奨されます Using Team Server - Version Control 7
更新プロセスでは 貴方の作業コピーのオリジナルも更新されます たとえば 前回更新した際 リビジョン 40 まで (40 を含む ) の変更をすべて受け取ったとしましょう これは 作業コピーのオリジナルがリビジョン 40 であることを意味します 貴方はこの作業コピーに変更を行います 作業を開始後 チーム内の他のメンバーが合計 4 件のコミット (41 42 43 44) を行いました この時点で更新を行うと 他のメンバーによる変更を受け取り 44 が新たなオリジナルとなって 貴方が行った変更がこのオリジナル (44) に対して比較されることになります 更新時にレポジトリから受け取る変更内容は 貴方が自分の作業コピーに行った変更 ( 存在する場合 ) と統合されます つまり 貴方の作業コピーには 貴方の変更と貴方が受け取った変更が含まれることになります 大抵のケースでは 変更は問題なく統合されます たとえば あるメンバーはウィンドウを追加し 別のメンバーはマイクロフローを変更しているかもしれません あるいは 2 人のメンバーがウィンドウにタブを追加したかもしれません 変更内容があまりにも似ている場合に限り 文書の競合が発生します たとえば 2 人のメンバーが同じデータビュー プロパティに変更を施す場合です そのような競合は コミットする前に解消する必要があります 2.10 Conflicts( 競合 ) 競合は 2 つの変更を統合できない場合に発生します 競合は 2 つの状況で発生します 1 つは 同じ文書内で非常に似ている 2 つの修正が行われる場合です たとえば 2 人のメンバーが同じデータビュー プロパティを変更する場合が挙げられます これを文書の競合と呼びます 2 つ目は プロジェクト レベルで発生します たとえば 別のメンバーが修正したウィンドウを削除した場合や 2 人のメンバーが同じマイクロフローをツリー内の別々の場所に移動した場合に発生します これをプロジェクトの競合と呼びます 文書の競合は Project Explorer 内と Changes ドックで表示されます 文書の競合が発生した 場合は 競合が発生している変更箇所にズームできます プロジェクトの競合の場合は Project Explorer ツリーでその文書がハイライトされます Using Team Server - Version Control 8
競合を解消するには バージョン管理ドックの Use mine と Use theirs ボタンを使います プロジェクトの競合の場合は Use mine ボタンのみ有効で 競合を解消して貴方の作業コピーどおりに状況が維持されます 文書の競合の場合は両方のボタンが有効であり 貴方のバージョンにするか 別のメンバーの バージョンにするかを選択することができます 2.11 History( 履歴 ) プロジェクトの履歴とは コミットされたすべてのリビジョンが日付順 ( 最新版が一番上 ) にリストされた一覧です History 画面では リビジョン番号 日付 時間 記述者 そして各リビジョンに関するメッセージを一目で確認することができます いずれかのリビジョンを選択すると 関連のユーザーストーリー 変更された文書 Modeler のバージョン ディスク上の変更内容などの詳細を確認できます プロジェクトで行われた変更の種類は アイコンで表示されます モデル変更があるかどうか ディスク変更があるかどうか プロジェクトが新しい Modeler バージョンに更新されたかどうかなどが アイコンを見れば一目で分かります Using Team Server - Version Control 9
3 Development lines 開発ライン 3.1 Main line vs. Branch line メイン ラインとブランチ ライン プロジェクトは 必ず メイン ライン と呼ばれる 1 本の開発ラインから始まります これ は 開発プロセスを率いる開発ラインです そのラインからのデプロイには リリース済み の アプリケーション機能をすべて含むようにすべきです メイン ラインの他に プロジェク トには複数のブランチ ラインを持たせることができます ブランチは ある開発者が行った特定のコミット リビジョン から作成されます ブランチを 作成するとは 選択したリビジョンのコピーを作成し これを新たな開発ラインの開始リビジ ョンとして使うことを意味します これにより 分離されたラインでモデルに変更を行うことが可能になります 大抵の場合 メ イン ラインで開発作業を続行しつつ リリース済みのアプリケーション バージョンで発見 された問題を解決するためにブランチ ラインを使います これにより 未完成/未テストの機 能をリリースすることなく メイン ラインで新規開発を進めることができます ブランチを作成し 問題を解決した後 あるいは新規の大型機能を作成した後 これらの変更 内容をメイン ラインに統合することが可能です 3.2 Development lines 開発ライン レポジトリには 多数の開発ラインを含めることができます 各開発ラインでは 他の開発ラ インから独立した開発が行われます 簡単なケースでは メイン ライン Subversion では ト ランク と呼ばれます と呼ばれる 1 本の開発ラインしかありません すべての開発作業はそ の 1 本のラインの中で行われます 1 本以上の開発ラインを設けると便利なケースがあります たとえば 1 本の開発ラインは現在 デプロイされているプロジェクト バージョンに存在するバグの修正に使用し 別の開発ライ ンは新機能の開発に使うことができます デプロイしたバージョンにバグが見つかった場合に Using Team Server - Version Control 10
は 新機能が開発されている開発ラインの状態とは無関係に 該当の開発ラインでその問題を 修正することができます メイン ライン以外の開発ラインは ブランチ ラインと呼ばれます 新機能はメイン ラインで開発し デプロイ済みのバージョンに存在するバグ修正はブランチ ラインで行うことをお勧めします Modeler をこのように活用することができますが さらに複雑なプロジェクトにも対応しています リビジョン番号はすべての開発ラインでユニークです つまり 1 本の開発ライン内のコミッ トに連番が振られるとは限りません たとえば 3 から 6 に飛ぶことが考えられます 3.3 Merge( 統合 ) 複数の開発ラインが存在する場合 時々一方の開発ラインの変更内容を別のラインに移植することがあります たとえば プロダクション バージョンのブランチ ラインに施した修正は メイン ラインで開発中の新バージョン 2.0 にも適用するべきです もちろん マニュアルで修正を行うことも可能ですが Modeler では一方の開発ラインの変更を別のラインにマージする機能に対応しています Using Team Server - Version Control 11
マージは 必ず作業コピーを開いている時に行います マージによって その作業コピーに新たなローカル変更が施されることとなります 作業コピーに追加変更を統合する前に まずローカルで行った変更をコミットすることが推奨されます さもないと コミットされていないローカル変更と統合で発生する変更が混ざり 統合結果に不備があった場合に対応することが非常に難しくなります コミットされていない変更がある場合 Modeler は警告を発します 以下の画像では ブランチ ラインのリビジョン 5 が リビジョン 6 であったメイン ライン の作業コピーにマージされています これらのマージされた変更内容がコミットされると リ ビジョン 7 になります これは 1 つのリビジョンをマージする例です 1 つの開発ラインから別の開発ラインにすべてのリビジョンをマージすることも可能です ブランチ ラインでメイン ラインに完全マージしたいという大きな新機能を開発している場合は そのブランチのすべてのリビジョンをマージできます 3.4 Best practices( ベスト プラクティス ) 頻繁にコミットしましょう 競合の軽減 / 防止 Using Team Server - Version Control 12
完了した作業の確認 正しいバージョンの確認 エラーは絶対にコミットしない 頻繁に更新しましょう 競合の軽減/防止 頻繁に統合しましょう 修正後すぐ 機能完成後 変更内容を忘れないうちに 競合を制限 ブランチの作成 修正 大型 機能 作業に 1 日以上要するもの 実装外作業 4 Related content 関連するコンテンツ 9_1GitHub レポジトリに貢献する 9_2 ユーザー フィードバックを収集する 9_3Mendix でアプリケーション要件を管理する 9_4 開発データベースを共有する 9_5 独自のリポジトリを開始する 9_6 チームサーバー バージョン管理 を使用する This Japanese translation is provided for by Buildsystem Co. Ltd., based on Mendix copyrighted documentation and materials which can be found here as licensed under CC BY 4.0 Using Team Server - Version Control 13