#random (2022-08)

Non-work banter and water cooler conversation

A place for non-work-related flimflam, faffing, hodge-podge or jibber-jabber you’d prefer to keep out of more focused work-related channels.

Archive: https://archive.sweetops.com/random/


DaniC (he/him) avatar
DaniC (he/him)

i just bumped into https://github.com/mgoltzsche/khelm and thought i should share it, especially when you look / read the motivation behind it


A Helm chart templating CLI, kustomize plugin and containerized kustomize/kpt KRM function


Azar avatar

https://www.youtube.com/watch?v=o5eWy-2SDtc good on Ko looks promising for GoLang based apps on K8s



sheldonh avatar

Anyone here use ADR’s (Often as markdown architectural decision records) and do this instead in GitHub Issues or discussions? I kinda like the idea of github issues as all history is preserved and logged and no overhead.

roth.andy avatar

my team uses both. Big decisions on architecture or anything that was worth spending significant time on to analyze a set of alternatives gets an ADR.

Think about the onboarding process for a new person. If it’s just “go dig through the issues” that’s gonna be hard for them. If it’s “look through this curated list of decisions” that’s better

RB (Ronak) (Cloud Posse) avatar
RB (Ronak) (Cloud Posse)

Yes, i love it. I use it in a monolithic infra directory. Id like to use it for all service repos. Its nice to summarize and codify all these decisions instead of having to dig through confluence, gh prs, git blames, issues to get the context.

Andrew Nazarov avatar
Andrew Nazarov

We tried to follow this approach years ago, but it didn’t work for us that well. And I witnessed how it didn’t work for other companies and teams somehow. Probably in our case the reason was that initially we tried to create the majority of ADRs retrospectively and this was no fun and people were not that dedicated to it.

Then we paused this for some time and after realising that it became again hard to follow architecture decisions and facing a growing number of “why?” questions we gave it another chance - picked a different template that fitted our needs and started to write things only for the current PoCs and stuff we are working on right now.

Of course, we also use Jira tickets, meeting protocols and Confluence articles to get to know what’s going on. However, I’ve been a big fan of ADRs as an idea and I’m glad that we’ve started it again. Jira tickets are hard to track for newcomers. Confluence articles get outdated quite fast for projects in an active development phase. Meeting protocols usually are written during the conversation with a time pressure, therefore it leaves much to be desired. So, to me personally ADRs are the essential part of a process.

Jonathan Le avatar
Jonathan Le

Yes on ADR. I think they’re good as long as they’re not so thick as they get in the way of things. By thick, I mean not so monumental that they can’t be amended with a superseding ADR when needed.