Iam very insterting in can managment release, but i have problems with plugins. Iam used a Bamboo 2.5.1, then any plugin is compatible …

Do you have a date about plugins will are compatible with bamboo 2.5.1?

Can i help you? … iam very interting!!!

After 1.0.0 is released, work will start on new features in 1.1.0. So new versions will be created, say: 1.1.0-dev1, 1.1.0-rc1, and 1.1.0; the bamboo build plan will start building 1.1.0-dev1, because that is the ‘first’ unreleased version, correct?

In the meantime we will need to fix some bugs in 1.0.0. Here the picture is not clear…

Normally the bug fixing occurs on new ‘release’ branch in SCM. If this work lasts about 2 weeks, to get some continuous builds, we will have to create another build plan for the new branch, and I guess associate this plan with same Jira project for which we need to create a new 1.0.1 version (in addition to the 1.1.* versions created after 1.0.0 was released). At first this 1.0.1 version is also unreleased in Jira, correct? How does the Jira versions plugin know that it needs to build 1.0.1, and not 1.1.0-dev1?

Or do we have to create a new Jira project for this, and start with 1.0.1

Can you clarify the sequence here?

Thank you

problem 1 (change log): Currently the way to do this is to include JIRA issue numbers in your svn commit comments. You can also add a pre-commit hook to ensure every comment has a valid issue number. Then, JIRA and bamboo will be able to tell you the related issues in a commit. Finally, if those issues are marked with a “fixfor” version, you’ll be able to hook up everything you want.

problem 2 (branch building): there are many ways to handle this in bamboo. one way is to create plans for each branch that builds when code is committed, then create a plan for the trunk that is always built manually. This way you can make a bunch of builds during development on the branch and when you’re ready to go to staging, merge to the trunk and run the trunk plan.

problem 3 (building tags): CustomWare has a plugin that will allow you to build specific tags. I haven’t used it but it may work for you.
https://plugins.atlassian.com/plugin/details/5790

- Jonathan

I’ve been setting your example up. I’m trying to evaluate jira+bamboo to replace our in-house release management tool.

The problem is: if I set up 2 staging versions (1.0-staging and 1.1-staging) how can I check which closed (or resolved issues) does build 1.1-staging include ? Because, in the end, the client is going to ask for that “change log”

Another good thing would be to build based on a branch. For example, you have to release an emergency fix on 1.0-stating. And that is labeled on SVN. How would you build that branch? Do I have to create a new plan for the project?.

Or better still, imagine you build 1.1-DEV and check that it’s OK for Staging. You’d want to “re-build” it based on that tag, not the HEAD of the repository. Is there a way to do it without creating a new plan and setting the SVN URL to that particular tag ( svn://server/project/tags/1.1) ?

Just one suggestion, I think it would be best to create the tag before the build, and checkout the tag. That way you make sure that nobody commited anything to the repository during the time of the build.

Thanks!!

Very nice post.

Is there a reason to do the deployment as a Post Build Command instead of in the main Build or in another, dependant, plan?

I also would like to do some automated functional testing (Selenium/Tellurium scripts) after the deployment has succeeded. Perhaps I have to do that in another Bamboo Plan with a dependency on the Build/deploy plan. Is that correct?

What are the differences between putting everything in 1) the same build, 2) in a build and a post build command, 3)in different plans with dependencies?

Thanks!

Yves

Please provide a little more info on point 1 in the feature request.

Thanks!

- Jonathan

Our IT department is in the process of defining our release management process and stumbled upon this system. Excellent work.

Question: What would you think of having the ability to set a value attribute for the Version Type instead of using whatever was set as the pattern match? That way you could have the ${bamboo.custom.jiraversion.type} match multiple patterns (as one use case). Also the ability to specify a value to pass on a release (no key) would be helpful to some build systems.

If it’s not working, please log a bug.

If it is working and you would like some other way to turn off the run build links (i.e. don’t show them for a certain version type), please log a feature request.

http://developer.atlassian.com/jira/browse/BJVER

Thanks,

- Jonathan

thx
jdoklovic