Deploy multiple artifacts from Bamboo build to different servers

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.

2 answers

1 accepted

This widget could not be displayed.

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

-Rich

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!

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

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.!

This widget could not be displayed.

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.

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.

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".

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!

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

113 views 2 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you