SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

GitHub Actionsをはじめよう

【GitHub Actions 実践編】小さく始めて育てる──CI/CD継続のポイント

GitHub Actionsをはじめよう 第4回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 近年、多くのチームがCI/CDに取り組んでいます。そんな状況の中、CI/CDに興味があるものの何から始めていいかわからない、他のツールを使っていたがGitHub Actionsを使ってみたい、という方もいるのではないでしょうか。そんな方に向けて、本連載ではGitHub Actionsの基本を解説していきます。複雑化するシステム、ますます求められる品質やセキュリティといった側面を考えると、CI/CDもシステム開発における基礎知識です。一緒にGitHub Actionsをはじめましょう!

  • X ポスト
  • このエントリーをはてなブックマークに追加

これまでのおさらい

はじめに

 こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。本連載「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のプロセスに含まれていると言えるでしょう。

 また、多くの場合リリースは一度限りではありません。繰り返し安全にリリースできることが重要です。そのためには自動化も外せないでしょう。

 継続的デプロイメントとは、ソフトウェアの変更をコミットごとにユーザーへ自動的にリリースすることを指します。継続的デリバリーの場合は「いつでもリリース可能な状態をつくる」という部分にポイントがあります。ソフトウェアの変更の結合や検証とリリースの間には人間の手による介入があります。継続的デプロイメントの場合はソフトウェアの変更からリリースまで自動的に行われます。

 継続的デプロイメントは、継続的デリバリーを拡張したもの、一歩先にあるものともいえます。

次のページ
CI/CDに取り組むポイント

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
GitHub Actionsをはじめよう連載記事一覧

もっと読む

この記事の著者

藤澤 千尋(フジサワ チヒロ)

 ソフトウェアエンジニアとして約10年働いており、最近は主にフロントエンド開発を担当しています。最近、筋トレを始めました。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/21912 2025/10/16 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング