Streamlining your development with 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

Create feature branches from JIRA and 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 your repository branches

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.

See the commits to your repositories

See just how much work has been done for a JIRA issue, and when the latest work was done.

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!

The Development panel shows the most relevant status of the Bamboo builds that are related to your JIRA issue. The status icon is:

  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.

See the status of pull requests

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 if there is at least one open pull request.

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.

Making the integration work

In general

  • 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.
    • Commits are linked automatically if the issue key is included in the commit message.

    • Branches are linked automatically if the issue key is included in the branch name.

    • Pull requests are linked automatically if the issue key is included in the pull request's title or in the source branch name.

    • Builds and deployments are linked automatically if a commit involved in the build has the issue key in its commit message.

  • 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.
  • Users who can see summarized data in the Development panel may not have permission to see in the details dialogs (for example, for branches, commits and pull requests) all the information that contributed to the summaries. That is, the details dialogs respect the access permissions that users have in the connected applications.
  • 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.

Supported versions

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+

When you create a new application link between JIRA and an instance of Stash, FishEye, Crucible or Bamboo, 2-legged (2LO) and 3-legged OAuth (3LO) are enabled by default. 2LO is required for information from any of those applications to be included in the summaries in the Development panel; 3LO checks that a user has authenticated with the other applications before they get to see the information in any of the details dialogs. 

  • 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.

When updating an older application link to use OAuth, 3-legged authentication is applied by default, but you need to explicitly enable 2LO. Enable 2-legged authentication for the application link from within JIRA as follows:

  1. Go to the JIRA admin area and click Add-ons > Application Links
  2. Click Edit for the app link with the other application.
  3. For both Outgoing Authentication and Incoming Authentication:
    1. Click OAuth
    2. Check Allow 2-legged OAuth.
    3. Click Update.

The application link update process will involve logging you into the other application for a short time to configure that end of the link, before returning you to JIRA.

Last modified on Jun 11, 2015

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.