こちらは 「SEROKUを支える技術〜CI/CD編〜」からの転載です。
本記事では SEROKU の開発を例に社内で採用している CI/CD の実現手法を紹介しています。
「SEROKUフリーランス」を支える技術シリーズ。今回は SEROKU フリーランスで行っているCI/CDについてご紹介します。
CI/CD とは?
CI/CD とは、 Continuous Integration/Continuous Delivery (継続的インテグレーション/継続的デリバリー)を示す言葉で、ソフトウェア開発におけるプラクティスの一種です。
比較的わかりやすい説明が AWS の DevOps サイトに掲載されていましたので、詳しい説明はそちらに譲ろうと思います。
https://aws.amazon.com/jp/devops/continuous-integration
https://aws.amazon.com/jp/devops/continuous-delivery
SEROKU フリーランスはどのようなCI/CDを行っているか
SEROKU フリーランスでは CI/CD ツールに Jenkins を使用しています。他の CI ツールも検討しましたが、社内の多くの他のプロダクトでも CI/CD ツールに Jenkins を採用しており、社内でも扱いに慣れているエンジニアが多数いることから、今回も Jenkins を採用しました。
従来のプロダクトでの CI/CD の一例
SEROKU フリーランス以前のプロダクト群では、Jenkins で以下のような CI/CD を行っていました。
-
git などの repository の default branch に code がマージされたら下記の CI/CD を実施
-
code の build 実施
- 開発したcodeを実環境で動かすために compile, transpile, bundle, ライブラリのインストールなどを行う
-
Test 実施
- 開発した code が意図した動作を行うか、自動化された unit test, e2e test を行う
-
上記に問題が無ければ、default branch の code を検証環境に deploy
- Web ブラウザで検証環境にアクセスして未リリースのプロダクトを先行利用することで、本番環境にリリースする前にプロダクトの動作を確認することができる
-
SEROKU フリーランスでの CI/CD
しかし SEROKU フリーランスでは上記をより発展させ、次のような CI/CD を行っています。
-
git などの repository の あらゆる branch に code が commit されたら、その branch ごとに下記の CI/CD を実施
- code の build 実施
- Test 実施
- 上記に問題がなければ、docker image を build して docker registory に登録
- default branch であれば build した docker image を検証環境に deploy
従来のプロダクトでの CI/CD と SEROKU フリーランスでの CI/CD では大きく2点の変更があります。
一つは従来では default branch のみ CI/CD 対象にしていたのを SEROKU フリーランスでは全 branch を CI/CD 対象にするようになった点です。これには Jenkins2 系から導入された multibranch pipline1 という機能を使用しています。
もう一つは docker image の build と docker registory が増えている点です。これは本番のプロダクト環境で Kubernetes を採用しているため、リリースを行うには開発した code は docker image 化されている必要があるからです。
また、「SEROKUフリーランス」を支える技術〜社内 Kubernetes 編〜 で触れた、「トピックブランチのデモを簡単に作れるといいなぁ」という要望をかなえるために構築した環境も Kubernetes を採用しているため、やはり docker image 化する必要があります。そのため、全ての branch で docker image を build しています。
改善された CI/CD の効果
上記の通り、SEROKU フリーランスでの CI/CD を従来型に比べて発展させた結果、以下のような恩恵を受けられています。
default branch にマージする前に test, lint 結果が正常か確実に確認できるようになった
以前は default branch のみ CI 対象にしていたため、default branch へ merge する前にコードレビューを行う際に、レビュアーは事前にテスト結果を知るために自身の開発環境で test を走らせるか、コード実装者に test 結果を共有してもらう必要がありました。一応、社内ルールでは実装者は test に通過することを確認した後にコードレビューを依頼するという決まりがあります。
しかし、希にルール通りの手順を踏まずにレビューを依頼してしまうことがあり、レビュアーも test を走らせたか素早く確認する術がなかったため、いざ default branch に merge したら実は test に失敗してしまう状態だった、ということが発生していました。
しかし multibranch pipeline により全ての branch で CI できるようになったので、実装者、レビュアーともに CI のステータスを素早く認識することができるようになり、前述のようなトラブルが減少しました。
CI/CD の動作が code 化されて管理できるようになった
multibranch pipeline 化以前の CI/CD では、CI/CD を行うためのコマンドやその実行順番は Jenkins 側で管理していました。そのためコマンドの実行順序変更などの履歴は Jenkins 側に記録される様になっており、開発コードとの管理の分離が発生していました。
これにより、例えば開発コード側の仕様変更に伴い CI のコマンドが変更されたとしても、開発コードの変更と CI コマンドの変更は別々システムで履歴管理がされるため、しばらく経過した後に当時の経緯を追跡しようとすると開発コードと Jenkins の CI コマンド変更履歴を両方確認し、突合させる必要があったりと難しい対応をする必要がありました。
multibranch pipelineでは、Jenkins での CI/CD のコマンドや手順は Jenkinsfile という file に記述し、開発コードの repository に内包する形を取ります。従って CI/CD のコマンドも開発コードと同一 repository で管理できるようになり、以前より管理が楽になりました。
リリース頻度の増加
multibranch pipeline による全 branch に対する CI/CD と 「SEROKUフリーランス」を支える技術〜社内 Kubernetes 編〜 で触れた、トピックブランチのデモでの動作確認が実現できたことにより、CD の目的である「どのようなタイミングでも default branch のコードはリリースできる状態である」が達成できるようになりました。
そのため、リリースがどのようなタイミングでも実施できるようになり、以前のプロダクトよりリリースを頻繁に行えるようになりました。SEROKU フリーランスでは週に1回以上のリリースを定常的に行っている実績があります。
今後の展望
現状では、トピックブランチごとのデモ環境に関しては、docker image を自動で立ち上げるところまで実施していません。なのでトピックブランチデモを立ち上げたい人が手動で社内 Kubernetes に環境を立ち上げる必要があります。(ただし manifest のテンプレートはあるので、文字列置換をすればすぐ立ち上がる状況です)
今後は、トピックブランチデモ環境も自動で立ち上がるようにしていきたいと考えています。すでに社内で新しく立ち上げた別の新プロジェクトでは実現済みですので、それを SEROKU フリーランスの CI/CD 環境にも導入するすることになるでしょう。
まとめ
いかがでしたか？CI/CD を適切に整備することで、開発環境や品質の向上が期待できるだけでなく、素早くリリースすることで最終的にユーザーの利益にもつながります。今回紹介した内容が、皆さんのプロジェクトの改善などに参考になれば幸いです。
