Git による非常に強力で継続的なデリバリー

実は、Git 自体は継続的なデリバリーにはそれほど適していません。ブランチ ワークフローは継続的なデリバリーに、Git はブランチ ワークフローにそれぞれ最適です。継続的なデリバリーの BFF (Backends For Frontends: フロントエンドのためのバックエンド) とは別に、ブランチ マージ ワークフローを使用すると、厄介なバグに取り組んだり、新しい技術を試したり、新しい機能をゼロからコーディングしたりできます。変更によってチームメイトのタスクの進捗が妨げられるリスクはありません。

Subversion やその他の従来のバージョン管理システムでもブランチできることは明らかです。ただし、ブランチにはマージという厄介な悪魔の双子がいます。

Subversion のような従来のバージョン管理システムは、複数のブランチが存在するファイルのバージョンの追跡にはあまり適していません。マージとなると、Subversion は頻繁に停止して足止めを食らうことになります(「マージされたバージョンでこの行は残しますか?」という小さいポップアップがよく表示されます)。マージ中には多くの手動操作が必要になるので、チームはコード フリーズを起こしてしまいます。そのため、マージを誰が行っているかに関わらず、いずれかのブランチで新しい変更があると作業が中断します。高いコストを伴うコード フリーズは、非常に非生産的な時間でもあります。

一方、Git は複数のブランチにある複数のバージョンのファイルの変更を追跡するのに最適で、ファイルの共通の親がどのようなものかを常に把握しています。Git には基本的に内蔵 GPS があるとも言え、それによって、常に停止して方向を確認することなくマージをナビゲートできます。

Git を使用すると、Subversion では普段は使えないようなブランチを活用できます。ブランチとマージに伴うオーバーヘッドは非常に小さいため、1 日 2 日だけ存在するブランチは実行可能なだけではなくメリットをもたらします。

それは良しとして、ブランチが継続的なデリバリーにおいてそれほど有効であるのはなぜでしょか?

たとえば、Atlassian のすべての開発チームは、main ブランチまたは安定したブランチに直接コミットしているものはないと認識しています。全員がブランチで作業しています。実際、当社が取り組んでいる各 Jira 課題への別々のブランチの作成は、全員が非常に前向きに取り組んでいます。

何にせよ、ブランチは好きなだけテストできて、そこで問題が発生しても良いのです! ブランチで問題が発生しても、main ブランチからのリリースは可能であり、壊れたコードを継承することなく新しいブランチを作成できます。これは継続的なデリバリーと開発者の一般的な生産性にとって (言うまでもなく士気にとっても) 有益です。

ブランチはチーム外からの協力の受け入れに役立ちます

Git ではブランチおよびリポジトリ全体のフォークを簡単に行えるため、チーム外 (請負業者、パートナー企業の開発者、その他のビジネス ユニットの開発チームなど) による協力を簡単に受け入れられます。コードベースに不慣れな人が重要なブランチを変更してしまい、新しいコードをリリースできなくなることを心配する必要がなくなります。

ここでも、ブランチまたはフォークされたリポジトリの厳格な自動テストが協力を成功させる鍵になります。main コード ラインへマージを承認する前に、ビルドとテストの結果を見直すべきです。

ブランチの適切性 = プロジェクト追跡の明確性

実装するストーリー、バグ修正、タスク (各 Jira 課題) ごとに開発ブランチを作成するのが、現在のトレンドです。数年前に Atlassian ではこの課題ごとのブランチ モデルを採用しましたが、それは大正解でした!当社のお客様の間でも人気になっています。

各課題にブランチを作成することで、どの変更を本番環境にリリースするか、リリースにバンドルするかを簡単に選択できます。main ブランチに変更を加えているわけではないため、いつ何を main ブランチ –に導入するかを選択できます。あると良いものがすべて完成するまで待つのではなく、エピックの MVP とあると良いもの 1 つをリリースしたり、過去の定期リリースのフレームワーク内で 1 つのバグ修正をリリースしたりできます。緊急性が高い修正であっても必要な変更だけを適用できるため、多忙でまだリリースの準備が整っていない中で変更をバックアップする手間は不要です。

単一のコード変更のリリースの容易さは、継続的なデリバリーの重要な要素です。

このアプローチによって証明されていないコードを main ブランチに導入せずに済むだけでなく、関連する Jira 課題キーと開発者の名前や頭文字をブランチの名前に含めると、進行中の各課題の進展が明確になります。

上の図の命名規則に関するメモ: 実施中の Jira 課題の一意のキーと、その課題の簡潔で人が判別できる説明です。リリース マネージャーやその他の関係者は、上の図のリポジトリを見て、AMKT-13952 で追跡されるユーザー ストーリーが main にマージされているためにリリース可能であることを一目で把握できます。これは、手動操作は一切不要のトレーサビリティです。

このような質問は大歓迎です。このサイトの他の記事で各フェーズについて詳述しているため、ここでは簡潔に概要を説明します。

• 作業する課題のブランチを作成します。ブランチの目的がわかるように、Jira 課題キーをブランチ名に含めます。Bitbucket や Bitbucket Pipelines などの Atlassian ツールを使用している場合は、課題キーを把握して、課題、ブランチ、すべてのコミット、ビルド、プル リクエスト、課題に関係するデプロイ間のリンクを作成します。言い換えれば、課題キーは魔法のようなものです。
• ブランチに変更を加えます。ブランチは master から独立しています、何をしても構いません。新しいことを試してください。何を壊しても大丈夫です。心配はいりません。加えて...
• ブランチを CI に置きます。ここで負荷テストやエンドツーエンド UI ベース テストなどの専門的なテストを実施するかどうか、さらにはブランチ変更を加えるたびにテストを自動でトリガーするかどうかを決定するのは、あなたとチームです。アトラシアンのチームは通常、開発ブランチでユニット テストと統合レベルのテストを実行します。
• main ブランチからの最新情報でブランチを頻繁にアップデートします。これは、リベースまたはブランチ コミットを使用して実現できます。その日時を決めるのはあなた次第です。(ただし、他の開発チームと共有するブランチは絶対にリベースしないでください。開発チームを煽るような行為です。)いずれにせよ、マージする前に統合の競合を発見できるので、main ブランチをクリーンに保ちやすくなります。
• マージ アップの準備ができたら、プル リクエストを作成します。これは、実装が完了してチームメイトからの変更を導入し、結果として発生した競合を解決してブランチに対するすべてのテストに合格したことを意味します。
• 自在にマージしてデプロイします。main ブランチへマージしてすべてのテストの合格時に各変更を自動でリリースすること (= 継続的デプロイ モデル) を好むチームもあります。どの変更をいつリリースするかは自分で決めたいというチームもあります。これは、あなたとチーム次第です。

もうおわかりいただけたと思います。ブランチ ワークフローによって継続的なデリバリーはよりシンプルな提案となり、Git によってブランチに関する悩みは解消されます。Git リポジトリを継続的なデリバリー フレンドリーにする方法と、Atlassian ツールですべてのアイデアを実践する方法について、さらに詳しく説明します。次のページもぜひご覧ください!