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?
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.
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 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'?
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.
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
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!
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