「GitHub CI/CD実践ガイド」イベント基調講演ダイジェスト＋FAQ #Forkwell_Library

2024/9/17に「GitHub CI/CD実践ガイド~ Forkwell Library#67」というイベントで登壇しました。本記事ではその講演をダイジェストでお届けします。あわせて当日のFAQにも回答します。

発表資料

イベントでは拙著『GitHub CI/CD実践ガイド』のポイントを解説しました。

https://gihyo.jp/book/2024/978-4-297-14173-8

資料はSpeakerDeckへ公開済みです。またアーカイブ動画がYouTubeから視聴できます。

発表ダイジェスト

それでは講演内容をかいつまんで説明しましょう。アジェンダは次のとおりです。

1. CI/CDとはなにか
2. GitHub Actionsの基本機能と作法
3. 持続可能性を高める習慣
4. 意図的脅威に対する防衛術
5. おわりに

なおFAQだけ読みたい場合は、こちらをクリックすると飛べます。

1. CI/CDとはなにか

我々ソフトウェアエンジニアの仕事は「ソフトウェアをとおして、ユーザーに価値を届けること」です。しかしソフトウェア開発は複雑性が高く、要件もたびたび変化します。そのためソフトウェア開発では、何度も試行錯誤を繰り返します。そこで活躍するのがCI/CDです。

CI/CD

CI/CDはご想像どおり、2つの概念を総称しています。それぞれ見ていきましょう。まずは「CI（継続的インテグレーション）」です。書籍内では次のように定義しています。

コードの変更を頻繁にコードベースへ統合し、正しく動作するか繰り返し検証する

次に「CD（継続的デリバリー）」です。こちらは次のように定義しています。

いつでも安全にリリースできる状態を保ち、ソフトウェアを繰り返し改善する

またCIとCDは同列の概念ではありません。CIはCDに包含されます。当然ながらリリースされるソフトウェアは正常に機能すべきです。そのためCDはCIによる検証が事実上必須です。

なおCI/CDの実体はさまざまなプラクティスの集合です。なにを実施するかはプロジェクト固有です。テストやリリースの自動化を想起しやすいですが、そのスコープはもう少し広いです。

ここであらためてCI/CDの目的を明確にしましょう。筆者は次のように考えています。

ソフトウェア開発の持続可能性を高め、長期に渡る価値提供を実現する

ソフトウェア開発はユーザーへの価値提供が使命です。CI/CDはここに時間軸の概念を加えます。ソフトウェア開発の持続性向上は、ユーザーへより長く価値を届けために不可欠です。

GitHub Actions

GitHubでCI/CDを実装する場合、オススメはGitHub Actionsです。GitHub Actionsは汎用的なワークフローエンジンで、YAMLファイルを置くだけで使えます。

ところでGitHub Actionsは構文が直感的です。なんならコピペでもわりと動きます。ただそのせいか動いたら満足しがちです。その結果セキュリティや運用は置き去りにされる傾向があります。

しかも属人化しやすいです。誰かが腕力でなんとかしてしまい、レビューも雑に通過してしまうなどはあるあるです。このあたりはJenkins登場時から状況があまり変わってません^[1]。

その一方でGitHub Actionsは学びやすい技術です。メンドウな環境構築は不要で、GitHubアカウントさえあれば誰でも使えます。所詮はYAMLなので、汎用プログラミング言語に比べると仕様も小さいです。そしてなによりも、我々には『GitHub CI/CD実践ガイド』があります！

というわけで書籍の中身を具体的に見ていきましょう。

2. GitHub Actionsの基本機能と作法

GitHub Actionsにはさまざまな機能があります。書籍では次のスライドへ記載した各機能を丁寧に解説しています。ここではさすがに全部は説明できないため、ひとつだけ触れます。

意外と知られていないコンテキストのアンチパターン

本記事で紹介するのはコンテキストです。コンテキストは「複数のプロパティで構成されたオブジェクト」です。ブランチ名やプルリクエストのタイトルなど、さまざまな値を参照できます。GitHub Actionsにおける基本的な機能で、利用頻度も高いです。

ただしトラップがあります。シェルコマンドへコンテキストを直接埋め込んではいけないのです。スクリプトインジェクション攻撃に利用される恐れがあります。

たとえば次のコードはダメな例です。このように実装すると、プルリクエストのタイトルを少し工夫するだけで攻撃できます。そして攻撃が成功すると、任意のコマンドが実行されます。

- run: echo "${{ github.event.pull_request.title }}" # 脆弱性アリ！

これはやらかしやすいアンチパターンです。残念ながらネットに転がってる多くのコードへ散見されます。とくにコピペで書いている人は、高確率でこの地雷を踏みます。

中間環境変数でスクリプトインジェクションを回避する

スクリプトインジェクションを避けるには「中間環境変数」が有効です。ポイントは2つです。

1. コンテキストを環境変数へマッピングし、環境変数経由で値を参照する
2. 環境変数をクォートし、値をただの文字列として扱う

先ほどのコードなら、次のように書き換えます。これだけでコマンド実行を抑止できます^[2]。

- run: echo "${PR_TITLE}" # 環境変数は忘れずにダブルクォーテーションで囲む！
  env:
    PR_TITLE: ${{ github.event.pull_request.title }} # 環境変数へマッピング

コンテキストに含まれるすべての値が、スクリプトインジェクションを招くわけではありません。しかしどの値にリスクがあるか、判別するのは困難です。そのためコンテキストをシェルコマンドで扱う場合、すべて中間環境変数を経由させたほうが安全です。

基礎は退屈だが、あとで必ず活きてくる

コンテキストについて見ていきましたが、GitHub Actionsではこのような作法がいくつもあります。次のスライドはその一例です。

作法の習得には本来、経験と時間が必要です。ただそれだと大変すぎます。そこで書籍では、構文と作法を同時に学べるよう工夫しました。設計や運用の観点を含めて解説し、学習効率を劇的に高めています。ふだん雰囲気で使っている人は第I部を読むと、多くの発見があるでしょう。

それでは次に習慣が大事という話題へ移ります。

3. 持続可能性を高める習慣

唐突ですが「なにもしてないのに壊れた」という、怪奇現象に遭遇したことはないでしょうか。筆者はあります。コードを一行も変えていなのに、突然エラーを出しはじめるのです。

壊れる原因のひとつに、周辺環境の変化があります。ソフトウェアはOS・言語・ライブラリなど、さまざまなものに依存しています。これらの依存関係は、我々の事情に配慮せず変更されます。そして後方互換性が壊れると、依存しているソフトウェアも道連れになります。

ソフトウェアに停滞は許されない

次のグラフは「State of the Software Supply Chain」というレポートの引用です^[3]。このレポートによれば、OSSは平均で年15回バージョンアップされるそうです。ソフトウェアが10個のライブラリに依存しているなら、年間150回もバージョンアップが発生するわけです。

ただ依存関係のバージョンアップは、正直かなりメンドウです。ソフトウェアを壊さないためには、次のような作業が必要です。しかもこの作業はバージョンアップのたびに発生します。

1. 検知: 新しいバージョンがリリースされたことを知る
2. 把握: 具体的にどのような変更が行われたか理解する
3. 実装: 新しいバージョンを自身のコードへ組み込む
4. テスト: リグレッションテストを実施し、壊れたら対処する

正直あまりやりたい作業ではありません。ただ放置もリスクがあります。そのうえ放置しすぎると、いずれ身動きが取れなくなります。EOL駆動のバージョンアップはたいてい地獄です^[4]。

Dependabot version updatesによる自動バージョンアップ

依存関係のバージョンアップは厄介な問題です。そこでGitHubは「Dependabot version updates」というサービスを提供しています。これは次の作業を自動化します。

• 新しいバージョンが出ていないか、定期的にチェック
• 新しいバージョンを検知したら、バージョンアップのプルリクエストを作成

GitHub Actionsとも連携でき、プルリクエスト作成時にワークフローを起動できます。そのためバージョンアップ時に自動テストが実行可能です。頑張ればマージまで自動化できます。

主要なパッケージマネージャーをサポートしており、設定も簡単です。次のようにYAMLファイルを記述すれば、あとはGitHubが勝手にやってくれます。

version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: daily

簡単なので使ったことがなければ、ぜひ一度試してみましょう。

世の中の大事なことって、たいてい面倒くさいんだよ（by 宮崎駿）

ここまで依存関係のバージョンアップについて掘り下げました。しかし持続可能性を高めるため、ほかにも実践すべきプラクティスはあります。次のスライドはその一例です。

しかしこの手のものは、習慣づけるのが大変です。ソフトウェア開発で価値あるプラクティスは多数存在しますが、たいていメンドウです。そこでオススメしたいのは、既存ソリューションの力を借りることです。たとえばGitHubなら、次のような機能をシレッと提供しています。

• ルールセット: ブランチやGitタグの保護
• CODEOWNERS: オーナーシップの維持と自動レビュー通知
• シークレットスキャン: コードに埋まったクレデンシャルの検知
• GitHub Releases: ソフトウェアとリリースノートの配信

これらは地味な仕組みですが、うまく使うと持続可能性の向上に寄与します。このような長期運用に役立つプラクティスは、書籍の第II部へ散りばめています。ぜひ活用してほしいです。

それでは少し切り口を変えて、次は脅威の話に移ります。

4. 意図的脅威に対する防衛術

マルウェアや不正アクセスのような悪意を持った攻撃は、意図的脅威と呼ばれます。意図的脅威はさまざまな場所に存在します。CI/CDも例外ではありません。

ソフトウェアサプライチェーンは悪い人に大人気

ソフトウェアサプライチェーンとは「コードを書いてから実行環境へリリースする」までに含まれる、一連のアクティビティを意味します。ソフトウェアサプライチェーンの構成要素には固有の脅威があり、それぞれに対策が必要です。GitHub Actionsはこのど真ん中に位置します。

残念なことにソフトウェアサプライチェーンへの攻撃は、近年大幅に増加しています。次のグラフは「State of the Software Supply Chain」からの引用で、まさに右肩上がりです。2021年から2023年の2年間で、20倍ぐらい増えています。GitHub Actionsも他人事ではありません。

第三者が提供するアクション

GitHub Actionsにおける脅威のひとつは、第三者が提供するアクションです。アクションはよくある処理をカプセル化する、便利な仕組みです。他者が提供するアクションを利用すれば、実装の手間が省けます。誰でも簡単に公開でき、審査もとくにありません。

ところでアクションに許されている操作はなんでしょうか。結論からいえば、「GitHub Actionsで実行可能なあらゆる操作」となります。たとえば次のような処理が実行できます。

• ソースコードの参照
• 任意のコマンド実行（ファイルダウンロード含む）
• クレデンシャルを利用した外部システムへのアクセス

アクションはまさに万能です。裏を返せばアクション提供者は、アクション利用者のリポジトリでなんでも実行できるわけです。他人のリポジトリを好き放題できるなんて最高ですね！

そんなわけでアクションがひとたび侵害されると、同時多発的な被害が出ます。たとえば2021年に起きたCodecovの侵害では、多数の企業からクレデンシャルが流出しました。

誰もあなたの代わりに責任は取ってくれない

アクションを利用するとき、我々は「アクション提供者へリポジトリを丸ごと差し出している」に等しいです。そのためアクションを導入する際には、次のことを肝に銘じましょう。

アクション提供者から裏切られると、基本的にはどうにもならない

これを鑑みると安全なアクションは、次の要件を満たす必要があります。

• アクション提供者に害意がない
• アクション提供者が害意ある相手に侵害されない

結論を述べます。アクション導入時は、提供者を信頼するか意識的に判断してください。アプリケーションコードへライブラリを追加する感覚で、考えなしに扱うのはリスクが高すぎます^[5]。

信頼は主観的な判断です。誰も絶対の安全は保証できません。それでも常に考えるクセをつけましょう。自分で判断して自ら運用することでしか、判断力は向上していきません。

出典: 質とスピード（2022春版、質疑応答用資料付き）

第三者のアクションを利用すると決断したなら、リスク軽減策を講じましょう。Verified Creatorsやコミットハッシュによる固定など、いくつか有益なプラクティスが存在します。単一の防御策ではなく、複数の防御策を講じることが大切です。

脅威への対抗策

アクションを掘り下げてきましたが、ほかにも脅威はあります。そして脅威の数だけ、対抗策も存在します。書籍では第III部を中心に、次のようなプラクティスを紹介しています。

ソフトウェアを運用し続ける限り、脅威は永遠につきまといます。一気にやろうとしてはいけません。メンドウですが地道に実践していきましょう。

5. おわりに

締めは執筆の軽い裏話と、読者の反響です。

執筆中に心がけたこと

IT業界に限らず、世の中には「経験をとおして学ぶコト」がたくさんあります。経験者にとっての優位性ともいえますが、本書ではそういったノウハウの言語化に努めました。個人の経験だけでなく、多くの参考文献からエッセンスを取り入れて解説しています。

また「最高の読書体験を提供する」という信念のもと、読みやすさ・わかりやすさへ妥協せずチューニングしました。狂気的なレベルで調整したため執筆は地獄でしたが、読者には優しい書籍になったと自負しています。ぜひこのあたりも着目してもらえるとうれしいです。

読者の声

感想をくださる方、本当にありがとうございます。本の著者というのは、読者の感想を心待ちにしている生き物です。たぶん読者が想像する、100倍ぐらいは渇望しています。本を読んだらじゃんじゃん感想をつぶやきましょう。面白かったの一言があるだけで、生きる活力になります。

せっかくなので書評記事をいくつか紹介します。わざわざ記事にしてくださって感激です！

• GitHub Actions の実践的なノウハウが凝縮されている素晴らしい一冊「GitHub CI/CD 実践ガイド」を読んだ
• [書評]素早い開発と品質を両立させるCI/CD職人のための『GitHub CI/CD実践ガイド』
• 「GitHub CI/CD実践ガイド」を読んで、GitHub Actionsを始めよう
• 読書備忘録：GitHub CI/CD実践ガイド

発表のダイジェストはこれで一区切りです。次はFAQへの回答です。

FAQ

当日のFAQ枠では、時間の関係で扱えなかった質問も多いです。そこで本記事では、未回答の質問を取り上げます。

GitHub Actionsのテストについて聞きたいです。actは利用していますか？

actは利用していません。そのかわりに実験用リポジトリを作って、そこで実験しています。ローカル環境でGitHub Actionsの再現を頑張るより、実験用リポジトリで試行錯誤したほうが楽なためです。コミットログをいくら汚してもよく、レビューなしにマージも可能です。単純ですが開発体験もよいため、ローカル環境で動かす必要性は感じていません。

ただブラウザ操作はメンドウなので、コンソールで完結するよう工夫しています。ワークフローへworkflow_dispatchイベントを組み込み^[6]、タスクランナーで次の処理を実行しています。

1. 作業中のブランチをForce push
2. GitHub CLIでワークフローを起動
3. GitHub CLIでワークフローの実行ログを取得

これで体感的にはローカル環境の開発に近くなります。実行スピードはそれほど早くないですが、個人的には妥協できるレベルなので、このスタイルで開発しています。

また少し凝ったロジックを実装する場合は、スクリプトを別ファイルへ切り出しています。GitHub Actions自体は実環境で検証し、複雑なスクリプトはローカルで検証する形です。

GitHub secretsの値はどの程度セキュアでしょうか？secretsから値が漏えいしたケースなどはありますか？

GitHub ActionsにおけるSecretsの特徴は、「暗号化されて保存される」「ログ出力時にマスクされる」の大きく2つです。Secretsはワークフロー実行時に復号され、メモリ上へ平文で展開されます。そのためワークフローが侵害されると、Secretsの値は漏えいします。発表資料で触れたアクションの侵害や、スクリプトインジェクションもSecrets漏えいの原因になります。

また「リポジトリへのWrite権があると、誰でもワークフローを実行できる」という仕様にも注意しましょう。ログマスクの回避や、外部システムへの送信は簡単に実装できます。ワークフローを動かせると、Secretsは見放題になります。そのため信頼できない人へ、リポジトリのWrite権を渡してはいけません。くわえて次のようなシークレットマネジメントの基本を守ることも大切です。

• 最小権限の原則を守る
• 定期的なローテーションの実施や、不要なSecretsの削除を徹底する
• 影響範囲や失効方法、クレデンシャルの管理者などをドキュメントへ残す
• OpenID Connect（OIDC）が使えるなら、常にOpenID Connectの利用を優先する

このあたりは書籍の15.8節が参考になります。また「OWASP Top 10 CI/CD Security Risks」では、Insufficient Credential Hygieneで同様の話題を扱っています。

複数のAWSアカウントに対して同じようなジョブの処理をデプロイする場合の質問です。処理をそれぞれジョブ単位で分割すべきか、またはジョブは分割せずステップで細かく処理を分岐させるのか、どちらの方法が長期で運用するのに適切でしょうか？現状はジョブごとに分けていて認証はOIDCのIAMロールを環境変数で適用しています。

複数AWSアカウントへデプロイする場合、筆者自身はAWSアカウント単位でジョブを分割します（質問者様と同じです）。デバッグのしやすさやセキュリティ、メンテナンス性などを考慮すると、ジョブ単位で分割するほうがベターだと考えています。

ただしコードが増えないよう、EnvironmentsでAWSアカウントを切り替えています。またデプロイメントプロテクションルールも併用しています。これで「デフォルトブランチでのみデプロイ」「承認時のみデプロイ」のような仕組みが作れます。環境ごとに異なるルールを設定できるため、本番環境だけ厳しくしています。書籍では12.5節や15.10節が参考になります。

最近のGitHub Actionsの面白い機能

面白いというか、興味を持っているのは「Push Rules」です。.github/workflowsのように重要なディレクトリ配下を、特定の人しか変更できないように設定できます。

これまでのGitHubは、リポジトリ単位でのアクセス制御が基本でした。しかしPush Rulesの登場により、もう少し細かいアクセス制御が可能になります。ちなみに最近GAしました。

プライベートなリポジトリでGitHub Actionsを使い倒すと意外にお金がかかるという話を聞きますが、お勧めの節約術が知りたいです

パッと思いつくのは3つです。

1. 必要ない場合はワークフローを実行しない
2. ワークフローを高速化する
3. パブリックリポジトリで実験する

まず重要なのが1番です。節約したいのであれば、とにかく不要なワークフローを起動しないことです。たとえば次のようなプラクティスがあります。

• イベントのフィルタリング（4.3節）
  • ファイルパスやブランチ、アクティビティタイプで条件が記述可能
  • とくにファイルパスはGlobを使うと、かなり細かく制御できる
• ジョブへの条件分岐を追加（3.7節）
  • コンテキストや関数を使うと、多少複雑な条件分岐が可能
  • 「ジョブが起動しない場合は課金対象外になる」という仕様を利用する
• Concurrencyを用いた自動キャンセル（4.8節）
  • 最新コードでのみ実行すればよい自動テストなどは、常に自動キャンセルを有効化する
  • プルリクエストで起動するワークフローの大半は、自動キャンセルして問題ない

またGitHub Actionsはランナーの種類と実行時間で課金額が決まります。そのためランナーは極力、一番安いUbuntuを使います。そのうえで2番の高速化を頑張ります。

• キャッシュ（5.8節）
  • 簡単なのはactions/setup-*アクションでキャッシュを有効化すること
  • セットアップアクションが使えない場合は、actions/cacheアクションを使う
  • さらにチューニングしたいなら、actions/cache/saveアクションやactions/cache/restoreアクションを使う
• 重い処理を分離する（4.10節）
  • たとえばスローテストをプルリクエストごとではなく、日時で実行する

最後は技術検証時のコスト最小化です。身も蓋もない話ですが、パブリックリポジトリで実験しましょう。それだけで無料になります。GitHub Actions自体の技術検証や学習用途なら十分です。ただし非公開にすべきコードを誤って持ち出さないよう、十分注意してください。

どのようなジョブを動かしてますか？

仕事ではAmazon ECSへのデプロイやTerraformの実行に利用しています。アクションやReusable Workflowsを実装して、複数チームが使う仕組みも整備しています。

個人プロジェクトではラベルの自動付与や、GitHub Releasesへのリリースなどに活用しています。あまりにも便利なので、テンプレートリポジトリへ組み込んで愛用しています。

workflow_call と actions の使い分けは何を軸に考えればいいかが知りたいです。

たぶんReusable Workflowsとアクションの使い分けという意図だと思われるので、その前提で説明します。まずこの両者は粒度が異なります。Reusable Workflowsは「ワークフロー全体」をカプセル化できます。アクションは「ワークフローの一部（ステップ）」をカプセル化します。

まったく同じYAMLファイルを複数リポジトリへコピーしているなら、Reusable Workflowsが役立ちます。ワークフローの一部だけ使いまわすならアクションです。強引にテストでたとえると、Reusable WorkflowsはE2Eテストに近く、アクションはユニットテストに近いです。

不慣れなうちはアクションを使いましょう。他のステップと連携しやすく、小回りがききます。一方Reusable Workflowsは玄人向けです。ワークフロー全体を記述するため、責務が大きくなります。設計スキルがそれなりに高くないと、うまく運用するのは難しいです。とはいえ実践しないと熟練度は上がらないので、チャンスがあればぜひ挑戦してみてください。

なお公式ドキュメントの「Avoiding duplication」には、両者の技術的な差分が記載されています。こちらも使い分けを考えるうえで、ヒントになるでしょう。

https://docs.github.com/en/actions/sharing-automations/avoiding-duplication

GithubActionsのモデルケースをいくつか知りたいです

GitHub Actionsの使い道としては、たとえば次のような用途があります。

• プルリクエストが作成されたら、静的解析とテストを実行する
• リリースタグが作成されたら、コンテナイメージをデプロイする
• Issueが作成されたら、ランダムにメンバーをアサインする

もっと知りたければ、公式ドキュメントの「Use cases and examples」が参考になります。またWorkflow Templatesにもサンプルコードが多数掲載されています^[7]。

書籍には載せなかった情報や載せられなかった新機能はありますか？

前述の「Push Rules」でしょうか。締め切り直前でベータ版がアナウンスされたため、コラムで言及するのが精一杯でした。それ以外で載せなかった話題には「IssueOps」があります。プルリクエストのコメント経由で、いろいろなオペレーションができるプラクティスです。IaCと相性抜群で面白いんですが、かなり玄人向けになるため割愛しました。

GitHub ActionsのCI/CD パイプラインをプロダクトととらえる（Platform Engineering的）とき、パイプラインの異常系についてもがっつり取り組まなければならないと考えていますが、それに関しての記述は豊富にありますか？

期待に添えるか不明ですが、基本は網羅しています。たとえば第5章ではロギングやレポーティング、第14章ではエラーハンドリングやコンテキストによるフロー制御などを扱っています。ただあくまでも「自分でワークフローを実装・運用する」前提で記述しています。他チームへの提供は考慮していないため、そのあたりを期待するとアテが外れるかもしれません。

余談ですが、Platform Engineering的な文脈では第13章がオススメです。アクションを題材にしていますが、進化プロセスやテスト設計の節はかなり役立つはずです。

Actionsの性能や負荷耐性で気をつけるべき点はあるでしょうか？

GitHubが提供する「GitHub-Hosted Runners」は、あまりマシンスペックが高くありません。とくにプライベートリポジトリではCPUとメモリが半減します（UbuntuやWindowsの場合）。

https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners

性能が足りない場合は、Larger Runnersを検討しましょう。有料でスケールアップでき、富豪的CI/CDが可能になります。またほかにはSelf-Hosted Runnersという選択肢もあります。環境構築と運用が自前になるデメリットはありますが、マシンスペックの自由度はダントツです。

執筆中の2年間は、別の仕事も請られていたのですか？その場合、時間配分はどんな感じでしたか？

執筆以外もしてました。一日の時間配分は時期によって異なります。最後の半年は執筆に6〜12時間、それ以外に2〜3時間という毎日です。休日はほぼなく、超絶ブラックでした。^[8]

スポットでCI/CDのコンサルとか設計の請負とかのお仕事は受けていますか？可能であれば事例など聞きたいです

スポットの仕事はほぼしていません。継続的にお付き合いしている会社がいくつかあり、その中でCI/CDも扱っています。執筆が大変すぎたため、スポットで請ける気力は正直ありませんでした。ようやく執筆から解放されたので、ニーズがあれば今後やってもいいかもですね。

むすびに

発表慣れしていないため資料作成に苦戦しまくり、当日も結構緊張していましたが、なんとか無事終わってホッとしています。普段フルタイムで働きながらカンファレンスなどに登壇している人、本当にすごいですね。素直にリスペクトしてしまいます。

というわけで『GitHub CI/CD実践ガイド』を紹介しました。本書は筆者の経験・知識・休日を総動員し、2年かけて完成した自信作です。ぜひ手にとってもらえるとうれしいです。

https://gihyo.jp/book/2024/978-4-297-14173-8

参考文献

おまけですが、スライドに登場した参考文献を紹介します。じっくり読む系が多いです。

• 継続的デリバリー
• 単体テストの考え方/使い方
• Googleのソフトウェアエンジニアリング
• LeanとDevOpsの科学
• システム運用アンチパターン
• Infrastructure as Code
• セキュアなソフトウェアの設計と開発
• チームトポロジー
• データベースリライアビリティエンジニアリング
• ソフトウェアアーキテクチャの基礎
• Linuxプログラミングインタフェース
• A Philosophy of Software Design

ちなみに書籍内でも大量の参考文献を紹介しています。手元に書籍がある人は、章またぎのコラムをぜひチェックしてみましょう。よりどりみどりです。

脚注

1. CI/CDはなぜか昔からあんまり興味を持たれません。一方でやってる人は、技術スタックが変わってもいつもやってます（筆者の観測範囲では）。ちなみに筆者はJenkins・AWS CodeBuild・CircleCIなどを渡り歩いてきました…。

2. 環境変数と異なり、コンテキストはダブルクォーテーションで囲んでもコマンド実行が抑止されません。環境変数とコンテキストはコードこそ似ていますが、挙動はまるで異なります。

3. このレポートはかなり面白く、このあともう一度登場します。ほかにも興味深い情報を提供しているため、ぜひ一読してみましょう。

4. EOLなんて無視！という考え方もありますが、それはそれで別の地獄を呼び起こします。

5. さんざん脅しつけておいてなんですが、アクションをまったく利用しないのは、利便性を考えるともったいないです。自身の状況に合わせて、トレードオフを探ってください。ウデの見せどころです。

6. すべてのワークフローへworkflow_dispatchを追加すると実験に便利です。特定のイベントでしか取得できない値も、入力パラメータ経由で注入可能です。DIみたいな設計思想です。

7. 書籍ではスターターワークフローという名前で紹介しましたが、出版後に名前が変わりました。

8. 執筆が終わって痛感したのは、休日がある生活は最高という世界の真理です。3ヶ月休みなしとか、マジでメンタルがヤバくなります😇