You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
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.
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.!
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.
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".