スキップしてメイン コンテンツに移動

投稿

注目の投稿

【Day 28】git add -p で必要な行だけを綺麗にコミットする部分ステージング技

最近の投稿

【Day 30】Git管理すべきファイルとVolumeに逃がすべきデータの境界線 〜コード(Git)・構成(Git/.env)・データ(Volume)の3層分離、巨大mdfバイナリ混入事故の防止、.gitignore徹底、チーム開発共有ルール〜

▲ Day 30: Git管理すべきファイルとVolumeに逃がすべきデータの境界線 🐳 「Dockerプロジェクト内のファイル、何でもGitにコミットしていませんか?」 前回のDay 29では、ホストPCとコンテナを直結してC#のホットリロードを実現する「バインドマウント(Bind Mount)」を学びました。 コンテナ環境でのデータ永続化(Named Volume)と高速開発(Bind Mount)の両輪を手に入れた開発チームが、次に必ず直面するのが 「プロジェクト内のどのファイルをGitで管理し、何をVolumeやローカルに逃がすべきか?」という境界線の問題 です。 昔のオンプレミス現場では、ファイルサーバーの共有フォルダにソースコード、SQL Serverの .mdf ファイル、設定ファイル、果てはログまで何でも放り込み、誰かが上書きしてDBが破損するなどの地獄絵図が日常茶飯事でした。 もしこの悪習をそのまま現代のGit×Docker環境に持ち込み、 巨大なデータベースファイルをGitにコミットしてしまうと、リポジトリが数十GBに膨れ上がり、チーム全員のPCでクローン不能になる壊滅的事故 を引き起こします。 本講義は第6部「データの永続化とボリューム」の総決算として、 「コード(Git)」「構成(Git/.env)」「データ(Volume)」の3層分離原則 と、事故を未然に防ぐ現場ルールを完全解説します! INDEX 本日の講義カリキュラム 第1章: 共有フォルダ破綻の歴史に学ぶ 〜なぜ「何でも詰め込み」は失敗するのか?〜 第2章: 現代コンテナ開発における「...

【Day 27】git worktree で再ビルドなしの超高速ブランチ並行開発

▲ 【Day 27】git worktree で再ビルドなしの超高速ブランチ並行開発 👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 26では、第5部の集大成として「AIエージェントを活用したケーススタディ自動実行(Issue-to-PR)」を学び、現代の自律型コーディング環境とGitの強力な連携をマスターしました。 そして本日のDay 27より、いよいよ 【第6部: プロの調査・保守・作業効率化テクニック】 がスタートします! 第1弾のテーマは、チーム開発や現場で活躍する全エンジニアに知ってほしいGitの神機能—— 【git worktree で再ビルドなしの超高速ブランチ並行開発】 です! 「新機能の開発に没頭している最中、突然本番環境で緊急障害が発生して調査を頼まれた……。ブランチを切り替えたら、Visual Studioが巨大なC#ソリューション全体をゼロから再ビルドし始め、NuGetパッケージの再復元で10分以上待たされた」 「調査が終わって元のブランチに戻ってきたら、またしても全件再ビルドで待ち時間……。開いていたタブやブレークポイントも消えて集中力が完全に削がれた」 こうした苦い経験は、エンジニアなら誰しも一度はあるはずです。 かつてのSubversion (SVN) では別フォルダにチェックアウトして複数開くことができましたが、Gitでも完全に別のフォルダへ別ブランチを即時展開し、Visual Studioを2つ同時に開いて並行デバッグできる仕組みが存在します。それが git worktree です! リポジトリを丸ごと別cloneする必要はありません。コミット履歴やローカルブランチは完全に共有されたまま、ワーキングディレクトリとビルド生成物(bin/obj)だけを物理的に分離できます。 本日は、この git worktre...

【Day 29】バインドマウント(Bind Mount)によるソースコード即時反映(ホットリロード) 〜ホストとコンテナのディレクトリ直結、dotnet watch run による変更検知と自動再起動、WSL2ファイルイベント伝搬の注意点、快適なC#ローカル開発環境の構築〜

▲ Day 29: バインドマウント(Bind Mount)によるソースコード即時反映(ホットリロード) 🐳 「C#コードを1行直すたびに docker compose build するの!? 待ち時間が長すぎて開発にならないよ!」 前回のDay 28では、SQL ServerのDBデータを安全に保護する「Named Volume(名前付きボリューム)」を学びました。 しかし、日々のアプリケーション開発現場で同じようにボリュームを扱おうとすると、多くのエンジニアが大きな壁にぶつかります。 「コードを修正するたびに、毎回イメージの再ビルド( docker compose up --build )を待たなければいけないのか?」 答えはもちろん NO です! Dockerには、ホストPC上のソースコードフォルダをコンテナ内に直接パイプで繋ぐ 「バインドマウント(Bind Mount)」 という強力な仕組みが用意されています。 さらにC#の dotnet watch コマンドと組み合わせることで、 「ホストのVisual StudioやVS Codeでコードを保存(Ctrl+S)した瞬間、コンテナ内のアプリがミリ秒で自動更新されるホットリロード環境」 が実現します! 本講義では、バインドマウントの原理、 docker-compose.yml の設定法、そしてWSL2環境で多くの人がハマる「変更検知トラブル」の完全解決策までを徹底解説します! INDEX 本日の講義カリキュラム 第1章: バインドマウント(Bind Mount)の基本...

【Day 26】【Case 6】AIエージェントを活用したケーススタディ自動実行

▲ 【Day 26】AIエージェント併用ケーススタディ(実務応用) 👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 25では、急な仕様変更や機能リリース順序の入れ替えにスマートに対応する「チェリーピック(git cherry-pick)」の実践テクニックを学びました。 本日のDay 26は、第5部「開発フェーズ別・現場ケーススタディ」の集大成として、現代のソフトウェア開発を根底から変革しつつある最先端テーマ—— 【AIエージェントを活用したケーススタディ自動実行(Issue-to-PR)】 を徹底解説します! いま、ソフトウェア開発の現場では Google Antigravity や Claude Code といった自律型AIコーディングエージェントの導入が急速に進んでいます。 かつてエンジニアが手作業で行っていた「チケット確認・ブランチ作成・ソース調査・コード修正・単体テスト実行・プルリクエスト作成」という一連の定型業務は、いまや 『Issue #101 のバグ修正用ブランチを切り、修正してPRを作って』 とプロンプトで一括指示するだけで、AIがターミナルとGitを操作して自律的に完走できるようになりました。 「AIにコードを書かせたら、思わぬバグが混入したりブランチが壊れたりしないのか?」「Gitのブランチ戦略やテスト自動化とどう組み合わせれば安全なのか?」と疑問に思う方も多いでしょう。 本日は、C#現場で頻発する NullReferenceException の障害Issueを題材に、AIエージェントによる「自律ブランチ作成からプルリク起票まで」の完全シミュレーションをお見せします! さらに、AIが90%の定型作業を高速代行する時代において、 人間のエンジニアが担うべき『最終コードレビューとマージ承認の絶対原則』 まで、実践的なプロの技術を分かりやすくお伝えします! ...