前回はスタンダードにpythonなアプリをwerckerを使ってCIしましたが、
今回はforce.comなアプリをCIしたいと思います。
pushからwerckerが動き出すまでは前回と同様。
werckerが動き出すとantでテスト走らせるっていうだけのシンプル構成。
1. リポジトリの構成
treeするとこんな感じ。├── build.properties
├── build.xml
├── lib
│ └── ant-salesforce.jar
├── src
│ ├── classes
│ │ ├── S3Common.cls
│ │ ├── S3Common.cls-meta.xml
│ │ ├── S3CommonTest.cls
│ │ └── S3CommonTest.cls-meta.xml
│ ├── objects
│ │ └── Account.object
│ └── package.xml
└── wercker.yml
リポジトリ内にant-salesforce.jarを入れてますがこれだとリポジトリが大きくなるので
jarは別サーバに置いておいて、wercker.ymlの設定でビルド時に取ってくる構成の方が効率的かと思います。
build.properties
sf.serverurl = https://login.salesforce.com
build.xml
<project name="Sample usage of Salesforce-CI Ant tasks" default="checkDeploy" basedir="." xmlns:sf="antlib:com.salesforce">
<property file="build.properties" />
<property environment="env" />
<!-- Build / TestResult never actually saves to the server -->
<target name="checkDeploy">
<sf:deploy username="${env.USERNAME}" password="${env.PASSWORD}" serverurl="${sf.serverurl}" deployRoot="src" checkOnly="true" runAllTests="true" />
</target>
</project>
ユーザ名やパスワードはうっかりgitに上げると面倒なことになるので環境変数を使うようにします。
2. bitbucketとwerckerアプリの設定
bitbucketでリポジトリ作成したあとはwerckerのアプリを前回と同様の方法で作成します。
wercker.ymlはこんな感じになります。
box: mies/openjdk7@0.0.3
build:
# The steps that will be executed on build
steps:
# A custom script step, name value is used in the UI
# and the code value contains the command that get executed
- script:
name: ant
code: |
sudo apt-get update
sudo apt-get install -y ant
ant -lib ./lib checkDeploy
antで環境変数を利用するように設定したので、wercker側で環境変数を定義する必要があります。
SettingsのPipelineからビルド時とデプロイ時に利用できる環境変数を設定できます。
環境変数の名前とその値をそれぞれ入力します。
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
<project name="Sample usage of Salesforce-CI Ant tasks" default="deployForCI" basedir="." xmlns:sfc="antlib:com.yutagithub.sforce.ci" >
<property file="build.properties" />
<property environment="env" />
<!-- Build / TestResult never actually saves to the server -->
<target name="deployForCI">
<sfc:deployForCI username="${env.USERNAME}" password="${env.PASSWORD}" serverurl="${sf.serverurl}" deployRoot="src" checkOnly="true" runAllTests="true" sobjectPlural="true" testResultFile="test-result.xml" coverageResultFile="coverage-result.xml"/>
</target>
</project>
wercker.yml
box: mies/openjdk7@0.0.3
build:
# The steps that will be executed on build
steps:
# A custom script step, name value is used in the UI
# and the code value contains the command that get executed
- script:
name: ant
code: |
sudo apt-get update
sudo apt-get install -y python-pip python-dev build-essential ant
sudo pip install awscli
ant -lib ./lib deployForCI
aws s3 cp test-result.xml s3://tzmfreedom-ci
aws s3 cp coverage-result.xml s3://tzmfreedom-ci
werckerが出力したファイルはビルド後に環境ごと無くなっちゃうので、s3でアップロードして永続化。
キーとシークレットはwerckerの環境変数で定義してあげればOK
ちなみに、ant-salesforce-ciを使った場合、テストでコケた時もビルドが成功してしまうっぽいので
werckerでテスト実行結果を判別させるには、テスト結果のxmlをパースして
実際のテストが通ったかどうかを適切なリターンコードで返す仕組みが必要になります。
Salesforceでwerckerを利用するメリット
正直あんまり無いｗ
wercker単体だとカバレッジとかテスト結果のビジュアライゼーションが出来ないので
ガッチリやるんだったらjenkinsおじさん召喚した方が良いと思います。
負荷の面を考えてもビルドやテストコード走らせる処理自体はSalesforceでやってくれるわけで
クライアント側はポーリングするだけなのでjenkins自体にも大した負荷はかからないと思いますし。
Salesforceというプラットフォーム自体、カバレッジレポートやテスト結果を出力する機能があるので
jenkinsを含むCIサービスを使うメリットが他の言語／プラットフォームより少ないのかなーなんて思ったり。
Salesforceの性質上（？）、バージョンアップでデプロイしにくいコンポーネント
（例えばプロファイルとかプロファイルとかプロファイルとか）があったりするので
そこを解消しないとCIとか継続的デリバリ自体が厳しい気がしています。
っていうか継続的デリバリだとちゃんとロールバック出来ないといけないから、そこらへんも…。
ブルーグリーン・デプロイメントが出来るまでまだまだ時間かかるんだろうなーSFDC。
ちょっと横道に逸れましたが、wercker自体は1ビルド25分以内ならプライベートリポジトリでも
無料という良い感じなCI as a serviceなので通常のWebアプリであればオススメです。
※ちなみにwerckerはまだベータ版です。
