werckerを使ってみる

# 目的
- ORACLEの [wercker](https://app.wercker.com) を使ったときのメモ
- 使い始めの最初の取っ掛かりとして参考になれば。

なお、アカウント名がサービスにより違っていたりするが、アカウント登録のタイミングによって名前がかぶっていて、止む無く他のアカウントにしているので統一感がなくなっている。

揃えておくのが分かりやすいが、仕方ない。

# 使い始めにやること

## アカウント作成、ログイン
- [wercker](https://app.wercker.com) で、アカウント名、メールアドレス、パスワードの登録。
- パスワード強度のチェックが意外と強め。
- 登録したメールアドレスにWelcomeメールが来ているので、アカウントをActivateし、ログイン。
- [自分のアカウント画面](https://app.wercker.com/niiku-y) を確認。

![wercker25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318326/cef7782f-c98e-8458-5fd1-f9ce4038377d.png)


## リポジトリの準備
- [GitHub](https://github.com/) などにCI対象のリポジトリを用意する
- このあと [自分のリポジトリ](https://github.com/niiku-y) のアプリケーションをwerckerに登録する

## アプリケーションの登録
- ログイン後の画面の右上のほうに「＋」マークがあるので、そこから「Add Application」により登録
- やることは4段階。Select SCM, Select Repository, Configure Access, Review.
- Select SCMではGitHub, GitLab, Oracle Developer Cloud ServiceとOther gitから選べる
- 私はGitHubを選択。OAuthによる認可（クライアントがwercker, 認可サーバ＋リソースサーバがGitHub）を実行
- GitHubの中で、CI対象とするリポジトリを選択する。
- Setup SSH keyでは、ssh鍵を使わないコードチェックアウトと、deploy keyを使う方法から選べる。前者を選択
- 最後に設定内容確認画面。問題なければMake my app publicにチェックし（もしくはチェックせずに）Createボタン押下。これでCI対象のアプリケーションの登録が完了。

![wercker2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318326/ec5123a8-970a-41ab-9c19-6920ce34cd7c.png)

## アプリケーション画面の確認
- タブが5つあり、Runs, Workflows, Access, Environment, Optionsとあるので、どのような内容が含まれるか確認しておく
- Runsタブではパイプラインの実行結果が分かるようになっている
- Workflowsタブにてpipelineを追加してbuild, test, deployなどのCI/CD処理の部品を追加していき、その各処理の詳細をリポジトリのwercker.ymlに記載していくことになる。
- Accessでは、自分のアプリにアクセスできるユーザを決めることができる
- Environmentでは、自分のアプリケーションで使える環境変数を定義できる
- Optionsは、そのアプリケーションの画面で使う色や、他の人から見えるかどうか等、各種設定ができる

![wercker19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318326/4e1d620a-ec46-02bc-a9e0-119d5fa86253.png)

## box用のリポジトリ作成
- werckerではboxというCI/CDタスク実行環境を自作できるので、これを作る。GitLabでいうexecutorを知っていれば分かりやすいはず
- ドキュメントにはqiitaで見かけるようなboxの作り方がなかったように思う。Dockerhubに入れてあるものを使うことはできるようなので、GitHubにて [box作成用のDockerfile](https://github.com/niiku-y/wercker-box-test/blob/master/Dockerfile) を置き、そこから作ったイメージを [Dockerhubのkura2i/wercker-box-test](https://cloud.docker.com/repository/docker/kura2i/wercker-box-test) に置くことにした
- GitHub上でファイル作成。Dockerfile以外にも必要なものがあれば作っておく

## dockerhubでのboxの準備
- [Dockerhub](https://hub.docker.com/) のアカウントがまだない場合は作成しておく
- DockerhubはGitHubとOAuthで連携させる
- Dockerhub上でリポジトリを新規に作成し、上記で作ったDockerfileのビルド結果を入れるのに使う。
- OAuthで認可されていれば、GitHub上の自分のリポジトリ（さらに特定のブランチやタグの指定も可能）をAutobuild対象にでき、git pushされたときにDockerfileからイメージを自動作成できる
- 上記により、GitHubのniiku-y/wercker-box-testから、Dockerhubのkura2i/wercker-box-testをbox用イメージとして作成できるようになった
- ねんのため、イメージが作成できたら他のサーバでdocker pull kura2i/wercker-box-test:latestなど実行してみて、ちゃんと使えるかの確認くらいはしておいたほうがよい。

## アプリケーション側でのCI/CDタスク定義
- 上記まででboxは準備できたので、いよいよアプリケーションのリポジトリにwercker.ymlをおいて、そこでCI/CDタスクを定義する
- アプリケーションは、今回練習なので何でもよい。  [自分のリポジトリ](https://github.com/niiku-y/) でどれか選ぶ
- [wercker.yml](https://github.com/niiku-y/sl/blob/master/wercker.yml) には、実行環境のboxを上述のものを指定したうえで、build, test, deploy というパイプラインを書き、その下にそれぞれstepをぶら下げている
- 今回stepは再利用可能なようにしていないが、werckerはこのstep(複数コマンドの集合)に名前をつけて再利用できる点がよいので、本来そういうふうに作っていくのがよかろう
- タスクはコンテナとして実行されるので、この例の場合、WERCKER_OUTPUT_DIRを介してパイプライン間で成果物の受け渡しをしないと、ビルド結果のコマンドを実行できない点に注意する
- wercker.ymlを直すたびにCIが実行され、結果はRunsに出てくるので、結果を見ながら修正していく。
- デフォルトではパイプラインはbuildしかなかった。deployなどはwercker.ymlに記載しても自動で検出されないようだったので、自分でpipeline追加をGUI(Workflowsタブ)でやらないといけなさそう。
- werckerのアカウント登録に使ったメールアドレスにビルド結果が飛んでいる。通知は適宜うまく利用すること。

![wercker24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318326/b45476eb-f08b-7e29-ad5e-4b54086bc31b.png)