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

投稿

注目の投稿

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

最近の投稿

【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%の定型作業を高速代行する時代において、 人間のエンジニアが担うべき『最終コードレビューとマージ承認の絶対原則』 まで、実践的なプロの技術を分かりやすくお伝えします! ...

【Day 28】ボリューム(Named Volume)によるSQL Serverデータの安全な永続化 〜Docker管理領域によるmdf/ldfファイルの完全保護、docker-compose.ymlでのボリューム定義構文、一時コンテナを用いた安全バックアップ・リストア術、C# EF Core現場でのデータ保持〜

▲ Day 28: ボリューム(Named Volume)によるSQL Serverデータの安全な永続化 🐳 「物理サーバーのDドライブのように、SQL ServerのDBレコードを安全に守り抜くにはどうすればいいのか?」 前回のDay 27では、Dockerコンテナが「いつでも使い捨てて作り直せるステートレスなプロセス」であり、何も設定せずにデータを書き込むとコンテナ破棄( docker compose down )と同時にデータが消滅する原理を学びました。 では、業務システムの要である SQL Server のデータベース(.mdf / .ldf) は、具体的にどのように保護すべきなのでしょうか? その答えが、Dockerが推奨する 「名前付きボリューム(Named Volume)」 です! 本講義では、SQL Server公式Linuxコンテナのデータ格納構造( /var/opt/mssql/data )を解剖し、 docker-compose.yml での正しいボリューム宣言、一時コンテナを用いた安全バックアップ&リストア手法、そしてC# / Entity Framework Core開発における超快適なデータ保護サイクルを徹底解説します! INDEX 本日の講義カリキュラム 第1章: 名前付きボリューム(Named Volume)の基本と仕組み 〜ホスト管理領域の完全隔離〜 第2章: SQL Server Linuxコンテナのデータ格納構造(/var/opt/mssql/data の秘密) 第3章: docker-compose.yml での volumes 定義構文...