金曜の夕方の手作業
あるコンビニチェーンでは、各店舗が発注アプリで商品を注文します。
金曜の夕方、担当者が小さな修正を手で本番に入れました。テストを動かすのを忘れていました。
翌朝、全国の店舗で発注の画面が止まりました。このレッスンでは、人が忘れても止まる仕組みを学びます。
このレッスンのゴール
メモ
コードをテストして本番に届けるパイプラインを説明できる。
キーワード
| ことば | いみ | れい |
|---|---|---|
| パイプライン | 変更を順番に確かめて届ける、自動の流れです。 | |
| ステージ | パイプラインの中の一つの段階です。 | build、test、deploy |
| CI | 変更のたびに自動でビルドとテストをすることです。 | |
| CD | テストを通った変更を、自動で届けられる状態にすることです。 | |
| デプロイ | 新しい版を本番に入れることです。 |
学生が入力するセルは、このプレビューでは空白です。
CI は変更のたびにテストする
開発者がコードを共有の場所に送ると、パイプラインが動き出します。
最初はビルドです。アプリが組み立てられるかを確かめます。次はテストです。決めた計算や動きが正しいかを、自動で確かめます。
どこかで失敗すると、そこで止まります。壊れた変更は、本番まで進めません。
三つのステージを動かす
set -e
stage() { echo "=== $1 ==="; }
# 発注金額 = 単価 × 個数
total() { echo $(( $1 * $2 )); }
stage "1. ビルド"
echo "発注アプリ v3.4 を作りました"
stage "2. テスト"
result=$(total 150 3)
if [ "$result" -ne 450 ]; then
echo "テスト失敗: 150円を3個で $result 円になりました"
exit 1
fi
echo "テスト成功: 450円"
stage "3. デプロイ"
echo "全国の店舗に新しい版を届けました"
# total の * を + に変えて、わざと壊してください。
# 実行すると、デプロイの前で止まるはずです。
パイプラインもファイルに書く
パイプラインの中身は、YAML という形式のファイルに書くのが一般的です。
いつ動くか、どのステージがあるか、どの順番か。それを全部この一つのファイルに書きます。
ファイルなので、コードと同じように変更の履歴が残ります。次のブロックで読んでみましょう。
パイプラインのファイルを読む
mkdir -p hacchu && cd hacchu
cat > pipeline.yml <<'END'
# main に push されるたびに動きます
on:
push:
branches: [main]
jobs:
build:
steps:
- run: npm ci
test:
needs: build
steps:
- run: npm test
deploy:
needs: test
steps:
- run: ./deploy.sh production
END
# needs: は「この前のステージが成功したら」という意味です
grep -n 'needs:' pipeline.yml
CD は小さく何度も届ける
テストを通った変更は、いつでも本番に出せる状態になります。これが CD です。
チームによっては、本番に入れる前に人が一度だけボタンを押します。全部を自動にするチームもあります。
大切なのは、変更を小さく分けて何度も出すことです。小さい変更なら、問題が起きても原因をすぐに見つけられます。
ある一週間の実行の記録
| 日付 | 変更 | テスト | デプロイ |
|---|---|---|---|
| 10月14日 | 値引きの計算を修正 | 成功 | 済み |
| 10月15日 | 発注画面の文言を変更 | 成功 | 済み |
| 10月16日 | 在庫の表示を追加 | 失敗 | 止まった |
| 10月16日 | 在庫の表示を修正して再送 | 成功 | 済み |
| 10月17日 | ログイン画面を修正 | 成功 | 済み |
学生が入力するセルは、このプレビューでは空白です。
よくある間違い
注意
パイプラインがあれば安全だ、と考える人がいます。それは正しくありません。パイプラインは、書かれたテストを動かすだけです。テストのない計算は、間違っていても通ります。新しい機能には、テストも一緒に書きましょう。