LoginSignup
4
2

More than 5 years have passed since last update.

Oracle WerckerでGithubにpushされたら自動でCIが動くようにした

Posted at

TL;DR

Githubにgit pushすると自動CIがテストしてくれるようにしたら最高でつよいエンジニアの人たちが「自動CI/CDは当たり前」と言ってる意味を完璧に理解した。

Oracle + Wercker

現在は自動CDまでは行っていなくてgit pushCI(Wercker)Slack通知という流れになっている。

Wercker導入以前は誰かが書いたコードの一部がテストを通ってなかったり、rubocopが怒るようなコードの書かれ方をしていてその状態でマージされてしまって他人のコードに影響がでるということが起こっていた。

pushする前に手元でテストしろ!とかrubocop動かせ!問題あれば自動フォーマットしろ!とかレビューできちんと問題のあるコードを指摘しろ!というのはある。

だがしかし、人間はだいたい自分にとって都合よく忘れたり、「これくらいならいいだろ」と思ってミスを起こす生き物なので自動化することの効果の大きさを実感した。

参考にさせていただいたサイトなど:

その節はお世話になりました、ありがとうございました! :)

自動CI導入して得たもの:

レビューする前に問題のあるコードであるのか?ということを意識しなくていいというのは非常に大きいということを実感した。
この精神的なコスト感が大きく自動CI導入によって軽減された、これはレビューを行う開発スタイルにおいて大きな効果がある。

テストは通っているのでコードの書き方や設計などの部分にフォーカスしてレビューできる、この感覚が導入当初と導入後で大きく変わったなと感じた点だと思う。
また当たり前だが動かないコードやレビュー以前の質の低いコードが紛れにくくなるというのがある。

何故CircleCIやSideCIでないのか?

ぶっちゃけお金の問題、できるだけ無料のサービスでやりたいというのが最優先事項だった。

いまのところCIが無料枠で遅くて困る!ってレベルには至っていないので問題ないが将来的にどこかでCircleCIやSideCIなどのサービスに課金しないといけないかなとは思ってる。
最近npm installしたりとだんだんWerckerが行うstepが多くなってきており、徐々に速度的な問題をじわじわと感じている。
遠くない未来に「もう無料枠ではつらいね」という話しがでそう。

なお、エンジニア全員が「Jenkins氏はメンテしたくない」という統一見解により早々に選択肢から脱落しました、南無。

困ったこと:

CLIの存在を知らなくてgitのログを汚染した。

wercker-cli

CLI、便利ではあるのだがモリモリとバッテリーを消費しており大変厳しい。

wantedly/pretty-slack-notifybundle-installがわからなくて非常に困った。

当初Qiitaのエントリを書いてる方をWantedlyの中のひとなのかと思ってwantedly/pretty-slack-notifyと名前を付けたのだと本気で思っていた。
いまもきちんと理解はしていないのだがStepStoreにあるものをプラグイン?的に使えると認識している。
当初手探り状態だったのでluccafort/pretty-slack-notifyとしていないと駄目だと思って書き換えており盛大にエラーが出ていた

wantedly / pretty-slack-notify

特にハマったというか困ったのがbundle-installで、前述した通りStepStoreのことを認識していなかったためコマンドでbundle installしないといけないと思っていたので何故bundle-installだけコマンド実行する他のステップと違うのかがわからなくて非常に困った。

最終的には↑のStepStoreのおかげでそういうプラグイン的なものが公式から提供されているのだと理解した。
とはいえwercker/bundle-installという記述にしてくれたほうが変に困らなかったので直してほしいと気持ちが強い。
(aliasで公式のものだけ省略可能なのかもしれないが検証していないのでわからない)

Wercker関係の情報が少ない&ググラビリティーが低い

ググラビリティーが低いため欲しい情報にたどり着けないことが多くて大変苦戦した。
また英語記事/日本語記事ともにどうしてもSideCIやCircleCIに比べて少なく困ったときの情報源を探すのに苦労した。

まとめ:

導入前までは「テストコードがある」、「レビューする」、「自動CIがある」はそれぞれ独立した手法だと思っていたのだがこれらは1つの大きな手法の中の項目なのでまずこの中で最初に着手すべきはテストコードだろうと思う。

テストコードを書きながらレビュー文化を導入するのは可能だが自動CI/CDはそれらが揃ってないとかなりつらそうだなと思った。

CIの導入によって手元の環境でテスト実行してストレスになったり、「この実装そもそも動くのか?」みたいな無意味なところで悩まなくなったので非常によい。
またSlackに通知するようにしたので誰が活発に開発してるのか?みたいなものが感じられてなんとなく頑張らないと!みたいな励みになった。

個人アプリ開発なんかでheroku使ってるならCI/CDの導入で楽になりそうだなーと開発していて感じた。
…というようなことを書こうと思っていたがいろいろあって後回しになってしまったせいで情報の欠落が激しい。

恐らくツッコミどころが満載だと思うので訂正箇所ある場合は編集リクエストください。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2