計画ブランチは、バージョン管理リポジトリ内のブランチを表すために使用します。計画ブランチでは、計画と同じビルド設定が使用されます。
Tools such as Git and Mercurial encourage a practice called feature branching, where a developer can use a new branch to work in isolation from his or her team members before merging their changes back into main line development. Previously however, changes made on a branch may not have been built and tested by Bamboo unless the developer had specifically set up a new build plan, or had cloned an existing plan and configured it to build the new branch.
現在では、Bamboo で計画ブランチを使用できるため、
- リポジトリで新規作成されたブランチは、親計画と同じビルド設定を使用して自動でビルドおよびテストされます。
- 必要に応じて、親計画を上書きしてブランチ計画を個別に設定できる柔軟性があります。
- オプションで、ビルドが成功した場合にフィーチャー ブランチからの変更を「master」(トランク ブランチ、既定のブランチ、メインライン ブランチなど) に自動でマージすることもできます。
このページの内容
計画のブランチングを有効化する
Bamboo で計画のブランチングを有効化すると、ソース リポジトリのブランチが作成されるたびに自動で計画ブランチが作成されます。計画ブランチを手動で作成することもできます。
You can override the master plan's configuration in a branch plan, if required.
計画のブランチのリストを表示するには、ダッシュボードの [すべての計画] タブの計画名の横にあるブランチ アイコンをクリックします。リストからブランチ名を選択すると、そのブランチ計画の要約ページに直接移動します。
スクリーンショット: ブランチの [Plan Summary (計画の要約)] ページに「ブランチ」メニューが表示されている。
自動ブランチング
You can use auto branching for Git, Mercurial and Subversion repositories. For other repository types, you can use manual branching.
Bamboo でリポジトリのブランチが作成されるたびに自動で計画ブランチを管理するには、次の手順を実行します。
- ブランチを作成する計画の設定ページの [ブランチ] タブに移動します。
- Select Automatically manage branches.
- Enter a regular expression to specify the repo branch names for which plan branches will be created. An example is:
(branch1|branch2|branch3)/.*See the Java documentation on regular expressions. Make the following optional settings as required. These will be applied to all branch plans created from this plan configuration, although they can be overridden in those branch plans, if required.
Remove after Edit the value, in days, after which branches are automatically deleted, if no commits have been made to the VCS branch in that period. A value of zero prevents plans from being deleted. マージ Not available for Subversion.
Check Branch Merging Enabled, and complete either the 'Branch updater' or 'Gatekeeper' sections, as described below.JIRA Feature Branches Check Create Remote Links from JIRA Issues to have the plan branch automatically linked, using an issue key in the branch name. Described below. 通知 Described below. ブランチのルート Subversion ソース リポジトリを使用する計画でのみ利用可能です。Bamboo では、Subversion リポジトリの構造がブランチの規則に従っていると仮定して、ブランチのルート URL が自動で計算されます。
たとえば、
https://svn.mycompany.com/svn/fastBuild/trunkという URL を持つfastBuildリポジトリの場合、Bamboo ではhttps://svn.mycompany.com/svn/fastBuild/branchesという場所にブランチが作成されることを想定します。Subversion リポジトリの構造が別の規則に従っている場合は、[Change branch root URL (ブランチのルート URL を変更)] を選択して、リポジトリ ブランチの作成場所を指定できます。
- 保存をクリックします。
ブランチ検出
Once plan branching is enabled, Bamboo will check for a new branch every 300 seconds. You may customize the branch detection interval:
- Click the icon and select Bamboo admin.
- Click General Configuration in the left navigation panel
- Enter a new value in the Branch detection interval field
- 保存 をクリックします。
手動ブランチング
Use manual branching for all supported repository types. You may want to consider using auto branching for Git, Mercurial and Subversion repositories.
計画のブランチを手動で作成するには、次の手順を実行します。
- ブランチを作成する計画の設定ページの [ブランチ] タブに移動します。
- [ブランチを作成] をクリックします。Bamboo では、計画の指定されたリポジトリ内のブランチが自動でチェックされます。
- 利用可能な VCS ブランチから選択して、[作成] をクリックします。
- You can override the default settings for the branch, such as the source repository used, if you wish.
ブランチを Jira と統合する
開発者は、Jira 課題に記述されている機能の開発を始める際に、Git や Mercurial を使用してリポジトリのブランチを作成します。課題キーを VCS ブランチ名の一部として使用すると、Bamboo によって課題キーが検出され、新しいブランチが自動で課題にリンクされます。
- ブランチ名に Jira 課題キーが含まれている必要があります。「jb-BDEV-790」や「BDEV-769 1」は有効な形式です。
- このリンクは、計画ブランチの [Build Result Summary (ビルド結果の要約)] のブレッドクラムのすぐ下に表示され、Jira 課題にも表示されます。
To use JIRA Feature Branching, Bamboo needs an application link to the JIRA server.
ブランチの通知
master 計画の場合と同じように、ブランチ計画からビルド通知を受け取ることができます。
計画から作成されたすべてのブランチによる通知の送信方法を指定するには、計画の設定の [ブランチ] タブに移動して、次のいずれかのオプションを選択します。
- Notify committers and people who have favourited this branch.
- 計画の通知設定を使用する。
- このブランチでは通知を送信しない。
You can override how notifications are sent from a particular branch plan, if necessary, by going to the Notifications tab on the Plan Branch configuration.
See Configuring notifications for a plan and its jobs for information about plan notifications.
ブランチの依存関係
You can use build dependencies for plan branches in a similar way to that for plans: a branch plan is triggered only when another branch plan has been successfully built. This can be used to ensure that breaking source code changes associated with one branch plan are detected before they can break the build of a dependent branch plan. Dependencies between master plans are maintained if their branch plans have the same name. See Setting up plan build dependencies for further information about dependencies.
Select Trigger Dependencies for Branches, on the Dependencies tab for the plan configuration, if you want plan branches to honour the build dependencies of their respective master plans.
計画ブランチの設定
計画ブランチの作成が自動か手動かにかかわらず、master 計画はそのブランチ計画の構造と構成を管理します。ただし、設定ページに移動して、ブランチ計画の次の設定を上書きすることはできます。
| Branch clean-up (ブランチのクリーンアップ) | On the Branch Details tab of the branch's configuration, you can specify that a plan branch is not cleaned up automatically.
|
| トリガーのタイプ | On the Branch Details tab of the branch's configuration. See Triggering builds. 1 つの計画ブランチに設定できるトリガーは 1 つだけであり、これは master 計画に設定されるすべてのトリガーよりも優先されることにご注意ください。 |
| マージ | On the Branch Details tab of the branch's configuration. Described below. |
| ソース リポジトリ | On the Source Repository tab of the branch's configuration. See Specifying the source repository. |
| 通知 | ブランチの設定の [通知] タブにあります。オプションは次のとおりです。
See Configuring notifications for a plan and its jobs for information about plan notifications. |
| Variables | On the Variables tab of the branch's configuration. See Defining plan variables. |
自動マージの使用
ブランチのマージを自動化する場合、Bamboo には 2 つのマージ モデルが用意されています。
- ブランチ アップデーター - ブランチ リポジトリが master の変更に応じて最新の状態に保たれます。
- ゲートキーパー - 正常にビルドされたブランチが変更された場合にのみ、既定のリポジトリが更新されます。
The automatic branch merge strategy for the master plan can be overridden in an individual plan branch, if required.
ブランチ アップデーター
使用環境
ブランチ アップデーターは、次のような場合に使用してください。
- Automatically merge changes from the team's master branch into your feature branch, after a successful build of the master branch.
- フィーチャー ブランチの変更がチームの master ブランチに対応しなくなった際に通知を受け取ります。
設定
別のリポジトリの最近の変更をブランチ リポジトリに統合するには、次の手順を実行します。
- ブランチ計画の設定ページの [ブランチの詳細] タブに移動します。
([すべての計画] タブで計画名の横にあるブランチ アイコンをクリックして、[アクション] > [ブランチを設定] を選択します。) - [マージ] で [Branch Merging Enabled (ブランチ マージが有効)] を選択して、[ブランチ アップデーター] をクリックします。
- [Merge From (マージ元)] リストを使用して、フィーチャー ブランチにマージする変更が行われるリポジトリを選択します。
- [成功時にプッシュ] は、ビルドが正常に完了した後で変更をブランチに再マージする場合にのみ選択します。
- 保存をクリックします。
Gatekeeper
使用環境
ゲートキーパーは、次のような場合に使用してください。
- 両方のブランチからマージされた変更が正常にビルドされた後、フィーチャー ブランチをチームの master ブランチに自動でマージします。
- 両方のブランチから結合された変更のビルドが失敗した際に通知を受け取り、フィーチャー ブランチがチームの master ブランチに再マージされないようにします。
設定
正常にビルドされた変更を別のリポジトリにプッシュするには、次の手順を実行します。
- ブランチ計画の設定ページの [ブランチの詳細] タブに移動します。
([すべての計画] タブで計画名の横にあるブランチ アイコンをクリックして、[アクション] > [ブランチを設定] を選択します。) - [マージ] で [Branch Merging Enabled (ブランチ マージが有効)] を選択して、[ゲートキーパー] をクリックします。
- [チェックアウト] リストを使用して、変更をマージする (同時に変更のプッシュ先となる) リポジトリを選択します。
- [成功時にプッシュ] は、ビルドが正常に完了した後で変更を他のリポジトリにプッシュする場合にのみ選択します。
- 保存をクリックします。
計画ブランチの制限事項
計画の自動ブランチングおよびマージには、次の制限が適用されます。
| 操作 | 制限事項 |
|---|---|
| 計画の自動ブランチング |
|
計画の手動ブランチング |
|
| ブランチの自動マージ |
|
ブランチ ウォールボード
The branches wallboard displays the status of all the branches and the plan that the branches belong to. The plan's own status always appears first. Plans shown as grey are disabled.
ブランチ ウォールボードを表示するには、次の手順を実行します。
- 表示するブランチがある計画の [Plan Summary (計画の要約)] に移動します。
- [アクション] > [ブランチ ウォールボード] を選択します。








22 Comments
Anonymous
Oct 12, 2012For the longest time we were trying to figure out what regex we needed to enter to get our branches pulled in. Figured I'd help others out.
The above regex will work for (where ANYTHING can be any value):
feature/ANYTHING
hotfix/ANYTHING
release/ANYTHING
This is useful if you are using the git-flow feature in SourceTree or Git
Lukas
Aug 16, 2013Thank you so much for this comment! Saved me a lot of time!
Anonymous
Feb 08, 2013We have noticed that when we turn on automatic branch detection, and create a new branch, a duplicate of the new branch will be added to the plan each time the automatic branch detection runs (so every 5 minutes).
We have just upgraded to Bamboo 4.4.0, and this didn't happen under our previous version (4.1.3).
Any idea what is going on?
ArmenA
Feb 08, 2013Hi there. I am really sorry that you are facing this issue. Please open a new ticket on https://support.atlassian.com/ja, and in your support ticket please mention your current comment. This way we will know that you have been helped.
Please reproduce the problem and provide your Bamboo logs and screenshots indicating the issue. We will investigate it, and in case there is a bug, we will try to fix it as fast as possible. Will talk to you on a support ticket.
Armen
ArmenA
Feb 08, 2013Is this what you meant? BAM-12789 - Getting issue details... STATUS
Anonymous
Feb 13, 2013OK, I'll raise a ticket. Thanks.
Oleg Semyonov
Feb 27, 2013When a new commit detected in a plan branch, Bamboo queues it for a build. What exactly remembered by Bamboo to checkout - branch names (as it is supposed to be) or explicit commits?
The problem is following:
- You have few branch plans configured as Gatekeepers for an integration branch (let's call it next).
- Developer A pushes his changes into personal branch, Bamboo checkouts next, merges A's changes into it, and starts building it.
- While it is building, Developer B does the same for his branch, and build B is queued.
- After the plan A completes, Bamboo pushes updated integration branch (next) to Gitolite server.
- Bamboo takes queued build B and checkouts integration branch (next) to do the same.
The problem is that on that step Bamboo 4.4.0 checkouts not NEW state of the integration branch with just pushed changes, but that commit in the next which was last when the build B was queued. As result, it attempts to push back non fast-forward changes, and since they are disabled on Gitolite, the push fails. In fact, this makes impossible to use this feature because too many pushes fail if you have active committers.
As I understand, it should checkout next by the branch name to its current state with just pushed updates, not an older commit (we configure branch by name, not a single commit). Then there will be no such problem since all commits into the integration branch will be fast-forward.
Is this behavior by design? Any suggestions?
Oleg Semyonov
Feb 27, 2013Commenting my own comment: I think it's done this way to make possible to rerun the same build with the same data. But in that case we need an option for integration branch with automerge: should the HEAD at the time of queuing be remembered or Bamboo should fetch its actual state before merge and build...
Oleg Semyonov
Mar 02, 2013https://jira.atlassian.com/browse/BAM-12926
Ron Stanonik
Apr 07, 2013I configured plan branches to automatically manage branches that match release/.*
That does create a plan branch for each new release (eg, release/1.0 release/1.1 ...)
But it doesn't run the plan branch.
Should I enable a trigger in the Plan Configuration (every 180 seconds)?
But I don't want the parent plan to trigger, just the latest release.
Thanks.
Lee Winder
Nov 13, 2013Is it possible to display the most recent or currently built branch status on the Build Dashboard for Plans with Plan Branches active? For example, our default branch is 'develop', but actually that never gets built, instead we build branches called 'feature/x' or 'feature/y'.
But this means that the Plan in the Dashboard always shows 'Never Built' even though we've built all of the other branches in there. It also means that if a branch is being built, the 'In Progress' icon isn't displayed (again it's showing the 'Never Built' status of the 'develop' branch) so at a glance it looks like our build machine is not busy when in-fact it is.
Thanks
user-055e6
Dec 05, 2013The problem I am having is that only the primary repository allows me to select a branch to build from. Would it be possible to enable branches on secondary repository branches when building? For example our primary repo is our main source but we have a secondary repo for our shared jars. We have different branches for the jars repo. As of now I have to hard code the jar branch when I build. I would like to have a secondary branch(es) drop down(s) for any repos other than the primary repo that have branches enabled for that repo.
ArmenA
Dec 10, 2013Hi Patrick, I think your described feature is tracked here - BAM-11803 - Getting issue details... STATUS .
Armen
Anonymous
Jan 15, 2014Dead Link: Java documentation on regular expressions
NathanA
Jan 16, 2014Ooops, it looks like Oracle have changed their documentation. I've updated the link with the new page.
Thanks for pointing this out.
Jordan Baucke
Jan 20, 2014I am attempting to implement a Plan Branch and Auto-merge strategy.
Plan Branch: So far, I have Bamboo automatically detecting feature branches, and correctly triggering builds when a commit is made and pushed on that feature branch. So that is working.
Auto-Merge: I have setup the Gate Keeper functionality (to merge & push the feature branch into the parent branch on successful completion of build)
I see the "merge" as having completed successfully under "Build result summary > Branch Integration Details" Feature Branch commit xxxxx successfully merged with xxxxx (latest commit on Plan's branch)
Issue: When I check the commits and branches on BitBucket however, I don't see the two branches as having been merged (the way they would be had I selected to merge them manually)
Does this process not actually run the merge process? Just test the result? And it's up to the developer to run the ACTUAL merge?
James Dumay
Jan 21, 2014You should see the merge details on the result page but at the moment the merge commit does not show in Commits.
Jordan Baucke
Jan 21, 2014So the commit has taken place? I don't see any commit / commit message?
James Dumay
Jan 21, 2014Can you see the commit in the git log? If not, be sure that you've checked
in your merge configuration.
Jordan Baucke
Jan 21, 2014I've added some screen captures, I actually maybe correct (and I just didn't realize the merge'd commits were rebased) onto my parent branch: http://imgur.com/a/OcoWW
James Dumay
Jan 22, 2014I spoke with our engineers and we use a fast forward merge, which does not leave a merge commit.
Jordan Baucke
Jan 22, 2014Thank you James, this makes sense. I appreciate the support!