HOME > 開発者向けBLOG > Sencha Blog >  Sencha Architect — 実際のチーム開発 (Part 3 of 3)

Technology Note 開発者向けBLOG

Sencha Blog

Sencha Architect — 実際のチーム開発 (Part 3 of 3)

こんにちは、ゼノフィnakamuraです。

この記事は、US Sencha社ブログ Sencha Architect – Team Development in the Real World Part 3 of 3 を翻訳したものです。

Sencha Architect Team Development in the Real World Part 3 of 3 このブログシリーズの パート1 パート2 では、CNX が Sencha Architect とともにチーム開発のために使用しているツールの詳細を提供し、基本的なプロセスを解説し、シンプルなシナリオ例も紹介していきました。最終回でもある今回は、もし二人以上の開発者がアプリ内の同じファイルに、同時に変更を加えた場合にどういった事が起きるかを説明したいと思います。

パート2 で説明した通り、CNX は二人以上の開発者が同時に同じファイルに変更を加える可能性を最小限にとどめるられるように、開発者へのタスクを割り当てています。しかし、それは起こりうることです。

サンプル3: 複数の開発者がアプリ内の同じエリアに同時に変更を加えた場合

この例では、私があるコントローラーにコードを加え、ショーン(CNX の別の開発者)も私が変更を加えた事を知らずに同じように変更を加えます。現実世界では、もしマージにコンフリクトがあるとわかった場合は、即座にショーンと相談してからマージの解決方法を決めます。その場合、3つの選択肢が考えられます。

  1. 私の変更を承諾し、ショーンの変更を取り消してなかったことにする。
  2. ショーンの変更を承諾し、私の変更をなかったことにする。
  3. 変更点をうまく統合し、開発者にレビューをしてもらい、ロジックの問題を解決してもらう。

例えば私とショーンがパート2で登場したコントローラーを、より良い「テンポラリ・メッセージ・ウィンドウ」を表示させるために改良をすると決めたとしましょう。そして、お互いにどちらがそのロジックをコード化するか誤解をしていたため、二人とも別々にアプリケーションのローカルコピー内で作業を済ませていたとします。

Sean’s Sencha Architect - Better temporary message window まず、これがショーンのバージョンです

そして、次のものが私がショーンとは別にコード化したバージョンであり、中身は似ているものの、全く同じでないことがわかります。

Richard’s Sencha Architect - Better temporary message window リチャードの Sencha Architect – より良いテンポラリ・メッセージ・ウィンドウ

ショーンがまず commit し、変更を push します。最初の push であるためコンフリクトが起きることはないので、スクリーンショットは省略します。次に私が commit し、変更を push すると、前回のサンプルに似たマージのコンフリクトが表示されます。

Richard’s WebStorm - Rejection when Richard’s new message window pushed リチャードの WebStorm – リチャードの新しいメッセージウィンドウがプッシュされるとリジェクトされる

マージボタンをクリックした後に、コンフリクトのあるファイルの一覧が表示されます。

Richard’s WebStorm - Files with merge conflicts リチャードの WebStorm – コンフリクトのあるファイル

コンフリクトがある最初のファイルは Main.js です。WebStorm は私の変更を左に表示し、ショーンの変更を右に表示させてくれます。そして、左右どちら側のものでも、自由に真ん中のマージリザルトにマージすることができるのです。

Richard’s WebStorm - Merge Revisions window for Main.js リチャードの WebStorm – Main.jsのマージリビジョンウィンドウ

ショーンと相談し、彼の変更の方が優れているということで落ち着いたので、彼の変更点の横の矢印を使う事で真ん中にマージさせ、私の変更点を投棄しました。

Richard’s WebStorm - Merge Revisions window for Main.js リチャードの WebStorm – どの変更点を承諾するかを決定しているマージリビジョンウィンドウ

Richard’s WebStorm - Merge Revisions window for Main.js リチャードの WebStorm – Main.js内でショーンのマージリビジョンが承諾されています。

他にも変更されたブロックがあれば、同じ様な流れでレビューします。他の種類の変更点であっても、どちらか片側のものを真ん中に持ってくることで簡単に求められた結果を得られます。

次にマージするファイルはメインコントローラーのための Sencha Architect のメタデータファイルです。

Richard’s WebStorm - Sean’s merge revision accepted in Main metadata file リチャードの WebStorm – ショーンのマージリビジョンがメインのメタデータファイル内で承諾されています。

まとめ

このブログシリーズでは、CNX がチーム環境で Sencha Architect を使って開発する時に使われる開発ツールや方法論の概略を述べました。このシリーズを通して一番学び、感じて欲しかったことは「あなたのチームに Sencha Architect を導入する時が来た」ということです。Sencha Architect は好きでしたが、チーム環境ではどう使えばいいかわからなかったという人も、もうこれでいつでも始められるくらい情報は揃いましたね。CNX がこの開発方法論を使い始めてから何ケ月も経ちますが、なぜ我々はもっと早く始めなかったか今でもわかりません。

参考文献

PAGETOP