Jenkins has a few issues but is quite straightforward

it’s a reliable tool with a huge userbase

haven’t tried JenkinsX though - makes sense if you’re invested into a kubernetes stack

I guess it’s not a daily job, but it needs a place to run, it must be installed, then patched, plugins need to be installed. Circle/Travis is just waiting to be installed.

yeah, I guess it’s a few days job starting from scratch to set the whole thing up with all the needed pipelines, plugins and backups given a fairly homogenous build environment (e.g. only Java shop).

haven’t tried circleCI though so can’t offer any comparison

my record for getting travis set up for something moderately non trivial is like an hour

for greenfield it’s like 5 minutes

I’ve spent weeks of my life maintaining single simple jenkins jobs

so like, sample size of 1 (me), but I’ve seen the time savings in switching

I’ve even managed to run an end-to-end kafka integration test in travis so you can definitely abuse it too ^_^

If there is a separate QA department then Jenkins maintenance will not be visible in a grand scheme of things, unless that department is meticulous in their task management. It only resurfaces if developers are tasked with Jenkins maintenance: time sunk in QA results in a lower number of defects found (= invisible), time sunk in dev results in delays or fewer features (= highly visible).

@alex.lynham - an example of something moderately non trivial I had to do recently - how easy would it be to set up a windows build on Travis?

I think you can get it to matrix build multiple OSs with a flag

I know you can do that for ios etc

lemme check

> If there is a separate QA department > department

well I’m a dev so obviously I only care about situations where: > developers are tasked with Jenkins maintenance

but that said, I think testing and QA is part of dev, and reducing the pain of doing it makes for higher quality software

ideal world: devs manage CI, do testing; slightly less ideal: devs and QAs pair; frankly not good: QAs are a separate team

just my 2 cents tho 🙂

@dm3 looks like this is the one to use for windows. Travis had experimental windows support for a while by the look of it but then gave up on it https://www.appveyor.com/

I see, it’s probably easier to get started when you have no experience with Jenkins

and when you can allow source code escape behind your firewalls

yeah, I guess the jenkinsfile paradigm is a step in the right direction in that it allows inline CI description

but all things equal, from all the things I’ve had to do I prefer the travis-like things

sounds like you might be able to run a windows docker container in travis btw, but that’s from a cursory google 🙂

yeah, once stuff gets complicated you have to script the builds

& remember if you don’t want travis to run in a container you can use the magic sudo: required to run in legacy mode

Boot is great for heavy-lifting

it runs in a GCP instance iirc rather than a container https://docs.travis-ci.com/user/reference/trusty/

I’ve found that can work better for e.g. JVM projects where memory in integration tests etc could be an issue if you’re running a DB

Our team has two QA guys on board and we do dailys together, actually we work as close as we work with the other developers from our team. So I have a pretty good insight into what they are doing and its not Jenkins maintenance. We use it for almost 10 years now and do all sorts of stuff. Amongst them setting up the whole dev environment for every testing stage on every system we support (which contains AIX / Solaris and the normal stuff like several Linuxes + Windows Server) + the dev env of every single developer + a lot more in our whole organization that I have no insight of.