Deploy multiple artifacts from Bamboo build to different servers

[cvsudheer]

I have a single .Net solution which has got UI project and WCF service project. I donot want to maintain 2 solutions and deploy UI and Service separately. I succeeded in building the solution and creating the UI artifact package and Services artifact package from the respective Bamboo tasks (zipping the respective project o/p from MSBuild output). Now I have 2 artifacts to be deployed to 2 servers. UI should go to UI servers and Service should go to Service servers. Can this be done at the Bamboo deployment project level or at the Nolio configuration level?

I know I can do 2 Babmoo build plans (building the UI and Service source codes) and 2 deployments for UI and Service, but I am trying whether I can optimize it. Thanks in advance.

[Rich Duncan · Accepted solution]

Yes - we have plans that produce artifacts intended for different target servers and each environment the deployment project deploys the various artifacts accordingly.

-Rich

[cvsudheer]

Thanks Rich

Can you please elaborate on how this can be done in a Bamboo build.

Is it being done by configuring different environments and if so how to assign different artifacts to different environments?

I was considering another approach where I have a single repository, but have multiple Bamboo builds assigned to it. Right now I see that the Bamboo build is closely tied to the repository and I can't have multiple Bamboo builds tiled to one repository. Do you think that is a possibility.

Thank you!

[Rich Duncan]

Hi Sudheer:

Let's say your build plan produces 3 artifacts A, B and C.  You have to define these as artifacts produced by the plan's jobs.  Then, you create a Deployment Project for the plan.  Each of the environments can access any/all of these artifacts.  Then the environment uses Bamboo tasks to effect the deployment of these artifacts to the environment. This may be as simple as using the pre-defined Tomcat task to deploy a war, or could be multiple steps involving database updates, configuration file updates, application deploys and so on.

Deployment Projects are great for the average application deployment.  If you have a complex deployment that involves many steps and requires rollback, you might want to look at some of the more application specific deployment tools.

-Rich

[cvsudheer]

Thanks Rich!

I found a way to pick and choose artifacts for a deployment environment. On a Bamboo deployment project, add a task for deployment environment and add an Atrifact task on it as here:https://confluence.atlassian.com/bamboo/tasks-for-deployment-environments-339051206.html . Here I can add more than one artifacts to the deployment environment. Thank you for guiding me to this solution.!

[Rich Duncan]

[jvelapol]

While Rich's answer is correct, the specific case you mention (UI and backend to different servers) you might want to purposely keep separate - otherwise a deployment will deploy both artifacts simultaneously.

Note, in our case, we have 12 microservices that one of our projects deploy, and usually deploy everything, but now and then only want to deploy less than all 12 (say one or two) at a time.  So in reality, we have 13 deployments for one of our products, 12 are the individual microservices, and the 13th one is basically a "master" that kicks off deployment tasks for the other 12 microservices.  We found that to be convenient for our use case.

[Dave Sharone]

I'm trying to figure out how to do this!  I have multiple deployment projects, but when I want to deploy I have to run them one by one.  What did you use to kick off the other deployment tasks?!

I have separate deployment tasks for the same reason you do.

[jvelapol]

In our case, we have one build plan that contributes to one deployment plan.  That one deployment plan has 13 "environments".  12 of the environments deploys one of the microservices.  We also have 1 "environment" that we use to trigger the 12 other "environments".  Basically, each of the 12 environments has as a trigger a "successful deployment" of the "master environment".

However, you can only trigger a deployment to another environment within the same deployment plan.  So you can't, for example, trigger a deployment from one plan to another plan, but you can trigger a deployment from one environment in a plan to another environment in that plan.

EDIT: remember, that triggers go one way - you can specify what triggers my deployment environment, not that "if I run, then trigger these to run".

[Dave Sharone]

I see what you're doing.  I currently have mine setup as different deployment projects, but will look into using environments to allow triggering to work this way.

Thanks!