リリース ベースのワークフローとは
ここでは、GitHub を使用してリリース ベースのワークフローを作成する方法について説明します。
リリース ベースのワークフローとは
リリース ベースのワークフローは、"ソフトウェアのリリース" に焦点を当てたパターンとポリシーのセットです。 この概念は開発チームにとって明らかな目標のように思えるかもしれませんが、この視点の価値はより微妙です。 このユニットでは、3 つの異なるリリース サイクルの部分 (プロジェクトの管理、ブランチ戦略の選択、顧客へのリリース) について説明します。
GitHub プロジェクト ボードを使用して作業を計画する
計画の考え方からすると、リリース中心であることは、イシューが新しいバージョンを生成する個別のイテレーションに分割されることを意味します。 これらのイテレーションは、"スプリント" と呼ばれることがよくあり、増分変更を生成するためにほぼ同じ期間でタイムボックス化されます。 他のチームは、リリース バージョン全体を数か月以上続く 1 つのイテレーションにパッケージ化することを好みます。 GitHub では、これらのイテレーションはプロジェクトとして管理されます。
プロジェクトの最も優先度の高い機能は、ボードです。 ボードは、イテレーションの中心となるレコードの計画であり、解決されるすべてのカードが含まれています。 カードは、イシュー、プル要求、または一般的なノートだけを表すことができます。
既定では、各カードは、[To Do] 列で始まり、作業の開始後は [実行中] に移動してから、[完了] で終わります。 チームのプロセスに合わせて、これらの列をカスタマイズしたり、さらに列を追加したり、これらのカードとそのプロパティの動きに自動化を適用したりすることができます。
詳細については、「プロジェクト ボードの管理」を参照してください。
カードのプロジェクトの状態は、リポジトリ全体に統合されています。 たとえば、カードを [To Do] から [実行中] にドラッグすると、その状態が変更され、プロジェクトのタイトルの横にある視覚インジケーターが更新されます。 緑のセクションは [完了] とマークされているカードの部分を示しているのに対し、紫は、[実行中] のカードに使用されます。 残りの領域は、まだ開始していないカードの数量を表します。 カードをボードの周りにドラッグするだけでなく、カードをメイン ビューから更新することもできます。
プロジェクト ボードを使用すると、すべての利害関係者が、プロジェクトの状態とベロシティを簡単に理解できます。 また、個々のユーザー、または組織によって所有されているリポジトリのコレクションにスコープを指定したボードを作成することもできます。
詳細については、「プロジェクト ボードを使用した作業の進行状況の追跡」を参照してください。
特定のマイルストーンを追跡する
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 アプリを使って自動化できます。このアプリは、前のバージョンからの変更を分析し、関連付けられている pull request のタイトルを含めます。
- ビルド済みのインストーラーなど、ファイルをリリースの一部として提供する場合は、それらをフォームにドラッグ アンド ドロップできます。 GitHub で自動的に処理されるため、ソースをパッケージ化する必要はありません。
- そのチェック ボックスをオンにして、バージョンがプレリリースであるかどうかを示します。 このように示すことで、顧客が望まない場合は、プレリリース バージョンの使用を回避できるようになります。
リリースが発行されると、リポジトリを監視しているすべての人が通知を受け取ります。
GitHub リリースの詳細については、こちらを参照してください。