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

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

Laura Daly Laura Daly

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

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

  • Coding best practices that will improve your ability to deliver quality product. Hear why code reviews are essential to delivering quality, and how monitoring and fixing failing builds will guarantee faster time to release.
  • How to set up and maximize Jira Software's release hub. Learn how to save hours of work by allowing the release hub to provide a clear picture into the progress and status of a release.
  • Complete automation from build, code, to release. Streamline your workflow by releasing your version straight from release hub.

見て学ぼう

Q & A

Our hosts Jason Wong and Megan Cook picked their favorite Q&As from this presentation. Read on to learn more about how to have successful and stress-free release.

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

A1: (1) Ship with confidence: Stakeholders inside and outside of the team will be able to know what exactly is ready to be released at anytime throughout the release cycle.

(2) Save time, make decisions faster: Automatically and instantly know what features are done and ready to be shipped, and which have problems. release hub checks through all you issues in your version for you, so that you don't have to manually reconcile issues and code.

(3) Record of releases: Know what went out (when & which release) by looking at released versions, and what is currently planned for each of the upcoming releases by looking at unreleased versions.

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

A2: Each team within Atlassian has it's own specific approach, but in general, we try to automate as much of the process as possible, so that putting out production bug fixes or releasing a new bug fix version of a product can be done by any developer in the team with minimal overhead.

Teams typically have a list of things that need to be done, but we try to minimize this as much as possible. Tools like the release hub help in this process to make sure that what we are planning to release is of the highest quality and there is no mismatch between the states of the Jira Software issues and their actual development.

Some of the larger teams (e.g. Jira Software and Confluence) will actually have a dedicated rotation for a bug master/release manager who manages all releases.

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

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

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

A3:

1. Branch - include the issue key in the branch name
2. Commit - include the issue key in the commit message
3. Pull request - Include the issue key in the source branch name, included commit message, or the pull request title
4. Build - include the issue key in an included commit message
5. Deployment - include the issue key in an included commit message

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

A4: Our experience is that this is rarely a problem. Most issues have little code overlap, but occasionally conflicts do occur.

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

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

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

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

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

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

A5: We have a number of branch strategies documented on our git web site. In particular see the comparing workflows section. 

More advanced details can be found in some previous talks, Getting Git Right and continuous deployment workflows are covered in more depth in Git workflows for SaaS teams.

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

For downloadable products, most teams use a variant of Gitflow Workflow where master is used for ongoing development, and each previous minor release has it's own branch, from which bugfix branches are made and merged back to, and when required, a bugfix release is built. Each previous release branch has all changes merged downstream to subsequent releases and master to make sure all bugfixes are included in all subsequent versions.

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

A6: Yes, it works very well. The Release button on the Kanban board can be used to create a new version containing all of the issues for that release. Once this version has been created, the release hub can be used to check for any warnings or to get an overview of the version.

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

Q7: Can the release hub show information about issues from multiple Jira Software projects or is the release hub project and fix Version specific?

A7: release hub is a detailed view of a version. As versions are currently specific to a project, the release hub is also specific to a project.

Q8: Can you have release hub warnings automatically populate in a Hipchat room?

A8: As of today there are no integrations between release hub warnings and Hipchat and we don't currently have plans to build any. We have been thinking about the different ways release hub could enhance team collaboration with Hipchat and would love to hear more from our customers on how they might use this integration or any other integrations with our other products.

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

A9: The 'Release' button has a few functions associated with it:

  • It can set the release date and change the status of a version to 'Released'. If there are any open issues in the version it will also give the option to move those issues to another version. This is all available with or without Bamboo integration.
  • When Bamboo is integrated with Jira Software, the Release button can be used to kick off a new build that can be configured in Bamboo to take the steps necessary to release your version (e.g. a script to deploy to production, or produce a new artefact).
  • リリースボタンを使用して、実行されている Bamboo のビルドに対してマニュアル ステージを開始することもできます。これによって、ビルドを自動的に実行させ、実際にデプロイメント/リリースを実行するステージでは手動でトリガーすることができます。(このステージは、オプション#2 のビルド全体に相当しますが、ビルドが実行中に生成する成果物を使用できます。)

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

A10: The release hub already works with GitHub and GitHub Enterprise. All you have to do is connect your Jira Software instance to your GitHub account using DVCS Accounts found under the add-ons administrator menu in Jira Software. Then you can start tracking the progress of any of your versions with any related development information included in the release hub. 

次の記事
Qa at speed