#random (2022-08)

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

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.

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.

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.

Backstage uses this: https://backstage.io/docs/architecture-decisions/adrs-overview

Nice! I setup some mage tasks for wrapping up adrgen. I generate a summary page mage adr:report and get a markdown summary table. I use adrgen create "Foo" etc.

I’ve considered eliminate PR and just have issues/wiki though that gets rid of the review in the same way. Problem is I’ve noticed in 3 teams getting folks to write even basic stuff on proposals for app/team process etc is super hard. Wondering if reducing the friction would solve anything or if the root issue is just it won’t happen without the right mix of folks that see the benefit and adopt.

Have you considered sops

https://fluxcd.io/docs/guides/mozilla-sops/

Shameless plug that I’m now working on a team (last few weeks) that has a k8s syncing tool for configmaps. The cli is sorta like a mix of hashi vault, aws ssm/secrets etc. It’s pretty interesting! The syncer removes the need to do in your pipeline directly and can keep configmaps updated directly or on creation.

Check this out: https://github.com/DelineaXPM/dsv-k8s/ sorta like externalsecrets.io stuff.

It’s a really interesting product that has a solid free tier fully SAAS so you can be up and running in mins.

Most tech startup mascots are pretty bad, this one is at least cute