Sencha Architect — 実際のチーム開発 (Part 1 of 3)
こんにちは、ゼノフィnakamuraです。
CNX,
では、Ext JS と Sencha Touch を利用し、たくさんのアプリケーションを開発しています。私は、CNX の CTOとして、開発者の教育カーブの減少とプロトタイプやアプリケーションをより速く作成するために Sencha Architect の魅力を初めから感じていました。しかし、一つの大きい理由で、最近まで実際の開発に Sencha Architect を利用していませんでした。その理由とは、これをどうやってチーム開発の環境で利用するか理解できなかったからです。次のような大きな疑問がありました(本当をいうと恐怖でした)。
- Sencha Architect が自動的に生成する JavaScript ソースをコントロールする方法は?
- Sencha Architect のプロジェクトファイル(メタデータ)をコントロールする方法は?
- 複数の開発者の Sencha Architect のメタデータ作業をマージする方法は?
- 複数の開発者の作業をマージしようとしたら、アプリケーションは壊れてしまうのでは?
恐怖を乗り越える
現在は、我々は Sencha Architect でのチーム開発方法論を持っていますので、そこまで恐怖を感じていた事が少し恥ずかしいくらいです。実際は、Git のようなソースコントロールに慣れていると、Sencha Architect を利用し、複数の開発者を管理する際に問題はないでしょう。ありがたいことに、Sencha の開発者は Sencha Architect のメタデータコードとそれが生み出す JavaScript のソースコントロールを簡単にできるような仕組みにしました。
細かく説明したいので、CNXの開発ツールと方法論を説明しますし、複数の開発者が効率的に一つの Sencha Architect アプリケーションで作業する方法も説明します。皆さんの使っているツールや皆さんのニーズは弊社とは異なるかもしれませんが、最低限のところは、私のサンプルを基にして、CNXの開発方法論が当てはまると思います。それと、怖がらないで下さい。今まで、簡単に解決できなかった問題や、マージのコンフリクトはありませんでした。
我々の開発ツール
CNXでは、アプリケーションの開発に次のツールと技術を主に利用しています。
Sencha Architect – 元々その方法で開発されたため、まだみっちりコードで作成されるアプリケーションもたくさんあります。しかし、数ヶ月前に我々のグループの方法論を設立した上、たくさんの新しいアプリケーションは Sencha Architect を利用して開発しています。
JetBrains の WebStorm – 様々な理由で WebStorm を気に入っています。素晴らしい JavaScript の編集もありますし、Git をコマンドラインから利用する必要がなくなる、素晴らしい Git のインテグレーションもあります。開発者はエディターに対してとても情熱的だと思いますので、WebStorm を絶対に利用する必要はありません。ただ CNX ではこれを利用していて、サンプルにも出てくるため、ここに記載しています。良い JavaScript のエディターと Git コマンドを実行する方法がさえあれば、それだけで充分です。
Sencha Architect 内で開発が行うなら、なぜ別の JavaScript エディターが必要なんだと思うでしょうか? 全ての場合に、必要だというわけではありません。我々の場合には、WebStorm は変更されたファイルを視覚的に表示する事、Git の分岐を視覚的に管理する事、マージのコンフリクトの確認と解決する素晴らしい方法などがあるため、WebStorm を利用するのはとても便利だと感じます。また、Sencha Architect を利用していますが、Sencha Architect 内では単純に reference で指定するだけの外部 JavaScript や別のリソースがあるアプリケーションもたくさんあり、それを WebStorm 内で編集や管理をします。
GitLab
GitLab をご存知でしょうか。自分でホストする GitHub のようなものです。 既に Git を利用していますと、これから説明するサンプルを理解できると思います。もし Git, GitHub, GitLab を使った事がない人は、最初はそれをよく勉強したほうがいいと思います。
仕様に興味がおありでしたら、CNX の GitHub サーバーの通常の設定は次のようになります:
- ハードウェア: ラックマウントした Dell PowerEdge R310
- 仮想環境: VMware ESXi
- OS: Ubuntu Server 14.04
ほとんどの読者には、このGitLab のセットアップはやり過ぎと感じます。ただ完全なディスクロージャーで、CNXの仕組みを知るために含めています。もし GitLab の設定について詳しく知りたい人は、最後の 「あわせて読みたい」 をご覧ください。または、github.com の GitHub を利用するのがおすすめです。私のサンプルで弊社の内部的にホスティングされている GitLab で行う事は、 GitHub でも行えます。
サンプル 1: シンプルなケース:一人の開発者が変更する
最もベーシックなワークフローを理解できるように、最初はとてもシンプルなケースで始めます。シンプルな Sencha Architect アプリケーションを変更し、変更したものを表示し、それを GitHub にチェックインする方法を説明します。
まずは、私のアプリケーション SimpleForm をご覧ください。顧客のレコードをフォームで表示する、とてもベーシックなアプリケーションです。一つのフォームと一つのコントローラーしかありません。Sencha Architect 上では、次のようになっています。
Sencha Architect – 変更前の SimpleForm サンプル
SimpleForm プロジェクトを GitHub からチェックアウトしました。 WebStorm の表示は次のようになります。
WebStorm – 変更前の SimpleForm サンプル
Lastly, here’s what the unchanged SimpleForm app looks like on the GitLab server: 最後に、GitLab のサーバーで表示される SimpleForm アプリケーションです。
さて、簡単な変更を施しましょう。フォームの下に国 (Country) フィールドを追加します。このスクリーンショットでは、変更を黄色でハイライトしました。
Sencha Architect – Country フィールドを追加した SimpleForm サンプル
さて、もし WebStorm に戻ると、WebStorm でファイルを開いたわけでもないのに、Sencha Architect で変更されたファイルを認識しています。
WebStorm – Country フィールドを追加した SimpleForm サンプル
次に、WebStorm 組み込みの Git 管理を利用し、変更を GitLab サーバーにコミットしてプッシュできます(重要な部分は黄色にハイライトしています)。
SimpleForm サンプル – GitLab に変更をコミット/プッシュする
ここで、GitLab サーバーに戻ると、コミットされた変更を見ることができます
コミットを詳しく見ると、JavaScript や Sencha Architect のメタデータの変更が見えます。メタデータは、経験ある Sencha 開発者は簡単に理解できると思います。Sencha Architect がそのメタデータをどのように JavaScript に切り替えたかも解り易いです。
GitLab – SimpleForm サンプルのコミットの詳細
Sencha Architect のアプリのソースコントロールに入れる部分
本当は、/app/ フォルダをソースコントロールに入れる必要はありません。プロジェクトを開いて、再び保存するだけで、全ての js ファイルは、Sencha Architect で再生成できます。しかし、/app/ フォルダや Sencha Architect が生成した全ての js ファイルをソースコントロールに入れます。メタデータとjs ファイルを扱う必要があるため、マージのコンフリクトを解決する時に少し手間がかかります。しかし、我々が思うには、js ファイルにソースの比較が簡単にできる能力や開発者がリポジトリからアプリケーションをクローンしたらすぐにブラウザで動作できる能力の方が大事だと思います(例えば、最初のものは Sencha Architect で再び保存する必要があります)。
もし、Sencha Architect のビルドツール、または Sencha Cmd を通してアプリケーションを作成する事に慣れているなら、bild フォルダをどうするんだろうとか考えているかもしれません。アプリケーションをビルドする時に、アプリケーションがチェックインされたら Sencha Cmd をサーバーで動作するように指示する特別なスクリプトでアプリケーションが構築されます。もちろんこれはこの記事の範囲外となります。
また、経験のある Git ユーザーには、CNX が通常 Sencha Architect のプロジェクトで利用する .gitignore ファイル入力のサンプルを提供します。
- *.apdisk
- *.DS_Store
- *.TemporaryItems
- *.idea
- build/
Git の Branch
このブログのサンプルを簡単に説明できるようにするため、全ての変更は、master ブランチで行っています。実際には、通常はやらない方法です。CNX の実際の方法論に従うと、development ブランチや他の featureブランチや bug ブランチを使い、常に変更を development ブランチに合流させます。新しいリリースを公開する時には、development を master にマージします。ブランチ管理のプロセスはとても人それぞれなもので、開発者によって意見や好みがあります。ブランチの管理に関して、詳しくはこの記事の最後の「あわせて読みたい」をご覧ください。
まとめ
この最初のブログ記事で、CNX が Sencha Architect を利用し、グループ開発を管理するツールを説明し、基本の処理を説明するために一つのサンプルも紹介しました。次の記事で、二人の開発者が同じアプリケーションの異なる部分に変更を起こし、その変更をうまくマージしていく方法を説明します。
あわせて読みたい
CNX が利用する Git のブランチの戦略についての情報
http://nvie.com/posts/a-successful-git-branching-model/
GitLab の詳しい情報:
https://about.gitlab.com/
Debian/Ubuntu Linux で GitLab のインストール:
https://gitlab.com/gitlab-org/gitlab-ce/blob/6-9-stable/doc/install/installation.md
CNXについて
CNX コーポレーションはSencha 公認のセレクトパートナーです。Sencha パートナーネットワークは、Sencha プロフェッショナルサービスチームの一部となります。
CNX は、1996 年からカスタムビジネスアプリケーションの開発の最先端に立っています。2008年に CNX がブラウザベースのユーザーインターフェースの開発をExt JS に標準化し、2010年にモバイル開発の標準として Sencha Touch を追加しました。世界中のお客様のために、教育、金融、食品、法律、物流、生産、出版、販売などの様々な業界のために最高級なウェブアプリケーションを生成しました。我々の開発グループはシカゴの事務所を拠点とし、どの規模のプロジェクトでも扱えます。CNXは単独で、またはあなたの開発グループと協力し、素早く、コストエフェクティブな方法でプロジェクトを実現できます。詳しくは http://www.cnxcorp.com をご覧ください。