Looking for some best practices advice here .... One of the key requirements we have for using Bamboo is to show in JIRA how a bug-fix or feature is linked with a build and where all it has been deployed. In this context we are mostly interested in showing the builds those are deployed to production environments. Issue linking with builds is happening but as we are building continuously (several times a day) issues are spread across several builds. When release time comes we create a final build and in this build we want to show all Issues since the last release. How to do this?
We thought reverting the svn rev number of the build workspace to the rev of last release would trigger svn up of all changes since last release and hence update the linked issues list, but that did not work. Looks like Bamboo saves this linked issues list somewhere else? Do we need to clear this cache or something? Another idea we have thought (though not tried) is to have a different build plan and workspace for production builds and run the build there only during release times, but again sometimes we may need to run the build multiple times before final build is ready, then how do we get a full list of linked issues (since last release) to the final build?
Any pointers or advice will be much appreciated.
Similar concern, How does Bamboo distinguishes between builds and releases ? And How to treat each build as release candidate but whether released or not remains in Manual control, with this will it be possible to list all issues fixed till current build from previous release ? Idea is to have Continuos Integrations with Continuos delivery (as function of major releases).
We use a perl script (which runs as part of the build) which uses the previous tag as an argument. Then we do an 'svn log' to find all the changes since the tag was applied, which gives us a list of the issues as we use the issue ID when we commit code.
You can use Deployment Projects in Bamboo for continuous deployment/delivery, and this allows you to see all the commits and issues they mention between two releases.
You'll need some kind of verification step to deployments so you don't promote to next unless this environment looks okay after the deploy.
Each build of a new version will create a "release" in the deployment project. If you look at a release there are tabs that show the commits and issues since the previous release.
If you don't want to release on every commit, create a separate release branch and only merge to that when you want to deploy. Then configure your release plan to build from that release branch.
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs