5
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Last updated at Posted at 2021-05-06

はじめに

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

  • 何から手を付ければいいのか?
  • 何を決めればいいのか?

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

CICDの全体像

まずCICDの全体像を図示すると以下のような感じになる。
CICD全体像.png
基本的なCICDの構成は上記のようになる事が多いと思うが、これを見ただけでは何から手を付ければいいか?何を決めればいいのか?は分からず実際にCICD導入を進めていくのは難しいように思われる。
そこで続いて何を決めればいいのか?という観点で検討事項となる事を一覧化してみる。

何を決める必要があるか? ~CICD導入の検討事項一覧~

CICD導入をするにあたっての全体像は上記通りだが、CICD導入を実際に行う際には以下のような検討事項(決めなければならない事)がある。

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

以下で触れる各検討事項をCICDの全体像の中に当てはめ、どの検討事項が何に関係しているのかを可視化すると以下の図のような感じになる。
CICD全体像と検討事項の関係性.png

CICDのベースとなる部分を構築するために必要な検討事項

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

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

CICDをより高度化して追加オプションを導入するために必要な検討事項

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

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

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などで選定する事になる。

代表的な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
Gradle
Python Pipenv
JavaScripts npm
yarn

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

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

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

デプロイの仕組み

デプロイと一口に言っても、

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

など環境や構成によってデプロイのやり方が違ってくる。まず手動でやっていたデプロイを精査し、デプロイのツールがあるか?なども調査を行う2。その上でどのようなフローでデプロイを行うかを決定する。

  1. AWS上で全て(ソースコードなど)を管理しているのでAWS環境がいいのでAWS CodePipelineにする、といった感じ。

  2. AWS Lambdaであればsumなど。昔からやっている既存のフローを自動化するのではなく、新しく出てきた手法などをキャッチアップしやり方を更新する。

5
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?