はじめに
初めまして、tomo37kunです。
業務に携わる中でCI/CDの存在を意識することが多くなったので、CI/CDについて正しい知識と理解を得られるように学習を行いました。また、近年、自動化の重要性の高まりやアジャイル開発の浸透進化といった背景から、実際にCI/CDに対する需要は急速に高まっています。
本記事のCI/CDの学習内容のアウトプットにより、CI/CDについて全く知識がない人でも体系的に理解できる足掛かりになれば幸いです。
CI/CDとは
まずはそれぞれの単語の意味からです。
CI
CIとは「Continuous Integration」の略で、「継続的インテグレーション」と訳されています。
「インテグレーション」には「統合」の意味があります。
ソフトウェア開発の場合、「統合」の対象は一連の作業（各種作業やテストなど）です。
これでソフトウェアの動作を「継続的」に確認でき、より正確により迅速に開発を進めることが可能になります。
CD
CD とは「Continuous Delivery」の略で、「継続的デリバリー」と訳されています。
一般的に「デリバリー」とは何かを届けることですが、この場合は「配信」や「公開」の意味で使われています。
「配信」するものは、開発テスト中のソフトウェア自体です。
なお「Delivery」と同じ頭文字で「Deployment」という用語も、「Continuous Deployment」（継続的デプロイメント）として使われています。
一般的に「デプロイメント」とは「配置」することですが、この場合は何らかのサービスを利用者が使える状態にすることです。
つまりCI/CDとは
CI/CDは1つの技術を表すものではありません。
作業から継続的インテグレーション（CI）および継続的デリバリー・デプロイ（CD）までを、自動化しておくことで、より効率良く迅速で、継続的に実施できるソフトウェア開発の手法のことです。
CI/CDを取り入れることで、バグを素早く発見することができたり、変更を自動でリリースすることができるようになります。
CI/CDのタイプ
CI/CDには大きく分けてオンプレミス型とクラウド型があります。
オンプレミス型としてはJenkins、クラウド型としてはTravis CIやCircleCIなどが有名です。
オンプレミス型は一般的に拡張性が高い一方、自分たちで構築・運用する管理コストが発生します。
クラウド型は拡張性が低いですが、サーバーなどを自前で用意する必要がなく、すぐに使い始めることができるのが大きな魅力です。
オンプレミス型
- Jenkins
- Concoures CI
- Drone（クラウド型もあり）
クラウド型
クラウド型のCI/CDサービスである「Circle CI」の無料枠には以下の特性があるため個人開発や試し使いには十分と言えるので興味を持たれた方は試してみるとよいでしょう。
- １コンテナのみ（したがって、同時実行ジョブは１つのみ）
- １か月あたり1000分のビルド時間まで
- リポジトリ数の制限なし
- ユーザ数の制限なし
CI/CDが注目されるようになった理由
CI/CDが注目されるようになった理由としては２つのことが挙げられます。
- 自動化テストの重要性の高まり
- アジャイル開発の浸透と進化
自動化テストの重要性の高まり
あらゆる作業がコンピュータに置き換わっている現在、ソフトウェアを使用していない企業や組織はほとんどいないと言っても過言ではないと思われます。
このソフトウェアの普及に伴って、求められる品質も必然的に高くなり、これまで手動で行われていたテストも自動化されるのは当然の流れといえます。
CI/CDを使うと、コードの変更が発生するたびに自動でテストが行われるので、テストの実行忘れや、環境依存のテストを失くすことによる品質向上が狙えます。
ここまでの説明だけだと、CI/CDサービスやCI/CDのツールが自動でテストを作成してくれるように思えるかもしれませんが、そういうわけではありません。
あくまで、実行するテストは自分たちで定義する必要があり、CI/CDは定義したテストを任意のタイミングで実行してくれるだけのものになります。
アジャイル開発の浸透と進化
アジャイル開発の浸透と進化もCI/CDの普及を推し進めました。
アジャイル開発とは小さな変更を積み上げるように加えていくことで、プロダクトを少しずつ開発していく手法のことです。
この手法が実際の開発現場で有効なことが分かり、現在は多くのチームがアジャイル開発をするようになっています。
アジャイル開発で最も重要とされていることはスピードです。
より小さな粒度の変更をいかに早くテスト／リリースしてフィードバックを得るかがアジャイル開発の成功の鍵となりますが、CI/CDを使うことがこれらの実現にマッチしているため、CI/CDの普及につながりました。
そして、近年アジャイル開発そのものも進化しています。
DockerやKubernetesのコンテナ技術とAWSやGCPなどのクラウド技術が進歩したおかげで、本番環境にコードをデプロイすることは驚くほど簡単になりました。
テストをパスした変更を常にリリースして、バグがあればロールバックを行う。
このような作業はもちろん手動でもできますが、CI/CDで自動化することでより効率的にできるようになります。
まとめると、CI/CDを使うとテスト自動化することで品質を高めるだけではなく、その後のリリース作業も自動化することで、よりアジャイルな開発ができるようになるということです。
自動化できるタスク
CI/CDの本質は自動化にあります。
今まで手動で行っていた作業を自動化することにより開発者は別のタスクに時間を割くことができるようになります。
ここではCI/CDによって自動化できる以下のものについて紹介します。
1. テスト実行の自動化
2. リリースの自動化
3. その他の作業の自動化
テスト実行の自動化
最近のCI/CDサービスやツールはGitHubなどのVCS（バージョン管理システム）サービスと連携しています。
そのため、開発者が変更を加えるたびに、CI/CDが自動でテストを実行してくれます。
また連携するCI/CD上ですべてのテストをパスしないと変更をメインのブランチにマージできないような機能もあります。
これを活用すればテストが失敗したとき、その変更点を作成した開発者に修正を強制できるので、プログラムにおいて、直したはずのバグが復活していたり、前はなかったはずのバグがあったり、実装したはずの機能がなくなっている状態が生まれることを防ぎやすくなります。
リリースの自動化
一般的にリリース作業は運用チームや開発者が手動で行うものだと思われます。
しかし、このリリースを自動化することにより、工数の削減だけでなく、ヒューマンエラーを失くすことも可能です。
リリースの自動化にはいくつかのステージがあり、実際のデプロイは手動で行うケースもあれば、CI/CDで一気にデプロイまでするケースもあります。
どちらのケースがいいかは組織やプロダクトの性質ごとに異なるため、一概には言えません。
しかし、デプロイの自動化を行うことで次のようメリットを受けられます。
- バグの迅速な修正
- リスクマネージメント（詳しくは後述）
- 変更に対するフィードバックを素早く得る（詳しくは後述）
継続的インティグレーションにより、ある変更がテストに通らなかった場合、その変更に問題があったことが瞬時に分かるようになります。
言い返せば、テストをすべてパスした変更はリリースしても安全だということが分かります。
この時注意したいのは、すべてのシナリオに対してテストがあるわけではないですし、仕様バグなどはCI/CDを使っても取り除くことはできません。
その他の作業の自動化
コードのコンパイル、静的解析、依存関係のアップデートはもちろん、CI/CDを使うことで、さまざまなことを自動化できます。
最近のCI/CDサービスやツールはとても柔軟に作られているので、ほとんどの作業をCI/CD上で自動化できます。
※ハードウェアに依存する作業などはCI/CDサービスによってはできない場合もあります。
そのため、自動化したいタスクを思いついたときは、まずCI/CDを使えないか検討してみるとよいと思われます。
CI/CDが走るタイミングは以下の通りです。
CI
- pull-request作成した時
- pull-request作成以降にpushした時
- 定期実行時(cron)
CD
- mergeした時
- ブランチによってデプロイ先を変えられる（masterブランチへmergeされたら本番環境、developブランチへmergeされたら検証環境など）
- 定期実行時(cron)
デプロイの自動化によるメリット
リスクマネージメント
変更Aと変更Bを個別にリリースする場合とAとBの変更をまとめた変更Cをリリースする場合を考えます。
リリースによって問題が発覚した場合、AとBは別に作業を行っているため、「変更Aに問題はなく変更Bに問題があったので、Bのみ対応を行った」というようにそれぞれ個別に対応することが可能です。
一方、変更CはAとBのどちらに問題が潜んでいるかの切り分けが複雑になってしまう可能性ある他、変更範囲が大きいためロールバックが容易にできない場合があります。
このようにリスクマネージメントの観点ではAとBを別々にリリースするべきであることが賢明といえます。
CI/CDによる継続的デプロイはこのリスクマネージメントを可能とします。
継続的デプロイができるということは、変更のロールバックも簡単にできるということであり、問題があった変更点を取り消して再度デプロイをすれば、ロールバックしたことになるからです。
上述のリスクマネージメントの考えに乗っ取ると重要なのはロールバックできる単位を小さくすることであると言えます。
継続的デプロイを用いることでこのロールバックできる単位を刻むことができるのです。
また、ロールバックによる保険があるため、開発者はより挑戦的にコードを書くことができ、開発者の仕事は劇的にやりやすくなることが見込めます。
デプロイの自動化によって変更の粒度を小さくしてバグのリスクを下げることができれば、バグを恐れる必要はありません。
フィードバックを素早く得る
ユーザが本当に求めるプロダクトを効率的に開発するには
1. 実用最低限の機能を作る
2. リリースする
3. フィードバックを得る
上記のループを素早く繰り返すことが大切です。
ユーザにとって価値があるかどうかわからない時でも本番環境でテストすることにより、フィードバックを素早く得られます。
「本番環境でテスト」という言葉に身のすくむ思いを抱かれるかもしれませんが、検証段階で必要かどうかを議論するよりも、本番環境で1度リリースし、フィードバックを集めてしまったほうが効率的な場合もあります。
そして、万が一不要な変更だったとしても継続的デプロイにより簡単にロールバックができるのです。
そのため、継続デプロイを使うことで本番環境からより早くフィードバックを得ることができるようになるのです。
まとめ
CI/CDを使うことでさまざまな作業を自動化できるだけではなく、デプロイとロールバックを自動化することでより効率的なプロダクト開発ができるようになります。
また、人力で行うテストとは異なり、人間に起因するミスが起きず、品質が担保されるというメリットもあります。
品質を落とさずに、高速な開発、リリースというサイクルを回すためには必須と言えます。
記事の途中でも触れましたがクラウド型のCI/CDサービスである「Circle CI」では無料枠があり、個人レベルの使用であれば十分に利用できるので、興味を持たれた方はお試しください。
参考資料
- 【図解】CI/CD とは？非エンジニアの方向けにわかりやすく解説します | カゴヤのサーバー研究室
- CI/CDのエキスパートが解説：CI/CDとは何か？ なぜ今、必要とされるのか？ (1/3)：CodeZine（コードジン）
- いまさらだけどCircleCIに入門したので分かりやすくまとめてみた - Qiita
- CI/CDとは | ニフクラ
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
