A long long time ago we used Jenkins. Then we switched to Bamboo because the Jenkins interface was feeling a bit 1990s.
So now it’s like 5 years later and we’re in the process of moving back to it. Here’s why.
Bamboo isn’t free. Want to host it on a server and build on that same server? $10. Want to use a single remote build server? $800. Want to use up to 5? $2,200. Want to upgrade next year? $1,100.
Money isn’t so much the deciding factor for us. If Bamboo was outright the best product, we’d pay happily. More of an issue is the fact that pretty much every atlassian product has overcomplicated year 2002 enterprise style pricing.
Jenkins is free. Open source.
It’s 2017. Updating software shouldn’t involve all this bullshit.
To update Jenkins you press a button and it updates and restarts. There’s updates every few days.
Our wiki uses Confluence (also by atlassian). It got 1000 comments on a page made by spam bots. There’s no bulk delete comments option. If you search you find multiple instances of customers with this problem. So what’s the solution? Obviously not to add that basic functionality. Let someone else add it and sell it for $10 a year. Or buy a script to run scripts for $100 a month.
Again, I’m not totally against paying for addons, but not for basic functionality. Not to clean up messes that the inadequate captcha software let happen.
Jenkins addons are free, one click install, update automatically and very very regularly.
The one huge thing Bamboo had over Jenkins is that it didn’t look like shit. Jenkins has changed in a few ways since I last used it – which closes that gap slightly.
Ocean Blue is a plugin they made that seems to specifically solve this problem. It replaces the functional engineer view with something more simple.
It’s all modern and appy. Which makes people more appy.
It’s made in a way so that non coders can put together build steps. But that’s for idiots, so don’t worry about that.
Fuck The Interface
Wouldn’t it be cool if instead of bullshitting around creating jobs, then creating build steps in the interface, you could just drop a file in your project’s repository that told it what to do.
Wouldn’t it be even cooler if Jenkins could scan though all the repositories on your SCM for repositories with these special files, and automatically create a job for them all. Maybe it could do branches too. Maybe it could build pull requests too.
Well you just described the Jenkinsfile.
If you use Github you’re gonna love it. Add a Jenkinsfile, it adds a project. It automatically registers hooks with Github so it gets notified on pushes.
For each commit it’ll do a build and report the status back to Github. Which’ll then do little ticks or crosses next to the commits.
It’ll also test pull requests and report the status back – so you know if they’re actually going to compile and pass tests before you bother with them.
Like pretty much everything like this, the PlasticSCM plugin for Jenkins is as basic as you can get. It works to do the basic stuff, move outside of that and you’re probably gonna hit bugs. It’s something they may improve over time, but at the moment it’s got a few issues.
- No organisation scanning like Github – all manual set up
- SCM polling is temperamental, manually set up web triggers
- Interface errors (set pipeline to use script from plasticscm then save, you get this)
- No lightweight checkout, jenkins host has to pull the entire repo down to read single file
Like most people, if GitHub handled 20GB repositories better we’d have probably already moved everything to it already. PlasticSCM’s strategy seems to be to create a wrapper so Plastic acts like Git – allowing everyone to use the good plugins. That’s a neat idea, but I’ve always felt that 90% of Git’s adoption is down to how great GitHub is, so unless they can wrap Plastic in Github I don’t see much advancement here.
So with PlasticSCM you can limp along, manually adding jobs and it works. And I assume that’s the case with every other SCM.