In the research Kohsuke, Tracy, and I did in the development of the Continuous Delivery Foundation, we learned a lot about how other free and open source foundations operate. I know more now than I had ever before about how the Eclipse Foundation, Apache Software Foundation, and numerous other LF-based foundations operate. One recurring theme which has come up has been the aversion to paying people to contribute code directly to the open source project. While not a universal pattern, looking to the FreeBSD Foundation which regularly issues grants for FreeBSD development, I am perplexed by this mindset in various foundations.

A number of people have asked me recently what I actually do for a living these days at Scribd. Due to the very public nature of my involvement with the Jenkins project and the Continuous Delivery Foundation, a few of my friends have seemingly forgotten that CI/CD is not actually my full time job! My career has largely been focused on two axis: building high-functioning engineering teams, and building backend API/service infrastructure.

Whether I’m sharing a locally developed service with a member of our globally distributed team, or I need to integrate some cloud-based service with local development, I frequently find the need to expose a local TCP service to the public internet. In the past I have tried to use tools such as localtunnel or smee.io, and in both cases I found them lacking; I simply want this TCP port open to the world! Yesterday afternoon I spent some time hacking on the first version of my own little solution: aci-tunnel.

Last week we announced the Continuous Delivery Foundation (CDF) at the 2019 Open Source Leadership Summit. Through a strange series of events I was fortunate to attend and participate in the “Continuous Delivery” keynote on the first day. Joining me on stage was Kohsuke (Jenkins), Kim and Christie (Tekton), Tracy (Jenkins X), and Andy (Spinnaker) to share a bit about the four initial projects joining the CDF.

The aviation community has been buzzing with speculation and commentary around the recently Boeing 737 MAX 8 plane crash in Ethiopia and the model’s subsequent grounding around the world. Watching this news report I was struck by the following quote from the “Deputy Assistant Secretary of State” regarding a similar crash in Indonesia:

Considering the percentage of my day which is spent typing on a keyboard, it should come as no surprise that I might have thoughts on what makes a “good” versus a “bad” keyboard. In fact, I think everybody who uses a tool with this level of frequency should have thoughts on what qualities make variations of the tool good or bad.

Today the Continuous Delivery Foundation officially launches, marking the completion of almost two years of work. Starting at the 2017 Jenkins World Contributor Summit where we, the Jenkins project discussed a “Jenkins Software Foundation”, to the 2018 Open Source Leadership Summit where the concept evolved into a continuous delivery focused organization, culminating in what we have today: a strong group of organizations and initial projects banding together for under the banner of the Continuous Delivery Foundation (CDF).

There are 90 days until the beginning of the week-long AIDS/LifeCycle, the 545 mile ride from San Francisco to Los Angeles to raise critically needed funds for HIV/AIDS-related services. For me, this means just under three more months to meet my fundraising goal. Not only that, this means my fellow riders and I have a shockingly small number of weekends to get our training in order!

The Jenkins project has long used Mirrorbrain, a great piece of software for running a high-traffic download site using redirect mirrors. We use it to transparently delegate traffic to a network of donated mirrosr, for downloading our Debian, Red Hat, and other packages of Jenkins and all of our plugins.

Linux has now been my primary desktop operating system for the better part of the last decade. Originally I had used openSUSE but found myself migrating to Debian for a number of reasons. I recently jumped back over to openSUSE, and have been impressed once again with the overall quality of the entire distribution.

I don’t think anybody can understate the value free and open source software has brought to the world at large, value which has largely been freely given with little expectation in return. The ubiquity of free and open source software seems to have fostered a sense of entitlement in the minds of some users. This presumption that free and open source software should do exactly what they expect it to do, and if not, that’s a problem that you the maintainer should address. I find this viewpoint to be not only incorrect, but abusive.

My exact words were “I could have likely filled half a book with thoughts and practices on good security for Jenkins” and were I to write that book, my colleague Daniel would certainly be a guest author of a few chapters, such as one on the limitations of credentials masking. In that linked post Daniel highlights some of the ways in which credentials can be misused in Jenkins. As I mentioned on Twitter, this is not a unique problem to Jenkins, any system which allows user-defined build processes and allows the use of credentials in those build processes will allow exposure of those credentials.

As the number of different ways to configure Jenkins approaches infinity, I have come to appreciate one pattern in particular as generally good. When I first started the draft of this blog post, three years ago (!), I wanted to share that by coupling Jenkins and Docker together I finally had the CI/CD server I had been waiting for. In the past few years, Docker has increasingly become the default environment for Jenkins, and rightfully so. In my previous post I mentioned some of the security pitfalls of using Docker in an untrusted CI/CD context, like that which we have in the Jenkins project. Regardless of trusted or untrusted workloads, I still think Docker is a key piece of our CI/CD story, and here I would like to outline why we need Docker in the first place.

Over the past few years, the topic of architecture and security for CI/CD environments has become among my favorite things to discuss with Jenkins users and administrators. While security is an important consideration to include in the design of any application architecture, with an automation server like Jenkins, security is crucial in a much more fundamental way than a traditional CRUD app. Walking that fine line between enabling arbitrary use-cases from developers and preserving the integrity of the system is a particularly acute problem for CI/CD servers like Jenkins.

This past Saturday, with support from a number of my friends, I passed the first fundraising goal for AIDS/LifeCycle 2019! Cue riotous applause! Prior to my training ride I mentioned on Twitter that I was only six dollars away from my first goal, and by the time the ride was over, a couple hundred dollars had been donated! Hoorah! Each AIDS/LifeCycle (ALC) rider must raise at least $3,000 and thanks to the tremendous support from friends, family, and a quite a few folks on the internet, I am definitely riding from San Francisco to Los Angeles in June.

One of the most significant personal revelations I have had in the past five years has been around the relevance and importance of high-quality engineering management and leadership. From my observations, poor engineering leadership has a negative and cascading effect throughout the product development process, and can substantially improve or degrade the overall performance of the company. As I have previously written, I now appreciate how engineering leadership is a specific skill set which requires practice, growth, and it’s own specialization.

The most recent Jenkins security advisory contains a fix for an issue in the GitHub Authentication plugin. One which I reported many moons ago, during an experiment I named “Code Valet.” Seeing the issue finally resolved brought fond memories back into my mind and I realized that I have never really reflected and shared what it was and more importantly: why it failed. At it’s core, Code Valet was intended to solve two fundamental problems: firstly, I wanted a Jenkins Pipeline as a Service, since I find Jenkins Pipeline to be a very useful tool, which I wanted for all my open source projects. Secondly, the Jenkins project needed to shift its footing towards a continuous feedback and continuous delivery model. Code Valet aimed to solve both of these problems.

Not knowing what I was getting myself into, about eleven years ago I started contributing to what became known as the Jenkins project. What followed has been nothing short of incredible; hundreds of new contributors, tens of thousands of new users, and millions of executed pipelines. Growth is challenging. Growth means new problems which demand new solutions. Two and a half years ago I stood in front of a large group of contributors at the 2017 Jenkins World Contributor Summit and made a pitch for what I called a “Jenkins Software Foundation”, never shy to pilfer ideas from the Python community. With help from my pal Chris Aniszczyk and the Linux Foundation, the concept morphed into something far more comprehensive the Continuous Delivery Foundation (CDF), for which my colleague Tracy Miranda has been leading the charge, helping drive the founding of the CDF.

The first bits I transmitted on the internet were sent through a modem on the end of a old-fashioned copper telephone wire. While I didn’t recognize the complexity at the time, its ingenuity still impresses me. An analog-only medium, the copper wire, could be made to transmit ideas via specially encoded chirps, squeaks, and chimes, to nearly any other destination connected to the web. At their most basic, words are a truly astounding mechanism for encoding and transmitting ideas from one brain to another. Without language, the rest of this wouldn’t be possible. Ideas alone are worthless, ideas in transit are incredibly powerful.

Wrapping up work some afternoon last November, I waltzed into the living room and found myself in the middle of one of those conversations where you weren’t actually necessary for the first half. “It will be great for you to train for ALC too!” She continued to talk excitedly about how we wouldn’t pay for the spin studio anymore, how convenient it will be, and how it would really be a good Christmas present. She showed me the price and I hummed to myself, giving the appearance of stern but deliberate thought “yeah, we’ll see.” Having already started to price out more cycling equipment, I didn’t want to give up the gag just yet.