GitLab Flowのベストプラクティスとは？

ソフトウェア開発チームが急いでデリバリーを早めようとすると、面倒で複雑なワークフローに陥る可能性があります。特に別のバージョン管理システムから移行した組織では、開発を遅らせるおそれのある厄介なプロセスが浮上する可能性が高まります。チームがGitLab Flowを使用すると、ユーザー機能駆動開発に加え、イシュートラッキングが可能なフィーチャーブランチにより、すべてのチームメンバーが効率的に作業できるようになります。こうしたGitLab Flowのヒントを活用することでプロセスがシンプルになり、ソフトウェア開発チームはより効率的でクリーンな結果を生み出せるようになります。

フィーチャーブランチを使用すると、ソースコードを開発してクリーンに保つことができます。たとえばチームが最近SVNからGitに移行した場合、トランクベースのワークフローを活用するようになります。Gitを使用する場合、開発者はマージする前にコントリビューターが簡単に[コードレビュープロセス](/topics/version control/what-is-code-review/)を開始できるよう、作業中のものすべてでブランチを作成する必要があります。

一部のデベロッパーは「main」ブランチにマージされたコミットだけをテストするようCIを設定していますが、これではソフトウェア開発ライフサイクルにおいて遅すぎます。デベロッパーからプロダクトマネージャーまで全員が、「main」ブランチは常にテストに合格していることを共通して認識できていることが大切です。デベロッパーが新機能の開発を開始する前に「main」をテストをしなければならない場合、非効率的です。

「feature」ブランチで作業して新しいコミットを追加する場合は、すぐにテストを実行するようにします。テストに時間がかかる場合は、複数のテストを並列で同時に実行してみてください。サーバー側でマージリクエストを行い、テストスイートすべてを実行します。開発用のテストスイートと新しいバージョンのみのテストスイートがある場合、[並列]テストを設定してすべて実行することをおすすめします。

週の終わりや、プロジェクトの完了間近の段階ですべてのテストを実行しないようにしましょう。開発者はライフサイクルの後半で潜在的な問題を特定する可能性が高く、コードレビューはできるだけ早く行う必要があります。問題が早く見つかるほど、解決策も簡単に生み出すことができます。

開発者が「main」を毎回デプロイしたくない場合は「production」ブランチを作成できます。スクリプトの使用や手動による実行ではなく、チームは自動化や本番環境デプロイをトリガーする特定のブランチを使用できます。

開発者は、CIにリポジトリを変更させるのではなく、CIがアクションを実行するよう「tags」を使用する必要があります。チームが詳細なメトリクスを必要とする場合は、新しいバージョンの詳細を記載したサーバーレポートを作成する必要があります。

各タグは新しいリリースを作成する必要があります。これをプロセスに組み込むことで、クリーンで効率的な開発環境が確保されます。

cherry pick中に改善とテスト結果を特定することが困難になるため、パブリックブランチにプッシュする場合、開発者はそれをリベースしないようにします。コードレビューの最後に、何らかの操作を取り消しやすくするためにスカッシュとリベースを第三者に依頼する場合、この推奨事項が無視されることがあります。一般的なガイドラインとして、コードはクリーンで、かつ履歴は事実に基づいていることを確認するようにします。

これを実践すると、長いブランチの発生を回避できます。 デベロッパーは「main」をチェックアウトし、機能を構築し、マージリクエストを作成してから、再度「main」をターゲットにします。中間ステージをマージして排除する前に、完全なレビューを行う必要があります。

バグが特定されると、「main」でされるべき修正が、リリースされたばかりのバージョンで行われるという問題が発生することがあります。それを回避するには、開発者は「main」の変更をプッシュして常に前方に修正し、それを別の「パッチリリース」ブランチにcherry pickする必要があります。

開発者は、何をしたかだけではなく、なぜそれをしたのかを説明する必要があります。また、今後のコントリビューターが開発プロセスを詳しく理解できるよう、他のものでなくこのオプションがを選択された理由も説明することが大切です。詳細なコミットメッセージを書くことで、コードレビューや将来の開発に役立ちます。