前回はスタンダードにpythonなアプリをwerckerを使ってCIしましたが、

今回はforce.comなアプリをCIしたいと思います。

 

pushからwerckerが動き出すまでは前回と同様。

werckerが動き出すとantでテスト走らせるっていうだけのシンプル構成。

1. リポジトリの構成

treeするとこんな感じ。

リポジトリ内にant-salesforce.jarを入れてますがこれだとリポジトリが大きくなるので

jarは別サーバに置いておいて、wercker.ymlの設定でビルド時に取ってくる構成の方が効率的かと思います。

 

build.properties

build.xml

ユーザ名やパスワードはうっかりgitに上げると面倒なことになるので環境変数を使うようにします。

2. bitbucketとwerckerアプリの設定

bitbucketでリポジトリ作成したあとはwerckerのアプリを前回と同様の方法で作成します。

 

wercker.ymlはこんな感じになります。

 

antで環境変数を利用するように設定したので、wercker側で環境変数を定義する必要があります。

SettingsのPipelineからビルド時とデプロイ時に利用できる環境変数を設定できます。

wercker-pipeline-variables

環境変数の名前とその値をそれぞれ入力します。

Protectedにチェックをつけると、ビルド/デプロイコンソール上に変数値が出力されないようになります。

これを使ってantで利用するUSERNAME、PASSWORDをそれぞれ定義します。

 

これだけでpush→webフック→werckerでforce.comのテストを回す、といったことが出来ちゃいます。

テスト通ったら自動的にFullSandbox等のステージング環境にデプロイしたいとかであれば

Custom deployのwercker.ymlの設定でデプロイ用のantコマンドを追加しちゃえばOK。

ant-salesforce-ciを利用する場合

jUnit形式のXMLを出力したい場合、ant-salesforce-ciをwerckerのビルドに設定可能です。

libに対象のjarファイルを入れて、build.xmlとwercker.ymlを変更します。

build.xml

wercker.yml

 

werckerが出力したファイルはビルド後に環境ごと無くなっちゃうので、s3でアップロードして永続化。

キーとシークレットはwerckerの環境変数で定義してあげればOK

wercker-variables-awskeys

ちなみに、ant-salesforce-ciを使った場合、テストでコケた時もビルドが成功してしまうっぽいので

werckerでテスト実行結果を判別させるには、テスト結果のxmlをパースして

実際のテストが通ったかどうかを適切なリターンコードで返す仕組みが必要になります。

Salesforceでwerckerを利用するメリット

正直あんまり無いw

 

wercker単体だとカバレッジとかテスト結果のビジュアライゼーションが出来ないので

ガッチリやるんだったらjenkinsおじさん召喚した方が良いと思います。

負荷の面を考えてもビルドやテストコード走らせる処理自体はSalesforceでやってくれるわけで

クライアント側はポーリングするだけなのでjenkins自体にも大した負荷はかからないと思いますし。

 

Salesforceというプラットフォーム自体、カバレッジレポートやテスト結果を出力する機能があるので

jenkinsを含むCIサービスを使うメリットが他の言語/プラットフォームより少ないのかなーなんて思ったり。

 

Salesforceの性質上(?)、バージョンアップでデプロイしにくいコンポーネント

(例えばプロファイルとかプロファイルとかプロファイルとか)があったりするので

そこを解消しないとCIとか継続的デリバリ自体が厳しい気がしています。

っていうか継続的デリバリだとちゃんとロールバック出来ないといけないから、そこらへんも…。

ブルーグリーン・デプロイメントが出来るまでまだまだ時間かかるんだろうなーSFDC。

 

 

ちょっと横道に逸れましたが、wercker自体は1ビルド25分以内ならプライベートリポジトリでも

無料という良い感じなCI as a serviceなので通常のWebアプリであればオススメです。

※ちなみにwerckerはまだベータ版です。