Bamboo build plans vs deployment plans for custom environment configurations

Question

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?

Awesome

Answer 1

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.

Awesome

The Build plan could build the solution and create all three configuration files that are each saved as separate artifacts. The Deployment plan could then select the appropriate configuration files from the artifacts to deploy. Possibly the configuration file artifacts would have to be named to indicate target environment and would need to be renamed when deployed. If renaming the files on deployment won't work, then the artifacts could be saved in different locations e.g. ...\config\dev\app.config, ...\config\test\app.config, ...\config\prod\app.config. – Gangplank