Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-14419

Deployment Project sourced from multiple builds

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Unresolved
    • None
    • Deployments
    • None
    • 1
    • 5
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      Our scenario:

      We primarily build Java web applications (usually packaged as ears) using Maven. Currently, each project has the following Bamboo builds:

      Build - Monitors "master" and continuously builds snapshots (e.g. 1.2.12-SNAPSHOT). Snapshots are deployed to our Nexus maven repo upon build completion (in our snapshot repos)

      Release - Manually triggered when the project is ready to begin the QA process and potentially be deployed to PROD (e.g. 1.2.12). Releases are deployed to our Nexus maven repo upon build completion (in our release repos)

      Site - Maven site build (documentation, static code analysis, etc...)

      Deploy Dev - Builds a new snapshot and deploys to our DEV environment (this is NOT a "Deployment Project", we have had these for years)

      We would like to use the new-ish "Deployment Project" feature of Bamboo, but it doesn't seem to fit our current workflow since it only allows a single build plan source.

      We have 4 environments (DEV -> UAT -> QA -> PROD). The way we currently work is:

      1 - Deploy snapshots (from the main "build" plan) very often to DEV. We also deploy these snapshots to UAT for clients to test and provide feedback. UAT is the furthest a SNAPSHOT can go in the deployment chain.

      2 - When features and bugs are complete for a version, then we trigger the "Release" plan. This uses the maven release plugin to take the project out of snapshot, deploy the release to Nexus, increment the POM versions and put the project back in SNAPSHOT mode for continued development.

      We then take the RELEASE and deploy it to DEV, then UAT, then QA and (hopefully) PROD.

      Our Problem:

      The problem we have is that "Deployment Projects" can only source from one build plan. If we pick the "build" plan as our source, then we would end up promoting SNAPSHOTs up through the environments (which isn't permitted past UAT).

      If we pick the "release" build as our source, then we won't be able to deploy SNAPSHOTs to DEV and UAT.

      Ideal Solution - Allow multiple sources:

      In a perfect world, we would have the ability to source artifacts from two build plans. That way, when it comes to deploying the latest snapshot to DEV for testing, we could source from "build". When it time to promote an actual release through the environments, we would source from "release".

      I realize we could "edit" the build plan every time we want to switch from "build" to "release" as the source, but that seems clunky and error prone.

      Is there any chance that multiple build sources could be included as a feature in a future release of Bamboo?

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              0af82789ca7c Andrew Pitt
              Votes:
              11 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

                Created:
                Updated: