A little earlier than usual due to my holiday, this week’s update brings you my initial impressions of Jenkins' first major update and a couple of other small things I wish to note.

Jenkins 2.0

Technically it happened 2 weeks ago, but Jenkins 2.0 was released. Jenkins is a continuous integration system, and this major release brings along some big changes that might cause changes in how you work with it. Or bring it back in your eye as a possible solution.

The blog post mentions 3 major cornerstones for this release. The least important (but still very nice) change is improvements in the initial experience. Jenkins has long been something that needs a lot of configuration and adding of plugins before you can actually use it for your projects. I’m pretty sure that I’m not alone in having created scripts or Chef/Puppet/Ansible recipes to prepare an instance for use. With version 2, the idea is that this will be less necessary as it will have more things installed out of the box. I can’t say yet how this works out, as I haven’t actually used it yet¹.

The second change is some much-needed UI improvements, but the biggest improvement is a change to the way Jenkins works. It is now possible to define full pipelines, which can include a deployment aspect for a continuous deployment setup. In the past deployments from Jenkins weren’t really supported. There were ways to do it, but personally I preferred to instead just pass the build result to a system like Samson. With the new pipelines, this should no longer be necessary². Other CI/CD systems (like Wercker, which is also great but a SASS and therefore not always suitable) have supported pipelines for a while and it’s great to see Jenkins have their own implementation.

I’m not going into details of how the pipelines work in Jenkins, I recommend instead to have a look at the documentation linked above. A couple of important changes I do want to mention. For one, the new pipelines (which you first have to configure) also allow Jenkins to scan your GitHub or Bitbucket teams for repositories it should include. This takes away a lot of the hassle for setting up the projects and can therefore save a lot of time and frustration. In theory (again, I haven’t actually tried it yet) this should also mean it’s no longer be necessary to have separate projects for different branches of a single repository.

The last change that I noticed in the documentation however is support for build on Pull Requests. I admit, I gave up looking for this a while back so it’s possible they’ve had it for longer now but this is something I’ve wanted for a long time.

So, if you use Jenkins or are looking for a new CI/CD system. Give version 2 a try and see how it works for you.

Small stuff

A couple of small things to note.

First there was a bit of attention on someone claiming to be the founder of Bitcoin. Craig Wright posted proof on his blog (which has now been replaced by an apology), but it didn’t seem convincing. Privately he apparently did give some convincing proof to others, but that wasn’t shared publicly. And by the end of the week the whole thing was mostly forgotten again by the press. Personally I don’t really care who made Bitcoin, but it looks like the hunt is going to continue after all.

I’ve mentioned that Whatsapp improved their encryption methods not long ago, and it seems like the Brazilian government, or at least one judge, wasn’t too happy with that. This judge demanded that ISPs switch off access to the app for 3 days. This impacted about 100 million users, and in that time a lot of Brazilians subscribed to alternatives like Telegram. The order was overturned relatively quickly, but no doubt this won’t be the last time some government wants access to encrypted data. Whether they try to get it from an app or the hardware vendor.

And lastly, Apple has demanded that all apps in the App Store need to support IPv6. As IPv4 addresses are running out (or actually have run out already in places), switching to IPv6 is becoming more and more important. Obviously this is a small move in that regard, especially as this support is already built into the standard iOS frameworks, but considering the importance of mobile devices it is important to ensure the switch can be made as frictionless as possible.