If you use Atlassian's Bitbucket Server to manage your Git repositories, your developers can create a code branch directly from an issue in Jira or Jira Agile. Clicking Create branch opens your DVCS application to begin the branch creation process. The process guides the developer in a number of ways at this crucial step:
Bitbucket Server suggests a branch type and a matching prefix for the branch name, when you have a branch model configured. The branch model helps developers to conform to your process guidelines when creating branches. Read more about the Bitbucket Server branch model.
Instead of having Jira issue statuses lagging behind, and the team not knowing the true state of the project, Jira administrators can now configure triggers in Jira workflows that respond to events in your linked development tools. For example, when a developer creates a branch to start work on an issue in Bitbucket Server, the issue will automatically be transitioned from 'Open' to 'In progress' in Jira.
Jira responds to events in Bitbucket, Bitbucket Server, Fisheye and Crucible, as well as GitHub and GitHub:Enterprise.
Currently available events include:
The Development panel, seen above, shows how many branches are related to the issue, wherever they're located (perhaps in multiple instances of Fisheye, or hosted in Bitbucket).
To see details of those branches, simply click the branches link. You'll see where each branch is located, and the status of any pull requests for the branches:
Click a branch to go to it in Bitbucket Server (or wherever it's hosted), or hover over a pull request status lozenge to see a direct link to the PR.
Use the Create pull request link to display the repository and begin the process for creating a pull request. This is a great way to start a discussion about the code changes on a particular branch – before they get merged.
As long as the branch name includes the issue key, and uses the default Jira issue key format, the branch is automatically included in the Development panel.
The Development panel shows the number of commits that are related to a Jira issue. It collects those from all the linked instances of Bitbucket Server (or other linked repository applications such as Bitbucket and Fisheye).
To see details for those commits, just click the commits link. You'll see who made each commit, when they committed, and how many files were changed (commits are greyed out if they've already been merged):
Click through to see a particular commit in the repository where the commit was made.
A developer only needs to add the issue key to the commit message, using the default key format, for the commit to be automatically linked to the Jira issue, and included in the commits summary in the Development panel for the issue.
The Development panel displays the most relevant status of all the Bamboo CI 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.
To see details for those builds, just click the builds link. You'll see the name of the build plan and how many tests have passed, or failed:
You can click through to see the build plan and the build result 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 Bitbucket Server to check out source code.
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.
The Development panel shows the most relevant status of the pull requests that are related to a Jira 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.
To see details for all 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 on the title of a pull request to see see it in Bitbucket Server.
Once you are ready to merge a pull request, and when the reviewers have approved it, just follow the link to the PR in Bitbucket Server.
Bitbucket Server 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 Bitbucket Server.
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. Merge commits are not included.
The Development panel shows the most relevant status of the Crucible reviews that are related to an issue. The review status is:
REVIEW if there is at least one open review.
APPROVAL if at least one review is ready for approval.
SUMMARIZE if there are no open reviews, and at least one review has had all reviewers complete their reviews.
REJECTED if at least one review has been abandoned.
CLOSED if there are no open reviews or reviews ready to summarize, and at least one review has been closed.
To see details for those reviews, click the reviews link. You'll see the status of each review, who the author and reviewers are, who has yet to complete their review, and whether the review is overdue. You can also see the number of comments:
You can easily click through to see a particular review in Crucible.
A developer just needs to add the issue key to the title of the review, or link the issue from the review, for the review to be automatically linked to the Jira issue.
The Development panel shows the environments to which related Bamboo builds for a Jira issue have been deployed.
To see the details of recent deployments, click the Deployed link. You'll see the deployment status and the release number and date:
Of course, you can click 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.
The Release Hub on your board lets you see the progress of your release (of a version) and determine what is likely to ship, at a glance. You can see all of the issues in the version, broken down by status category, as well as problems that could affect the release of the version (e.g. issues that should be in the release but are part of unmerged pulled requests, issues that haven't had code reviews, broken builds, etc).
You don't need to do any further configuration once you have connected Jira Software to your development tools. However, your team will need to know how to reference issues in their development work.
Learn more: Referencing issues in your development work