🐣

CI/CD を導入するまえに

2025/01/20に公開

CI/CDって何?メリットは?導入する際に考えておきたいことを中心に、CI/CD の全体像についてまとめました🐱

CI/CD とは?

「CI/CD」とは、ソフトウェア開発におけるビルドやテスト・デリバリー・デブロイを自動化し継続的に行うアプローチを指す名称です。

「CI」と「CD」はそれぞれ「Continuous Integration(継続的インテグレーション)」と「Continuous Delivery/Deployment(継続的デリバリー/デプロイ)」の略で、この2つを組み合わせた開発手法を「CI/CD」と呼んでいます。

CI/CD について、5W1Hの軸で整理してみます。

👤Who(誰が)
開発チームやDevOpsエンジニア

What(何を)
ソフトウェアのコードを頻繁に統合し、自動的にテスト・デプロイするプロセス

🕰️When(いつ)
コードの変更があった際や、新しい機能を追加する際

🏟️Where(どこで)
開発環境や検証環境、本番環境で実施

Why(なぜ)
ソフトウェアの品質を向上させ、リリースサイクルを短縮するため

How(どのように)
自動テストツールやCI/CDツール(例:Jenkins、GitHub Actions)を使用して、プロセスを自動化する

背景

現代のソフトウェア開発では、自社で作ったコードに加えて、外部のライブラリやフレームワークを使うことが一般的です。
また、変わり続ける要求仕様を満たしながら複数の開発者やチームが同時に作業を進めることもよくあります。

このような環境では、「効率的に統合、展開、構成管理できること」 が、ソフトウェアのデリバリーの効率を高める上で重要になります。

CI/CD を導入することで

  • 開発者はより短いサイクルでコードの統合とテストを行うことができる
  • バグの早期発見と修正が可能になる
  • リリースプロセスの自動化により人的エラーを減らすことができる
  • デリバリーの効率を高めることができる

...などのメリットがあります。

CI/CDの導入を検討しているソフトウェアのデリバリー頻度や開発人数・規模などによって、導入を検討しましょう🎉

CI/CD を導入するにあたって考えること

CI/CD を適切に行うためには、ソースコードの管理方法や、構成管理のあり方など、開発プロセスやルール全体を見直し、継続的に統合・リリースできる状態を作り上げる必要があります。

CI/CDを導入するために考えておきたいポイントを以下の流れで解説します。

  1. CI/CD ツールを選ぶ
  2. ブランチ戦略を決める
  3. リリース戦略を決める
  4. リポジトリの運用方針を決める

1. CI/CD ツールを選ぶ🐱

CI/CDを始めるには、まずは使いやすいCI/CDツールを選ぶことが大切です。
どんな役割を果たすのかを理解した上で、自社のプロジェクトに合ったツールを選びましょう🎉

CI/CD用ツールの主な役割と代表的なツール

  1. CI(継続的インテグレーション)

    • 開発者がコードをリポジトリにプッシュするたびに、コードを自動的にテスト・ビルドする。
    • コードの変更が他の開発者の作業と統合される際の問題を早期に発見できる。

    例:Jenkins、CircleCI、GitHub Actions

  2. CD(継続的デプロイ/デリバリー)

    • ビルド済みのコードを自動的に本番環境や検証環境に展開する。
    • デプロイ戦略(例: カナリアリリースやブルー/グリーンデプロイ)をサポートし、変更を安全にユーザーに届ける。

    例:ArgoCD、Spinnaker

  3. CI/CD一体型ツール

    • CIとCDの両方を1つのツールで実現するものもある。
    • 開発からデプロイまでを一貫して管理できるため、シンプルで使いやすい。

    例:GitLab CI/CD、GitHub Actions、Jenkins

各ツールの比較については、下記サイトをご参考ください。
https://notepm.jp/blog/25434

2. ブランチ戦略を決める🐱

「ブランチ戦略」では、複数の開発者が同時に作業を進める際に、リポジトリ内のコードの整合性を維持するためのルールを定義します。
具体的には、ブランチの作成、マージ、削除のタイミングや方法、さらにブランチの命名規則などを規定します。

ブランチについて

Gitには「ブランチ」という機能があり、複数の人が並行して作業できます。ブランチ運用の規約を定めたものを「ブランチ戦略」と呼びます。

各自がブランチを切ることで独立して開発し、コードをマージ(統合)できますが、制限がないため誰でも自由に作成可能です。ルールがないまま開発を進めると、ブランチが乱立し、運用事故が起こりやすくなります。

こうした問題を防ぐため、ブランチに関するルールの整備が必要です🙆‍♀️
https://pjm-project.com/news/blog/696

主なブランチ管理の方法

  1. Git Flow

    • 大規模プロジェクト向けのモデル。
    • mainブランチ(リリース済みの安定版)とdevelopブランチ(開発中)を基点に、機能開発用のfeatureブランチ、リリース準備用のreleaseブランチ、バグ修正用のhotfixブランチを使い分ける。

      引用:Gitのブランチの役割を考える
  2. GitHub Flow

    • シンプルなモデルで、小規模から中規模プロジェクト向け。
    • mainブランチに直接コミットせず、featureブランチで開発を進め、プルリクエスト(Pull Request)を通じてコードをレビュー・マージを行う。
  3. GitLab Flow

    • GitHub Flow に各種環境用のブランチを足したものが GitLab Flow。
    • 開発フローとデプロイフローを統合したモデル。
    • mainブランチを基点とし、環境別ブランチ(例: staging, production) を用意することで、デプロイ管理を簡略化する。
  4. Trunk-Based Development

    • 継続的インテグレーションに適したモデル。
    • mainブランチ(またはtrunk)に細かいコミットを頻繁にマージする。

ブランチ戦略の規定方法

  1. ブランチの命名規則

    • feature/, hotfix/, release/などのプレフィックスを統一する。
    • プレフィックス以降に、各ブランチに関連するタスク名やタスクの番号を含めることで、追跡しやすくする(例: feature/HELPDESK-1234)。
  2. ブランチ保護ルール

    • 本番環境に関わるブランチに対して、直接のコミットを禁止し、プルリクエスト(PR)を必須にする。
    • コードレビューの完了やCIツールでの自動テスト合格をマージ条件として設定する。
  3. コミットメッセージ規約

    • コミットメッセージのフォーマットを統一する(例: "feat: 新機能追加", "fix: バグ修正", "docs: ドキュメント更新")。
    • Conventional Commitsのような標準的なスタイルを採用することで、変更履歴をわかりやすくする。
  4. タグとリリース管理

    • バージョン管理ルール(例: セマンティックバージョニング v1.2.3)を明確化する。
    • リリース時にはタグを使用して、特定のコミットを識別可能にする。

3. リリース戦略をきめる🐱

リリース戦略では、新しい機能や修正を本番環境に展開するプロセスを定義します。
具体的には、リリースの頻度、タイミング、手順、品質基準などを規定します。

リリース戦略の規定方法

  1. リリーススケジュールの明確化

    • 定期リリース(例: 毎月や四半期ごと)か、アジャイルなオンデマンドリリースにするかを明確にする。
    • 緊急時のリリース(例: バグ修正やセキュリティパッチ)の手順と優先度も定義する。
  2. リリースの品質基準

    • 本番環境へのデプロイ前にクリアすべき条件を設定する(例: 自動テストの成功率、コードレビューの完了、パフォーマンステストの結果)。
    • 検証環境での検証プロセスをルール化する。
  3. 承認プロセスの定義

    • リリース前の承認が必要な担当者やチーム(例: プロダクトオーナー、品質保証チーム)を明示。
    • クリティカルなリソースは複数の段階的承認を設定する場合がある。
  4. デプロイ方法と戦略の規定

    • 使用するデプロイ戦略(例: ローリングデプロイ、ブルー/グリーンデプロイ、カナリアリリース)をリソースの種類ごとに指定する。
    • 各戦略の手順と、失敗時のロールバック方法を詳細に定める。
  5. リリース後のモニタリングとフォローアップ

    • リリース後に監視すべき指標(例: エラーレート、レスポンスタイム、ユーザー行動)を設定する。
    • リソース展開後の初期段階で、運用チームや開発チームがフォローアップする仕組みも必要。

4. リポジトリの運用方針をきめる🐱

リポジトリ運用方針では、ソースコードやその他の開発生成物を管理するためのルールを定義します。
具体的には、リポジトリの構成、アクセス制御などを規定します。

リポジトリ運用方針の規定方法

  1. リポジトリの構成管理

    • モノリポジトリ(単一のリポジトリに全プロジェクトのコードを集約)かマルチリポジトリ(プロジェクトごとに分割)を選択する。
    • フォルダ構成や命名規則(例: src/, test/, docs/)を統一し、わかりやすいプロジェクト構成を維持する。
  2. アクセス制御

    • 開発チームや役割ごとに適切なアクセス権を設定する(例: 管理者、読み取り専用、書き込み可能)。
  3. ガバナンスと監査

    • リポジトリ内の変更やアクセス履歴を監査する仕組みを導入する。
    • 定期的なリポジトリのレビューを行い、不要なファイルやブランチを整理して、運用の効率化を図る。

その他🐱

  • クラウド環境でのインフラ管理
    クラウドを利用したインフラでは、「インフラ構成をコードとして管理(Infrastructure as Code)」することで、CI/CD環境への統合を実現しましょう。これにより、環境の再現性が確保され、インフラ構築や変更作業の自動化が促進されます。

  • 学習コストを考慮したツール導入
    初めてCI/CDツールやGitを導入する際は、それらを習得するための学習期間を見積もり、計画に組み込むことが重要です。ツールを効果的に活用するためのトレーニングやリソースを確保しましょう。

  • Gitと課題管理ツールの連携
    GitをJiraなどの課題管理ツールと連携することで、課題のステータスとGitのブランチ情報を同期できます。これにより、開発タスクごとの進捗状況が視覚化され、チーム全体で作業の進行を把握しやすくなります。✨

Atlassianの製品「Jira」と「Confluence」の紹介

「Jira」は、Atlassianが提供する製品でチケット型のプロジェクト管理ツールとして、課題の追跡や管理に適しています。
また、同社が提供している「Confluence」というツールは、社内Wikiやドキュメントの管理に適しています。
Jira(ジラ)とConfluence(コンフルエンス)を連携して使用することで、プロジェクトの管理や作業の完了を効率化できます。

https://www.atlassian.com/ja

さいごに

CI/CDって何?メリットは?導入する際に考えなければいけないことは?について解説しました。

私が以前開発を担当していたシステムでは、バージョン管理システムにSVNを使っており、コードに変更を加えることは半年に一度程度、そしてコードの変更も開発者一人で対応していました。そのためリリースまで手動で行うことが多くてもまぁいっか…という感覚でした。

その後、毎日複数人で開発を行うシステムの担当になり、CI/CD環境の恩恵を受けられるようになったので記事としてまとめてみました。

CI/CDの導入には開発チーム全体の理解と協力が不可欠です。導入前にメリットや運用フローを共有し、共通認識をもって始めましょう🎉

以上、どなたかの参考になれば幸いです。
えみり〜でした|ωΦ)ฅ

参考

Discussion