Skip to content

Instantly share code, notes, and snippets.

@akesterson
Created April 29, 2014 06:22
Show Gist options
  • Save akesterson/11391984 to your computer and use it in GitHub Desktop.
Save akesterson/11391984 to your computer and use it in GitHub Desktop.
Why I switched from bamboo to jenkins
TL;DR - It was proving to be more buildsystem than I needed,
and I had found that there were other buildsystems that met my needs
that I felt were lighter and more nimble. It's still a fine product
that I continue to recommend to this day, I just no longer see it as
"The One True Way".
=========================
1: Bamboo was consuming a significant amount of system resources,
and I wasn't using much of its functionality.
Bamboo was running on my older combined webhost (where I run mail,
web, and a bunc of other crap together). And maybe it was just my version
( I was running 4.x or 5.x, either way I was not updating regularly ),
but it was a bit resource heavy. I wasn't using deployment plans,
I wasn't integrating it with jira or confluence, and even my github
and bitbucket integration was light. All it was really doing was pushing
1 sdist up to pypi, and a bunch of RPMs up to my YUM repo. I just didn't
think I needed that much horsepower tying up my boxen for that
little amount of work.
Jenkins was a good alternative here because it seemed to (I have no
empirical data) use less resources doing the same amount of work, and
I didn't have to feel guilty about there being tons of functionality
I wasn't using.
===========================
2: Refactoring it out the way I wanted was actually kinda hard.
I wanted to have a remote build slave for ubnutu, os x, centos, and windows.
And while I could do that in bamboo, the way the agents were managed was
actually kind of a pain. Installing & managing windows agents was a
headache, and installing & managing unix agents was not anywhere near
as easy as I'd like. I mean still we're talking a 5-20 minute process
to get an agent running on any given platform (less if you use puppet),
but I wanted it to be easier (and I didn't want to bring EC2 into the
picture).
jenkins remote agents are supereasy to deploy and manage. Spin up a host,
give jenkins the SSH key, and it literally handles everything else. The
windows agent was more involved, but even here it was easier than bamboo
(go to a JNLP URI on the windows slave, click a button, and it's done).
===========================
3: Upgrades were a real, *serious*, pain in the neck.
This is my only real serious gripe. Have you ever upgraded bamboo?
You have to login to the box, move a bunch of application and data
directories around, unpack an archive, then babysit the instance
while it comes back up and hopefully runs successfully through all
the SQL upgrade scripts. And you have to keep track of the versions
yourself; Bamboo doesn't tell you it's out of date.
C'mon, guys, seriously, it's 2014. We can't do better than this?
Jenkins is easier in this regard. It tells you (on the management page)
when your instance is out of date, and the upgrade procedure is
significantly more simple (drop a war in this particular location,
restart jenkins). And if you are using jenkins exclusively from your
linux distro's usptream package repo, you can just let 'apt' handle it
for you.
Package management is a particular gripe of mine (I build RPMs of my
open source, for example). I know this is not that hard, and yet
so many projects get it wrong by simply not devoting the time to it.
=================
4: Automating plan creation was damn near impossible
This is getting less into 'why I switched' and more into 'things that
always bothered me'. Ever try creating a Bamboo plan from the CLI?
Ever tried doing it with some custom steps that use a particular plugin?
Yeah. It's a nightmarishly bad process. What about moving a plan from a
"testing" bamboo (where you might design/perfect plans & processes) to
a "production" bamboo? How do you migrate a single plan? Export the backup
and then grok only that project from the backup? *barf*
Jenkins wins here. The jobs are stored in XML, and there is builtin
functionality in the jenkins CLI to export and import plans in your
instance. No fuss, no muss.
======================
5: I had used Jenkins at my last professional location
I spent a good amount of time evangelizing Bamboo at my last workplace,
especially the deployment plans, to replace our Jenkins that I felt was
inferior. But after spending a year with Jenkins, I found that there really
wasn't anything Bamboo offered that Jenkins simply couldn't do. So why
bother with all the above things, if I didn't even need Bamboo in the
first place?
@alok15ee
Copy link

Jenkins allows you to have branch based tasks via Jenkinsfile where you can't have separate tasks for plan branch and default branches. It is such a useful feature and Atlassian is still ignoring it.

@Raj2347
Copy link

Raj2347 commented Oct 3, 2018

Is there any document or a plan for the migration form Bamboo to Jenkins? Plz share if any.

@Raj2347
Copy link

Raj2347 commented Oct 3, 2018

Please any script/plugin help me to migrate plans from bamboo to jenkins

May I know if you got any help? need help.

@Raj2347
Copy link

Raj2347 commented Oct 3, 2018

I might be doing this soon myself. If I come up with any scripts/plugins, I'll check them in and share with you all.

Did you find any help or make any documentation?

@rranjith406
Copy link

@Raj2347 Did you find any help or make any documentation for the migration activity?

@themunendra
Copy link

Jenkins noob here. If any of you went through the migration, please share your learnings. Thanks!

@MounikaDeva
Copy link

MounikaDeva commented Oct 12, 2023

Did anyone find any help or make any documentation for the migration activity? Please share insights.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment