読者です 読者をやめる 読者になる 読者になる

CIでの確認項目

こんにちは、Misoca開発チームのmzpです。 GWは日光に遊びにいっていました。

MisocaではJenkinsを利用してCIによる自動テストを行なっています。最初はrspecを実行するだけのシンプルなものでしたが、都度設定を追加し、様々な項目をCIで確認するようになっていきました。

今日はそのCIで確認している項目について紹介したいと思います。

f:id:mzp:20160512140254p:plain

確認している項目

静的解析

コーディングスタイルのぶれや脆弱なコードを書かないようにするために、各種静的解析ツール(RubocopHAML-LintBrakeman)を導入し、警告がでないことを確認しています。

導入した直後は違反箇所の一覧を作成するのみで、ジョブの成否とは無関係でした。しかし、だんだんと違反箇所の修正をしなくなってしまったので、今は違反箇所がある場合はジョブが失敗する設定にしています。

rspec

全specの実行はrspec-queueで並列化した上で、実行します。

以前は失敗したspecがある場合でも全specを完走させていました。

しかし、開発メンバーの増加にともないビルドキューがつまり気味になってしまいました。そこで、 --fail-fast オプションをつけ、失敗したspecがある場合は以降のspecを実施しないようにしました。

また並列度は何度か調整をおこない、ほどよい数に制限しています。

デプロイできるかの確認(masterブランチのみ)

masterブランチのみですが、開発環境では実行することがほぼないデプロイ用のコマンドの確認を行なっています。

具体的には以下のコマンドが失敗しないことを確認しています。

  • RAILS_ENV=production bundle exec rake db:create db:migrate db:seed
  • RAILS_ENV=production bundle exec rake assets:precompile

何度かCIは通ったがデプロイしようとしたら失敗したということが発生したので、このようにしています。

その他: 夜間ビルド

CI で稀に失敗してしまうテストへの対処方法 - クックパッド開発者ブログにあるallnightジョブを参考に、夜間にmasterブランチにあるspecを繰り替えし実行しています。

これは「たまに失敗するspecがあるが、ビルドボタンを連打したらCIを通った」ということがしばらく続いたので、失敗するspecを洗いだすために実施しています。

洗いだしたspecは、適宜失敗する原因を突き止めて修正しています。ただ、外部サービスと通信するspec等があるため、なかなか全部成功にはできていません。

結果は毎朝Slackに通知されるようになっています。

f:id:mzp:20160512122705p:plain