Brownfield

From experiencing organizations ranging from 10-person start-ups to dozens-of-thousands-of-people organizations, I have found a consistent experience among shared service providers. They say “no.” A lot.

As-of posting this, Mike is moving from GitLab to Coder. The purpose of this site and the gitlab.com group are not changing, though the day-to-day problems to solve are likely to be more about Developer Experience going forward.

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.

The GitLab Commit this summer is free for all with unlimited attendance due to the pandemic. This creates an opportunity for tons of people to have access to fantastic ideas that can help their organizations, teams, and individually.

In support of simplifying the Segregation of Duties pipeline definition, the Lab Assistant app will now create a dotenv formatted file and deliver it to the newly created branch. This perfectly meshes with what the Auto Deploy Image is expecting to allow Segregation of Auto DevOps Duties.

To help make it clear what the intermediate step is between the existing Deployment project example and real DevOps, I created a streamlined version.

The original recording was 40 minutes of chatting and pipelines and other nonsense. I sliced it up and we are left with about 9 minutes of the process and 4 minutes explaining a few pipeline jobs in greater detail.

When transitioning from classic methods to Agile and DevOps, the gatekeepers can feel stuck in limbo. The first step to easing the transition for security reviews, change management, and independent verification is to give them a place they control. As of GitLab 13-ish, the existing roles do not meet this need, despite the merge request approval with branch, tag, and environment protections.

This article lays out a 2 project workflow with an automated merge request handoff to support the access levels needed for segregation of duties with Auto DevOps.

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.