Zenn
Open6

Github CI/CD 実践ガイド メモ

sarashinasarashina

Github actions CI/CDガイドを読みます。
https://www.amazon.co.jp/GitHub-CI-CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub-Actionsの設計と運用-エンジニア選書/dp/4297141736

目次

第1章　ソフトウェア開発とGitHub
第2章　GitHub Actionsの基礎概念
第3章　ワークフロー構文の基礎
第4章　継続的インテグレーションの実践
第5章　運用しやすいワークフローの設計
第6章　アクションによるモジュール化
第7章　クリーンなリポジトリの維持
第8章　Dependabotによる依存関係バージョンアップ
第9章　GitHub Releasesによるリリース自動化
第10章　GitHub Packagesによるパッケージ管理
第11章　OpenID Connectによるセキュアなクラウド連携
第12章　コンテナオーケストレーションのデプロイメント
第13章　アクションのオープンソース化
第14章　GitHub Actionsの高度な使い方
第15章　GitHub Actionsのセキュリティ
第16章　セキュリティのシフトレフト
第17章　GitHub Appsトークンによるクロスリポジトリアクセス
第18章　継続的デリバリーの実践

  • github actionsの料金形態を調べる
  • スターターワークフローを使ってみる
  • actionlintの確認
  • キャッシュとアーティファクトの違い
sarashinasarashina

第1章　ソフトウェア開発とGitHub

  • ソフトウェアをとおして、ユーザーに価値を届けるためには以下の2点が重要
    • コードをソフトウェアに変換し、正しく動作するか検証すること
    • ソフトウェアをユーザーが使える状態にすること
  • ソフトウェア開発は試行錯誤を繰り返す継続的なライフサイクルを歩み、CI/CDは 開発から運用の間にあたる「ビルド→テスト→リリース」を自動化する
    • CI (Continuous Integration): コードの変更を頻繁にコードベースに統合、正しく動作するか繰り返し検証する
    • CD (Continuous Delivery): いつでも安全にリリースできる状態を保ち、ソフトウェアを繰り返し改善する
  • CI/CDの実践にはバージョン管理システムの導入が前提である -> GitHubの出番（共同でバージョン管理できるシステム）
  • ghコマンドでCLIからリポジトリを操作できる
sarashinasarashina

第2章　GitHub Actionsの基礎概念

  • Github Actionsはワークフロー単位（「いつ」、「どこで」、「どのような」）でタスクを自動化し、処理を実行する。
  • ワークフローにおける処理の最小単位「ステップ」は2種類の実装方法がある。
    • シェルコマンド
    • アクション：Github Actionsのモジュールを呼び出す
  • トリガーにできるイベントの中には手動実行や定期実行も挙げられる
    • 手動実行：workflow_dispatch 試行錯誤に使えそう
  • 実行環境である「ランナー」
    • 予めAWS CLIやDockerもダウンロードされている（<- OSで差異ありそう）
    • 参考
    • ワークフロー中に自分でインストールすることもできる
  • GitHub-Hosted-Runnerはジョブ開始時に起動し、終了時に破棄されるエフェメラルな特性を持つ
    • ジョブ終了後にデータアクセスしたい場合は注意
  • Github Marketplaceで公開されているアクションを検索できる
    • Verified CreatorsのActionsを使うと安全がある程度保障されてるかも

Github Marketplace調べてみた

sarashinasarashina

第3章　ワークフロー構文の基礎

  • github actions中は、トリガーになったイベントの情報を保持している
  • 環境変数はワークフロー・ジョブ・ステップ単位で定義可能、それぞれスコープが違う
    • コンテキストを直接シェルコマンドに埋め込むのはアンチパターンー＞中間環境変数を用いる
  • リポジトリ全体で共有したい環境変数はVariablesやSecretsに登録する
  • 案外github actionsで利用できるデフォルトの演算子はある
  • ステータスチェック関数を使うと、失敗時のみ通知するみたいな処理も作ることができる
  • GitHub APIでGithubの操作が可能（PRの書き込みとか）
    • permissionを宣言する必要がある
  • スターターワークフロー：GitHubが提供しているリファレンス実装のコレクション
sarashinasarashina

第4章　継続的インテグレーションの実践

  • デフォルトブランチ：開発の中心、開発時はデフォルトブランチから別のブランチを作成し、PRを出す。最終的なマージ先もデフォルトブランチ。
  • 一般的なPR時のCIとして、自動テストと静的解析を行う
  • 自動テスト
    • イベントのフィルタリングで、PR時の差分ファイル毎に挙動を変えてもいいかも（.jsファイルが変更されたらテストを実施みたいな）
    • テスト時に実行する言語インストールをセットアップアクションで行う（githubのhostの言語は用いない）
    • フォルダ内にバージョンファイルを作成して、バージョン指定することも有効（.go-version)
  • 静的解析
    • actionlintが良いらしい。
  • タイムアウトとデフォルトシェルはすべてのワークフローに導入する価値がある
    • パイプエラーを拾うかつ実行時間の削減によるコスト削減
    • デフォルトのタイムアウトは360分
    • Bashはpipefailを拾えるようにする
  • actionsの多重起動の抑制（Concurrency）
    • 往々にして同じPRは最新のpushにしか興味はない
  • 継続的インテグレーションに必要なのは以下の3点
    • クリーンに保つ
    • 高速に実行する
    • ノイズを減らす
  • 自動テストの運用プラクティス
    • ユニットテストは網羅的に実行（異常系も含め）
    • インテグレーションテストやE2Eテストは正常系中心に
    • フレーキーテストをリトライでごまかさない
    • フラジャイルテストはテストコードを見直した方がいい
      -時間のかかるテストは後回し（例えばPRの後）でもいいかも
  • 静的解析の運用プラクティス
    • 不要な警告は無視せず抑制（with コメント）
    • 新規の警告を増やさない
    • 警告理由を理解する
sarashinasarashina

第5章　運用しやすいワークフローの設計

  • ロギング
    • ACTION_STEP_DEBUG」でログが取れる
    • Bashのトレーシングオプションを使って値を取得
    • ::group::でログを畳むこともできる
  • レポート
    • GITHUB_STEP_SUMMAYでジョブサマリーを出せる
    • アノテーションでログレベルを出せる
      -jobは基本並列実行、逐次実行する場合は依存関係を作成する
  • Environmentsを用いることで環境ごとの変数を持てる
  • キャッシュ: フロー中にダウンロードするファイルを一時保存できる（7日以上アクセスされなければ消える）
  • アーティファクト: ワークフロー内で生成したファイル