How to manage "new" artifacts?

[jvelapol]

We have a build that is currently churning along just fine.  We use plan branches to help keep our own sanity (rather than create n additional builds, one for each branch we need to maintain, then age them off).  One of the problems that I've now come across is if we have a "new" artifact (new capability, to be released in, say "release 1.7").  In our repo, "main" tracks "all current development tasks", and we branch off to create maintenance releases (so, we have a 1.0.x, a 1.1.x, a 1.2.x, etc up through a 1.6.x maintenance branches - though we only really need to keep track of "what's at least in production").

So far, we've been managing things just fine with releases up through 1.6.x.  However, in 1.7.x, we'd like to create a new capability and deployable component (call it new-capability.jar).  So, I edited our build plan to create a definition for the new artifact (new-capability.jar found in new-capability/target, with new-capability-*.jar as the target for the artifact).  The problem is, any deployments we do with 1.6.x now fail, since it can't find the artifact "new-capability.jar".

How do other people handle this situation?  Do you create multiple build plans for a given project, one for each release?  Do you have a "dev build" that runs, then when the time comes to create a "release branch", clone that project, and change the "target" branch from the "Repositories" heading for the Plan?  If you do that, how do you manage automated testing of feature branches?  (by default, we also build all feature branches, with some pattern matching of the feature branch name - we've gotten pretty good at training our developers to use feature branch names that correspond to an existing ticket so that's easy to only build actual feature branches that are planned for merging in the future).

[Timothy]

Are you using Branch Deployments?

Plan branches represent a build for a branch in the version control system.

Which is what you are doing when one branch has the artifact and one does not.

Branch deployments extend plan branches by allowing users to create a deployment release from any plan branch.

and

The problem is, any deployments we do with 1.6.x now fail, since it can't find the artifact "new-capability.jar".

This feature should complement the above feature. 

Source: https://confluence.atlassian.com/display/BAMBOO/Deployments+from+branches

[jvelapol]

Are we using Branch Deployments? I guess so - I can create a release on any branch from the Build Plan, then deploy that release to certain environments, if that's what you're asking. There are no automated deployments in our setup. We can certainly create a release, and that's fine. Our "download artifacts" task in the deployment is what fails, I think: error 22-Jun-2015 11:20:57 /data/bamboo/bamboo-home/artifacts/PROJEC-PLANXX/shared/build-00003/new-capability.jar is not a directory error 22-Jun-2015 11:20:57 Unable to download artifact Shared artifact: [new-capability.jar], pattern: [new-capability*.jar] anchored at: [new-capability/target] Then fails with: simple 22-Jun-2015 11:20:57 Finished task 'Download release contents' with result: Error It's possible that this was an isolated incident - (this was the first time that this artifact had ever actually been accessed, I think, and I don't know if it had ever been generated in the past). However, for this build/branch combo, the artifact would never have existed. Note that in the Deployment Plan, the task "download artifacts" I choose "All artifacts" (rather than the individual artifacts one at a time).

[jvelapol]

Nope - this will happen every time. It looks like I'll have to individually manage each and every artifact for each Deployment Environment, as they migrate through the environments. I was hoping that the "all artifacts" target for "Download Artifacts" task would have a checkbox to "ignore if you can't find the artifact". In this use case, it's not really an error. The alternative to this is to make a new build for every new release branch, but that just puts more burden on maintaining Build Plans, rather than Deployment Plans.

[jvelapol]

OK, so I think the reason why this doesn't work is because the artifact definition is for the entire plan, not for the plan branch. If Bamboo were able to modify the Artifact definitions for a job based on what branch was being built, and manage that separately, then I suppose that might work. Or, if I was smarter, I wouldn't actually manage individual artifacts, but dump them into a "artifacts" directory for the specific job that I'm interested in, and defining the "artifact" as "everything in this directory". It's possible, then, that what I'm asking is just not how artifacts work in Bamboo.