仮想空間の日常

▲ Day 22: C# Web API ＋ SQL Server の連携環境をcomposeで一発構築 🐳 受講生の皆さん、お疲れ様です！ Docker/コンテナ実践講座の専任講師です。 前回【Day 21】では、複数のコンテナを1行でまとめて動かす「Docker Compose」の全体像と宣言的YAMLの基本を学びました。 そして本日【Day 22】は、C#/.NETエンジニアにとって最も実務直結であり、最も頻出する黄金の組み合わせ 「ASP.NET Core Web API ＋ Microsoft SQL Server」 のマルチコンテナ連携ハンズオンに挑みます！ 開発者PCを重厚なSQL Serverのインストールで汚す悪夢から完全に脱却し、 docker compose up -d のたった1コマンドで、完全なデータベース付き開発環境を一瞬で立ち上げるモダンな開発フローを体感しましょう！ ① 導入・本日の達成目標 「プロジェクト参画初日、開発PCにSQL Server Developer Editionをインストールするだけで半日終わった…」 「同僚のPCでは動くのに、私のPCではSQLの照合順序（Collation）や大文字小文字の区別設定が違っていてクエリエラーになる…」 「ローカルのSQL Serverサービスが常駐しているせいで、ノートPCのメモリが圧迫されてVisual Studioの動作がもっさりする…」 長年Windows環境でC#開発に携わってきたベテランエンジニアほど、このような 「ローカルDB個別インストール地獄」 に苦しめられた経験があるはずです。 しかし、現在マイクロソフトは 公式のLinux版SQL Serverコンテナイメージ（ mcr.microsoft.com/mssql/server ） を無償提供しており、...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 18では、世界標準のブランチ命名規則とチケット連携フォーマットをマスターしましたね。 さて、本日のテーマは、チーム開発の信頼性を決定づける最も重要な作法、 「プロのコミットメッセージ・プッシュ作法（Conventional Commits）」 です！ ITエンジニア歴30年以上の皆さん、Subversion (SVN) や Visual SourceSafe (VSS) で開発していた当時、コミットログに「修正」「更新」「完了」「20261017作業」といった一言だけを書いて終わらせていませんでしたか？ 集中型SVNではコミットログが多少雑でも、フォルダ単位の最新状態さえ動いていれば何とかなっていたかもしれません。 しかし、GitとGitHubを基盤とする現代のチーム開発では、コミットメッセージは 「未来の自分や仲間へ送る設計意図の手紙」 であり、 「CI/CDによるリリースノート自動生成の入力データ」 そのものです。 もし「修正」としか書かれていないコミットにバグが混入していたら、 git blame や git bisect で調査しても「なぜこのコードを追加したのか（Why）」が全く分からず、誰も修正できなくなってしまいます。 本日は、世界共通の規約である『Conventional Commits』の基本型から、プロが実践する『黄金3段構成（要約・空行・Why本文）』、C#現場でのバグ修正Before/After、そしてCopilotやClaudeを使ったAI自動生成テクニックまで余すところなく解説します！ ① 導入・本日の達成目標 「コミットメッセージなんて、自分が後でなんとなく思い出せればいい」——もしそう思っているなら、今すぐその意識を変える必要があります...

▲ 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大目標を完全に達成できます。 ...