Integration Bamboo + Jira: When defining in Jira a Release, why is it integrated/linked to Bamboo Builds and not to Bamboo Releases?

Daniel Tunjic

We are in the process of evaluating Jira and Bamboo as our potentially future plattform and learning / playing around with our local evaluation installations as much as we can.

Right now I focus on the integration of the CI/CD perspective and the integration with Jira.

We found following basic understanding issue, that we as a team can not solve on our own.

Please bear with me when explaining the basic setup and need "a little bit".

Consider following simple scenario for our website development:
We use classically 3 "stage"-environments:

1. (local developer laptop)
2. Dev-Stage (loadbalanced servers for early developer feedback)
3. QA (loadbalanced servers where internal end-user make tests by hand as well es automated QA)
4. Production environmant.

We took one solution / website (Visual Studio sln File) as a example to evaluate with.

First we defined a Jira Project (template "empty jira project") and we defined a Bamboo Build Project having one Plan.

According to https://quickstart.atlassian.com/en/qac/download/bamboo/get-started/bamboo-elements/ (specially secion 'stages') - we defined the whole "super mario" jumping process from Dev > QA > Production within this one plan using stages.

According to our needs, we defined those 'stages' (now ment in bamboo terminology) that deploy to our environment stage as 'manual'.

To be complete please take a look at the following screenshot an note the "pause" icons that mean the stage is "manual":

We did this is because our Dev-Stage is actually the "developers QA" stage. They can build, automatically integrate-test, smoke-test,unit-test, load-test how often they like and need.

Our QA-Stage is more our DevOps/QA-Stage. This stage gets only the builds that the lead developer decided manually to provide to our whole QA Team and proved already on the dev stage to be stable.

Our whole QA testers have now to proove by automated and manual tests, that a package indeed is worth "releasing" to the prod stage. So they too have to manually "release" the package and trigger the automated deploy to the production environment.

After deployment to prod we "only" do smoke testing in terms of a sanity check that nothing basically went wrong after deploy.

Now back to Bamboo.

After creating the plan with its stages and jobs per server, we defined a Bamboo Deployment Project with the environment.

We find this feature genius, because it need indeed a lot of builds to get the final package stable. And this view show on a blink of an eye what Release (=labeled build) is deployed where.

And now we're ready for the first question. Take a look at this screenshots:

We have now a build that is actually sucessfully deployed on develop. OK. Now we click on the "create a release" button and want officialy nominate this build as a candidate for the next environment > therefore "release 1.1.36".

Now the first question: How could we automate for the dev stage the fact that actually this build is already deployed to the Develop stage. It shows here "develop stage never deployed". Actually we did this within the bamboo plan? We have no clue how all the "stages" that are actually logically linked to an environment could play together automatically.

We understood that when clicking in the bamboo deployment stage deploy release X that we can define own scripts what this should do. But where is the point in automating everything in the bamboo plan and again in the deployment plan?

After that we found the second question Regarding integration with jira.

In the corresponding Jira Project we can define Versions. We did this too and could argument sense in that. Our end user folks should be able to bundle their tickets, issues, bug into an logicall Version/Release (you name it; whatsoever).

And we even found it charming, that maybe our product manager could decide alone, what bamboo "release" that our QA team labeled to be "ready for production", should actually be deployed further. Maybe he can choose from two or three "ready" packages, but he want a new feature be deployed in e.g. 3 days; not today.

Therefore we took this usage path:

And now the actually second and main question.

Why is this part integrated into Bamboo Builds and not with Bamboo Releases? It seems to us that the Jira users can now (by clicking the according manual checkbox) deploy any build that has not run through (=finished) to any environment stage as he likes without understanding, what build is being labeld a "release" or who has approved what release at what stage. And if he triggers the further executino of this unfinished builds, they do not sync their status to the Bamboo deployment plan so we got lost in our basic understanding.

We simply have difficulties to understand how this puzzle of Bamboo Plan/Stages, Bamboo Deployment Environments, Bamboo Releases/Aprovals, Jira Versions/Release, is logically linked out of the box.

We tried to figure it out on our own by the forum, googling and the docu, but could solve the riddle. Sorry in advance for the long post and if the answer should be somehow easily gainable and we missed to find it.

Thank you for feedback in advance.

Gretchen

I think the answer is that we have always (since I've been using bamboo, 3 years now) been able to deploy using the build side. The deployment side is new and has a lot of overlap with the build side because previously that was what we had. I suspect the goal was to allow you to migrate (copy/recreate etc.) the deployment tasks over to the deployment side and remove them from the build side.

This takes a bit of adjustment and acceptance to break away from the concept that the dev deployment is part of the CI build rather than a valid deployment in its own right. Even though it's "only dev" it's still a deployment to an environment and should configured that way if you want to represent it via the deployments component of bamboo. Now whether you can do that without configuring it as a true "release" (which I wouldn't expect every dev deployment to be considered a part of - though that is arguable) I don't know. That gets into the whole partial/full deployment discussion and I don't want to go there right now.

Now your second question regarding the integration with JIRA and how releases in JIRA are linked to deployments in Bamboo and how the controls on this should work is a bit trickier and an area I don't have much insight into. It seems that you wouldn't ever want anyone, except the annointed few, to trigger a deployment to production from JIRA (unless your CI/CD mindset is pure - and I suspect most aren't). CCB's and paperwork that typically accompany deployments to highly controlled environments would prevent that type of access in any company I've ever worked for. Perhaps QA leads would have rights to deploy to QA and maybe UAT type environments if full responsibility (aka ownership) of those environments belongs to them.

In general I wish there were more test cases like this available on any of the atlassian sites to provide visibility to complex deployment projects with exception cases to promote discussion of this type.

I'd like to hear more from users who are actively using the deployment functionality on how it's working for them. I have several projects that are moving in that direction (a couple set up but not being used at this time) and I'm looking forward to working with it. I don't however expect it to be without its challenges. No one can code for all the ways we crazy devops people think up to use an application.

Thank you for posting this question, it has given me some things to think about. I hope you were successful in your testing, I noticed this post was rather old and hadn't been responded to. I would be interested to hear what you decided and how you ended up implementing this in it's final version.