Gitの変更を自動でテストする

アプリを変更するたびに、開発者は同じテストを行い、配布用のファイルを作ります。 手作業では一つの確認を忘れたり、開発者ごとに違う手順を使ったりすることがあります。

確認手順をファイルへ記録し、Gitへ変更が届くたびに専用のコンピューターで実行すれば、すべての変更を同じ方法で確認できます。

CIがGitの変更を受け取り、テストするまで

ソースコードや画像などから、実行または配布できるファイルを作る処理をビルドと呼びます。 CI（継続的インテグレーション）は、Gitのリポジトリへ変更が共有されるたびに、テストやビルドを自動で行う方法です。 GitHub ActionsなどのCIサービスは、リポジトリの変更を検知し、確認作業を行うコンピューターを用意します。

用意されたコンピューターは、設定ファイルに書かれた順番で次のような処理を実行します。

1. Gitからファイルを取得する
2. アプリが必要とするライブラリを取得する
3. ファイルの書式や文法を確認する
4. 自動テストを実行する
5. 配布するファイルやコンテナイメージを作る

CIが順番に実行する一連の処理をパイプラインと呼びます。

テスト結果と作ったファイルを残す

テストが失敗した場合、CIサービスは失敗した処理と、その処理が出力したログを残します。 開発者はログを読み、失敗した変更を直してからもう一度Gitへ記録します。

CIが作った配布用ファイルやコンテナイメージを成果物と呼びます。 使用するライブラリとビルド環境のバージョンを固定すると、同じGitの記録から同じ内容の成果物を作りやすくなります。

GitHub Actionsで処理を順番に書く

GitHub Actionsでは、一台の実行環境で行う作業のまとまりをjob、job内の一つひとつの処理をstepと呼びます。 次の例では、一つのjobがファイルの取得、テスト、ビルドを順番に行います。

name: verify
on:
  pull_request:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - run: make test
      - run: make build

onはパイプラインを開始する条件です。 runs-onはjobを動かす環境、stepsは実行順を表します。 最初はこの対応だけを読み、YAMLの細かな書式は設定を変更するときに確認します。

usesで指定するactionは、ほかのリポジトリから読み込んで使う処理です。 外部のactionもCIの実行環境で動くコードなので、使用する版を変更されないcommit IDで指定します。

パスワードをGitへ入れずに渡す

外部サービスへ接続するパスワードやアクセストークンは、Gitのファイルへ書きません。 CIサービスの設定画面へ登録し、必要なjobを実行するときだけ渡します。 そのjobへ与える権限も、実行する処理に必要な範囲へ絞ります。

運用で分かったことを次の変更へ戻す

アプリを公開したあとは、利用状況やエラーを確認し、次に直す内容を決めます。 DevOpsは、ソフトウェアを開発する人と運用する人が協力し、変更を安全に短い間隔で利用者へ届けるための考え方と仕事の進め方です。 計画、開発、テスト、公開、運用で分かったことを次の計画へ戻し、同じ作業を繰り返し改善します。

開発側

1. 1計画する Plan
2. 2コードを書く Code
3. 3実行できる形にする Build
4. 4テストする Test

提供と運用

5. 5公開の準備をする Release
6. 6本番へ届ける Deploy
7. 7運用する Operate
8. 8状態を確かめる Monitor

.PHONY: verify
verify:
	./scripts/lint.sh
	./scripts/test.sh
	./scripts/build.sh