SEROKUを支える技術〜CI/CD編〜

「SEROKUフリーランス」を支える技術シリーズ。今回はSEROKUフリーランスで行っているCI/CDについてご紹介します。

CI/CDとは?

CI/CDとは、 Continuous Integration/Continuous Delivery (継続的インテグレーション/継続的デリバリー)を示す言葉で、ソフトウェア開発におけるプラクティスの一種です。

比較的わかりやすい説明がAWSのDevOpsサイトに掲載されていましたので、詳しい説明はそちらに譲ろうと思います。

継続的インテグレーションとは?

継続的デリバリーとは?

[adinserter block="1"]

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を実施
  1. codeのbuild実施
     • 開発したcodeを実環境で動かすために compile, transpile, bundle, ライブラリのインストールなどを行う
  2. test実施
     • 開発したcodeが意図した動作を行うか、自動化されたunit test, e2e testを行う
  3. 上記に問題が無ければ、default branchのcodeを検証環境にdeploy
     • Webブラウザで検証環境にアクセスして未リリースのプロダクトを先行利用することで、本番環境にリリースする前にプロダクトの動作を確認することができる

[adinserter block="1"]

SEROKUフリーランスでのCI/CD

しかしSEROKUフリーランスでは上記をより発展させ、次のようなCI/CDを行っています。

• gitなどのrepositoryの
  あらゆるbranchにcodeがcommitされたら、そのbranchごとに下記のCI/CDを実施
  1. codeのbuild実施
  2. test実施
  3. 上記に問題がなければ、docker imageをbuildしてdocker registoryに登録
  4. default branchであればbuildしたdocker imageを検証環境にdeploy

従来のプロダクトでのCI/CDとSEROKUフリーランスでのCI/CDでは大きく2点の変更があります。

一つは従来ではdefault branchのみCI/CD対象にしていたのをSEROKUフリーランスでは全branchをCI/CD対象にするようになった点です。これにはJenkins2系から導入された multibranch pipline という機能を使用しています。

もう一つはdocker imageのbuildとdocker registoryが増えている点です。これは本番のプロダクト環境でkubernetesを採用しているため、リリースを行うには開発したcodeはdocker image化されている必要があるからです。また、「SEROKUフリーランス」を支える技術〜社内 Kubernetes 編〜 で触れた、「トピックブランチのデモを簡単に作れるといいなぁ」という要望をかなえるために構築した環境もkubernetesを採用しているため、やはりdocker image化する必要があります。そのため、全てのbranchでdocker imageをbuildしています。

[adinserter block="1"]

改善された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回以上のリリースを定常的に行っている実績があります。

[adinserter block="1"]

今後の展望

現状では、トピックブランチごとのデモ環境に関しては、docker imageを自動で立ち上がるところまで実施していません。なのでトピックブランチデモを立ち上げたい人が手動でk8sに環境を立ち上げる必要があります。(ただしmanifestのテンプレートはあるので、文字列置換すればすぐ立ち上がる状況です)

今後は、トピックブランチデモ環境も自動で立ち上がるようにしていきたいと考えています。すでに社内で新しく立ち上げた別の新プロジェクトでは実現済みですので、それをSEROKUフリーランスのCI/CD環境にも導入するすることになるでしょう。

[adinserter block="1"]

まとめ

いかがでしたか？CI/CDを適切に整備することで、開発環境や品質の向上が期待できるだけでなく、素早くリリースすることで最終的にユーザーの利益にもつながります。今回紹介した内容が、皆さんのプロジェクトの改善などに参考になれば幸いです。

 

＞SEROKUを支える技術 ～開発準備編～
＞SEROKUを支える技術～プロジェクト管理編～
＞SEROKUを支える技術～社内 Kubernetes 編～
＞SEROKUを支える技術～CI/CD編～
＞SEROKUを支える技術～社内 Kubernetes トラブルシュート前編～
＞SEROKUを支える技術 Angular Tips編 その1
＞SEROKUを支える技術 Angular Tips編 その2
＞SEROKUを支える技術 Angular Tips編 その3