ストレスのないリリースへの道のり

このビデオを見れば、ストレスレベルが低下し、次の大ヒット作のリリースにつながることを保証します。

Laura Daly Laura Daly
トピック一覧

アジャイルチームの成功を判断する最適な瞬間は、開発したソフトウェアをお客様にリリースする時です。しかし、経験豊富なソフトウェアチームでさえ、成果物に対して完了済みの課題を検証するときがくると、痛みを感じるものです。コードのレビューがスキップされているとか、コードが統合されていないとか、マージされたコードのビルドの失敗とか… 覚えがありませんか。

このプレゼンテーションで学習する内容:

  • 質の高い製品を提供する能力を高めるコーディングのベスト プラクティス。高い品質を提供するにはコード レビューが不可欠で、ビルド エラーの監視や修正によってリリースまでの時間の短縮が保証される理由をお聞きください。
  • Jira Software のリリース ハブを設置し、最大限に活用する方法。リリース ハブでリリースの状況や進捗を明確に把握し、作業時間を短縮する方法について説明します。
  • ビルドからコード、リリースまでの完全な自動化。リリース ハブから直接バージョンをリリースし、ワークフローを効率化しましょう。

見て学ぼう

Q & A

ホストの Jason Wong と Megan Cook が、このプレゼンテーションからお気に入りの Q&A を選びました。ストレスなくリリースを成功させる方法を読んで、学習を深めてください。

Q1:リリースハブの使用を成功させる非技術的な要因のトップ 3 は何ですか。

A1: (1) 自信を持って出荷する: チーム内外の関係者は、リリース サイクルを通じていつでも、リリースの準備が整っている内容を正確に把握できるようになります。

(2) 時間を節約し、迅速な意思決定を行う: どのフィーチャーが完了し、出荷する準備ができていて、何が問題なのか、自動的かつ瞬時に把握できます。リリース ハブがユーザーに代わってバージョンの課題すべてにわたってチェックを行うため、手動で課題とコードを調整する必要がありません。

(3) リリースを記録する: リリース済みのバージョンを調べれば、何 (リリースの時期と内容) が出荷されたかわかります。未発表バージョンを調べれば、今後の各リリースで計画されている内容がわかります。

Q2:Atlassian では、一般的に誰がリリースバージョンを管理しますか。

A2: Atlassian 内のチームはそれぞれ独自のアプローチをしていますが、一般的な方針として、できるだけ多くのプロセスを自動化するように努めているため、製品のバグ修正公開や製品の新しいバグ修正バージョンのリリースはチームの誰でも、最小限のオーバーヘッドで実行できます。

チームにはふつう実行するべき内容の一覧がありますが、これを最小限に抑えるよう努めています。こうしたプロセスでリリースハブのようなツールを使用することにより、現在計画中のリリースが最高の品質であり、JIRA 課題の状態と実際の開発物との間に不一致がないことを確認しやすくなります。

大きなチーム (Jira Software と Confluence など) の中には、すべてのリリースを管理するリリース マネージャーに特化した交代制を実施しているところがあります。

規模の大きなメジャーリリースとマイナーリリースに関しては、ふつうリリース担当のスタッフがいて、スコープが管理されているか、リリースまでのすべての作業がリスクと時間について管理されているか確認しています。チームリーダーや開発マネージャーがこうした監視を行うことも可能ですが、誰もがプロセスを知っていて、高品質のソフトウェアをリリースするための要件を理解できるように、チームメンバーの間で確実に担当を交代するように努めています。

タイムライン計画に関しては、チームリーダーはリリースの準備が整う時期およびスコープや時間を管理する必要性に関する期待値設定について、プロダクトマネージャーやマーケティング担当と調整します。どのフィーチャーがどのバージョンでリリースされるかという決定は、こうした人々の間で判断されます。

Q3:ブランチ / コミット / プルリクエスト / ビルド / デプロイメントをどのようにして課題に関連づけますか。

A3:

1. ブランチ - ブランチ名に課題キーが含まれます
2. コミット - コミット メッセージに課題キーが含まれます
3. プル リクエスト - ソース ブランチ名、含まれたコミット メッセージ、またはプル リクエスト タイトルに課題キーが含まれます
4. ビルド - 含まれたコミット メッセージに課題キーが含まれます
5. デプロイ - 含まれたコミット メッセージに課題キーが含まれます

Q4:別々の課題ブランチ上で同じコードの作業を行った場合に発生する競合に対処した経験がありますか。

A4: 経験では、これが問題となることはめったにありません。たいていの課題でコードが重複するのはまれですが、競合が発生する場合もあります。

一般的に問題が起こるのは、次の 2 つの場合です:

  • 他の進行中の開発から分離され、長い期間使用されているフィーチャーブランチ
  • 完了、テスト、リリース準備まで分離しておく必要がある大規模なリファクタリング タスク

前者の場合、本格的なオプションとしては、開発を行いながら頻繁に統合を行うが、フィーチャー自体はフィーチャーフラッグの後ろに隠しておき、チーム内または選ばれた少数の顧客にだけ進行中の変更が表示されるようにします。これによって、競合するコードが継続的に統合され、競合の可能性を最小限に抑えられるだけでなく、大規模なフィーチャーがメインの開発ブランチに追加された場合のリスクと影響を最小限に抑えられるようになります。

これが実現できない場合、また大規模なリファクタリングを行う場合、(ベース / 開発ブランチの変更をフィーチャーブランチにマージすることにより) 開発ブランチができるだけ頻繁にフィーチャーブランチに統合されるようにします。これによって、進行中の開発をすべて完了させ、長期間使用されているフィーチャーブランチに対するテストをできるだけ頻繁に行えるようになります。マージの競合がある場合は、変更を行った人にその解決を支援もらったり、または少なくともスコープを最低限に維持してもらって解決しやすくする方がはるかに簡単です。

最善の解決策は、すべての作業をチャンクに分割し、できるだけ頻繁に安定ブランチや開発ブランチにマージすることです。これによって、同じファイルへの変更がフィーチャーブランチで同時に行われる可能性を最小限に抑えられます。

Q5:進行中の開発 (フィーチャー)、ホットフィックス、異なる環境 (QA/ ステージング / 生産) へのデプロイメントを行う並列ブランチを管理する方法として、どのような戦略を推奨しますか。

A5: Git の Web サイトにブランチ戦略をいくつか掲載しています。特にワークフローの比較セクションを参照してください。

詳細は以前の講演、「Getting Git Right (Git の適切な活用)」を参照してください。また、継続的デプロイのワークフローについては、「SaaS チームのための Git ワークフロー」で詳細に説明しています。

簡単に言うと、主なワークフローは 2 つあります:ダウンロード可能な製品向けの製品リリース ワークフローとオンラインサービス向けの SaaS ワークフロー (SaaS チームのための Git ワークフロー) です。

ダウンロード可能な製品については、ほとんどのチームは Gitflow ワークフローの変形を使用しています。このワークフローでは、main が進行中の開発に使用され、以前の各マイナー リリースにはブランチがあり、そこからバグ修正ブランチが作成されてマージ バックされ、必要な場合はバグ修正リリースがビルドされます。以前の各リリース ブランチの変更部分は、下流にあたる後続のリリースと main にマージされて、すべてのバグ修正がすべての後続のバージョンに含まれるようになっています。

Q6:リリースハブはカンバンや頻繁なリリースに対してうまく機能しますか。

A6: はい、非常にうまく機能します。カンバンボードのリリースボタンを使用すれば、そのリリースの課題すべてを含む新しいバージョンを作成できます。このバージョンが作成されたあとは、リリースハブを使用して、あらゆる警告を確認したり、バージョンの概要を取得したりできます。

カンバンボードを使用しなくても、バージョンをいつでも作成でき、課題が完了した場合でも、課題をバージョンに追加できます。その後、リリースハブを使用して、すべての警告を確認し、リリースの準備ができていることを確認できます。

Q7: リリース ハブで複数の Jira Software プロジェクトの課題に関する情報を表示できますか? あるいは、リリース ハブ プロジェクトと修正バージョン限定ですか?

A7: リリースハブは 1 つのバージョンの詳細を表示します。バージョンは現在、1 つのプロジェクト限定であるため、リリースハブもまた 1 つのプロジェクト限定です。

Q8:リリースハブの警告を自動的に Hipchat ルームに取り込むことができますか。

A8: 現時点でリリースハブの警告と Hipchat は統合されていません。また現在のところ統合する計画はありません。当社では Hipchat とリリースハブを使用して、チームのコラボレーションを高める方法を別に検討しています。こうした統合および当社の他の製品との統合を活用する方法について、お客様からさまざまなご意見をいただきたいと考えています。

Q9:「リリース」ボタンは何に接続されていますか。Bamboo のジョブとしてプロダクションサーバーにデプロイするスクリプトですか。

A9: 「リリース」ボタンには、それに関連する機能がいくつかあります。

  • リリースボタンによってリリース日を設定し、バージョンのステータスを「リリース済み」に変更できます。また、バージョンにオープン中の課題がある場合、その課題を別のバージョンに移動するオプションを提供します。こうした機能は Bamboo 統合の有無にかかわらず、すべて利用可能です。
  • Bamboo が Jiraソフトウェアと統合されている場合、リリースボタンを使用して新しいビルドを開始し、バージョンをリリースするために必要な手続きを実施するよう Bamboo で設定できます (たとえば、製品にデプロイしたり、新しい成果品を製造したりするスクリプト) 。
  • リリースボタンを使用して、実行されている Bamboo のビルドに対してマニュアル ステージを開始することもできます。これによって、ビルドを自動的に実行させ、実際にデプロイメント/リリースを実行するステージでは手動でトリガーすることができます。(このステージは、オプション#2 のビルド全体に相当しますが、ビルドが実行中に生成する成果物を使用できます。)

Q10:リリースハブを Github/GitHub Enterprise と統合する計画はありますか。

A10: リリース ハブはすでに GitHub および GitHub Enterprise と連携して動作しています。Jira Software のアドオン管理者メニューの下にある DVCS アカウントを使用して、Jira Software のインスタンスを GitHub アカウントに接続できます。接続後は、リリース ハブに含まれる任意の開発関連情報を使用して、どのバージョンの進捗状況でもトラッキングを開始できます。

次の記事
Qa at speed