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

投稿

注目の投稿

【Day 17】ブランチは「いつ切り、いつ統合するのか?」その絶対原則

最近の投稿

【Day 19】Dockerfileを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 先行コピー ➡...

【Day 16】リリースポイントを記録する(git tag)

👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 15では、作業途中の書きかけコードを安全に退避できる救世主コマンド「git stash」と、未追跡ファイルを置き去りにしない -u オプションの鉄則を学びましたね。 さて、開発作業やテストが無事に完了し、いよいよ顧客やユーザーに届ける 「本番リリース」の瞬間 がやってきました! このとき、皆さんは 「リリースした時点のソースコード」 をどのように記録・保管していますでしょうか? Subversion (SVN) や VSS を使っていたベテランエンジニアの方なら、 「サーバーの /tags/v1.0.0/ フォルダにプロジェクト全体を丸ごとコピーして保存していた」 という経験があるかと思います。 しかし、Gitではフォルダコピーのような重たく危険な方法は一切使いません! Gitには、特定の完成コミットに対して永遠に動かない目印をペタッと貼り付ける超軽量コマンド 「git tag(タグ)」 が用意されています。 本日は、Gitのタグの仕組み、本番運用で必須となる「注釈付き(Annotated)タグ」、C#のバージョン定義(セマンティックバージョニング)との連動、そしてTortoiseGitでの直感操作まで、現場で即役立つプロの技を徹底解説します! ① 導入・本日の達成目標 ソフトウェア開発において、 「過去にリリースしたバージョンのコードを、何年後でも1ミリの狂いもなく完全再現できること」 は、品質保証とサポートにおける絶対条件です。 もしユーザーから「2年前に納品されたバージョン1.0.0で重大な不具合が出た」と報告された時、「どのコミットがバージョン1.0.0だったか分からない」では話になりません。 🎯 本日の...

【Day 18】.dockerignore の完全攻略(.git や bin/obj を除外して爆速ビルド)

▲ Day 18: .dockerignore の完全攻略(.git や bin/obj を除外して爆速ビルド) 🐳 皆さん、こんにちは! Docker/コンテナ実践講座の専任講師です。 前回(Day 17)では、SDKイメージとRuntimeイメージを分離してイメージサイズを劇的に軽量化する「マルチステージビルド」をマスターしました。 しかし、現場で実際に docker build を叩いていると、こんな違和感に直面したことはありませんか? 「ソースコードを1行直しただけなのに、ビルド開始時に何十秒も待たされる…」 「PCのファンが爆音で回り、ギガバイト単位の転送中プログレスが表示される…」 その元凶こそが、今回攻略する 『ビルドコンテキスト(Build Context)への不要ファイルの無差別転送』 です! 本日学ぶ .dockerignore は、ビルド速度を秒速化するだけでなく、Git履歴や認証鍵の漏洩を水際で防ぐ 現場の絶対必須スキル です! ① 導入・本日の達成目標 Docker初心者が最も陥りやすい落とし穴が、「 .dockerignore を作らずに docker build . を実行してしまうこと」です。 この設定を怠ると、Gitの膨大なコミット履歴( .git フォルダ)や、Windowsローカルでビルドされた巨大な bin/ ・ obj/ フォルダ、さらには秘密情報を含む開発用設定ファイルまで、すべてがコンテナのビルド領域に無防備に送り込まれてしまいます。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 ビルドコンテキスト転送の仕組み を理解し、なぜ .dockerignore がビルド爆速化に直結するのかを...

【Day 15】作業途中の緊急退避(git stash)

👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 14では、コミット履歴を美しく一本道に整頓する「リベース(git rebase)」と、絶対に破ってはいけない公開ブランチの黄金律について詳しく学びましたね。 さて、開発の現場で日常茶飯事のように起きるのが、 「新機能のコードを書いている最中に、本番環境で緊急バグが発覚した!」 というトラブルです。 Visual Studioを開けば、画面には赤波線(コンパイルエラー)だらけの書きかけコード。この状態のままコミットしたくはないし、かといって別のブランチ(緊急修正用ブランチ)に切り替えようとすると、Gitに「未コミットの変更があるため切り替えできません」と怒られてしまう……。 Subversion (SVN) 時代なら、泣く泣く差分パッチファイルを手動エクスポートしたり、作業フォルダを丸ごとZIP圧縮してデスクトップに避難させていたのではないでしょうか? ご安心ください! Gitには、そんな絶体絶命のピンチをわずか1秒で解決してくれる魔法のコマンド 「git stash(スタッシュ)」 が用意されています。 本日は、書きかけコードを安全な引き出しに一時退避し、何事もなかったかのように作業ツリーをクリーンにするプロの必須テクニックを徹底解説します! ① 導入・本日の達成目標 「stash」とは、英語で 「(安全な場所に)隠す、一時的にしまい込む」 という意味です。 Gitのstash機能を使えば、コミット前の変更(作業ツリーやインデックス)を丸ごと一時退避領域(スタック)へと退避させ、作業ディレクトリを直前のきれいな状態(直前のコミット直後)に一瞬でリセットできます。 本日の講義でマスターする達成目標は以下の3点です! ...

【Day 17】マルチステージビルド(SDKイメージ vs 軽量Runtimeイメージの分離)

▲ Day 17: マルチステージビルド(SDKイメージ vs 軽量Runtimeイメージの分離) 🐳 皆さん、こんにちは! Docker/コンテナ実践講座の専任講師です。 前回(Day 16)では、C# / ASP.NET Core Web API をコンテナ化するための「初めてのDockerfile構文(FROM, WORKDIR, COPY, RUN, ENTRYPOINT)」を学びました。 しかし、前回の単純なDockerfileには 「イメージサイズが800MB超に肥大化してしまう」「本番環境にコンパイラやソースコードが丸見えで残ってしまう」 という重大な課題がありました。 本日学ぶ 『マルチステージビルド(Multi-stage builds)』 は、この問題を完璧に解決し、現場のDockerイメージ作成において 100%必須とされる最重要テクニック です! 開発環境と本番サーバーの分離を30年間実践してきたベテランエンジニアの皆様なら、その合理性に思わず膝を打つはずです。じっくりマスターしていきましょう! ① 導入・本日の達成目標 一般的なアプリケーション開発では、「ビルドに必要な道具(巨大なSDK、コンパイラ、開発用ヘッダー、NuGetキャッシュ)」と「本番で動かすために必要なもの(最小限のランタイムと発行済みDLL群)」は全く異なります。 もしビルド環境をそのまま本番コンテナに含めてしまうと、ディスク容量を圧迫するだけでなく、余計なツール類がサイバー攻撃の足場(攻撃対象領域: Attack Surface)となってしまいます。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 マルチステージビルドの概念と、1つのDockerfile内で 複数の FROM を使い分ける仕組み を論...

【Day 14】履歴を美しく整える「リベース(git rebase)」入門

👨‍🏫 皆さん、こんにちは! 本講座の専任講師です。 前回のDay 13では、チーム開発の登竜門である「コンフリクト(競合)解消」を学び、Gitの衝突マーカーやTortoiseMergeの3画面比較、さらにはAIを活用したスマートな統合手法をマスターしましたね。 さて、ブランチを合流させる手段として前回まで「マージ(git merge)」を使ってきましたが、Gitにはもう一つ、プロの開発者が愛用する極めて強力な合流・整頓コマンドが存在します。 それが本日学ぶ 「リベース(git rebase)」 です! Subversion (SVN) や Visual SourceSafe (VSS) に長く慣れ親しんだエンジニアの方にとって、「過去の分岐点を付け替える」「コミット履歴を一本の直線に作り直す」という概念は、最初まさに異次元の魔法のように感じられるでしょう。 「リベースを使うと何が嬉しいのか?」「マージと何が違うのか?」そして何より 「絶対にやってはいけない禁忌(リベースの黄金律)」 とは何か? Windows/C#エンジニアの視点から、TortoiseGitの直感操作も交えて世界一わかりやすく徹底解説します! ① 導入・本日の達成目標 「Gitのコミットグラフが複雑に枝分かれして、まるでタコ足配線やスパゲッティのように絡み合って読めない……」 開発が長期化したりメンバーが増えたりすると、無数の「マージコミット」が乱立し、どの機能がいつどこで入ったのか履歴を追うのが困難になることがあります。 この問題を解決し、 「あたかも最初から一直線に開発が進んでいたかのような、美しく整然とした履歴」 を作り出すのが「リベース」の役割です。 本日の講義でマスターする達成目標は以下の3点です! ...