これまでのおさらい
はじめに
こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。本連載「GitHub Actionsをはじめよう」の第1回では簡単なワークフローを作って動かしてみました。第2回ではより詳しくGitHub Actionsの構文を学びました。第3回ではアクションを作成してみました。
最終回の今回は、CI/CDに取り組みやすくするためのポイントを紹介します。GitHub Actionsからは少し離れてCI/CDそのものについて考えてみましょう。
対象読者
- GitHub Actionsを使ったことはないが使ってみたい方
- GitHub Actionsを学び直したい方
- Git、GitHubの基本的な利用方法を理解されている方
本記事の情報について
本連載に掲載している内容は、2025年10月現在の情報を元にしております。実際に利用する際は公式ドキュメントをご確認ください。
CI/CDとは
本連載ではGitHub Actionsを利用してワークフローを構築してきました。ここで改めてCI/CDとは何なのかについて考えてみましょう。
CI - 継続的インテグレーション
CIとはContinuous integrationの略であり、日本語では継続的インテグレーションと呼ばれています。ソフトウェアの変更を高い頻度で結合し各変更を検証していくプロセスです。
結合、検証、継続的、の3つがポイントです。ただ単にソフトウェアの変更をマージするだけではなく、そこには必ず検証というプロセスが入ります。例えば静的解析や自動テストはこの検証にあたります。さらにどの程度の頻度で結合と検証が行われるのか、というのもポイントです。
なんらかのソフトウェアを作るときに、「全ての機能を作り終えるまで一度も動作確認をしない」ことは、まずないでしょう。想像もできないかもしれません。万が一そのような状況になったとして、作り終えたときに大量の不具合が発見されることは予想がつくかと思います。起動すらできないかもしれません。そのような状態からどこにどんなバグがあるのか、何が原因なのか、探すのは至難の業です。
一方で、こまめに動作確認をすることによって、その都度不具合に対応することができます。全ての機能を作り終えた段階での不具合の数は相対的に少ないです。不具合があったとしてもどこまでは正常に動いていたのかがわかっているため、あたりをつけて原因を探すことができます。小さな変更を頻度高く結合、検証していくことの重要性がわかるかと思います。
CD - 継続的デリバリー
CDは2つの用語の略語として使われています。
- Continuous Delivery: 継続的デリバリー
- Continuous Deployment: 継続的デプロイメント
継続的デリバリーとは、ソフトウェアの変更をいつでも安全にリリースできるようにするためのプロセスです。そのためには以下の2点がポイントとなります。
- ソフトウェアが常にリリース可能であること
- リリースするプロセスが自動化され、繰り返し実行可能であること
特に1つ目を実現するのが、前節で説明をしたCIです。頻度高く結合し、その度に検証することで、常にソフトウェアがリリース可能であることを確認します。CIのプロセスはCDのプロセスに含まれていると言えるでしょう。
また、多くの場合リリースは一度限りではありません。繰り返し安全にリリースできることが重要です。そのためには自動化も外せないでしょう。
継続的デプロイメントとは、ソフトウェアの変更をコミットごとにユーザーへ自動的にリリースすることを指します。継続的デリバリーの場合は「いつでもリリース可能な状態をつくる」という部分にポイントがあります。ソフトウェアの変更の結合や検証とリリースの間には人間の手による介入があります。継続的デプロイメントの場合はソフトウェアの変更からリリースまで自動的に行われます。
継続的デプロイメントは、継続的デリバリーを拡張したもの、一歩先にあるものともいえます。
