Let me prefix this by saying the following: Jenkins is a wonderful tool. It’s great, it works beautifully, and we’ve been using it for the last three years. There’s no argument against using Jenkins whatsoever, as long as you are comfortable with it.
Still though, when you are basically running all Atlassian tools there are (Jira, Confluence, Stash etc), chances are that Bamboo gives you something – actually, quite a lot – that Jenkins doesn’t give you. And that’s what changes everything.
The first 10 minutes. Feeling like being run over.
Yes, this is how I felt. You fire up Bamboo, after working with Jenkins for years, and the first thing you’ll say is “okay, what the beep do I do now?”.
And then, the next thing you’re saying is “Okay, let me try to copy my stuff from Jenkins over to Bamboo. Can’t be that hard, right?”. Well, it isn’t, if your Jenkins is up2date. Then you simply go into your Bamboo administration, click the Jenkins import link, point it to your Jenkins instance, and you are good to go.
If your Jenkins instance is, however, not up2date, this is where some learning will take place.
Projects, Plans, Stages, Jobs
This is how Bamboo, much like other Atlassian tools, splits up your tasks. You have your Projects, which are equivalent to your JIRA or Stash projects – which is what you’d have as a View in Jenkins. Then you have your Plans, which can be used to split your Projects into smaller models (for example, your Backend and your Frontend) – kinda like a subcategory for Projects to put your Jobs into. Stages are a lot like your Jenkins Jobs. You split your tasks up for you to have some order there. And last, but not least, you have your Jobs. And they are what you know as Tasks in Jenkins. Kinda.
Projects – Like Views
As I wrote before, Projects are more or less there for organizational reasons. Simply for you to know which thing belongs where. That’s all there is to it. No big deal, right?
Plans – Like Jobs, part 1
Here’s where things start do differ from Jenkins. Remember when I wrote Plans are like Jobs in Jenkins? Well, the biggest difference, up front, is that you can re-use Jobs in your Plans. As often as you like. You have 5 different test-runners and want to get all the tests together? Bamboo can do that. Split your Maven tasks up into phases and use them synchronized? No problem. This is what will be really nice later down the line.
Here’s where you’ll have one – or more – Stages.
Stages – Like Jobs, part 2
And here’s where the difference continues. Given that you’ll have multiple stages (for example, Checkout and Compile, Testing, Coverage), you want to have multiple Jobs in each stage. The Checkout stage should get your source, maybe compile it and install dependencies for testing (in node, npm install jumps to mind), and archive it so later stages don’t have to checkout the source again. In Testing, you may want to run Unit tests, Acceptance Tests, Integration tests, etc pp.
Here’s where you’ll have one – or more – Jobs. (CAREFUL: THEY CAN/WILL BE RUN PARALLEL)
Jobs – a Summarizer for Tasks
This is for further summing up your tasks. As stated above, for Testing, you want a Job that runs the Unit Tests, one that runs Acceptance Tests, one for Integration Tests, and the list goes on and on.
Here’s where you’ll have one – or more – Tasks.
Tasks – like Tasks
Tasks are pretty much exactly like Tasks in Jenkins. Just like Jenkins’ “Execute Shell”, you have something similar in Bamboo. The great thing is, you can add them as often as you’d like. If your Stage produces 5 different test results, that’s no problem.
Conclusion for week one
Yes i picked that word carefully. You will be confused for the first 10 minutes, I’m pretty sure. But after that, things will look quite similar, and you’ll have a great overview about what is happening, and when it is happening.
Stay tuned for next week, when i’ll get into integrations and the big difference