process

In response to a twitter thread about questions to identify whether a applicant would want to accept a job, one of the most brilliant responses was by Lars Albertsson (@lalleal) asking “How much does it cost your company to buy a thing for 1000 EUR? Spend a day chasing approvals, and you are at > 100% overhead.”

Legacy organizations with legacy products have designed complex and rigid processes for releasing software into a production environment. The production environment is special and has limited access and compliance and constraints and needs to always work so developers shouldn’t even try to look at it.

Except things change and stuff breaks. So now what? Continuous deployment to the rescue!?

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.

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.

A brief lengthy rant follows on what adoption of the “Scaled Agile Framework” (SAFe) indicates in 2020. For a more comprehensive blow-by-blow of how SAFe is deficient, head over to google. This focuses on the indicators related to the selection of SAFe and not the framework itself.

After attending the ATARC IRS Container Forum late last year, I was inspired to share some of my perspective. Between the folks who spoke at that forum and my own interactions with federal agencies, it was clear that waterfall was leaking into DevOps.

Agile software development has revolutionized the way private sector organizations build software. The primary tenets are that all companies are software companies, software is never done, and requirements always change. What does that mean for the federal space?

GitLab’s developers use a pull workflow so the assigned field is editable by anyone. The intended worfklow is to leave the issue unassigned (though tagged for a team) and when a developer is ready, they assign it to themself and work on it. Assignment is seen as a “leave this alone if it’s not you” sort of signal rather than “someone wants me to get this done.”