JIRA を使った開発の効率化

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

JIRA and the Atlassian toolset work together to provide you and your team with a fast and guided software development process.

Discover how to integrate JIRAStash and Bamboo to support common Git workflows, while easily monitoring progress.

If you browse your Subversion repositories with FishEye, rely on Crucible reviews, or host your repos with Bitbucket, then this is for you too!

If you're using JIRA Cloud, head over to Streamlining your development with JIRA Cloud – that's the page you want!

If you don't have JIRA or the other tools installed yet, Installing Atlassian Tools will help you find what you need to know.

Read on for the JIRA integration story:

Git software development workflow process

JIRA および JIRA Agile から機能ブランチを作成する

A developer can quickly create a branch in the repository as soon as they start work on an issue.

If you use Atlassian Stash (or Bitbucket) to manage your Git repositories, your developers can quickly create a code branch directly from an issue in JIRA or JIRA Agile. The Create branch link will open your connected DVCS application and launch the process for creating a branch. If you have multiple repository applications connected, then they can choose where to create the branch. 

 

The key for the JIRA issue will be automatically added to the name of the branch, clearly defining the purpose for the branch, and automatically linking the branch to the issue.

The process guides the developer at this crucial step in a number of ways:

  • It defaults to the developers latest project and repository
  • It suggests a branch to branch from
  • It prepopulates the branch name and adds the JIRA issue key to the name automatically.

Git software development workflow with Atlassian tools

 

The screenshot above shows how Stash suggests a branch type and a matching prefix for the branch name when you have a branch model configured. A developer can override the settings that Stash suggests, but the branch model helps developers to conform to your process guidelines when creating branches. Read more about the Stash branch model.

See Making the integration work below, for the technical details.

リポジトリブランチを見る

See all the branches that have been created for work on a JIRA issue, wherever they're located.

The Development panel in a JIRA issue shows how many branches are related to the issue, wherever they're located (perhaps in multiple instances of Stash and FishEye, or hosted in Bitbucket). As long as the issue key is part of the branch name, using the default JIRA issue key format, the branch is automatically included in this summary in the JIRA issue:

 


To see details of those branches, simply click the branches link. You'll see which repository each branch is located in, and the status of any pull requests for the branches. Click a branch to go to it in Stash (or the linked DVCS where it is hosted), or hover over a pull request status lozenge to see a direct link to the PR.

 

Git software development workflow with Atlassian tools


Use the Create pull request link to begin a discussion about the code changes on a particular branch – it opens the repository and starts the process for creating a pull request.

See Making the integration work below, for the technical details.

リポジトリへのコミットを見る

JIRA 課題に対してどのくらいの作業が行われたか、最後に作業が行われたのはいつかなのかを確認します。

The Development panel summarizes all the commits related to the issue, from all the linked instances of Stash (or other linked DVCSs such as Bitbucket and FishEye). A developer only needs to add the issue key, using the default key format, to the commit message. When the commit is later pushed to Stash, for example, the commit is automatically linked to the JIRA issue  and gets included in the Development panel for the issue. 

 

 

To see details of all those commits, just click the commits link. You can see just who made each commit, when they commited, and how many files were changed. Click through to see a particular commit in the repository where the commit was made. Commits are greyed out if they've already been merged.

 

See Making the integration work below, for the technical details.

See your build results

Quickly see at a glance whether builds are failing!

「開発」パネルには、JIRA 課題と関連付けられた Bamboo ビルドの最も関連性の高いステータスが表示されますステータスアイコン:

  if all the different builds (for example, unit tests, functional tests, deploy to staging) succeeded.
  if at least one run failed for any build by any linked instance of Bamboo. 

A build is automatically linked to a JIRA issue if a commit involved in the build has the JIRA issue key in its commit message, as described above.

 

To see details for all the builds, you can click the builds link. You can see the name of the build plan and how many tests passed, or failed. Click through to see a build result in Bamboo:

 

Git software development workflow with Atlassian Bamboo

 

The screenshot above shows the build result for a plan branch in Bamboo. You can configure plan branches to be automatically created by Bamboo when a new branch is detected in the repository for the plan. Using plan branches ensures that commits to repository branches, and not just commits to master, get continuous integration testing. Because Bamboo does this automtically, there's no need to manually, and repetitively, configure a new Bamboo plan for every new branch in the repo. Read more about plan branches in Bamboo.

Bamboo can be configured to regularly poll the repo and to start a build when it finds changes. Alternatively, a repository change can trigger Bamboo to run the build, for example by using a post-receive web hook, such as this one. The web hook triggers the build plan (or plan branch) whenever a commit is made. Either way, the build result is passed to the JIRA issue and added to the summary in the Development panel. Note that Bamboo must be able to authenticate with Stash to check out source code.

Git software development workflow with Atlassian tools

See Making the integration work below, for the technical details.

プルリクエストのステータスを見る

Quickly spot if the work on a JIRA issue has been reviewed and integrated.

The Development panel shows the most relevant status of the pull requests that are related to the issue. The pull request status is:

OPEN (未処理)未処理のリクエストが 1 つ以上ある場合

MERGED if there are no open pull requests, and at least one pull request has been merged.

DECLINED if there are no open or merged pull requests, and at least one pull request has been declined.

A developer just needs to add the issue key to the title of the pull request, or have the key in the source branch name, for the PR to be automatically linked to the JIRA issue.

 

 

To see details of the pull requests simply click the pull requests link. You'll see the status of each pull request, who the reviewers are, and who has yet to complete their review. You can also see the number of comments on a pull request. Click through to see a particular pull request in Stash. 

 

Git software development workflow with Atlassian Stash

 

Once you are ready to merge a pull request, and when the reviewers have approved it, just follow the link to the PR in Stash.

Stash can be configured to automatically merge changes to newer release branches. This reduces the need for manual maintenance of repository branches, and allows bug fixes, for example, to be propagated to other branches where they should be applied. Read more about automatic merging in Stash.

See Making the integration work below, for the technical details.

See what's been deployed

Easily check if the work on a JIRA issue has shipped to customers yet.

The Development panel shows the environments that Bamboo builds related to the issue have been deployed to. 

 

Git software development workflow with Atlassian JIRA

 

To see the details of recent deployments, click the Deployed link. You'll see the deployment status and the release number and date, and you can through to see more details in Bamboo.

 

 

A deployment is linked to a JIRA issue if a commit involved in the deploy has the issue key in its commit message. When those code changes are later built (see above), and the resulting artifact is deployed (either manually or automatically)  the environment information is passed to the JIRA issue. This assumes that the Bamboo build plan is associated with a deployment project in Bamboo.

Git software development workflow with Atlassian tools

See Making the integration work below, for the technical details.

連携を機能させる

一般的な確認事項

  • JIRA users only need the "view development tools" project permission to be able to see the Development panel. By default, anonymous users (those who are not logged in) don't have this permission, and so do not see the panel. 

  • A developer needs to use the default JIRA issue key format, that is, two or more uppercase letters ([A-Z][A-Z]+), followed by a hyphen and the issue number, for example EG-123.
    • コミットメッセージに課題キーが含まれる場合、コミットは自動リンクされます。

    • ブランチ名に課題キーが含まれる場合、ブランチは自動リンクされます。

    • プル申請者のタイトルや、ソースブランチ名に課題キーが含まれる場合、プルリクエストは自動リンクされます。

    • ビルドと関係するコミットのコミットメッセージに課題キーが含まれる場合、ビルドとデプロイは自動リンクされます。

  • JIRA needs to be connected with Stash, FishEye, Crucible or Bamboo using a 2-way application links that have both 2-legged and 3-legged authentication enabled. See the Application Links section below.

  • JIRA needs to be connected with Bitbucket, GitHub or GitHub Enterprise using the DVCS Connector in JIRA. See Use the JIRA DVCS Connector.
  • When using the supported versions of JIRA and the other applications, the Development panel replaces the Source, Commits and Builds tabs, as well as the Deployment panel, in a JIRA issue. So, for example, you won't see the Source tab, and commits in Stash will be accessible from the Development panel. However, if a connected application is older than the supported version, information from that application will continue to be displayed in those locations.
  • The details dialogs, for example for commits, may display duplicates, although the number of unique items are reported at the top of the dialog and in the Devlopment panel summary. Duplicate commits, for example, can arise from having both Stash and FishEye linked to JIRA, and FishEye in turn connected with Stash, so that FishEye indexes, and reports. Stash commits.
  • 開発ツールのサマリーデータを表示できるユーザーが、サマリーに貢献したすべての情報の詳細ダイアログ (ブランチ、コミット、プルリクエストなど) の閲覧権限を持っていない場合があります。これは、詳細ダイアログが、そのユーザーが接続しているアプリケーションで持っているアクセス権限を尊重しているためです。
  • Note that if commits linked to the JIRA issue are involved with a Bamboo build that fails, the first successful build that follows will be reported, even though the original commits are no longer involved with that build.

サポート対象バージョン

To see the integrations described on this page, you'll need the following application versions:

Jira6.2 以降
Stash2.10 以降
BitbucketCurrent version
FishEye3.3 以降
Crucible3.3 以降
Bamboo5.4 以降

JIRA と Stash、FishEye、Crucible、または Bamboo のインスタンス間に新しいアプリケーション リンクを作成すると、2-legged (2LO) および 3-legged OAuth (3LO) が既定で有効になります。2LO は、開発パネルのサマリに含まれることになる、これらのアプリケーションからの情報のために必要です。3LO は、ユーザーが詳細ダイアログの情報にアクセスする前に、他のアプリケーションで認証済みであることをチェックします。 

  • Users who can see summarized data in the Development panel may not have permission to see all the information that contributed to those summaries and which is visible in the details dialogs (for example, for branches, commits and pull requests). That is, the details dialogs respect the access permissions that users have in the connected applications.
  • An older application link between JIRA and any of those applications will need to have 2LO authentication explicitly enabled.
  • Application links must have Trusted Applications and Basic Access authentication disabled. The Development panel only supports QAuth authentication.
Click here to see how to enable 2-legged OAuth...

An existing application link between JIRA and Stash, FishEye, Crucible or Bamboo (that perhaps used Trusted Apps authentication) needs to have 2-legged authentication (2LO) enabled for both outgoing and incoming authentication, so that information from the application can be included in the Development panel summaries.

OAuth を使用する古いアプリケーション リンクを更新したときは、3 -legged authentication がデフォルトで適用されますが、送受信両方の認証で明示的に 2LO を有効化する必要があります。次のように、JIRA 内からアプリケーション リンクの 2-legged authentication を有効にできます。

  1. JIRA 管理エリアへ移動し、アドオン > アプリケーションリンクをクリックします。 
  2. 他のアプリケーションのアプリ リンクの編集をクリックします。
  3. For both Outgoing Authentication and Incoming Authentication:
    1. Click OAuth
    2. Check Allow 2-legged OAuth.
    3. Click Update.

アプリケーション リンクの更新プロセスでは、短時間他のアプリケーションにログインし、リンクのもう片方を設定してから JIRA に戻ります。

最終更新日 2015 年 6 月 11 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.