チーム開発 リポジトリ共有の考え方

最終更新日: 2020年2月15日

リポジトリフォルダ

WagbyDesignerによって編集された設計情報(リポジトリ)は、Wagby EEをインストールしたフォルダ直下にある「repository」というフォルダに管理されます。このフォルダ構造の詳細は「リポジトリ > リポジトリ構成」をお読みください。

チーム開発では、この repository フォルダを共有する必要があります。

フォルダ共有方式(非推奨)

リポジトリを各開発機で個別管理しますが、別途「共有ドライブ」を用意します。このドライブを介して、お互いのリポジトリを更新していきます。

図1 共有ドライブを用意する

この方式は、モデル単位で開発担当者を決め、担当フォルダを管理する運用になります。

図2 共有ドライブの運用方法

本方式の特徴と注意点

  • 最も簡単に導入できます。
  • 変更履歴の管理は別途、運用ルールを定める必要があります。(例:改訂履歴台帳への記載)改訂履歴のためのWebアプリケーションを用意するということも検討するとよいでしょう。
  • 他の開発者が担当するモデルを変更することは(操作上は)可能です。これはトラブルの原因になります。
    • 誤って同じモデルを修正した場合、他人の編集を上書きしてしまい編集内容が消失してしまいます。
    • やむをえない場合は、いったん他の開発者が持っている最新のモデル情報をファイルサーバに置き、その上で誰か一人が修正し、全員に(修正したことを)伝えるようにするとよいでしょう。
    • 例えば「モデル名やモデル項目名の変更」などが該当します。当該モデルを参照している項目を書き換える必要が生じるためです。これは開発者にとって面倒で、間違えやすい作業となってしまいます。

このように開発者が運用時に注意しないといけないことが多いため、本方式の利用は非推奨となっています。

WagbyDesigner共有方式

WagbyDesignerはWebアプリケーションとなっています。そこで、複数の開発者が(サーバで稼動する)一つの WagbyDesigner に同時にログオンし、設計情報を全員で書き換えるという方法です。

  • WagbyDesignerを開発サーバで起動する。
  • 開発機(クライアント)からブラウザで開発サーバのWagbyDesignerを操作する。
図3 WagbyDesigner共有方式

Unlimited Team ライセンスキーを適用することで、本方式で開発できるようになります。詳細は Wagby 販売パートナーにお問い合わせください。

本方式の問題点

  • 一人の開発者がビルド処理を行うと、他の開発者は作業が中断します。「バージョン管理システム利用方式」によってこの問題を解消することができます。

バージョン管理システム利用方式

Wagby EEのリポジトリを共有するために、よく知られたバージョン管理システムを使うことができます。著名な製品として cvs, subversion, Git などがあります。いずれもオープンソースソフトウェアとして提供されており、無償で利用できます。

どの製品を使っても、Wagby EEのリポジトリを共有できます。

図4 バージョン管理システムの利用

リポジトリという単語について

バージョン管理システムによって管理される対象のこともまた「リポジトリ」と呼ぶことがあります。

Wagby EE の「リポジトリ」は設計情報のことですので、同じ単語で二つの意味を持ってしまいますが、混乱のないように使い分けて説明します。

図5 バージョン管理システムの「リポジトリ」

変更を記録する

バージョン管理システムに変更を記録することを「コミット (commit)」といいます。

バージョン管理システムはcommit単位で状態を管理します。また、いつでもその時点の情報に戻すことができる仕組みを備えています。

図6 コミットの考え方

編集履歴を確認する

バージョン管理システムは編集履歴を確認する仕組みが備わっています。図はアトラシアン社が提供する無償のバージョン管理ソフトウェアSourceTreeを使った、編集履歴の確認例です。

図7 氏名項目(customer/name/name.txt)の編集履歴を表示した例
図8 変更前と変更後の値がわかる

過去の状態に戻す

過去のファイル内容を確認しながら、元の状態に戻すことが可能です。

図9 SourceTreeを使った操作の例

競合の検出と解消

複数の開発者が同じモデルを編集した場合、それぞれの修正がぶつかってしまうことがあります。これを競合(コンフリクト; conflict)と呼びます。

この場合は開発者による目視チェックを行い、どの編集を有効にするか(残すか)を決めてコミットします。

図10 競合の検出と解消を行う操作の例

バージョン管理の対象

設計情報(repositoryフォルダ)に加え、カスタマイズを行う場合は customize フォルダもバージョン管理システムの管理対象に加えてください。

自動生成されたコードは、バージョン管理の対象としません。常に自動生成可能なためです。

図11 バージョン管理の対象となるフォルダ

変更したモデル以外のファイルが変更される場合

開発者が変更したモデル以外の、他のモデルが変更される場合があります。これはメニューに関する操作を行った場合に発生します。

詳細は「リポジトリ > リポジトリ構造とチーム開発 > メニュー > チーム開発時の注意点」をお読みください。

Eclipse利用時の注意点

$(DEVHOME)/.project等の設定ファイルは、バージョン管理システムの管理対象としません。ビルド時にwork/srcgen/eclipse以下のファイルが$(DEVHOME)へ上書きされるためです。

一方で、カスタマイズしたeclipse設定ファイルを格納するためのフォルダである$(DEVHOME)/customize/eclipse/は、work/srcgen/eclipseよりも優先されます。このフォルダを用意した場合は、バージョン管理システムの対象としてください。