近頃は実装の仕事よりもその周りの援護的な仕事が多い江藤です。その中の一環で行った CI 環境の整理について、今回は記事にします。

WIZY のこれまで

WIZY では Jenkins で自動テストを走らせていました。 流れを図にするとこんな感じです。

1. 開発者は開発が終わると Pull Request を 出す
2. マージ権限のある人がPRをレビューをして、問題があれば修正
3. 問題がなければ権限のある人がマージを行う
4. マージされると、自動テストが走り出す(単体テストの後で結合テスト)、同時にマージを行った人がEC2のサーバに入り手動デプロイを行う
5. 自動テストで問題があれば、再修正を行い最初からやり直す
6. 全てのテストがパスしていれば、次の開発に入る

このフローにはいくつか問題がありました。

• テストコードが走る前に検証環境へデプロイを行っている マージをトリガーにして自動テストを走らせていたので、検証環境へデプロイをしている裏側でテストが走ることになっていました。 たまに Typo などのミスでレビューでは見逃された構文エラーがあったりします。(ちゃんとスモークテストとかしていれば防げるハズなのですが…) これが原因で、検証環境にデプロイしたところ、検証の WIZY が止まってしまうなんてこともありました。 先に単体テストを行っていれば、これは防ぐことができます。 つまり、本来はPRが出た段階でテストコードは実行しなければいけないのです。

• 検証環境へ手動でデプロイを行っている 検証環境へのデプロイはマージを行った人が手作業で行っていました。 SSHでサーバへ入って、ソースコードを最新にして、サービスを再起動させて、と一回一回は大した作業ではないのですが、レイアウトの微修正など細かいデプロイが重なった時など、予想以上の時間をデプロイに持っていかれていた気がします。 それ以外にも、複数のブランチに依存するモジュール(例えば、WebとAPIの仲介をSwaggerで行っていますが、これはWeb画面のサーバとAPIのサーバのどちらにもデプロイが必要です)で片方だけデプロイを忘れていて動かなくなるということもありました。 いずれにせよ、デプロイ時に叩くコマンドは決まっているので人力で行う必要はなく、これも自動化が出来ます。 ということで、これもJenkinsで行わせます。

WIZY の現状

ということで、この問題を解決すべくフローを再考・再構成しました。 今はこのようなフローで行っています。