Trunk Based Development

https://trunkbaseddevelopment.com/

#HackerNews #TrunkBasedDevelopment #AgileDevelopment #SoftwareEngineering #DevOps #ContinuousIntegration

🚀 Trunk based development simplifica la integración de código en equipos ágiles. Menos ramas, menos conflictos y despliegues más rápidos. ¡Conoce esta estrategia! 💻

Lee más 👉 https://www.soloingenieria.org/ingenieria-de-software/trunk-based-development/

#TrunkBasedDevelopment #IngenieríaDeSoftware #DevOps #Integración Continua

El código que no se integra rápido, se convierte en deuda técnica. Trunk based development te obliga a mantener tu trabajo siempre listo para producción. 💡 Pequeños cambios frecuentes superan a grandes cambios esporádicos.

#TrunkBasedDevelopment #IngenieríaDeSoftware #DevOps #Integración Continua

Wrote a blog post about #xp #trunkbaseddevelopment #git #branches
https://dev.to/mrksdck/from-branches-to-trunk-a-journey-2kc8

Let me know and comment :)

0 days since hearing someone say "pair programming is not enough, a pull request has to be made anyway so someone fresh can review the code!"

PR is waste. PR is too late. PR is too little. Reviews after the fact are fine, but should not be blocking, unless someone worked solo. "Fresh eyes" is a fallacy and mostly offers nothing else than manual nitpicks.

#Software #SoftwareDevelopment #PullRequest #CodeReview #PairProgramming #Mobbing #MobProgramming #Teamwork #TrunkBasedDevelopment

Published an update to: So, Yes, Trunk-based Development! Now What?

Added the missing reference to the Walking Skeleton when implementing large changes.

Thanks to Steve Hallman for bringing that to my attention 🫶

#trunkbaseddevelopment #faq

https://thinkinglabs.io/articles/2025/08/10/so-yes-trunk-based-development-now-what.html

How can you maximise feedback, streamline pipelines and minimise disruption caused by bugs etc?

I really enjoyed chatting to Bryan Jones about trunk-based development and many other things on his Quality Blether podcast! Listen to this episode and relive the vibe.

https://shows.acast.com/quality-blether/episodes/688160332a38d6f5cb162996

#CSudberyRecordings #ContinuousIntegration #TrunkBasedDevelopment

At work I have a monorepo with a bunch of helm charts in it.
The LCM for this repo is garbage - I wrote it a few years ago not really knowing what I was doing, but also knowing it was a temporary thing.
Turns out it’s not so temporary.

The company is looking to move to trunk-based development and I’m looking to redo the LCM of this repo.

Specifically this TBD: https://trunkbaseddevelopment.com/
We want to be able to say “we are doing this” and point at an industry way of doing things, rather than looking at something home grown or modified.

TBD makes sense to me, I’m pretty sure I understand it.

But- the charts on the repo are released altogether monthly (looking to change this, but anticipating another year or more before being able to do so), there are two breaking changes a year.

If I need to patch an old (supported) version, I might not be able to commit it to trunk and cherry-pick back to a relevant release branch because feature flags are hard to impossible in Helm (specifically in the way we use a library chart to provide 99% of the templating).

Am I “allowed” to commit/PR directly to the release branch in this case?
I know I technically can, but I can’t find what is idiomatic TBD in this situation.

#branchingstrategies #trunkbased #trunkbaseddevelopment #git #lifecyclemanagement

I've added a new project page to my blog for git-next, complete with an animation, to help explain the workflow that git-next enables.

https://kemitix.net/projects/git-next/

#git #TrunkBasedDevelopment #ci #ContinuousIntegration