リリース ベースのワークフローとは
ここでは、GitHub を使用してリリース ベースのワークフローを作成する方法について説明します。
リリース ベースのワークフローとは
リリース ベースのワークフローは、ソフトウェアのリリースに重点を置いた一連のパターンとポリシーです。 この概念は開発チームにとって明らかな目標のように思えるかもしれませんが、この視点の価値はより微妙です。 このユニットでは、3 つの異なるリリース サイクルの部分 (プロジェクトの管理、ブランチ戦略の選択、顧客へのリリース) について説明します。
GitHub プロジェクト ボードを使用して作業を計画する
計画の考え方からすると、リリース中心であることは、イシューが新しいバージョンを生成する個別のイテレーションに分割されることを意味します。 これらのイテレーションは、"スプリント" と呼ばれることがよくあり、増分変更を生成するためにほぼ同じ期間でタイムボックス化されます。 他のチームは、リリース バージョン全体を数か月以上続く 1 つのイテレーションにパッケージ化することを好みます。 GitHub では、これらのイテレーションは プロジェクトとして管理されます。
プロジェクトの主な特徴は、その ボードです。 ボードはイテレーションの記録の中心計画であり、解決されるすべての カード が含まれています。 カードは、イシュー、プル要求、または一般的なノートだけを表すことができます。
既定では、各カードは To do 列で開始され、作業が始まると 進行中 に移動し、最後に 完了 で終了します。 チームのプロセスに合わせて、これらの列をカスタマイズしたり、さらに列を追加したり、これらのカードとそのプロパティの動きに自動化を適用したりすることができます。
プロジェクト ボードの管理について詳しくは、こちらをご覧ください。
カードのプロジェクトの状態は、リポジトリ全体に統合されています。 たとえば、To Do から In progress にカードをドラッグすると、その状態が変更され、プロジェクトのタイトルの横にあるビジュアル インジケーターが更新されます。 緑色のセクションは、 完了としてマークされたカードの部分を示し、紫色は進行中のカード に使用されます。 残りの領域は、まだ開始していないカードの数量を表します。 カードをボードの周りにドラッグするだけでなく、カードをメイン ビューから更新することもできます。
プロジェクト ボードを使用すると、すべての利害関係者が、プロジェクトの状態とベロシティを簡単に理解できます。 また、個々のユーザー、または組織によって所有されているリポジトリのコレクションにスコープを指定したボードを作成することもできます。
プロジェクト ボードを使用して作業の進行状況を追跡する方法について説明します。
特定のマイルストーンを追跡する
チームまたは場合によってはチームのサブセットに対して、GitHub は マイルストーン 追跡を提供します。
マイルストーンは、issue と pull request を優先的に完了することに重点を置いている点で、プロジェクトの追跡に似ています。 ただし、プロジェクトでチームのプロセスに重点が置かれている場合、マイルストーンでは製品に重点が置かれます。
マイルストーンを使用して作業の進行状況を追跡する方法について説明します。
ブランチ戦略を選択する
複数の開発者が並行して作業するリポジトリには、適切に定義されたブランチ戦略が必要です。 プロジェクトの早い段階で統一されたアプローチを採用することで、チームとコードベースの規模が拡大したときに混乱とフラストレーションを軽減することができます。
GitHub フロー
GitHub では、ソフトウェアの共同開発用のプラットフォームを提供するだけでなく、該当する各種機能の使用を最適化するように設計された規定のワークフローも用意されています。 GitHub はほぼすべてのソフトウェア開発プロセスで作業できますが、チームがまだプロセスに落ち着いていない場合は 、GitHub フロー を検討することをお勧めします。
有効期間の長いブランチで作業する
有効期間の長いブランチは、削除されない Git ブランチです。 一部のチームでは、有効期間の短い機能とバグ修正のブランチを優先的に回避することを好みます。 これらのチームにとって、すべての作業の目的は、作業を main にマージするプル要求を生成することです。 このアプローチは、以前のバージョンがサポートされないファーストパーティの Web アプリケーションなど、振り返る必要のないプロジェクトには有効な場合があります。
ただし、有効期間が長いブランチがチームにとって一番の利益になる特定のシナリオがあります。 有効期間が長いブランチの最も一般的なケースは、製品に複数のバージョンがあり、長期間サポートする必要がある場合です。 チームがこのコミットメントを計画する必要がある場合、リポジトリは release-v1.0、release-v2.0 などの標準規則に従う必要があります。 これらのブランチは、書き込みアクセスが制御され、誤って削除されないように、GitHub で保護済みとしてマークする必要もあります。
チームは引き続き main をルート ブランチとして維持し、リリース ブランチの変更がプロジェクトの将来に適合する限り、上流でマージする必要があります。 しかるべき時に、release-v2.0 へのサービス作業でリポジトリが複雑にならないように、release-v3.0 を main ベースにする必要があります。
有効期間が長いブランチのサービス
バグ修正が release-v2.0 ブランチにマージされた後、上流で main に再度マージされたとします。 その後、このバグが release-v1.0 ブランチにも存在していることが検出され、そのバージョンをまだ使用している顧客のために修正プログラムをバックポートする必要がありました。 この修正プログラムをバックポートする最善の方法は何ですか?
main ブランチを release-v1.0 にマージすることは、そのバージョンの一部となることを意図していなかったかなりの数のコミットが含まれるため、実行可能な選択肢ではありません。 同じ理由から、現在の main コミットに release-v1.0 をリベースするという選択肢もありません。
別の方法として、release-v1.0 ブランチで修正プログラムを手動で再実装する方法もありますが、この方法では多くの作業が必要となり、複数のバージョンにわたって適切にスケーリングすることはできません。 ただし、Git では、この問題に対する自動化されたソリューションを cherry-pick コマンドの形式で提供しています。
Git の cherry-pick コマンドとは
git cherry-pick は、あるブランチから別のブランチに特定のコミットを適用できるようにするコマンドです。 単に選択されたコミットを反復処理し、それらを新しいコミットとしてターゲット ブランチに適用します。 必要に応じて、開発者は、バックポートを完了する前に競合をマージできます。
詳細については、Git の cherry-pick に関するページを参照してください。
コンシューマーにリリースする
製品バージョンをリリースする準備が整うと、GitHub によってパッケージ化とコンシューマーへの通知のプロセスが簡略化されます。
バージョンの作成は、フォームに入力するのと同じくらい簡単です。
- 適用する Git タグを入力します。これは、などの
v1.0.2に従う必要があります。 GitHub により、指定した Git タグの作成プロセスが管理されます。 - リリースの名前を入力します。 一般的なプラクティスは次のとおりです。
- わかりやすい名前を使用する
- Git バージョンを使用する
- このリリースが前のものからどのように変更されたかを簡潔に説明する
- コード名またはランダムなフレーズを使用する
- リリース ノートを提供します。 このタスクは、以前のバージョン以降の変更を分析し、関連するプル要求タイトルを含む Release Drafter アプリを使用して自動化できます。
- ビルド済みのインストーラーなど、ファイルをリリースの一部として提供する場合は、それらをフォームにドラッグ アンド ドロップできます。 GitHub で自動的に処理されるため、ソースをパッケージ化する必要はありません。
- そのチェック ボックスをオンにして、バージョンがプレリリースであるかどうかを示します。 このように示すことで、顧客が望まない場合は、プレリリース バージョンの使用を回避できるようになります。
リリースが発行されると、リポジトリを監視しているすべての人が通知を受け取ります。
GitHub リリースの詳細を確認します。