2014-09-27

werckerでforce.comなアプリをCIする。

前回はスタンダードに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からビルド時とデプロイ時に利用できる環境変数を設定できます。

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

<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

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はまだベータ版です。

このエントリーをはてなブックマークに追加