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

投稿

注目の投稿

【Day 27】コンテナを破棄するとデータが消える!? データの永続化の原理 〜書き込み可能レイヤー(OverlayFS)の消滅、ステートレス設計、Volume vs Bind Mount の使い分け、C#ログ・画像保存設計〜

最近の投稿

【Day 24】【Case 4】本番障害! 緊急バグ修正(Hotfix)の完全手順

▲ 【Day 24】本番障害! 緊急バグ修正(Hotfix)の完全手順 👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 23では、製品リリースの総仕上げとして、mainマージ、注釈付きタグ(Annotated Tag)打刻、そしてdevelopへのマージバックによる安定バージョンの凍結サイクルを学びました。 本日のDay 24は、現場のエンジニアが最も緊張感を強いられる実践ケーススタディ—— 【本番障害! 緊急バグ修正(Hotfix)の完全手順】 を徹底講義します! 金曜日の夕方やサービス公開直後、「本番環境でユーザーの特定操作によってC#アプリが突然クラッシュした!」「至急パッチを当ててほしい!」という緊急アラートが鳴り響いた経験は、ベテランエンジニアなら誰しも一度はあるはずです。 Subversion (SVN) や Visual SourceSafe (VSS) で開発していた現場では、中央のトランク(trunk)にすでに次期バージョンの未完成コードや実験的コードがコミットされているため、本番修正を行うには「過去のリビジョンに戻してコードを手動で修正し、本番用バイナリをビルドしたあと、トランクにも手動で差分をコピペする」という恐ろしい二重管理を強いられていました。その結果、本番に未完成機能が誤って混入したり、トランクへの反映漏れで次のリリース時に直したはずのバグが復活する(先祖返り)大事故が日常茶飯事でした。 しかしGitなら、本番稼働中の安定コミット(mainブランチまたはv1.0.0タグ)から直接 「hotfix/* ブランチ」 をわずか1秒で切り出すことができます! 現在developブランチで進んでいる次期機能の開発中コードには指一本触れず、完全に隔離された安全な環境で最小限の緊急パッチを作成・検証できます。そして即座にmainへマージして新パッチタグ(v1.0.1)を打ち、最後にdevelopへもマージ...

【Day 26】docker compose up / down / build の実務コマンド完全マスター 〜バックグラウンド起動(-d)、差分再ビルド(--build)、ログ監視、コンテナ・ボリューム完全初期化(down -v)の実務頻出ワークフローとC#開発サイクル〜

▲ Day 26: docker compose up / down / build の実務コマンド完全マスター 🐳 「C#コードを直したのにコンテナに反映されない…」「DBを初期状態にやり直したい…」と悩んでいませんか? Windows ServerやIIS、物理サーバーで長年システム構築・運用に携わってきたベテランエンジニアにとって、「サービスの再起動」や「設定反映」「テストデータ初期化」は、GUIツールや手動バッチで行うのが日常茶飯事でした。 しかしDocker Composeを導入すると、 「 docker compose up を叩いても古いイメージのまま起動する」「ターミナルがログ出力で埋まって次の操作ができない」「コンテナを消したのに前回の古いDBデータがゾンビのように残っている」 という独特の挙動に戸惑う方が続出します。 本講義では、実務の現場で毎日何十回と叩くことになる up / down / build / ps / logs の黄金オプションとライフサイクル を徹底解説し、C#/.NET開発における超高速でクリーンな開発サイクルを確立します! INDEX 本日の講義カリキュラム 最速・確実な起動コマンド: docker compose up -d --build の全貌 データの運命を分ける停止コマンド: down vs down -v の決定的な違い 状態監視とトラブルシューティング: docker compose ps と logs -f Gitブランチ運用と連動するC#現場の最短開発ワークフロー 実務頻出 Compo...

【Day 23】【Case 3】本番リリースとタグ打ち(安定バージョンの凍結)

▲ 【Day 23】本番リリースとタグ打ち(安定バージョンの凍結) 👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 22では、リリースブランチ( release/v1.0.0 )を活用して、次期新機能開発をブロックせずにステージング検証とバグ修正だけを綺麗に収束させる手法を学びました。 本日のDay 23は、第5部 ケーススタディの第3弾として、開発サイクルの集大成である 【本番リリースとタグ打ち(安定バージョンの凍結)】 を徹底解説します! Subversion (SVN) や Visual SourceSafe (VSS) で長年開発されてきたベテランエンジニアの方なら、「リリース時に tags フォルダへ丸ごとコピーしたけれど、後から誰かが tags 配下のファイルを直接編集・コミットしてしまい、リリース時と実際のバイナリが一致しなくなった」「リビジョン番号が大きすぎてどのコミットが製品版かわからない」といった苦いトラブルを経験したことがあるはずです。 Gitのタグ機能は、特定コミットに対する 「暗号学的に改ざん不可能な不変のピン留め」 です。特に「注釈付きタグ(Annotated Tag)」を使えば、リリース担当者の署名・日時・リリースノートがリポジトリ内に永久に記録され、いつでも寸分の狂いもなく過去のリリース状態を100%再現できます。 本日は、検証完了後の安全なmainマージ手順、セマンティックバージョニング(v1.0.0)に基づくタグ打ち、C#のアセンブリバージョン( Directory.Build.props )とGitHub Releasesの自動公開連携、そしてリリース直後に絶対に忘れてはならない 「developへのマージバック(先祖返り完全防止)」 まで、現場で即座に役立つ実践ノウハウを完全網羅してお届けします! ① 導入・本日の達成目標 結合テ...

【Day 25】複数環境設定の切り替え(docker-compose.override.yml) 〜ローカル開発とCI・本番の構成を安全に多重合成するベストプラクティスとC#環境分離設計〜

▲ Day 25: 複数環境設定の切り替え(docker-compose.override.yml) 🔀 受講生の皆さん、お疲れ様です! Docker/コンテナ実践講座の専任講師です。 前回【Day 24】では、 .env と .gitignore を駆使してパスワードや機密情報を安全に隔離し、Gitリポジトリをチーム共有するセキュリティ手法を学びました。 これで安全なマルチコンテナ環境が整いましたが、次のステップとして 「環境ごとの構成の違い」 という現場特有の壁に直面します! 「開発環境ではホストPCからSQL ServerやRedisに直接GUIツールで繋ぎたいからポートを公開したい」「でも本番やCI環境では余計なポートは絶対に塞ぎたい」「ソースコードのホットリロードはローカルだけに適用したい」… 環境ごとにYAMLファイルを丸ごとコピーして別名保存していませんか? 本日【Day 25】は、Docker Compose最強の拡張機能である 「 docker-compose.override.yml による構成の自動多重合成」 と、 「C#(ASPNETCORE_ENVIRONMENT)と連動した環境切り替え設計」 を完全攻略します! ① 導入・本日の達成目標 Docker ComposeでWeb APIとDBを定義した docker-compose.yml を運用していると、必ず以下のようなジレンマが生まれます。 ⚠️ 現場で陥りがちなアンチパターン(構成ファイルの丸ごとコピー増殖): 開発用の設定と本番用の設定を分けたいあまり、 docker-compose.dev.yml と docker-compose.prod.yml をそれぞれフルセットで作成してしまう。 その結果、共通のDBサービス定義や環...