First, this is how we are setup: we have Jira with the agile (scrum) plugin, Bamboo (+ Fecru, Confluence) and our software is in several Mercurial repositories. So, what we could have is a version that looks like this:
Currently, when someone commits to the default branch of a repo, Bamboo will start a build and deploy that project to the Testing servers of our TAP street. There is no version being release, only build, test, deploy. Releasing a version to Acceptation and Production servers is done manually:
What I would like to have is something like this:
So, in all this, the only manual steps are: release the version in Jira. Deploy to Acceptation. Deploy to Production.
There are a few things I'm wondering about:
Quite a long story :) I'm interested in how other people solve this. TIA!
We do something similar. In Bamboo -- we have release build plans that are designed to be triggered from clicking the release button in Jira.
These build plans are separate from the nightly / dev build plans.
In the release builds plans, we have a custom script tasks that makes sure $bamboo.jira_version variable is set (this implies it was kicked off from Jira). If it is not set, then it fails the build. If it is, it continues.
We then have another script task which parses out this variable and uses it to do things like merge our release branch, change the maven pom file to the right build, do the build, etc.
Thanks Chris. How do you deal with versioning of the projects that are in a release? Do they all have the same version ($bamboo.jira_version) ? We often have releases where project A has fixes/new functionality but project B hasn't, and in that case project B's version shouldn't change.
In our case, we have 1 jira project that corresponds to an end-customer project. Within that project we can have N number of repositories -- each being it's own software product.
Because of this -- we use a naming convention in our versions. So for example, if we have a product called ABC, then we have versions in jira like this: ABC_1.0.0, ABC_1.0.1, ABC_2.0.0, etc.
We have a release build job for each product (eg, ABC). When a release is triggered on ABC_2.0.0 the build job parses out the version string to use in the build (for example, if it's a maven job, it fixes the version in the various POMs, merges the correct release branch, sets the commit tag at the end, etc).
If ABC has a dependency on XYZ 1.5, then it is expected that by the time we do a release in jira, that dependency is already properly set -- our releases are already tested at this point in their integration branches, so this is always true.
Hi, If you are running self-managed environments and looking to adopt modern infrastructure, Bamboo Data Center can now be deployed in a Kubernetes cluster. By leveraging Kubernetes, you can easily...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events