こんにちは！株式会社OPTiMに所属しております川田剣士です。最近の業務でciパイプラインを見直したことによって、テスト環境へのデプロイにかかる時間を10分近く短縮することに成功しまして、こちらの経験を皆さんにも共有したく技術執筆をしようと思いました。記事に対する質問・コメント大歓迎です！

目次

タスクを取り組むに至った背景
採用した解決方法
終わりに

タスクを取り組むに至った背景

元々、ciパイプラインは以下のような戦略を取っていました。

MergeRequest作成時
- checkstyleのvalidationを自動実行(code-validate job)
- 全テストを自動実行(test job)
- coverageの測定を自動実行(coverage job)
MergeRequestをdevelopブランチにmergeする時
- test stage
  - checkstyleのvalidationを自動実行(code-validate job)
  - 全テストを自動実行(test job)
  - coverageの測定を自動実行(coverage job)
- build stage
  - docker imageの作成を自動実行。このjobで作成されるdocker imageのtagをtest用のhelmfileに指定することでテスト環境へのデプロイを行う。(docker-build job)
- test stageのjobが全て完了してから,build stageのjobが実行される。

上記の戦略だとテスト環境へデプロイするためにはtest stageのjobが全て終わり、その後実行されるdocker-build jobが完了するを待つ必要があります。そのため、以下のような課題が存在していました。

普段のテスト環境へのデプロイ作業に時間がかかる。
テスト環境でエラーが発生した時のエラー解決の仮説検証のサイクルが遅い。

この問題を解決することでチーム全体のテスト環境へのデプロイ作業の効率化を目指しました。

採用した解決方法

私が採用した解決方法を以下に記載します。

MergeRequest作成時のciパイプラインは変更しない。
MergeRequestをdevelopブランチにmergeする時のciパイプラインに関して、test stageとbuild stageを1つのstage(build_and_test stage)に統一させた。
build_and_test stage内の全てのjobを並列実行させた。(ciパイプラインで利用しているサーバーは高性能であるため、並列実行は問題なく可能)

上記の戦略を取ることで、test stageのjobが全て完了するのを待つことなく、docker-build jobが完了した時点でテスト環境へのデプロイができるようになりました。しかし、この戦略を取ることのデメリットはcode-validate jobやtest jobが落ちた状態でテスト環境にデプロイされる可能性があるということです。ただし、MergeRequest作成時にcode-validate jobやtest jobが成功し、かつMergeRequestをdevelopブランチにmergeする時にcode-validate jobやtest jobが失敗する頻度自体はかなり低いです。また、仮にcode-validate jobやtest jobが失敗した状態でテスト環境にデプロイしたとしても、デプロイ対象はテスト環境であるため、後からjobが落ちた原因を治し再度デプロイすれば問題ないと判断しました。このような戦略は本番環境へのデプロイなどではできませんが、テスト環境のように失敗しても許される環境だからこそ取れる戦略です。

上記の案を開発チーム全体に共有し、合意が取れたため採用することとなりました。
test stageのjobは全て完了するのに10分ほどかかっており、テスト環境へのデプロイ作業は1週間で平均数十回はあるため、今回のパイプライン戦略でデプロイ作業の効率化に大きく貢献できたかなと思います。

終わりに

最後まで読んでいただき、ありがとうございます！