development

When running other people’s software, there are a variety of ways that one can impact the deployment. Developers typically provide a set of configurations that can be set during deployment. Additional configurations are available once it’s running. These are design choices to decide which levers to provide and how flexible to make them. I wanted my instance to do some stuff that the latest release doesn’t do.

There is a lot of talk circulating about the exit of the Air Force and DOD’s first “Chief Software Officer”. Having first-hand experience with the plans, processes, and outcomes allows me to write from a detached observer perspective. What can be learned by those embarking on improving a massive, Brownfield organization?

Most people these days have written some javascript. This may not be true of humanity (though I wouldn’t bet either way), but it is definitely true of the Brownfield.dev audience.

Taking a couple of hours to revisit the basics is actually fun.

Coder recently made their enterprise offering free for up to 10 developers. Since my solution, which I will henceforth call “ICSW”, supports 1 developer, it is well within that limit. I configured a new namespace in the same cluster to run the Coder Enterprise system to see how they compare.

TL;DR: Coder Enterprise has a lot of benefits for centrally managed code-server deployments as well as a multi-image workflow.

Upgrading code-server from 3.4.1 to 3.5.0 was always supposed to be easy. Turns out it was easy.

Just for the sake of sharing the ease, I’ve written up the embarrassingly simple process.

The new capability is running additional pods and services (and ingress and statefulsets) within the development namespace using the developer service account. This limited access role can’t impact other services but can start a container and use internal DNS and services to access them.

Pushing the limits of mobility and performance has become easier now that the iPad Pro has the Magic Keyboard and Visual Studio Code can be web-based as code-server.

TL;DR: It’s pretty nice but has some shortcomings. This article covers both the workflow and configuration.

As DevOps evolves, new technologies enable better processes. If your team has a process defined by tradition, take a fresh look. Use some of these examples and keep an eye out for other accelerators as time passes.

Branches for input, merges for admission, tags for output.

GitLab released a dozen page book about Git Branching Strategies to serve as a high-level overview of branching strategies and how they work.

No Factor Apps is what we can call classic applications that people have been building since the dawn of time. This is a reference to the “factors” used by the folks at 12factor.net which is a fantastic resource for what approaches to use and how they contribute to improved delivery quality and speed.