I'm evaluating Bamboo to replace our Jenkins setup and have a couple questions. I have a .NET solution that generates two artifacts: a packaged website and an MSI. I have three environments I deploy to: test, stage, production. Our Jenkins server in turn has three jobs--one for each environment. Each job builds the solution, copies in configuration files for the environment it will be deployed to and then deploys the artifacts. Reading the documentation and other stuff (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), I'm getting mixed signals about how deployment should work with Bamboo. It seems to me like deployment plans expect artifacts to exist and then deploy them. But, build plans include deployment steps as well. How is all of this supposed to interact together?
The reason I'm confused is because I have environment specific configuration files that get packaged during a build. Any direction on how this should work?
A deployment project in Bamboo is a container for holding the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed. Teams typically have QA, staging and production environments.
A Plan in Bamboo defines a sequence of tasks for Bamboo to perform. When a plan is triggered, Bamboo executes the defined tasks sequentially. It also provides options to define final tasks.
I posted the question to the Atlassian board as well and got an answer I think I like the best:
Jason Monsorno · 762 karma · Aug 30 '13 at 04:38 PM
Deployment projects in Bamboo seem to be dependant on the existance of an artifact, the catch is you don't necessary need to use that artifact so you could use an empty artifact and do completely independent steps. Deployment projects are still fairly new to Bamboo and your structure may favor the "normal" workflow so each environment would be a separate manual stage.
The Deployment project do have a separate workflow and versioning. To use Deployment projects in your scenario, I'd suggest making the artifact the entire checkout then each Deployment environment can build a copy of the artifact. The space-saving/less-time-efficient option would be to just save the current revision in a file as the artifact and use that to check it out and build in each Deployment environment.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With