Force.comでの開発におけるバージョン管理手法

• Tweet
• 

システム開発、運用、メンテナンスを行う際に、GitやSubversionなどのバージョン管理システムを導入してソースコードのバージョンを管理することはよくあることと思います。このエントリーでは、Force.comプラットフォームでの開発においても、このようなバージョン管理を行うためのひとつの方法をご紹介します。

Force.comプラットフォームを利用したシステム開発は、通常Force.com IDEと呼ばれるEclipseプラグインを利用し、Apexクラス、Visualforceページなどのメタデータと呼ばれるソースコードを開発していきます。Apexクラス、Visualforceページはテキスト形式のファイルで、J2EEでいうところのjavaファイル、jspファイルにあたります。

J2EEなどでシステム開発を行っている方からみれば、「じゃぁ、Subversionのリポジトリを構築して、EclipseのSubversionプラグインを入れるだけの話じゃないの？」と思われるかもしれませんが、Force.com IDEで開発を行う場合、そのいくつかの特性がバージョン管理システムとの相性を悪くしています。

では、まずバージョン管理システムを導入しない場合の一般的なForce.com開発環境を見てみましょう。

この構成では、各開発者は１つのSandbox Salesforce組織を共有して開発を行うことになります。各開発者は、任意のメタデータをSandbox組織からretrieve（Salesforce組織からメタデータを取得すること）し、Force.com IDEでメタデータの編集を行います。Force.com IDEでのファイル（メタデータ）の変更は、自動ビルド機能を使って自動的にSalesforce組織へ反映されます。

では、次にバージョン管理システムを上記構成に単純に追加した場合の構成を見てみましょう。この例ではバージョン管理システムにSubversionを使います。

この構成でメタデータに変更を行い、バージョン管理システムへ変更をcommit（Subversionへメタデータをアップロードすること）する場合のおおまかな流れを見てみましょう。

1. 開発者Aがメタデータ１を変更しファイルを保存する
2. Force.com IDEが自動的にSandbox組織へ変更されたメタデータ１をdeploy（Salesforce組織へメタデータをアップロードすること）する
3. 開発者AがSubversionへメタデータ１の変更をcommitする
4. 開発者BがSubversionからメタデータ１の変更をupdateする（Subversionからメタデータを取得すること）
5. Force.com IDEがSubversionからのupdateで変更されたメタデータ１をSandbox組織へ自動的にdeployする

上記の流れを実際に実行した場合、ステップ５のSandbox組織へのdeployで競合が発生してdeployは失敗に終わります。これは、Salesforce組織もバージョン管理リポジトリとしての性質を持っており、ファイルのタイムスタンプによる排他制御を行っているために発生しています。

Force.com IDEの競合検知は、”変更対象のファイルのタイムスタンプがSalesforce組織上の当該ファイルのタイムスタンプより前であるか？”で行われているようです。したがって、ステップ４の前に開発者Bは、開発者Aの変更内容をまずretrieveしてからでないと、タイムスタンプの同期がとれていないことになってしまい、競合として扱われることになります。

このようなことが起こる主な原因としては、以下のようなこと考えられます。

1. Force.comの特性上ソースコードのコンパイルはローカルでは行えないため、必ずサーバーサイド（Salesforce組織）へメタデータをdeployする必要がある。
2. Sandbox組織を複数の開発メンバーで共有している。
3. Sandbox組織がメタデータのバージョン管理リポジトリの役割も担ってしまっている。ここまでSalesforceへの操作をretrieve、deploy、Subversionへの操作はupdate、commitと表現してきましたが、これらはバージョン管理リポジトリへの操作としては、同様の意味をもっており、非常に紛らわしいと感じたと思います。これがその原因になっています。

では、このような問題を回避するために以下のような構成を考えてみましょう。

このようにSalesforce組織を分割することで、Sandbox組織が担っていたコンパイラーとしての役割とバージョン管理リポジトリしての役割を完全に分離することができます。これによってSubversionが唯一のバージョン管理リポジトリとして扱えるようになります。

それでは、上記構成でメタデータに変更を行い、バージョン管理システムへ変更をcommitする場合のおおまかな流れを見てみましょう。

1. 開発者Aがメタデータ１を変更しファイルを保存する
2. Force.com IDEが自動的に開発者AのDeveloper Edition組織（以下DE組織）へ変更されたメタデータ１をdeployする
3. 開発者AがSubversionへメタデータ１の変更をcommitする
4. Subversionのcommit-hookスクリプトからSalesforceの移行ツール（Ant）を起動し自動的にSandboxへdeployする（deploy対象のメタデータはSubversionからcheckoutする）
5. 開発者BがSubversionからメタデータ１の変更をupdateする
6. Force.com IDEが自動的に開発者BのDeveloper Edition組織（以下DE組織）へ変更されたメタデータ１をdeployする

この構成では、各自のDE組織はプライベートなものになりますので、あたかもローカルのコンパイル・単体テスト環境のように扱うことができます。また、本来の開発対象であるSandbox組織へのデプロイはSubversionからのみ行うようにすることで、Subversionを唯一のバージョン管理リポジトリとして活用できるようになります。この場合、各開発者はSalesforce組織からのretrieveは一切行わず、最新のソースコードの取得は、すべてSubversionからのupdateで行うことになります。

このような構成を採用すれば、Force.comでの開発以外で行っていたバージョン管理に関する開発フローをForce.comの開発へも同様に適用することができます。例えば、RedmineなどのIssue Tracking SystemとSubversionを連携した開発等も可能になります。

今回は、Force.comでバージョン管理を行うための１つの例を紹介させていただきました。プロジェクトごとにバージョン管理を行う粒度やスコープなどは異なりますので、必ずしもこのような構成がベストプラクティスになるとは限りませんが、もしこのような構成を適用可能なプロジェクトがあれば是非実践してみてください。

ただし、以下のような留意点もありますので適用する場合は、事前に十分評価を行ってください。

1. DE組織は保存できるデータ容量が５MBと非常に小さいため開発に際して大量のテストデータが必須であるような場合は、この構成の適用は難しい。
2. メタデータの削除や、オブジェクト項目などの削除など削除系の変更は、手動でのメンテナンスが必要（リポジトリからのupdate時の自動ビルドで変更できない、Salesforce組織のWebインターフェースなどで直接メンテナンスが必要）

Posted by Oi Jun (Appirio Japan)