DevOps

GitHub Actionsでモノレポを安全に自動リリースする設計: 変更検知・段階配布・失敗復旧 モノレポのCI/CDは、単一リポジトリだから楽になる一方で、リリース設計を誤ると一気に難しくなります。 1つの変更で全サービスを再デプロイしてしまう 並列ジョブが増えてキュー渋滞する どのコミットがどのサービスへ反映されたか追跡できない 一部失敗時のロールバックが曖昧 本記事では、GitHub Actionsでモノレポを運用しているチーム向けに、実務で耐えるリリース自動化の構成を具体的に説明します。 1. モノレポCI/CDで先に決める設計原則 最初に次の原則を明文化します。 変更のないサービスはデプロイしない リリース対象は機械的に決定する 本番反映は段階的（canary/割合配布） 失敗時の復旧手順を自動化する 監査ログ（誰が何をいつ）を残す この5つがないと、運用が属人化し、障害時対応が遅れます。 2. 変更検知をワークフローの入口に置く モノレポでは「どのディレクトリが変わったか」を最初に判定し、対象サービスだけを処理します。 2.1 changed-filesの例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 jobs: detect: runs-on: ubuntu-latest outputs: matrix: ${{ steps.set-matrix.outputs.matrix }} steps: - uses: actions/checkout@v4 - id: changed uses: tj-actions/changed-files@v45 with: files_yaml: | api: - services/api/** web: - services/web/** worker: - services/worker/** - id: set-matrix run: | python .github/scripts/build_matrix.py '${{ toJson(steps.changed.outputs) }}' ここでmatrixを作り、後続ジョブを fromJson で動的展開します。 ...

Terraform→OpenTofu移行実践ガイド: 既存IaCを止めずに移行するエンタープライズ手順 Terraformのライセンス変更以降、OpenTofuへ移行したいという相談は確実に増えています。とはいえ現場の本音は「理屈は分かるが、stateが壊れたら終わる」「本番を止めずに移行できるのか不安」です。 結論から言うと、移行は十分可能です。ただし「CLIを置き換えるだけ」で済むケースは限定的で、実際は providerバージョン整合・state lock・CI/CD・運用Runbook までまとめて整える必要があります。 本記事では、既にTerraformを本番運用しているチーム向けに、OpenTofuへ段階移行する実践手順をまとめます。 1. 移行方針を先に決める 最初に決めるべきは「一気に切り替えるか」「ワークスペース単位で段階移行するか」です。実務では次の方針が安全です。 低リスク環境（dev/sandbox）から先行 本番は最終フェーズで移行 旧TerraformとOpenTofuを一定期間並行運用 ロールバック手順を文書化してから実施 この順序を守るだけで、移行事故の大半を避けられます。 2. 互換性の棚卸し（最重要） まずは現状のIaC資産を棚卸しします。 Terraformバージョン（例: 1.5.x / 1.6.x） 使用provider（AWS/Azure/GCP/Kubernetes等） backend（S3 + DynamoDB lock、Terraform Cloud、GCSなど） moduleの参照方式（registry / git / local） CI実行環境（GitHub Actions, GitLab CI, Jenkins） 2.1 依存を固定化してから移行する .terraform.lock.hcl を必ずコミットし、providerを固定します。移行時にproviderまで同時更新すると、差分原因の切り分けが困難になります。 1 2 3 4 5 6 7 8 9 terraform { required_version = ">= 1.6.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 5.40" } } } 移行フェーズでは「ツール差分」と「provider差分」を分離してください。 ...

Kubernetes環境でDBスキーマ変更を止めずに進める：ゼロダウンタイム移行の実践戦略 「カラムを追加するだけだから大丈夫」──この油断が、本番障害の入口になります。Kubernetes のように複数バージョンの Pod が同時に存在する環境では、DB スキーマ変更はアプリ変更よりも慎重に扱う必要があります。 本記事では、Expand-Contract パターンを中心に、ゼロダウンタイムを目指すための具体手順を解説します。実際の運用では、DDLの速さより「互換性のある期間をどう作るか」が勝負です。 1. なぜKubernetesでDB移行が難しいのか Kubernetesでは、ローリングアップデート中に新旧Podが混在します。つまり次の状態が同時に発生します。 新アプリは新スキーマを期待 旧アプリは旧スキーマしか知らない DBは1つしかない このとき破綻するのが「破壊的変更を先に適用する」ケースです。たとえば旧カラムを即削除すると、旧Podがエラーを連発します。 2. 基本戦略：Expand → Migrate → Contract ゼロダウンタイム移行の原則はこの3段階です。 Expand: 互換性を壊さない変更を先に入れる（新カラム追加など） Migrate: アプリを段階的に切替え、データを移行する Contract: 旧仕様を最終削除する（十分な監視後） この順序なら、どの時点でも旧新どちらのアプリも動作可能にできます。 3. 具体例：users.full_name を first_name / last_name へ分割 3.1 Expand フェーズ まず破壊的でないDDLを適用します。 1 2 ALTER TABLE users ADD COLUMN first_name text; ALTER TABLE users ADD COLUMN last_name text; この時点で旧アプリは full_name を使い続けられます。新アプリは新カラムに対応した実装を持っていても、まだ必須にしません。 3.2 アプリを「両対応」にする 書き込み時は両方へ保存（dual write）し、読み込み時は新カラム優先 + 旧カラムフォールバックにします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 def save_user_name(user_id: str, full_name: str): first, last = split_name(full_name) db.execute( """ UPDATE users SET full_name = %s, first_name = %s, last_name = %s WHERE id = %s """, (full_name, first, last, user_id), ) def read_user_display_name(row): if row.first_name and row.last_name: return f"{row.first_name} {row.last_name}" return row.full_name この両対応期間を作るのが、ゼロダウンタイムの本質です。 ...

GitHub Actions高速化実践：Matrix戦略・依存キャッシュ・失敗切り分けの設計ガイド GitHub Actions は便利ですが、プロジェクトが成長すると「遅い」「不安定」「原因が分かりにくい」という三重苦になりがちです。特に monorepo や複数ランタイム対応（Node/Python/Go など）では、ワークフローの設計次第で CI 時間が 2〜3 倍変わります。 本記事では、実行時間を短くしながら失敗時の調査コストも下げるために、matrix 設計・キャッシュ設計・障害時の確認順序を具体的に整理します。 1. まず「何を並列化するか」を決める Actions の高速化は、いきなりキャッシュ最適化から入るより、先にジョブ分解を決める方が効きます。原則は次の通りです。 並列化すべき: 独立テスト（OS/バージョン別、サービス別） 直列にすべき: デプロイ、DB マイグレーション、本番反映 依存を分ける: lint/typecheck/test/build を一つに詰め込まない 悪い例は、1ジョブに全部詰め込み、失敗時に最初から再実行するパターンです。良い設計では「lint は通るが test だけ失敗」のように切り分けできます。 2. matrix を作るときの実践ルール matrix は便利ですが、組み合わせ爆発で逆に遅くなることがあります。例えば os x runtime x db をすべて直積にすると、不要なジョブが大量発生します。そこで include/exclude を活用します。 1 2 3 4 5 6 7 8 9 10 11 12 strategy: fail-fast: false matrix: os: [ubuntu-latest, macos-latest] node: [20, 22] include: - os: ubuntu-latest node: 22 coverage: true exclude: - os: macos-latest node: 20 ポイントは次です。 ...

Terraformドリフト検知プレイブック：本番事故を防ぐCI設計と運用手順 Terraform を導入していても、運用が進むほど「実環境がいつの間にかコードとズレる」問題にぶつかります。いわゆるドリフトです。最初は小さな差分でも、放置すると本番変更時に予期せぬ差分が混ざり、障害やリリース遅延の原因になります。 本記事では、Terraform ドリフト検知を単なる terraform plan 実行で終わらせず、継続運用できる仕組みとして実装するための具体策をまとめます。対象は AWS を例にしますが、考え方は他クラウドでも共通です。 1. ドリフト検知で最初に決めるべきこと 多くのチームが失敗するのは、実装前に運用設計を決めないことです。まず以下を決めます。 どの環境をいつ検知するか（prod は毎日、stg は平日など） 検知結果をどこに通知するか（Slack/Discord/Issue） 誰がいつまでに対応するか（当番制、SLA） 「意図した手動変更」をどう扱うか（例外ラベル、期限付き） ここを決めずに CI だけ作ると、通知がノイズ化して無視されます。ドリフト検知は技術課題より運用課題です。 2. リポジトリ構成と state 分離 最小限、次のような構成を推奨します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 infra/ modules/ vpc/ ecs/ rds/ envs/ prod/ main.tf backend.hcl variables.tf stg/ main.tf backend.hcl .github/ workflows/ terraform-drift.yml 環境ごとに backend と state を分けることが重要です。ドリフト検知ジョブが state を誤って参照すると、存在しない差分が出ます。S3 backend + DynamoDB lock を使う場合は、bucket/key/region/table の整合性を必ず固定化します。 ...

GitHub Actions再利用ワークフロー運用設計：属人化を防ぎつつ開発速度を上げる実践ガイド 複数リポジトリを運用していると、ほぼ同じ CI 設定を各リポジトリにコピーし続ける状態になりがちです。最初は早く見えますが、半年後には「どこに正解があるのかわからない」状態になります。セキュリティパッチを当てたいだけなのに 20 リポジトリを横断修正し、1つだけ取りこぼして監査で指摘される、というのは珍しくありません。 この問題に効くのが GitHub Actions の workflow_call を使った再利用ワークフローです。ただし、単に共通化するだけでは逆に運用事故が増えることがあります。重要なのは、共通化の粒度、権限境界、変更リリース方法を最初に設計することです。 本記事では、実運用で詰まりやすいポイントを中心に、導入から定着までを具体的に解説します。 1. 再利用ワークフローの基本方針 まず押さえるべき方針は次の 3 つです。 再利用ワークフローは「プラットフォーム製品」として扱う 呼び出し側（各アプリ repo）は薄く保つ 破壊的変更はバージョンを切って段階移行する 「共通化＝1ファイルに全部詰め込む」ではありません。lint, test, build, deploy を1個にまとめると、対象外プロジェクトまで影響します。まずは小さく分割し、必要なものだけ組み合わせられる構造にします。 2. 推奨ディレクトリ構成 共通ワークフローを専用 repo に分離しておくと、監査や変更履歴の管理が容易になります。 1 2 3 4 5 6 7 8 9 org-ci-workflows/ .github/workflows/ ci-node.yml ci-python.yml security-scan.yml release-tag.yml docs/ onboarding.md migration-checklist.md 呼び出し側は以下のように最小化します。 ...

GitHub Copilot Workspace活用術：仕様書から実装まで一気通貫 はじめに ソフトウェア開発の現場にいる皆さん、日々の業務フローを思い返してみてください。 GitHub Issue や Jira のチケットで仕様を確認する。 内容を理解し、ローカルで新しいブランチを作成する。 関連ファイルを特定し、エディタで開く。 仕様に沿ってコードを書き、修正する。 動作確認のためのテストコードを記述する。 ローカルでテストを実行し、問題ないことを確認する。 変更をコミットし、リモートにプッシュする。 ブラウザで GitHub を開き、Pull Request (PR) を作成する。 この一連の流れは、私たちエンジニアにとって日常茶飯事です。しかし、このプロセスには多くのコンテキストスイッチ（思考の切り替え）が含まれており、特にプロジェクトの初期段階や、新しいコードベースに触れる際には、仕様の理解や関連ファイルの特定といった「準備運動」に多くの時間が費やされます。 「Issue の内容を理解したら、あとはAIが自動でコードを書いてPRまで作ってくれたら最高なのに…」 そんな未来の夢物語が、GitHub Copilot Workspace の登場によって、現実のものとなりつつあります。この記事では、GitHub がテクニカルプレビューとして公開した Copilot Workspace を徹底的に解説し、Issue（仕様書）を起点として、AIと共に実装計画を立て、コードを生成し、Pull Request を作成するまでの一気通貫の開発フローを実践的なハンズオン形式で紹介します。 この記事を読み終える頃には、あなたは Copilot Workspace の強力な機能を理解し、自身の開発プロセスを劇的に効率化させるための具体的なイメージを描けるようになっているでしょう。 なぜ今、Copilot Workspaceが重要なのか？ GitHub Copilot が登場し、私たちのコーディング体験は大きく変わりました。関数名やコメントから意図を汲み取り、驚くほど的確なコードを補完してくれる Copilot は、もはや手放せない相棒となっているエンジニアも多いでしょう。その後、Copilot Chat が登場し、エディタ内で対話形式でコードに関する質問やリファクタリングの相談ができるようになりました。 しかし、これまでの Copilot は、あくまで「コーディング」という実装フェーズに特化した支援ツールでした。開発プロセス全体を見渡すと、実装の前には「仕様の理解」「設計」「実装計画」といった上流工程が存在し、実装の後には「テスト」「PR作成」「レビュー」といった下流工程が存在します。 ここに、現代の開発プロセスが抱える根深い課題があります。 コンテキストスイッチのオーバーヘッド: Issue、設計ドキュメント、エディタ、ターミナル、ブラウザ… 開発者は複数のツールやウィンドウを絶えず行き来する必要があり、そのたびに集中力が削がれます。 定型作業の繰り返し: ブランチ作成、ボイラープレートコードの記述、基本的なテストケースの作成など、創造的とは言えない定型作業に多くの時間が奪われています。 オンボーディングの壁: 新しいメンバーがプロジェクトに参加した際、広大なコードベースのどこから手をつければ良いのかを把握するのは非常に困難です。 GitHub Copilot Workspace は、これらの課題を解決するために生まれました。それは単なるコード補完ツールではありません。Issue を起点として、開発タスクの全体像をAIが把握し、人間と対話しながら「仕様の明確化」「実装計画の立案」「コード生成」「テスト」までを半自動的に実行する、いわば「AI搭載の開発環境」 なのです。 Copilot Workspace は、開発プロセスの上流から下流までをシームレスに繋ぎ、エンジニアを煩雑な作業から解放します。これにより、エンジニアはより創造的で、本質的な価値を生み出す「設計」や「アーキテクチャの検討」「複雑なビジネスロジックの実装」に集中できるようになるのです。これは、開発の生産性を根底から覆すポテンシャルを秘めた、大きなパラダイムシフトと言えるでしょう。 Copilot Workspaceによる開発フロー徹底解説 それでは、実際に Copilot Workspace を使って Issue から PR 作成までを駆け抜けるプロセスを、具体的なハンズオン形式で見ていきましょう。 ...

【運営報告】ブログ自動化システムの安定化に向けた取り組み はじめに：その自動化、本当に「自動」ですか？ 「ブログの自動投稿システムを組んだけど、なぜか時々ビルドに失敗する…」 「CI/CDパイプラインがエラーで止まるたびに、原因究明に数十分も費やしている…」 「最初はシンプルだったのに、機能を追加していくうちにリポジトリがカオスになってきた…」 もしあなたが個人ブログや技術ドキュメントサイトをGitHub Actionsなどで自動化していて、このような悩みを抱えているなら、この記事はあなたのためのものです。 こんにちは。当ブログを運営している筆者です。私もかつて、まさにこの問題の渦中にいました。Markdownで記事を書いてGitHubにプッシュすれば、あとは魔法のようにサイトが更新される──そんな夢のような自動化システムを構築したはずが、いつしかそれは「時々機嫌を損ねる気難しい同居人」のような存在になっていました。依存関係のエラー、ローカルとCI環境での挙動の違い、肥大化したワークフローファイル…。これらは、自動化による恩恵を帳消しにするほどのストレスと時間的損失をもたらしていました。 この記事では、私が直面したブログ自動化システムの不安定化問題と、その根本原因を深く掘り下げ、リポジトリの再構築とビルド環境のコンテナ化というアプローチでいかにして安定稼働を実現したか、その全貌を余すところなくお伝えします。 この記事を読み終える頃には、あなたは以下の知識とテクニックを手にしているはずです。 不安定なCI/CDパイプラインの根本原因を診断するための着眼点 モノレポとマルチレポの考え方を適用した、メンテナンス性の高いリポジトリ設計 Dockerを活用して「どこでも同じように動く」ビルド環境を構築する方法 堅牢で再利用性の高いGitHub Actionsワークフローを設計するための具体的なベストプラクティス 技術的負債と向き合い、システムを長期的に健全な状態に保つためのマインドセット 単なる対症療法ではない、根本からのシステム改善に興味のある方は、ぜひ最後までお付き合いください。 なぜブログ自動化システムは不安定になったのか？ - 課題の深掘り 解決策を語る前に、まずは私のブログシステムがどのような問題を抱えていたのか、その背景と原因を詳しく見ていきましょう。問題を正しく理解することが、正しい解決策への第一歩です。 当初のシステム構成 私のブログは、多くの技術ブログで採用されているであろう、ごく一般的な構成でした。 コンテンツ管理: Markdownファイル 静的サイトジェネレーター(SSG): Hugo ソースコード管理: GitHub CI/CD: GitHub Actions ホスティング: GitHub Pages この構成における自動投稿の基本的な流れは、以下の図のようになります。 graph TD A[記事(Markdown)をpush] --> B{GitHub Actions}; B --> C[Hugoでビルド]; C --> D[GitHub Pagesへデプロイ]; 非常にシンプルで、最初はこれで何の問題もありませんでした。しかし、ブログ運営を続けるうちに、様々な機能を追加したくなり、システムは徐々に複雑化していきました。そして、以下の3つの大きな問題が顕在化したのです。 問題1：依存関係地獄 (Dependency Hell) 「私のローカル環境ではちゃんとビルドできるのに、なぜかGitHub Actions上では失敗する」。この現象に、あなたも見覚えがないでしょうか。これは、開発環境と実行環境の間に存在する「差異」が原因で発生します。 私の場合、具体的には以下のような問題に悩まされていました。 Hugoのバージョン不整合: ローカルで使っているHugoのバージョンと、GitHub ActionsのワークフローでセットアップされるHugoのバージョンが微妙に異なり、テンプレートの仕様変更などでビルドエラーが発生する。 Node.js依存ツールのバージョン問題: 私が使っていたHugoテーマは、CSSのトランスパイルにSass（Dart Sass）を利用しており、これはNode.jsに依存していました。ローカルのNode.js/npmバージョンとCI環境のバージョンが異なると、npm installが失敗したり、Sassのコンパイル結果が変わってしまったりしました。 Go Modulesの混乱: HugoはGoで書かれているため、テーマによってはGo Modules (go.mod, go.sum) を利用します。CI環境のGoのバージョンが古いと、これもまたエラーの原因となりました。 これらのバージョンをpackage.jsonやワークフローファイルで固定しようと試みましたが、複数の依存関係が絡み合うと管理が非常に煩雑になり、根本的な解決には至りませんでした。 ...