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

Git によってマージが簡単になったため、ブランチ ワークフローがこれまで以上に魅力的になりました。

Sarah Goff-Dupont Sarah Goff-Dupont

私たちは誰でも、「作成者が 1 人だけのコードに気を付けて」という言葉を耳にしたことがあり、チームとしてソフトウェアを作ることのメリットを理解しています。そのメリットとは、考え方、背景、経験の多様性が得られることです。解決しようとしている問題に関わらず、多様性を活かすことでソフトウェアを改善できます。保守性と品質が高まり、最終的にユーザーにより良いサービスを提供できます。

チーム コラボレーション | Atlassian CI/CD

それと同時に、チームの構築の難しさも理解しています。

チーム メンバーがコードのどの部分を扱っているかを理解して変更が競合しないようにし、顧客より先に欠陥を見つけてプロジェクトに関わる全員が作業の進捗を把握できるようにするのは、骨が折れるような工程です。実際には、これらの問題は Git のブランチや継続的なデリバリーで対処できます。

これらの 2 つの要素を組み合わせること (おそらく、楽しめるための最高のツールを導入しながら) が、成功への大きな一歩になります。

ブランチ ベース ワークフローの力

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

基本的なワークフロー図 | Atlassian CI/CD

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

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

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

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

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

ブランチは main をクリーンでリリース可能な状態に保つ

短期間のブランチは、開発者がお互いの作業を妨げずにプロジェクトやフィーチャーに関して協力する上で、非常に役立ちます。継続的なデリバリーにとってさらに重要なのが、開発上で進行中のすべての作業をわけることです。これによって main と安定したバージョン ブランチをクリーンな状態に保てるので、自在にリリースできます。

つまり、開発ブランチに対して自動テストを最大限実施できるため、開発者は開発したコードの品質について有益なフィードバックを受け取って、変更をマージ アップできるタイミングについて自信を持って決断できます (自動テストをまだ導入されていない場合は、RebelLabs のこの投稿をご覧ください。初めての単体テストの作成に関する面白い話とハウツーを紹介しています)。

また、Git のプル リクエストをコード レビューの形式として使用することで、チーム全体がコードの保守性とコードベースのその他の領域との相互運用性に自信を持てます。これは、従来のデリバリー モデルよりも多くの事前の準備が必要であることは確かです。しかし、その価値はあります。

継続的なデリバリーの成否は、リリース ブランチをクリーンに保てるかどうかにかかっています。

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

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

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

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

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

ヒント: Bitbucket などのリポジトリ マネージャーによって、Git フックを使用して品質基準を適用できます。たとえば、プル リクエストを受け入れてマージできるようにするために、すべてのブランチ ビルドが順守するルールを設定できます。

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

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

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

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

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

Bitbucket が Git リポジトリ スクリーンショットをコミットする | Atlassian CI/CD

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

では、Git と継続的なデリバリー ワークフローはどのように機能するのでしょうか?

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

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

Git CI 自動化 | Atlassian CI/CD

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