CICD構築全体像　DevOpsの最初の一歩でやる事とは

## はじめに
DevOpsだ！などをきっかけにCICD導入を検討する事があるかと思うが、

- 何から手を付ければいいのか？
- 何を決めればいいのか？

などが漠然としていて分からない…という事は多いように思う。
そこでCICD導入を進めるにあたり迷子にならないようにするため、その全体像や決める事などを整理してみたい。

## CICDの全体像
まずCICDの全体像を図示すると以下のような感じになる。
![CICD全体像.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1372684/b313fb2e-c5d5-07f5-e2e6-4d829a290e40.png)
基本的なCICDの構成は上記のようになる事が多いと思うが、これを見ただけでは何から手を付ければいいか？何を決めればいいのか？は分からず実際にCICD導入を進めていくのは難しいように思われる。
そこで続いて`何を決めればいいのか？`という観点で検討事項となる事を一覧化してみる。

## 何を決める必要があるか？　～CICD導入の検討事項一覧～
CICD導入をするにあたっての全体像は[上記](#cicdの全体像)通りだが、CICD導入を実際に行う際には以下のような検討事項（決めなければならない事）がある。

- CICDのベースとなる部分を構築するために必要な検討事項
- CICDをより高度化して追加オプションを導入するために必要な検討事項

以下で触れる各検討事項をCICDの全体像の中に当てはめ、どの検討事項が何に関係しているのかを可視化すると以下の図のような感じになる。
![CICD全体像と検討事項の関係性.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1372684/1083f007-59c6-e7c8-82c0-c309eea351c4.png)

### CICDのベースとなる部分を構築するために必要な検討事項
これは最低限のCICDを導入する際に必要な検討事項で、これらがないとCICDの本領を発揮させるための追加的なオプションの導入などが難しくなる。まずはこれらの検討から始めるのがCICD導入の基本的なアプローチである。
※さらにsmall startでCIだけを導入すると言う場合は、以下から「デプロイの仕組み」が不要になるイメージ。

| VCS | CICD基盤（パイプライン）|
|---|---|
| ・ブランチ戦略<br>・VCSツール | ・CICDツール<br>・パッケージ(構成)管理ツール・ビルドツール<br>・デプロイの仕組み |

### CICDをより高度化して追加オプションを導入するために必要な検討事項
以下の内容は、上記の検討に基づいてベースとなる基本的なCICDを導入した後に、さらにCICDによるメリットを引き出すためのオプションを導入する際の検討事項。DevOpsを目指すのであればここは外せない部分になる。

| 静的解析 | Unitテスト / APIテスト / E2Eテスト |
|---|---|
| ・静的解析ツール<br>・静的解析のルール・コーディング規約 | ・各テストのためのツール・フレームワーク<br>・テスト対象（テスト戦略）<br>・テスト結果の解釈方法 |

## CICD導入の検討事項の詳細
### ブランチ戦略
ブランチモデルとしては、

- Git-flow
- GitHub-flow
- GitLab-flow

などあるがこれらのナレッジを利用しつつ、開発のスタイルに合わせてカスタマイズしてその開発に合ったブランチ戦略を決定する必要がある。
ここをきちんと検討しておかないと、

- ブランチモデルをそのまま使ったがブランチ運用時に無駄な操作が発生し開発が思うように進まない
- 作業ミスによりブランチが壊れる

といったトラブルが後々起きてしまい、CICDどころではなくなってしまう。

### VCSツール
基本的な機能は同じようなものだが、検討時に判断軸になりそうな部分としては

- 色々な操作の権限関係の設定ができるか？（pushの制限、マージ制限、タグ付け、承認機能など）
- 構築する環境は選べるか？（オンプレ・クラウド）
- 導入はしやすいか？（学習コスト・必要スキル、ドキュメントの豊富さ）

といった部分なるだろう。
代表的なVCSツールとしては以下。

| 名前 | URL |
|---|---|
| GitHub | https://github.co.jp/ |
| GitLab | https://about.gitlab.com/ |
| Bitbucket | https://bitbucket.org/ |
| AWS CodeCommit | https://aws.amazon.com/jp/codecommit/ |

### CICDツール
VCSと違ってツールによる差はほぼないので諸事情やVCSツールとの兼ね合い[^1]などで選定する事になる。
[^1]: AWS上で全て（ソースコードなど）を管理しているのでAWS環境がいいのでAWS CodePipelineにする、といった感じ。

代表的なCICDツールとしては以下。

| 名前 | URL |
|---|---|
| GitHub Actions | https://github.co.jp/features/actions |
| GitLab CI/CD | https://gitlab-docs.creationline.com/ee/ci/README.html |
| circleci | https://circleci.com/ |
| AWS CodePipeline | https://aws.amazon.com/jp/codepipeline/ |

### パッケージ(構成)管理ツール・ビルドツール
ソースコードのbuild、自動テストにも関わってくる部分だが、パッケージ管理を導入しているだけでCICDがかなり楽になるというか、これなしにCICDは不可能と言って過言ではないので、各言語に合わせたパッケージ管理ツールを選定する。以下はその一例。

| 言語 | 主な選択肢 |
|:-:|:-:|
| Java | Maven<br>Gradle |
| Python | Pipenv |
| JavaScripts | npm<br>yarn |

※パッケージ管理ツールを導入していると設定をしておけば、

- コマンド1つで環境構築が簡単にできる（ex `npm ci`）
- コマンド1つでUnitテストやE2Eテストが実行できる（ex `npm run test`）

といったメリットを享受できる。

### デプロイの仕組み
デプロイと一口に言っても、

- スクリプト言語だから単純に`git pull`がデプロイ
- コンテナを使っておりそこにデプロイ
- AWS Lambdaへのデプロイ
- dev？、stg？、prod？

など環境や構成によってデプロイのやり方が違ってくる。まず手動でやっていたデプロイを精査し、デプロイのツールがあるか？なども調査を行う[^2]。その上でどのようなフローでデプロイを行うかを決定する。
[^2]: AWS Lambdaであればsumなど。昔からやっている既存のフローを自動化するのではなく、新しく出てきた手法などをキャッチアップしやり方を更新する。