Quick background:
95% of our projects produce a single EAR as an artifact. Each of our projects generally have the following four builds:
- Build (Triggered upon each commit. Produces a snapshot)
- Release (Manually triggered. Produces a non-snapshot artifact)
- Site (Maven site build, run nightly)
- Deploy Dev (Deploy the most recent snapshot to DEV)
What we want to do is get rid of our "deploy dev" plans, and use "Deployment Projects". We are moving towards automated deployments to three environments (DEV, UAT, QA), so this seems like a natural fit.
The problem I'm having is that a Deployment Project can only be sourced from a single build. For us, that causes a big problem because:
- We want to be able to deploy snapshots regularly (maybe 2-3 times/day) to DEV, and sometimes to UAT
- When it's time to do a release, we want to be able to promote the release through all environments
Ideally, when you generate your next "Release" for your Deployment Project, you would be able to pick from more than one source plan (perhaps provided the plan produces an artifact of the same name). Since we can only source from a single plan, we are either stuck with snapshots (which will never make it past UAT) or with releases (which means we can't user our deployment project to deploy snapshots to dev).
We could keep our trusty old "Deploy Dev" plans for snapshots and use a Deployment Project only for releases, but that means two things:
- We have to duplicate the "DEV" deploment config in a normal bamboo build and in a Deployment Project.
- The deployment history for "DEV" in the deployment plan would be useless, since most of the deploys to that env would be from a different plan.
Has anybody else run into this problem and solved it? I created a ticket with Atlassian about this a month ago, but it's still awaiting triage.
Thanks!