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

この動画を視聴すれば、ストレスレベルが低下し、次の大ヒット作のリリースにつながることを保証します

Laura Daly Laura Daly
トピック一覧

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

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

  • 高品質の製品を提供する能力を改善する、コーディングのベストプラクティス。高品質の製品を作成するためにはコードレビューが必要不可欠で、欠点のあるビルドの監視および修正はより迅速なリリースにつながります。その理由をご確認ください。
  • Jira Software のリリースハブを設定および最大化する方法。リリースハブで進捗やリリースステータスを明確化し、何時間もかかる作業を削減する方法をご覧ください。
  • ビルドから、コード、リリースまでの完全自動化。リリースハブからバージョンを直接リリースし、ワークフローを効率化します。

見て学ぼう

Q & A

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

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

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

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

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

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

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

チームには通常、完了するべき To Do リストがありますが、アトラシアンではこれを最小限に抑えるよう努めています。リリースハブのようなツールをこうしたプロセスに使用すると、現在計画中のリリースが最高品質であること、また Jira Software の課題のステータスと実際の開発との間に不一致がないことを確認しやすくなります。

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

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

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

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

A3:

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

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

A4: アトラシアンの経験では、これが問題となることは滅多にありません。たいていの課題においてコードが重複することはまれですが、競合が発生する場合もあります。

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

  • 他の進行中の開発から孤立した長期のフィーチャーブランチ
  • 完了、試験、リリース準備後まで分離する必要のある膨大なリファクタリングタスク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A9: 「リリース」ボタンに関連付けられた機能はいくつかあります。

  • リリース日を設定し、バージョンのステータスを「リリース済み」に変更できます。バージョンで解決されていない課題が存在する場合、それらの課題を別のバージョンに移行する選択肢も提供します。これは、Bamboo と統合していても、していなくても使用可能です。
  • Bamboo が Jira Software と統合される際、「リリース」ボタンは Bamboo で構成される新しいビルドを開始するために使用され、バージョンのリリースに必要な手順 (本番環境をデプロイする、または新しい成果物を作成するためのスクリプトなど) を実行できるようになっています。
  • 「リリース」ボタンは、実行されている Bamboo ビルドの手動ステージを開始するためにも使用できます。これにより、ビルドを自動で実行できるようになりますが、デプロイ/リリースを実際に行う、手動でのみトリガーされる任意のステージを設定することもできます。ステージはオプション #2 の全体的なビルドに相当するものですが、実行時にビルドが作成する成果物を使用できます。

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

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

次の記事
Qa at speed