How do you do deployments?

To help shape the future of Bamboo, we would love to hear how you do deployments.

Are your deployments automated? How do you automate them? What problems do you have with the way that it is being done now? What configuration management tools do you use (eg Puppet, Chef, MCollective, RunDeck, etc)?

If you are not automatically deploying, whats blocking you?

5 answers

1 accepted

The thing that is blocking me the most when it comes to using Bamboo for completely automated deployments is the fact that I cannot reset the build number in Bamboo. I wrote a quick Python script to do it:

The only issue is that backups now don't work because I'm not clearing out a key correctly somewhere. I'd much rather do this in Bamboo. I need the ability to do this to fall in line with our development cycle.

There is an open feature request to manage application version and schema numbers directly in Bamboo (not based off of build numbers). Would this work for you? If so, please vote for it :)

Our deployments to internal environments are automated from build to the actual deploy. We use Bamboo to create our build artefacts and actually deploy them to our application servers. For the deployment we use Ant scripts in combination with the application server's proprietary Ant tasks or scripts depending on the platform. In addition to that, we have created a, in-house deployment tool which is oriented specifically towards our application(s) for internal and external use. This tool uses the same principles as the scripts running currently in Bamboo and will replace them in the future by custom Ant tasks and maybe even a nice Bamboo plugin.

The biggest challenges with the deployment for us are the need to support different application server vendors and versions. This causes several variations of the same deployment script to meet the specifics of each application server vendor and version.

The error checking of the deployments and validation of the deployment (is it installed ok and does it run properly) is something that can be better too. Often errors are logged in some way but are not trapped by our scripts or Bamboo (because it is just a line in the output for example) leading to badly installed deployments and leading to user complaints. This is of course caused by the scripts/api's used to deploy the application, which are 3d party which means that we can't do much about it.

It would be fantastic to have deployment tasks out of the box in bamboo, lets say for Oracle Weblogic, IBM WebSphere, JBoss...

We don't really use configuration management tools but we do have a meta database with server meta data and we try to use standardized scripts and procedures to install and configure our servers.

We usually mount WebDAV to the filesystem and copy bamboo artifacts to the destination directory using ant ant script. Also rsync and Git based deployments are not unheard of.
Whats the nature of your deployment? A website? What language?
We have a static file server which hoss our front-end CSS, js and images etc. The code is built using ant, checkout html5boilerplate build script on github for a simular build routine. Anyhow we deploy the code using bamboo to execute an ant copy task which just moves the files to a WebDAV mounted disk. It's pretty rudimentary and were are planning to host this same code in the cloud, probably using custom endpoint on AWS or simular. Ultimately I'd love to integrate cache busting based on build number. One point of difficulty is that while we deploy using CI on Dev our test and production require manually triggered automated deployments. Since we've just upgraded to bamboo v4 I'm really keen to try our the manualy triggered stage. My only concern is that if we combine all our builds into a single plan a with a manuly triggered deploy stage then a Dev could carelessly deploy to prod not realizing that it just take the one click to trigger a prod deployment. I was thinking it would be nice to require a double confirmation like > Del *.* > are sure you want to do this? N, y

We use puppet for configuration management, but for us, configuration management and deployment are separate processes - puppet is declarative whereas a deployment is imperative. Where bamboo and puppet do overlap for us is that we use puppet to distribute the deployment script that we call from bamboo to execute a deployment.

I think that most people's deployment methods will be different - often involving custom scripts. I don't think that bamboo needs to get too involved in how deployments are performed (because each one if different), it just needs to provide a means of executing them (and seeing what you last deployed where).

One of my issues with using bamboo for deployment is this:

I have bamboo checkout and build my application on each commit in different stages, running tests, user acceptance tests etc, which works fine. Thereafter, I want to deploy the binary to different environments manually. Bamboo offers manual stage execution, but the environments that I want to deploy to are not necessarily sequential - our application is run as a service for different clients, and I don't want to deploy each version for each client.

I could split the deployment into a separate plan and parameterize it, but it would be nice to keep it as part of the pipeline that created it. It seems like bamboo is forcing me into running everything in sequence? Ideally I'd be able to split the plan after all tests have run into different streams, each with a 'deploy to test environment' and 'deploy to production'?

Very useful - thanks for the feedback!

Some of the key high level themes in deployment involve fleixbility in deployment methods, step by step audit logging of the deployment process, optional workflow approval (i.e. developers can deploy to Dev and Test environments any time, but only QA can deploy to Stage or Prod environments, etc), and the ability to ROLLBACK a deployment. I would suggest looking for examples using the ControlTier deployment product. We don't use it internally, but i did a quick eval and it seems to handle many of the concepts talked about here in this thread. Obviously it's a separate product with a different focus than Bamboo, but if you're looking for ideas for deployment scenarios and capabilities that is a good place to start.

Suggest an answer

Log in or Join to answer
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,093 views 0 5
Read article

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot