Practically every professional developer can name a great, and a terrible, manager they have worked with in the past. Good Engineering Managers are kind of like the bass line in a song, you might not notice them when they're there, but something will definitely sound wrong if they're absent. For one reason or another, I have somehow ended up leading a team or acting as an Engineering Manager at each of the four companies I have worked for over the past decade. As time has progressed, I have become increasingly aware of "management" as a skill, rather than some intristic talent. A skill which can be practiced, honed, and improved upon.
To say that I'm an expert gardener would be an extraordinary stretching of the truth; capable, yes, expert, not even close. While I tend to focus on what crops fail outright, or produce lower-than-desired yields, my neighbors and some of the folks I know online seem to be impressed with my results.
Yesterday I participated in a very fun and productive Docker Hack Day, wherein a few folks (myself included) spent the day hacking on porting Docker to FreeBSD. After which, I had a nice relaxing beer (or two) on my boat/train rides home and enjoyed one of my favorite past-times: shit-posting on Twitter.
Jenkins World 2017 is nearly upon us, and I must admit that I am not actually presenting a talk at the event. I haven't been speaking as much this year, compared to 2016, since I have been very busy building the Evangelism team at CloudBees. Three new hires and one transfer later and it's already time for Jenkins World! Eep!
Azure has started to grow on me. I could imagine myself, a couple years ago, lamenting their poor non-Windows support, clumsy user interfaces (and APIs), and overall "beta dog" performance. Fortunately for cloud users like myself, Microsoft is hungry, and has heavily invested in Azure, becoming very competitive in a very short amount of time. One aspect of Azure I didn't expect to like however, was their web UI. If you're already familiar with the AWS web dashboard, you're probably accustomed to...low expectations, so just about any web interface designed later than 2008 would be an improvement in comparision. Fortunately for me (and you if you use Azure), the Azure "blade UI" was designed more recently, and was clearly created by a team of thoughtful UI designers rather than engineers.
I consider myself one of the world's foremost experts in terrible ways to use Jenkins, partially because my brain is awash with awful ideas, but also because I have been around the project long enough to see hundreds of different "clever" (ab)uses of Jenkins. Today I thought I would share something I came up with a few weeks ago which, to date, might be one of my more deplorable creations.
Jenkins Pipeline has rapidly become one of my favorite tools in the entire Jenkins ecosystem. Part of my job at CloudBees has been advocating for its use, but I can confidently state that I would be a passionate user of Jenkins Pipeline regardless of who was paying me; it is simply better than what preceded it. As Pipeline has evolved and matured, I have pushed for its unilateral adoption within the Jenkins project's own Jenkins environment. Wielding Pipeline as a developer is one thing, managing infrastructure which utilizes it is quite another.
One of the things I have worked on this week has been documenting the "In-process Script Approval" and some of sandboxing features in Jenkins Pipeline. While waiting for some pull requests to be reviewed I had the thought "how bad could disabling the sandbox be?"
Recently Microsoft announced an interesting new addition to their public cloud offering: Azure Container Instances. Azure Container Instances are fast and billed by the second, which is quite compelling on its own. They are interesting in that they provide two novel levels of container orchestration, the first is rather basic:"take this container and run it." The second is an integration with Kubernetes which allows the Kubernetes cluster, most likely one an Azure Container Service, to schedule container workloads through Azure Container Instances rather than on the existing Kubernetes agents )VMs) via the "ACI connector." As this service matures, this could enable some very novel load-based bursting, or cost-saving, deployment patterns on top of Kubernetes in Azure.
Automation is a wonderful thing, and for the past eight or so years, I have been a heavy user of Jenkins as my hammer of choice for just about every nail I needed to automate. There's one dirty little secret about Jenkins however: it's a godawful nightmare to try to automate.