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

Technology Note 開発者向けBLOG

Sencha Blog

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

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

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

Sencha Architect Team Development in the Real World Part 2 of 3 このブログのシリーズのパート1で、CNXが Sencha Architect を使って開発するチームを管理するツールについて説明し、基本的な過程を表すために、一つのショーケースを紹介しました。今回は、もっとよくあるシナリオを紹介します — 違う場所で、同じアプリケーションの開発を行っている複数の開発者。Sencha Architect のメタデータと JavaScript ファイルは、実際に変更した モデル、ストア、コントローラー、ビューなどだけに対して変更します。例えば、もし一人の開発者がコントローラーを変更し、別の開発者がビューを変更した場合、Git がこの変更を自動的にマージし、問題無く GitLab サーバーにプッシュされます。

サンプル 2: よくあるケース — 複数の開発者がアプリの異なる部分を変更する

さて、サンプルを見ましょう。 SimpleForm ビューを変更して、ここで下の部分に Help ボタンを追加している時に、ショーン(CNXの他の開発者)はそのボタンが押された時のハンドラをコントローラーに同時に追加します。

このように、下部のツールバーに Help ボタンを追加しました:

Richard’s Sencha Architect - Added Help Button Richard の Sencha Architect – ヘルプボタンを追加しました

次はショーンの Sencha Architect のスクリーンショットで、Help ボタンが押されたら動く Controller Action を追加しました。

Sean’s Sencha Architect - Added onHelpButtonClick Controller Action ショーンの Sencha Architect – onHelpButtonClick Controller Action を追加しました

次のショーンの WebStorm のスクリーンショットでわかるように、Main コントローラーしか変更されていない事を表しています。(ショーンの WebStorm は暗いテーマを使用っていますが、私は、薄い灰色のテーマを使用しています。また、次のスクリーンショットの .architect ファイルは無視して下さい:変更が追跡されないように .gitignore ファイルに追加するべきでした)

Sean’s WebStorm - Only the Main controller has changed ショーンの WebStorm – Main コントローラーだけが変更されました

私の WebStorm では、Viewport ビュークラスだけが変更されたようになっています。

Richard’s WebStorm - Only the Viewport class has been changed リチャードの WebStorm – Viewport クラスだけが変更されています

さて、私とショーンが二人で Gitlab に commit して push するとどうなるか見てみましょう。まずは、ショーンが commit / push します:

Sean’s WebStorm - Commit and push his changes to the Main controller ショーンの WebStorm – Main コントローラーに変更を commit / push します

次に、ビューの変更を commit し push します。

Richard’s WebStorm - Commit and push changes to Viewport class リチャードの WebStorm – Viewport のクラスに変更を commit / push します

この場合、ショーンは、私のローカルバージョンに入っていなかった変更を Gitlab にコミットしたため、WebStorm は push 拒否のメッセージを表示しています。しかし、このエラーメッセージには、Merge するオプションがあります。

Richard’s WebStorm - Push rejected with option to Merge リチャードの WebStorm – push は拒否されましたが、Merge するオプションがあります

さて、私が Merge ボタンをクリックします。私とショーンが同じファイルを変更していない限り(していません)、すぐに Push ウィンドウに移動し、変更を push します:

Richard’s WebStorm - Push changes after a merge リチャードの WebStorm – マージした後に変更を押す

Gitlab のファイルを確認すると、最後にコントローラーを変更した人はショーンで、ビューを最後に変更した人は私ということわかります。

Gitlab Server - Files after changes pushed by both Sean and Richard Gitlab サーバー : ショーンとリチャードの変更が push された後のファイル

もちろん、これは本当に単純なシナリオですが、複数の開発者が異なるクラス(つまりファイル)に対して作業している限り、全ての変更はコンフリクトなしでマージできるはずです。CNXでは、マージのコンフリクトを防ぐために、上手にプログラミングのタスクを割り当てるようにしています。

まとめ

このブログ記事で、複数の開発者が同じ Sencha Architect のアプリケーションで、異なる部分を変更し、その変更をうまくまとめるサンプルを紹介しました。このシリーズのパート3 では、最も複雑なシナリオを紹介します — 複数の開発者がアプリケーションの同じ部分を変更し、マージのコンフリクトを解決します。

参考文献

PAGETOP