Software Design 202312
開発を加速する CI/CD
- ブランチ戦略
- Github Flow
- ブランチは main だけ
- main が進んだら自動的にデプロイされる
- Git Flow
- 5 つくらいブランチがあるやつ
- タグを打ってリリース
- リリース日が決まっている場合などに向いている
- Trunk-based Development
- Github Flow と似ているが、最低 1 日 1 回はメインブランチに変更を取り込む点が異なる
- CI/CD 基盤整備のポイント
- セルフホストはなるべく避ける
- 使うツールはなるべく絞りこむ
- 認証の選択肢
- 🟢 OIDC にする (サービスが対応しているなら)
- 🟡 環境変数に静的なトークンを埋め込む
- 🟡 HashiCorp Valut など外部のシークレット管理サービスを使う
- ソフトウェアライフサイクル
- プラン
- コード
- ビルド(CI)
- テスト(CI)
- リリース(CI)
- デプロイ(CD)
- 運用
- 監視
- CI とは
- コードをビルド&テストして、品質の担保された成果物を生成すること
- monorepo or polyrepo
- polyrepo の方が CI はシンプルになる
- 一方で、同じような CI 設定を共有するための仕組みが必要になることもある
- CD とは
- CD の目的
- まずは、シンプルに、小さく、自律的なしくみを作るのがよい
- 検証環境のデプロイ
- 検証の目的はあらかじめ明確にしておくこと
- いつデプロイするか?
- PR 作成時 / Pull Request Environment
- PR が作成されたら、その差分のみを反映した独自の検証環境が作成される
- お金がかかる
- 特定ブランチやタグの変更時
- 技術的に容易でコストも安い
- PR の差分のみを検証することはできない
- 任意のタイミング
- いまなにが反映されているのか把握しづらいのでおすすめしない
- 検 証からデプロイを自動化する場合の流れの例
- develop ブランチなど特定のブランチが更新される
- 検証環境が更新される
- E2E が実行される
- テストが完了したら本番にデプロイする
- 本番環境のデプロイ
- 検証環境のデプロイと考え方は同じ
- デプロイ後に以下をやるとよい
- E2E の実行
- Datadog 等のオブザーバビリティツールとの連携
- パターン
- お手軽パターン
- 構成
- CD/CD: Github Actions 等
- 検証環境: AWS Fargate や Cloud Run
- ブランチ戦略:GitHub Flow
- CD パイプライン: 予め用意されている仕組みを最大限活用する
- セキュリティ: OIDC による認証
- 全てマネージドサービスを使う
- 以下を設定しておく
- リリースブランチへの直プッシュ禁止
- PR には承認者が必須
- PR はステータスチェックの通貨が必須
- GitOps (Argo CD) を使用したパターン
- GitOps とは、Git においた構成ファイルを正としたうえで、Kubernetes 等のサービスを宣言的に管理する手法
- Kubernetes 側から Argo 側にポーリングするので Kubernetes API を触らなくて済む
- デメリット
- Argo の定期的なバージョンアップが必要
- CI と CD で使うツールが分断される
- セルフホストランナーを使用したパターン
ある会社での具体例