You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.