The goal of this post is to find some resources about Bamboo Best Practices, review the current setup on our project and propose some changes.
The very basic resource is a video course on Lynda.com. I’d suggest such course to a developer starting out with Bamboo as it contains quite a comprehensive overview of Bamboo’s structure, architecture and set up. Then we have the main resources directly from Atlassian (links to a direct example page):
- Documentation – contains basic information how to use main features, not many real life examples
- Community – discussion, similar to Stack Overflow, contains some real life scenarios and advice from other Dev teams also trying to build a dream pipeline
- Blog – official blog posts that go into more detail than the documentation but still feel a bit high level and without real life examples
In general from this on-line search exercise I picked up a few main points to consider when building your pipeline:
- Fail fast (the whole team should stop committing and go fix the bug)
- Leverage Plans, Stages, Jobs and Tasks
- Checkout SVN ideally once
- Use shared artifacts instead of multiple SVN checkout when possible
- More than 1 agent? Use parallelism where possible.
- Leverage branching (feature/release/hot-fix …) – more relevant for Git based projects
- Use Deployment Projects for higher environments (TRAIN, UAT, PROD, …) – can be automated/scheduled/manual deployment
Current setup on a project
This chapter describes our current setup on a project. Diagrams follow the C4 Model structure. C1 being the most high-level overview, C2 representing the Bamboo CI pipeline’s structure and later C3 going into detail of one of the Jobs.
C4 diagram – level C1
C4 diagram – level C2
In Build and Deploy Stages, the jobs run in parallel, but the Test Stage has only one job that executes tests sequentially.
One of the key slow-downs during deployment is the use of a client’s tool called SCM* for deploying MS BI projects. It takes about 5-6 mins for each project to be deployed (SSIS, SSAS, SSRS Native, SSRS SharePoint). SSRS cannot run in parallel which makes the whole Deployment Stage run about 10-12 mins each time.
*SCM is a client’s in-house deployment tool/web application. Developer can use it to manually package an artefact and deploy it to different environments with PROD having further auditing options and special approval process to schedule the deployment. The tool supports also other types of projects but in this post we are considering only MS BI. In the background the tool uses custom developed PowerShell scripts to deploy MS BI artefacts.
After using it for 1-2 years we have come across a few pains with the current solution:
- CI overall duration (takes about 40-50 mins to run)
- Building and deploying stuff that did not change
- Testing stuff that did not change
- Disabling tests requires full build and deployment
Suggested Improvements (shown on diagram below in practice)
- Covers pain no. 1,4
- Uses Parent-Child dependency between Bamboo Plans (Build > Deploy > Test as seen on below diagram)
- Test Plan uses SVN checkout to get the tests (if triggered by parent, it maintains revision)
- Child plan does not start if previous plans are queued/running or have unbuilt changes (can be changed in settings)
- Main advantage: Test plan can be triggered separately after fixing/enabling/disabling a test in SVN
Main disadvantage: While Test plan is running, there can be a next run already triggered which will start a new deployment which can interfere with the tests
- Can be solved by a custom script task using PS-Bamboo module that would check in a do-while loop if Test plan is running (at the expense of blocking an agent possibly for a long time)
Run Tests in Parallel
- Covers pain no. 1
- Some of the tests can run in parallel which will save quite some time, ie. Report execution tests
- Different Stages can be seen on below diagram under Test Plan – within Stage we can add several parallel jobs
- Would need adjustment of paths in NBi/NUnit tests to leverage shared artefacts executed on different agents
Skip Tasks If No Changes
- Covers pain no. 1,2,3
This would make use of Bamboo global variables Previous SVN revision and Current SVN revision for SVN diff command in a script task and then parse the paths of modified files in the script and based on that either continue or skip that specific build/deploy task
- Such example workflow is shown below on C4 diagram – level C3: Deploy SSRS Native Direct job.
- Main advantage: It would work with the current plan setup as well (only 1 plan)
Main disadvantage: Currently it works only with script task, not with specific Bamboo tasks (SCM Deploy plugin, artefact download, NUnit runner, …), meaning that we could skip only a step that can be written in a Script task
- Can be solved by a free skip task plugin (needs to be added by Bamboo team at client’s company)
Custom Deploy Scripts
- Covers pain no. 1
- Use of “direct” deploy scripts in PowerShell (or using Tabular Editor for SSAS) instead of client’s in-house deployment tool which is slowing down the Deployment part of our pipeline
- Such scripts are already in-use in DEV and for local DEV environments so they can be ported to CI pipeline
This suggestion was implemented during this exercise and brought down the time for deployment of:
- SSIS, SSAS from 5-6 mins to well under 1 minute
- SSRS Native from 5-6 mins to 2-3 mins
C4 diagram – level C2 (suggested)
C4 diagram – level C3 (suggested)
The following diagram shows a detailed look at the Deploy Stage where we have several jobs running in parallel on different agents. One of the jobs is then displayed with all its steps (tasks) which is the lowest detail in Bamboo’s setup.
There is no clear answer how to universally setup Bamboo pipeline as a best practice. That was probably expected because each project/technology is different and has specific needs. Especially MS BI projects, compared to software development, ie. Java/C# CI pipelines with unit tests.
While looking at the official and unofficial suggestions, examples and best practices, I realized that the basis of our set up is quite well done. This is mainly due to the fact that in the beginning we sat down, examined the main Bamboo options within a plan (Stages, Jobs, Tasks) and tried to create the most versatile and fast pipeline using common sense. This is something I’d suggest to any Bamboo newbie (and works for other technologies as well): Find out what your tool is capable of and then build what you need around it. Then with time and experience you will be able to iterate on that and bring your setup ever closer to perfection.