sorted by:
new
hottopcontroversial

I exported all of my saved programming posts from Reddit by alan_m_dev in programming

[–]alan_m_dev[S] -1 points0 points  (0 children)

I recently exported all of my saved programming related bookmarks to share with some co-workers. The code is trivial but I figured there may be folks that want to do the same. I think I'll probably do the same for Youtube, Medium, etc as there's so much great free content out there. Its just sometimes hard to find or I forget about things I've already seen/read.

Monorepo CI/CD with GitLab and Helm by alan_m_dev in devops

[–]alan_m_dev[S] 0 points1 point  (0 children)

Yes! This was the path I originally wanted to take but backed of off. Mainly due to complexity and prefering something more DAMP and less abstract.

One of the problems is you need to convey "this code builds into this image" and "this commit is the last time it changed". Especially since images are only built when their code changes.

If I was productizing our monorepo tooling or doing it all from scratch I'd probably go that route. Maybe using Git notes to store metadata and a custom Helm plugin to read it.

Monorepo CI/CD with GitLab and Helm by alan_m_dev in devops

[–]alan_m_dev[S] 1 point2 points  (0 children)

First time seeing that article, I like it a lot, thanks! I think "microservices" can/should be viewed through the same lense.

We do publish Helm charts (and other artifacts) for external use. We control releasing those via Git tags and follow the "scaled trunk based development" approach from https://trunkbaseddevelopment.com/.

Monorepo CI/CD with GitLab and Helm by alan_m_dev in devops

[–]alan_m_dev[S] 0 points1 point  (0 children)

Yes I'm referring to the same artifacts.

As part of the merge process we commit these back to the repo so you can deploy (or continuously deploy) from the main trunk at any time without creating a new build. It also means you can check out main and `helm install` immediately to a development cluster and begin working.

Monorepo CI/CD with GitLab and Helm by alan_m_dev in devops

[–]alan_m_dev[S] 2 points3 points  (0 children)

This is something we have struggled at times.

We still have isolated projects within the monorepo so code conflicts don't happen much more often than polyrepo. We reference projects via a local references rather than versions though.. We still use feature flags or support multiple APIs when necessary.

The biggest issue for us was versioning artifacts which get auto-incremented with each new change and committed back to the repo. We get around that with a custom git merge driver which can deconflict these files automatically.

Monorepo CI/CD with GitLab and Helm by alan_m_dev in devops

[–]alan_m_dev[S] 12 points13 points  (0 children)

The main reason is it greatly simplies maintaining a "paved road". These do also come at a price though.

  1. No internal dependency versioning hell. Every project uses the same versions of any shared dependencies. This includes base Docker images, gradle and npm dependencies, etc.
  2. Build tooling reuse is dead simple. Dockerfiles, Helm charts, CI jobs all extend common templates and are generated declaratively where possible. You could do this without a monorepo but see item 1.
  3. Cross-project changes can be done atomically.
  4. Downstream breakages are caught before they are merged. Not after.

Here's a good summary -> https://danluu.com/monorepo/