仮想空間の日常

▲ 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...

▲ 【Day 39】コードレビューの実践と3つのマージ方式の選び方 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回（Day 38）は、チーム開発の絶対的品質ゲートである「Pull Request（PR）の仕組みとGitHub Flowの実践」を学びました。 そして本日のDay 39では、PRの真価を引き出す 【コードレビューの実践と3つのマージ方式の選び方】 を徹底マスターします！ 30年選手のベテランエンジニアからよくいただくお悩みがこちらです： 「SVN時代は、席まで歩いていって口頭で『あそこ直しといて』と伝えるか、ソースコードを印刷して赤ペンで直していた。なぜGitHubの画面上でわざわざ1行ずつコメントしなければならないんだ？ それに、いざPRをマージしようとすると緑のボタンに『Create a merge commit』『Squash and merge』『Rebase and merge』と3つも選択肢があるが、一体どれを選べば正解なんだ？！」 お気持ちはとてもよく分かります。しかし、GitHubのインラインレビューと適切なマージ方式を味方につければ、 手戻りゼロの爆速レビューと、10年後もバグ原因を瞬時に特定できる超綺麗なコミット履歴 が手に入ります！ 本講義では、C#開発現場でのリアルなレビュー指摘例や「Suggest changes」の革新的な活用法、そして絶対に失敗しないマージ戦略を徹底的に解き明かします！ ① なぜGitHubのインラインレビューが最強なのか？ SVN口頭・メールとの決定的な差 Subversion（SVN）やVSSの時代、コードレビューは「開発者の席に集まって画面を指差す」「メールやチャットでファイル名と行番号を送る」「印刷した紙に赤ペンを入れる」といった属人的な手法が主流でした。 ...

html

▲ 【Day 38】Pull Request（PR）の仕組みとGitHub Flow実践 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回（Day 37）はリモート追跡ブランチの仕組みと、事故を防ぐ「fetch先行」の同期作法を学びました。 そして本日のDay 38では、GitとGitHubを導入する最大の価値と言っても過言ではない 【Pull Request（プルリクエスト / 通称PR）の仕組みとGitHub Flow】 を徹底マスターします！ 30年選手のベテランエンジニアから最も頻繁に寄せられる疑問がこれです： 「Subversion（SVN）時代は、C#のコード修正が終わったら直接中央（trunk）にコミットして終了だった。なぜGitではわざわざブランチを切って、Webブラウザを開いて、他人に『取り込んでください』とお願い（Pull Request）しなければならないんだ？ 二度手間で面倒ではないか？」 お気持ちはとてもよく分かります。しかし結論から申し上げますと、 PRを使わない直接push運用は、いわば「鍵も監視カメラもない無施錠の金庫に全員が手を突っ込んでいる」のと同じ状態 なのです！ 本講義では、Pull Requestがチーム開発の「絶対防衛ライン（品質ゲート）」としてなぜ不可欠なのか、そして世界中で標準採用されている最もシンプルで強力な運用法 「GitHub Flow」 の実践手順を余すところなく解説します！ ① なぜ直接mainにpushしてはいけないのか？ 品質審査ゲート制への移行 SVNやVSSの中央集中型バージョン管理では、すべての開発者が単一の中央リポジトリ（trunk）に直接コミットを送信していました。 この運用が許されていたのは、「少人数で全員の顔が見え、各自が慎重に作業していた」という暗黙の前提があ...