nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you do deployments?

James Dumay

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?

Accepted answers

Keith Miller

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:

https://github.com/SingleMalt/bamboo_build_reset/blob/master/resetVersion.py

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.

All comments

Jan Swaelens1

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.

Asa Baylus

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.

Keith Miller

https://github.com/SingleMalt/bamboo_build_reset/blob/master/resetVersion.py

James Dumay

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

Keith Miller

My vote is in!

Barry Pitman

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'?

James Dumay

Whats the nature of your deployment? A website? What language?

Asa Baylus

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

James Dumay

Very useful - thanks for the feedback!

Adam Myatt2

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bamboo

deployment