I’ve heard it thrown around in professional circles and how everybody’s doing it wrong, so… who actually does use it?

For smaller teams

“scaled” trunk based development

  • wewbull@feddit.uk
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    7 months ago

    Second diagram, yes absolutely.

    Short lived (1-2 day) branches, and a strong CI systems to catch regressions.

    Be warned, the strength in the CI lies in its capacity to detect when some functionality that previously worked doesn’t work anymore. So, the flow must be green always, and it must evolve as the features evolve. Without good CI you’re destined for failure.

  • Ismay@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    I do, on a 900+ developer mono repo. Works like a charm.

    We just have a CD that allows to deliver each project each micro service individually.

      • Ismay@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        Yeah, the biggest problem is keeping up to date.

        That’s where the mono repo really shines. We have a folder for common stuff that everyone depends upon. A modification is automatically applied/compatible with every micro service. Really streamline the lib updates problem ^^

  • jjjalljs@ttrpg.network
    link
    fedilink
    arrow-up
    1
    ·
    7 months ago

    Here there’s main. You branch off. Do your work. Make a PR to main. Build passes and someone approves, merge to main. Production release is done by tagging main.

    The branches are short lived because the units of work we select are small. You have like one pr for an endpoint. You don’t wait until the entire feature with 20 endpoints is ready to merge.

    Seems to work fine. I think this is different than trunk based development but honestly I’m not sure I understand trunk.

  • BatmanAoD@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I haven’t worked on any teams where all members committed “every 24 hours”, and there have always been some branches that live longer than we’d like (usually just unfinished work that got deprioritized but still kept as an eventual “todo”), but most teams I’ve worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.

    • ____@infosec.pub
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      A hard timeline on commit strikes me as less than ideal.

      People are people. They have issues, they screw up, but they still write good code.

      Seems like a brutal metric that encourages minimal commits without real change.