Qiita Engineer Festa20242024年7月17日まで開催中！

Qiita 投稿マラソン 2024 - DevOps 編 12 日目継続的デリバリーのための Git ブランチモデルを確認する

Last updated at 2024-08-29Posted at 2024-06-22

Qiita Engineer Festa 2024（キータ・エンジニア・フェスタ 2024） - Qiita

投稿マラソン
Qiita Engineer Festa 2024 の記事投稿キャンペーンに紐づけて19記事投稿すると、「Qiitaオリジナルグッズ」を必ずプレゼント！38記事投稿すると更に特別な「Qiitaオリジナルグッズセット」を必ずプレゼント！

とのことで「学び」を強制的に自分に課したいな、どこまで走れるか分からないがちょうど目の前に、学びたい Azure DevOps Services | Microsoft Azure があるじゃない、これをテーマに走り出してみたら良いじゃないという個人的コミット駆動です。

本日のタイトル: 継続的デリバリーのための Git ブランチモデルを確認する

エンタープライズ DevOps の開発 - Training | Microsoft Learn

ブランチの戦略とワークフローを設計し、実装する - Training | Microsoft Learn

継続的デリバリーのための Git ブランチモデルを確認する - Training | Microsoft Learn

プロセスのオーバーヘッドが多すぎるブランチモデルは、顧客に変更を加える速度を上げるのに役立ちません。ブランチモデルを開発すると、品質の低い変更を出荷しないための十分なパディングが得られます。ただし、速度を低下するほど多くのプロセスを導入することはありません。

インターネットには、Git 用のブランチ戦略があふれています。正しいか間違っているかではなく、チームに最適なブランチ戦略が役立ちます。

Git ブランチポリシーと設定 - Azure Repos | Microsoft Learn
ブランチポリシー - Azure Repos | Microsoft Learn

レビュー担当者の最少数を要求する
リンクされた作業項目を確認する
コメント解決の有無を確認する
マージの種類を制限する
ビルドの検証
状態の確認
コードのレビュー担当者を自動的に含める
ブランチポリシーをバイパスする

既存の Git リポジトリを複製する - Azure Repos | Microsoft Learn

forking ワークフローでは、フォークを作成してローカルで複製し、ローカルで変更を加えてブランチにプッシュし、アップストリームに PR を作成して完了したら、フォークをアップストリームから最新版に同期します

演習

演習: Git をローカルで操作する方法を説明する - Training | Microsoft Learn

dotnet new mvc

でこれができる。驚き。

拡張機能など

GitLens — Git supercharged
Pull Request Merge Conflict Extension - Visual Studio Marketplace

「正しいか間違っているかではなく、チームに最適なブランチ戦略」とのことで、以下などが参考になりそう。

Azure Reposでブランチポリシーを設定する方法 #AzureDevOps - Qiita
チームでのアプリ開発におけるブランチ戦略とプルリクエストのマージ方法

Gitにおけるブランチ戦略について調べてみた #git-flow - Qiita
【第1回】Gitブランチ戦略について調べた（前編）
【第2回】Gitブランチ戦略について調べた（後編）

に記されているプラクティスが面白いのでメモ。

プラクティス

Microsoft による DevOps 開発手法

トランクベースの分岐戦略

さまざまなニーズに対応するために、Microsoft はトランクベースの分岐戦略を使用して、製品を迅速に開発し、定期的に展開し、変更を運用環境に安全に配信できるようにしています。

プラットフォームエンジニアリングの原則

Microsoft では、One Engineering System の一部としてプラットフォームエンジニアリングの原則も使用しています。

ブランチと機能フラグ

バグを修正したり機能を実装したりするには、開発者はメインの統合ブランチから新しいブランチを作成します。 Git の軽量ブランチモデルは、コードのコントリビューションごとに、これらの短期間の topic ブランチを作成します。開発者は機能フラグを使用して早期にコミットし、長時間実行される機能ブランチを回避します。

2 つの別々の概念があります。リングはデプロイメント用であり、ステージは機能フラグ用です。リングとステージについて詳しくご覧ください。

独自の機能フラグインフラストラクチャを構築することも可能ですが、一般的には LaunchDarkly または Split のようなプラットフォームを採用することをお勧めします。機能フラグ機能を再構築するのではなく、機能の構築に投資することをお勧めします。

機能フラグを使用して実行時間の長いブランチを管理する

機能ブランチに名前を付ける際の推奨事項

機能ブランチに名前を付ける際の推奨事項は次のとおりです。

ユーザー/ユーザー名/説明

ユーザー/ユーザー名/作業項目

バグ修正/説明

機能/機能名

機能/機能領域/機能名

修正プログラム/説明

正常な pull request に関するいくつかの推奨事項

正常な pull request に関するいくつかの推奨事項は次のとおりです。

レビュー担当者 2 名が、調査に基づく最適な数です。

チームに既にコード確認プロセスがある場合は、既に実行している内容に pull request を取り込みます。

同じレビュー担当者を多数の pull request に割り当てる際には注意してください。レビュー担当者の責任がチーム全体で共有されている場合、pull request の機能が向上します。

十分に詳しい説明を提供して、レビュー担当者が変更を迅速に処理できるようにします。

pull request のあるステージされている環境で実行されている変更のビルドまたはリンクされたバージョンを含めます。他のユーザーは、容易に変更をテストできます。

本日のまとめ

2024.06.24 個人的注目記事
Gitでコード管理する際の運用ガイドライン #コードレビュー - Qiita

つづく
次回は「技術的負債を特定する」を見ますー。

技術的負債を特定する - Training | Microsoft Learn
GitHub Advanced Security の概要 - Training | Microsoft Learn

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Qiita 投稿マラソン 2024 - DevOps 編 12 日目 継続的デリバリーのための Git ブランチ モデルを確認する

本日のタイトル: 継続的デリバリーのための Git ブランチ モデルを確認する

演習