仮想空間の日常

▲ Day 44: Gitタグ（v1.0.0）とDockerイメージタグの完全同期リリース 〜セマンティックバージョニング連携で実現する「野良バイナリ」完全根絶とトレーサビリティの極意〜 🏷️ 「本番サーバーで動いているこのDLL、Gitのどのコミットからビルドされたものか……100%の自信を持って答えられますか？」 前回のDay 43では、GitHub ActionsからGitHub Packages（GHCR）へテスト済みDockerイメージを自動プッシュするCIパイプラインを構築しました。 しかし、実務で絶対に避けては通れない重大な問いがあります。 「本番環境にデプロイするコンテナのバージョン管理、本当に安全に行えていますか？」 もし手動でイメージタグを付けたり、常に myapp:latest を本番へデプロイしているなら、それはかつて社内サーバーを混乱の渦に陥れた「野良バイナリ」と何一つ変わりません。 本講義（Day 44）では、Gitのリリースタグ（例: v1.2.0 ）とDockerイメージタグをミリ秒の狂いもなく完全同期させ、どのコードから作られたコンテナかを100%追跡可能にする 「セマンティックバージョニング自動同期リリース」 を徹底解説します！ § 本講義の学習アジェンダ（Day 44） 第1章： 30年選手の疑問：「野良バイナリ」の恐怖と完全なトレーサビリティの重要性 第2章： リリース自動化の全体像：Gitタグから始まる3ステップの配信フロー 第3章： 公式アクション「docker/metadata-action」によるSemVer自動解析 第4章： タグ戦略の鉄則：なぜ本番環境で「la...

▲ 【Day 41】CODEOWNERS と PR/Issueテンプレートによるチーム統制 👨‍🏫 皆さんこんにちは！ 本講座の専任講師です。 前回（Day 40）は、mainブランチへの直接pushを物理遮断し、レビュー承認とCIテスト合格を義務付ける「ブランチ保護ルール（Branch Protection Rules）」を学びました。 そして本日のテーマ【Day 41】は、組織拡大に伴う属人化を排除する強力なガバナンス機能 【CODEOWNERS と PR/Issueテンプレートによるチーム統制】 を徹底解説します！ 30年選手のベテランエンジニアから、開発現場のリアルな悲鳴が届いています： 「SVN時代は、誰がどのコードを修正したか把握するために、口頭やチャットで『〇〇さん、この部分直したんで見てもらえますか？』と個別に頼んでいた。だがチームが10人、20人と増えると『このファイルは誰に見てもらえばいいんだ？』と新人が迷い、忙しそうなベテランを避けて新人同士で承認し合って重大バグが混入してしまった！ 逆に特定のテックリードに全レビューが集中してボトルネックになることもある。 さらにプルリクエストの概要欄も、人によって『直しました』の1行だったり、ポエムだったりしてバラバラだ！ チームが大きくなってもレビュー漏れや品質のバラつきを防ぐ仕組みはないのか？！」 その悩み、まさに チームがスケールする際に全世界のエンジニア組織が直面する共通の壁 です！ 「気配りでレビューを頼む」「良識を持って丁寧にPRを書く」という属人性に頼った運用は、組織が拡大すると100%破綻します。 そこでGitHubが提供するのが、重要ディレクトリの変更時に責任者を自動でレビュアーに指名する 「CODEOWNERS」 と、記述フォーマットを統一する 「PR/Issueテンプレート」 です！ ...

▲ Day 43: GitHub Packages (GHCR) / Docker Hub への自動プッシュ 〜テスト済みコンテナをクラウドレジストリへ安全・高速に自動保管・配布する本番CI/CD〜 🐳 「ビルドした成果物を共有フォルダにZIPで置いて手動連絡……そんな運用に疲れていませんか？」 前回のDay 42では、GitHub Actionsを使ってDockerイメージを自動ビルドし、コンテナ内で dotnet test を完結させるCIパイプラインを構築しました。 しかし、テストに合格したコンテナイメージは、クラウドランナーが終了すると同時に破棄されてしまいます。 「じゃあ、合格したコンテナイメージはどこに保管して、どうやって本番環境や社内メンバーに届けるの？」 その答えこそが、本日のテーマである 「コンテナレジストリ（Container Registry）」 です！ 今回は、GitHub公式の GitHub Container Registry（ghcr.io） を活用し、テスト済みC#イメージをセキュアかつ完全に自動でプッシュ・保管・組織配布する極意を徹底解説します！ 📋 本講義のカリキュラム目次 第1章： 手動ZIP配布の終焉 〜なぜ「コンテナレジストリ」が必要なのか？〜 第2章： GitHub Actions × GHCR 自動プッシュの全体像（3ステップフロー） 第3章： 【セキュリティ最前線】 GITHUB_TOKEN による安全認証と最小権限設計 第4章： 【実践コード】 .github/workflows/push-ghcr.yml の完全実装 第5章： 【C#組織開発...

▲ 【Day 40】ブランチ保護ルールでmainを守る 👨‍🏫 皆さんこんにちは！ 本講座の専任講師です。 前回（Day 39）は、プルリクエストの真骨頂である「インラインコードレビューの実践と3つのマージ方式（Squashマージの推奨）」をマスターしました。 そして本日のテーマ【Day 40】は、チーム開発の最終防衛ライン 【ブランチ保護ルール（Branch Protection Rules）でmainを守る】 を徹底解説します！ 30年選手のベテランエンジニアから、現場でこんな悲痛な疑問が届いています： 「SVN時代はサーバーのauthzファイルで特定フォルダへのコミット権限を縛っていたが、Gitは誰でもリモートのmainにpushできてしまわないか？ 口頭で『mainには直接pushするな』と周知しても、新人が深夜の作業でうっかり git push origin main したら即座に本番が壊れるんじゃないか？！ どうやって事故をゼロにするんだ？！」 その心配は痛いほど分かります。人間の「気をつける」「注意する」という性善説の運用ルールは、忙しい時やトラブル発生時に 100%破綻 します。 そこで登場するのが、GitHubの 「ブランチ保護ルール（Branch Protection）」 です！ これを設定すれば、mainブランチへの直接pushはシステムレベルで物理遮断され、レビュー承認やCIテスト合格がなければ絶対に合流できない鉄壁のガードレールを構築できます！ 本講義では、C#開発現場で必須となる3大保護設定と、GitHub Actions（CI）と連携させた未ビルドコード混入防止ゲートの作り方を完全伝授します！ ① なぜ「性善説の運用ルール」は破綻するのか？ SVN権限管理との違い Subversion（SVN）やVSSを使...

▲ Day 42: GitHub ActionsでDockerイメージを自動ビルド＆テスト実行 〜git pushから単体テストまでをクリーンに完結させる現代的クラウドCIの極意〜 🐳 「社内ビルドサーバーの管理や、『自分のPCでは動いたのにCIで落ちる』問題に悩んでいませんか？」 オフィスの片隅に置かれたオンプレミスのJenkinsサーバーや物理マシン……。 ・ベテラン管理者が手作業でSDKやツールを更新しており、設定変更がブラックボックス化している ・誰かがビルドした一時ファイルがディスクを圧迫し、「ディスク満杯」でビルドが止まる ・開発者のローカルPCではテストが通るのに、ビルドサーバーの環境差異でエラー連発…… 今回から突入する 第9部「CI/CD連携（GitHub Actions × Docker）」 では、開発者が git push やプルリクエストを作成した瞬間に、 クラウド上のクリーンなDockerコンテナ内でC#テスト（xUnit / NUnit）を自動実行し、バグ入りコードのマージを100%遮断する最新CIパイプライン をゼロから構築します！ 📋 本講義のカリキュラム目次 第1章： なぜ「オンプレ専用ビルドサーバー」から「クラウドコンテナCI」へ移行するのか？ 第2章： GitHub Actions × Docker CI パイプラインの全体像（3ステップフロー） 第3章： 【実践①】マルチステージビルド内で dotnet test を完結させるDockerfile設計 第4章： 【実践②】 .github/workflows/ci.yml の完全実装とキャッシュ爆速化 第5...