今さら聞けないCI/CD（継続的インテグレーション/継続的デリバリー）とは

# はじめに
ここ数年で一般的になってきたソフトウェア開発のプロセスである「**CI/CD**」ですが、なんとなく知ってはいるけどちゃんと理解しているわけではない・・・という方もいるかと思います。
今回はCI/CDの特徴と、その重要性についてわかりやすく説明したいと思います。

# CI/CDとは
CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称です。
CI/CDは、ソフトウェアのマージからリリースまでの自動化された一連のプロセスを指します。

今までの開発では変更のマージやビルド、テスト、デプロイとリリースを手動でやっていました。
それらを自動化することで、ソフトウェア開発が効率化され、品質が上がり、リリース速度の向上を期待できます。

:::note warn
**マージをCIの範囲に含めるか**
変更のマージはバージョン管理システム（リポジトリ）自体の機能であり、CIの対象から除外する考え方もありますが、今回はマージ処理も自動化された継続的インテグレーションの一部として説明します。
:::
## CI（継続的インテグレーション）とは
CI（継続的インテグレーション）は、変更のマージ、ビルド、およびテストを自動化することを指します。
自動化されたビルドとテストにより、開発者は手動での作業やテストの重複を省くことができ、効率的な開発プロセスを実現します。
具体的な手順としては、開発者がコードをリポジトリにコミットすると変更がマージされ、CIサーバー（もしくはCIのクラウドサービス）が自動的にビルドを実行し、コンパイルエラーやビルドの問題を検出します。
その後、自動化されたテストスイート（テストの目的や対象ごとに複数のテストケースをまとめたもの）が実行され、テストの結果がレポートされます。

## CD（継続的デリバリー）とは
CD（継続的デリバリー）は、CIを含む概念であり、変更のマージからリリースまでを自動化することを指します。

まず、開発者がコミットしたコードが自動的にマージ、ビルド、テストされ、リリースの準備ができた状態に保たれます。
そして、人による操作をトリガーとして自動的にデプロイとリリースが行われます。

:::note warn
**継続的デリバリーと継続的デプロイメント**
一般的にCI/CDのCDは継続的デリバリーのことを指しますが、CDは継続的デリバリーと継続的デプロイメントの両方を表す言葉として使われています。

継続的デリバリーではデプロイとリリースのトリガーは手動ですが、継続的デプロイメントでは手動によるトリガーを必要とせず、自動的に本番環境にリリースされます。 
:::

## CI/CDのイメージ
図にするとこうなります。CDはCIを含んだ概念です。

![CICD_____.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1203022/5f5cd89d-1f5b-ced8-4493-6938609c65b3.png)

※参考までに
下記図のように、CDをデプロイとリリースだけに絞って説明しているサイトもあります。
どちらかが間違いということではなく、CIはマージ～テストまでに重きを置いた概念で、CDはデプロイ～リリースに重きを置いた概念であることには変わはありません。

![CICD___.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1203022/f1f4984b-bd19-798b-089c-e4a347ad583a.png)


:::note info
**この章のまとめ**
CI（継続的インテグレーション）は、変更のマージ、ビルド、およびテストを自動化すること。
CD（継続的デリバリー）は、CIで行う変更のマージ、ビルド、およびテストに追加してデプロイとリリースを自動化すること。

CDは人の操作をトリガーとしてデプロイとリリースが行われる。

ややこしいことに、CDは継続的デリバリーと継続的デプロイメントの両方を表す言葉。
:::


# CI/CDのメリット
CI/CDのメリットを紹介します。
デメリットはコストがかかることと、テストとリリースを行う頻度が少ないシステムの場合にメリットを享受できないことくらいなので、今回はメリットのみ説明します。
もし、実際にCI/CDを導入してデメリットを感じた方がいらっしゃったらコメントで教えてください。

## 作業の簡素化
今まで手動で行っていた作業が自動化されることで、アプリケーションを作成してからリリースするまでの作業が圧倒的に簡素化されます。

## ヒューマンエラーの減少
通常コード変更時のマージ、ビルド、テスト、デプロイ、リリースには様々な手順が存在します。
手順が多い分、ヒューマンエラー（人間が思い違いや確認不足によって起こすミスや事故）が発生する可能性が常にありました。
CI/CDを導入することで、そもそも手作業が減るため、ヒューマンエラーが減少します。

## リリース速度の向上
以前までのリリース作業は手順も多く、手順の確認として事前にリリースのリハーサルを行うこともあるほどでした。
CI/CDを導入することで、変更したコードのコミットによって自動的にビルド、テスト、デプロイされるため、リリースまでの時間が大幅に短縮されます。

## バグの早期発見
コミットのたびにテストが実行されるため、バグを早期に発見して対処できます。
通常、後工程になればなるほど手戻りが大きくなり、バグの影響は大きくなります。

:::note info
**この章のまとめ**
CI/CDを導入することで、作業が簡素化されてリリース速度の向上やヒューマンエラーの減少が見込める。
コミットのたびにテストが実行されるため、バグの早期発見も期待できる。
:::

# 代表的なCI/CDツール
様々な会社がCI/CDツール（サービス）を提供しています。

## オンプレミス型のCI/CDツール
+ Jenkins
+ Concourse CI
+ Drone

## クラウド型のCI/CDツール
+ GitLab
+ Travis CI
+ CircleCI
+ Wercker
+ AWS CodeBuild
+ Azure Pipelines
+ GCP Cloud Build

# さいごに
アジャイル開発の台頭とともに、ソフトウェア開発の世界はますます迅速さと効率性を求められるようになりました。
その中で、CI/CDは現代の開発プロセスにおいて重要な役割を果たしています。

:::note info
**最近よく聞くけど今さら聞けない技術用語**について、いくつか記事を書いています。
良かったらそちらもご覧ください。
:::
https://qiita.com/shinkai_/items/efe653174e8dc1bcd625

https://qiita.com/shinkai_/items/0fd5d72b6a584c16a8ec

https://qiita.com/shinkai_/items/79e539b614ac52e48ca4

https://qiita.com/shinkai_/items/4dcd8742cc524ceaa3a2

https://qiita.com/shinkai_/items/486f8b75d5904752842e

# 参考
[AWS - 継続的デリバリーとは?](https://aws.amazon.com/jp/devops/continuous-delivery/)