Change macro parameters in bulk on selected Confluence pages or blogs
How to use ScriptRunner to automate your code review best practices
Get version control and manage all custom scripts in ScriptRunner for Jira’s Script Registry
This short post demonstrates how the ScriptRunner Cloud Engineering Team at Adaptavist benefits from using Bamboo deployment projects whilst keeping Staging tests entirely separate from deployments.
Separating Staging tests from Deployments helps to see if your deployment still works
The ScriptRunner Cloud Engineering Team runs hundreds of builds per day on the Bamboo server, with 26 actively used build and deployment plans grouped into sections for each microservice or feature within the product. Regardless of what we are building or deploying, all build plans follow the same pattern:
- When a branch is created in the repo, the plan runs unit tests and code analysis checks
- Once branches have been code reviewed and there are no build errors, we merge the changes and there is a corresponding deployment to three environments: Dev, Staging and Production
All Staging tests are separated from their corresponding deployments. This allows us to know, at a glance, if there is a deployment problem, or if the service itself no longer behaves as expected. We follow this process as deployment permissions could have been revoked or the service failed to start for some reason.
We see this as a separation of concerns:
- If the Bamboo deployment project performs deployments and nothing else, we can tell at a glance where the problem is if something fails.
- If the deployment is successful, but fundamentally breaks the functionality of the product, that should only show up when we run tests against the environment we deployed to. This also lets us run tests manually against an environment at a click of a button, without having to redeploy again.
Bamboo deployment projects don’t allow for separate testing on Staging before deploying to Production
We have been using Bamboo long before Atlassian introduced deployment projects, so when they were introduced we wanted to start using them right away. It’s a great way to view old releases and deploy them with one click when a roll-back is required. However, we soon discovered that Bamboo deployment projects have a major drawback: a deployment project doesn’t allow for separate testing on Staging before deploying to Production.
For example, you can start the Dispatcher Service Deploy Dev when the Dispatcher Service Default Build completes, and then you can run Staging after Dev, and Production after Staging. But there is no way to add the Dispatcher Service Staging Test on the deployment project (Dispatcher Service Deploy), because Bamboo deployment projects only deploy to environments and they don’t have a mechanism for running tests independent of the deployment. Because Bamboo only allows for the deployment to be triggered by the Dispatcher Service Default Build, there is no way to go from the Dispatcher Service Staging Test build to a Production Deploy.
Due to this limitation, we looked for a workaround that would allow us to enjoy the benefits of Bamboo’s deployment projects, without changing our setup. We immediately realised that using the Bamboo API we can trigger a deployment on demand. We could have written a Bamboo app using the API for our use case, but somebody would have had to maintain it. Not ideal, especially as our team is constantly stretched for time. Luckily, one of our colleagues pointed us to ScriptRunner for Bamboo.
The ScriptRunner workaround
If you’re familiar with any of the other ScriptRunner apps, ScriptRunner for Bamboo shares the same main features: creating complex automations, customisations and integrations by running Groovy scripts.
In our case, the ScriptRunner for Bamboo feature we needed was a Scriptable Task, which allows you to dynamically create and execute tasks with different parameters depending on build variables, files changed, etc.
So we created a Scriptable Task under ‘Trigger deployment’ to deploy to production after running our tests. It was built to be completely generic - meaning whoever runs the task needs to specify all variables (projectKey, deploymentName, buildKey, releaseName, environmentName) to trigger a deployment.
Now Bamboo runs the unit test build, then the Dev deployment before Staging deployment, whereafter the Staging Tests are run as a regular build. Finally the Scriptable Task triggers the Production deployment.
This is a quicker solution as compared to building and maintaining your own app. Groovy is very similar to Java so it is easy to write the scripts, and if you’re curious about the code we used for this particular scriptable task, you can see it below. You’re welcome to copy it and use it for your own optimisation needs.
Copy the script - tested on Bamboo 6
If you’re curious about the code, you’re welcome to copy ours and use it for your own optimisation needs. Please bear in mind that it has only been tested and used for Bamboo 6, and you might need to make adjustments for use on Bamboo 7.
ScriptRunner for Bamboo is an amazingly versatile tool that lets you customise, extend and automate your Bamboo builds as much as you need. Once Atlassian releases Bamboo Data Center, ScriptRunner for Bamboo Data Center will be available. Find out what you can achieve with it and start a 30-day free trial: