freedom-man.com

ブログは俺のセーブポイント

Tag: CI

Homebrewの独自リポジトリをGithub Contents APIで自動更新する

HomebrewのFormulaを更新する場合

  • Formulaのバージョン
  • ダウンロードするファイルのSHA256

を変更する必要があります。毎回手作業でやるには面倒な上に、Travis CIなどでバイナリをビルドしてGithubのReleasesページに自動アップロードする処理を書いていたりすると、tarコマンド(GNU or BSD)やアーカイブ時間、UID/GIDの差異によって、tar.gzのバイナリが変わってしまうためハッシュ値取得のところでハマりやすいです。例えば、macOSで作成したtar.gzのハッシュ値とTravisの環境で作成したハッシュ値が異なるので、macOSからFormulaをgit commit/pushで更新する場合は、GithubのReleasesページからダウンロードしてきたものに対してハッシュ値を取る必要があります。

ということで今回はTravis CIでHomebrewの独自リポジトリをGithub Contents APIを使って自動更新する方法を紹介します。

Makefileや.travis.ymlの設定はこちらのリポジトリも参考にしてもらえればと思います↓
tzmfreedom/goroon: Cybozu garoon library and command line interface by golang

Continue reading

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

前回はスタンダードに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はまだベータ版です。

werckerでPython/FlaskなアプリをCIする。

CI as a Serviceに触れてみよう第一弾として今回はwerckerを触ってみます。

巷ではTravisCICircleCIが有名ですが、privateでフリーなgitリポジトリを利用したかったので

bitbucketが利用できるwerckerを選択!

 

werckerを使うと…

リモートリポジトリにソースをpush

→リモートリポジトリがwerckerに対してWebフック

→werckerが対象のgitリポジトリからソースをダウンロード

→werckerがgitリポジトリ内にある設定ファイル(wercker.ymlなど)からCI用のVMを作成し

必要なモジュールインストール及びビルド、テストを自動実行

→必要に応じて自動デプロイを実施

というフローでCIしてくれます。

 

今回はbitbucketに対してソースをpushすると自動的にwerckerでテストを走らせて

通ったらOpenShiftに自動デプロイをする、というのをやってみます。

1. Webアプリを準備

今回は(も?)Python/Flaskでやってみます。

ソースをtreeした結果はこんな感じ

 

対象のFlaskアプリのciapp.py↓

 

と、そのテストコードのtest_ciapp.py↓

 

applicationファイルはOpenShiftでFlask動かすためのwsgiの設定ファイルで以下のように記述

OpenShiftでFlask動かすためのサンプルはこちらを参照→openshift/flask-example

 

requirements.txtはpip installでライブラリとかインストールするためのファイルで

依存関係のあるライブラリを以下のようにして書き出せばOK。

2. bitbucketにリポジトリを作成

bitbucketに適当なリポジトリを作成します。

bitbucket-for-wercker

3. Werckerでアプリケーションの設定

werckerにログインして、アプリケーションを作成します。

wercker-top

今回はbitbucketを選択

wercker-app1

対象のリポジトリを選択

wercker-app2

Configure Accessはgitリポジトリからcloneする権限をwerckerに付与する設定です。

詳細はこちらから。

wercker-app3

ここではbitbucketのリポジトリのデプロイキーをwerckerに付与しています。

bitbucketのリポジトリの設定でwerckerが追加されていることを確認できます。

bitbucket-wercker-deploykey

次にwerckerがリポジトリのソースを見て「こんなwercker.ymlどう?」ってリコメンドしてくれます。

イチから作る場合は、ここは飛ばしてもOK。

wercker-app4

wercker.ymlはCIの環境設定を行うファイルになります。

ざっくり言うと、どのプラットフォームでどういったビルド・テストスクリプトを動かして

どういう風にデプロイするか、というのを設定できます。

werckerでCIを行う場合は、このファイルをgitリポジトリ内に入れる必要があります。

 

今回のアプリの場合のwercker.ymlはこんな感じになります。

boxはOSや必要なソフトウェアがインストールされた環境でdockerのコンテナ的な感じ。

今回はpython使うのでwercker/pythonを利用。

 

buildはwerckerでビルドを実行した時の処理内容を記述します。

 

stepというのはビルドやデプロイの一つ一つの操作・工程を示しています。

virtualenvやpip installなどpythonお馴染みのコマンドはwercker側で提供されてます。

scriptではシェルスクリプトを自由に書ける部分になり、今回はnoseを使って自動テストを行っています。

 

上記例だとvirtualenvでpythonの仮想環境構築

→仮想環境上でpip installで必要なライブラリをインストール

→テスト実行

という流れになります。

 

werckerにアプリを作成した時点でbitbucketのリポジトリには前述のデプロイキーと

フックの設定が追加されているので、werckerでの自動ビルドまでが出来るようになっています。

4. OpenShiftへのデプロイ設定

ビルドまでうまくいくのを確認したら

今度はOpenShiftへの自動デプロイの設定を行います。

OpenShift側でテキトーなアプリ(ギア)を作ってAuthorization Tokenを発行します。

openshift-add-authorizationtoken

openshift-create-authorizationtoken

werckerのアプリのSettingsでAdd deploy targetからOpenShiftを選択すると

以下のようにAuthorization Tokenを要求されます。

wercker-deploy-openshift1

そこで、上記で発行したAuthorization TokenをコピペしてConnectすると

OpenShiftや対象のブランチ、自動デプロイの有無の設定画面が表示されます。

wercker-deploy-openshift2

Saveをすると、werckerの公開鍵が表示されるのでコレをOpenShiftの公開鍵として登録します。

wercker-deploy-openshift3

あとはSaveを押して設定を保存します。

これでビルドが成功したらwerckerが持ってる秘密鍵を使って

自動的にOpenShiftにデプロイする設定が完了しました!

実際の動作

bitbucketのリモートリポジトリに対してpushするとフック設定によりwerckerが動きます。

werckerが動くと対象アプリのビルド一覧が更新されます。

wercker-builds

ビルドの詳細はこんな感じ

wercker-buildlog

 

ビルドのステップで一つでもミスるとビルド失敗になります。

コマンドの戻り値が0以外で返って来たらミスという判定になっているっぽいです。

コマンドのログも画面上でちゃんと見れます。

wercker-buildlog-nosetests

 

自動デプロイの設定をした場合はビルド成功後に自動的にデプロイタスクが実行されます。

wercker-deploys

 

今回はOpenShiftにデプロイしましたが、デプロイでもビルドと同じようにスクリプトを書けるので

Capistrano、fabric、dockerやら何でもいけちゃいます。herokuも対応してます。

 

Bitbucket + JenkinsでSalesforceのCI

前回はJenkinsで手動デプロイをするところまでやったので、今回はbitbucketと連携させてみます。

 

仕組みとしては

bitbucketにコミット

→コミットをトリガとしてhook(HTTP POST)が起動し、jenkinsに通知する。

→jenkinsは通知されたタイミングでbitbucketからデータを取得して、取得したデータでantを走らせる。

って感じです。

 

1. Jenkinsにgitのプラグインをインストール

Jenkinsの管理>プラグインの管理 からGIT pluginをインストール。

 

2. jenkinsユーザのssh設定

まずjenkinsユーザでsshキーを作成します。

 

生成された公開鍵(${JENKINS_HOME}/.ssh/id_rsa.pub)をbitbucketに設定します。

 

初回はknown_hostsにbitbucketが登録されていないので

とかで登録しておきます。

 

3. 新しいJobを作成

ソースコード管理にbitbucketのリポジトリを設定

sf-bitbucket-git

 

ビルド・トリガはSCMポーリング。スケジュールは空白で。

sf-bitbucket-build-trigger

 

bitbucketにID/Passwordを保持したくなかったので

適当なディレクトリにbuild.xmlとbuild.propertiesを入れる。

sf-bitbucket-build

 

あとは同じ

sf-bitbucket-afterbuild

 

4. antの設定ファイルを編集

今回はbuild.xmlやbuild.propertiesが別の場所にあるので相対パスは使ってません。

 

 

5. bitbucketのリポジトリにhookを設定

jenkinsっていうフックがありますが、うまくいかなかったのでPOSTにしました。

bitbucket-hook

 

URLはhttp://{user}:{password}@{jenkins-server}/git/notifyCommit?url=git@bitbucket.org:{bitbucket-user}/{bitbucket-repository}.git って感じで。

(Basic認証使ってなければhttp://{jenkins-server}/git/… って感じになります。)

 

6. bitbucketにコミットする。

前回同様こんな感じのフォルダ構成でcommitします。(ForceComSampleを利用させていただきました!)

tree-bitbucket-src

 

これでbitbucketにcommitしたら自動的にJenkinsのビルドが走ってくれるように設定が完了しました!

githubとか別のgitサービスの場合も同じような設定方法になります。

 

うまくいかない場合は上記URLを直接叩いてみて、1-4の設定が合っているかどうかを確認すると良いかも。

 

実際の開発の時はmeta.xmlとかpackage.xml作るの面倒なので

Eclipseのforce.com IDEやsalesforce migration toolとかで取ってきたものを

編集してcommitする流れになると思います。

 

今回の参考URL:

Bitbucketのprivate repositoryとJenkinsの連携について

Ubuntu – BitbucketのプライベートリポジトリをJenkinsからビルド

GithubからJenkinsへのServer Hook

Jenkinsを使ってSalesforceのCIにトライ

今更感がありますが、JenkinsでSalesforceのCIにチャレンジ!

 

今回は手動デプロイ実行と、カバレッジ/テスト結果表示まで。

 

1. JenkinsやWebサーバ、antのインストール

まずはここから。

 

2. nginxの設定変更

/etc/nginx/sites-enabled/default を以下のように編集して

Basic認証とJenkinsへのリバースプロキシを設定します。

※ここでは非SSLの設定ですが、Basic認証使っているので絶対にSSLにした方が良いです。

→参考URL:JenkinsサーバのSSL対応とBasic認証

 

htpasswdの設定も忘れずに

 

3. 必要なライブラリを取ってきて、$ANT_HOME/libに入れる。

以下のライブラリが必要。

ant-salesforce.jar

ant-salesforce-ci.jar

scala-library.jar

面倒なときはここから根こそぎ取ってきてください。

 

4. デプロイ対象のビルドファイルを入れる。

ここらへんは相対パスの関係で色んな配置パターンが考えられますが、以下の方針で配置しました。

・jenkinsユーザのホームディレクトリを作成して、その配下にビルドファイルを入れる。

・成果物(カバレッジとテスト結果のxmlファイル)はworkspaceに置く。

 

ということで配置としてはこんな感じ。(ForceComSampleのファイルを置いています。)

tree-sforce-ci

 

5. build.propertiesとbuild.xmlの設定

 

testResultFileとcoverageResultFileはworkspace直下に設定します。

カバレッジやテストレポートはworkspaceからの相対パスで指定するっぽいのでこの場所に置いてます。

 

あと、sfc:deployForCIはant-salesforceのdeployを拡張したものなので

checkOnly=”true”でデプロイをせずテストのみ行うことも可能です。

 

6. jenkinsの設定

http://{your domain}/でjenkinsにアクセスして

Jenkinsの管理>プラグインの管理からCobertura Pluginをインストール後、新規ジョブを作成します。

jenkins-new-project

 

ビルドの設定

jenkins-project-build

 

ビルド後の処理

jenkins-project-afterbuild

 

7. ビルドを実行してカバレッジとテスト実行結果を取得!

実行結果はこんな感じ。

コンソール出力

jenkins-console

 

カバレッジ(何かグラフの凡例が…)

jenkins-coverage-summary

 

カバレッジ詳細

jenkins-coverage-detail

 

テスト実行結果

jenkins-test-result

 

 

パスの設定がおかしいと、

[Cobertura] No coverage results were found using the pattern****

と言われるので注意してください。

 

※coverage.xmlとtest-result.xmlがファイルシステム上のどこにも出力されていなければ

3のライブラリ設定がおかしい可能性があります。

出力されていて、上記エラーが出た場合は完全にパス設定の問題です。

 

ということで、Salesforceのコードを手動でデプロイして実行結果を取得できることができました!

次回は、bitbucketと連携したいと思います。

© 2017 freedom-man.com

Theme by Anders NorenUp ↑