仮想空間の日常

▲ Day 21: なぜdocker-composeが必要なのか？（単一コマンドで複数サービス起動） 🐳 受講生の皆さん、お疲れ様です！ Docker/コンテナ実践講座の専任講師です。 第4部までの講義で、Dockerfileの作成、マルチステージビルド、.dockerignore、Gitコミット運用、そしてWorker Serviceの常駐運用まで、 「単体コンテナをプロ品質でビルド・運用する技術」 を完全にマスターしました。 そして本日、本講座はついに 【第5部: マルチコンテナ連携（docker-compose）】 へ突入します！ 実際のエンタープライズ現場では、Webアプリ単体で完結するシステムは存在しません。SQL Server、PostgreSQL、Redisキャッシュ、メッセージブローカーなど、複数のサービスが有機的に連携して初めて動きます。 これらを毎回手動の docker run で起動する苦行から私たちを解放する救世主 「Docker Compose」 の全貌を解き明かします！ ① 導入・本日の達成目標 「Web APIを立ち上げる前に、まずSQL Serverコンテナを起動して…あ、ポート番号何番だっけ？」 「コンテナ同士を繋ぐためのネットワークを作成し忘れて、WebアプリからDBが見つからずにクラッシュした…」 「新しくプロジェクトに参加したメンバーの開発PCで、ミドルウェアの起動手順書が10ページもあって半日潰れた…」 このような苦い経験は、エンジニアなら誰しも一度はあるはずです。 VM（仮想マシン）時代、私たちはHyper-VやVMware上の複数サーバーを「DBサーバー ➡ Redisサーバー ➡ APサーバー」と順番に手動で起動ボタンを押して回っていました。 コンテナ時代になっ...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 17では、ブランチをいつ作成し、いつ統合（マージ）すべきかという運用の絶対原則と、短命ブランチ（トランクベース開発）の考え方をマスターしましたね。 さて、本日のテーマは、チーム開発の規約編として最も重要な 「迷わないブランチ命名規則のデファクトスタンダード」 です！ Subversion (SVN) や Visual SourceSafe (VSS) を長年使ってきたエンジニアの方ほど、当時はブランチを頻繁に切る文化がなく、ローカルのフォルダ名に「20261016_修正」や「bk_work」といった適当な名前をつけてバックアップを取っていた経験があるのではないでしょうか。 しかし、Gitではチーム全員が1つのリモートリポジトリ（GitHubなど）を共有し、日々何十本ものブランチが作成・破棄されます。 もしここで、各メンバーが好き勝手に test 、 fix2 、 yamada-branch といった無秩序なブランチ名をつけてしまうと、リポジトリは一瞬で「ゴミ捨て場」のようなカオス状態に陥ります。 「このブランチは何のために切られたのか？」「もうマージ済みで消していいのか？」と誰にも判断できなくなるのです。 さらに現代の開発現場では、GitHub ActionsなどのCI/CDや、Claude Code・AntigravityなどのAIアシスタントがブランチ名を認識して自動テストやコード生成を行います。 本日は、世界共通の5大プレフィックス（feature/, bugfix/, hotfix/, release/, spike/）の使い分けから、GitHub Issue（チケット番号）との連携黄金ルール、C#現場での具体例、そしてAIへのブランチ命名指示プロンプトまで、現場で一生役立つベストプラクティスを徹底解説します！...

▲ Day 20: .NET Worker Service（バックグラウンド処理）のコンテナ化 🐳 受講生の皆さん、お疲れ様です！ Docker/コンテナ実践講座の専任講師です。 前回の講義では、DockerfileのGit管理とレイヤーキャッシュ最適化をマスターし、チーム開発における高速ビルドの基盤を完成させました。 本日は、エンタープライズ開発でWeb APIと並んで頻出する 「常駐型バッチ・非同期キュー処理（.NET Worker Service）」のコンテナ化 を解説します！ かつてWindowsサービス（ sc.exe ）で構築していた常駐プログラムを、なぜコンテナ化すべきなのか？そしてコンテナ停止時にデータを絶対に壊さない 「Graceful Shutdown（安全な終了）」の実装極意 を徹底解剖します！ ① 導入・本日の達成目標 「Webアプリのコンテナ化はイメージが湧くけれど、深夜の定期バッチやメッセージキューを監視し続ける常駐ワーカーはどうやってコンテナ化するの？」 「 docker stop でコンテナを止めたら、処理中のDB書き込みや外部API通信が途中で強制切断されてデータが破損しないの？」 長年Windows Serverで常駐サービスを運用してきたエンジニアほど、このような疑問や不安を抱くはずです。 コンテナは「エフェメラル（使い捨て可能）」な思想で作られていますが、 「いつでも乱暴に電源を切ってよい」という意味ではありません。 停止要求を受け取った際に、実行中のタスクをキリの良いところまで完遂してから安全に終了する仕組みこそが、実務で絶対に外せない 「Graceful Shutdown」 です。 本日の講義を修了すると、以下の3大目標を完全に達成できます。 ...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 16では、リリースポイントを永遠に刻む「git tag」と、セマンティックバージョニングおよび.csprojの連動手法を学びましたね。 さて、本日から本講座はいよいよ 【第4部: 現場の実践ルール＆規約】 へと突入します！ これまではGitの基本コマンドやマージ・リベースの仕組みを解説してきましたが、実際の開発現場で最も多くのエンジニアが頭を悩ませるのが 「ブランチは一体いつ切り、いつ統合（マージ）すべきなのか？」 という運用の絶対原則です。 Subversion (SVN) や VSS を長年使ってきたベテランエンジニアほど、「ブランチを切ると後でマージが大変だから滅多に切りたくない…」「リリース直前まで何ヶ月もブランチを放置してしまう」という心理的ブレーキが働きがちです。 しかし、Gitの真価を発揮するためには 「1タスク1ブランチ」「数時間〜数日で破棄する短命ブランチ」 という全く新しい思考法（パラダイムシフト）が不可欠です！ 本日は、ブランチを作成する3大タイミング、mainへ安全に合流させる3大絶対条件、そしてマージ地獄を根絶する短命ブランチ戦略まで、C#現場の実践例とともに徹底解説します！ ① 導入・本日の達成目標 チーム開発において、Gitのコマンドを知っていることと、「チームとして混乱なく開発を進められること」は別物です。 もしメンバーが思い思いのタイミングでブランチを切り、何週間も放置したあとに巨大な差分をいきなりマージしようとすれば、プロジェクトは確実に 「マージ地獄」 に陥り、ビルドエラーとデグレの嵐に見舞われます。 🎯 本日のゴール SVNの「長命・重量級ブランチ」とGitの...

▲ Day 19: DockerfileをGitにコミットしチーム共有するベストプラクティス 🐳 受講生の皆さん、お疲れ様です！ Docker/コンテナ実践講座の専任講師です。 前回の講義では .dockerignore を活用してビルド転送量を劇的に軽量化し、C#の bin/ や obj/ 混入事故を完全に防ぐ方法をマスターしました。 本日は、チーム開発における最大の関門である 「DockerfileをGitリポジトリにコミットし、全員で安全・爆速に共有するためのベストプラクティス」 を学びます！ 「書き方ひとつでビルド時間が100倍変わる」Dockerレイヤーキャッシュの最適化と、チーム開発で絶対に破綻させないコーディング規約を徹底伝授します！ ① 導入・本日の達成目標 「DockerfileをGitに共有したけれど、C#のコードを1行修正するたびに毎回3分もビルドに待たされる……」 「メンバーの手元では動いたのに、CIサーバーや新人のPCでビルドしたらNuGetパッケージの不整合でエラーになった……」 このような経験はありませんか？ 従来のサーバー構築では「手順書」に従って手作業でコマンドを実行していたため、作業順序が違っても最終的な状態が合っていれば問題ありませんでした。 しかしDockerの世界では、 「命令を書く順番」がキャッシュ効率とビルド時間を決定づけ、チーム全体の生産性を大きく左右 します！ 本日の講義をマスターすることで、以下の3つの重要ゴールを達成できます。 Dockerレイヤーキャッシュの無効化メカニズム を論理理解し、キャッシュヒット率99%を達成する命令順序を設計できる。 C#/.NET開発における 「.csproj 先行コピー ➡...