akesterson · April 29, 2014 06:22 · themunendra · Feb 21, 2022 · MounikaDeva · Oct 12, 2023
diff --git a/gistfile1.txt b/gistfile1.txt


 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?


	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?