code.talks 2023 - Our journey from Gitflow to Trunk Based Development

No video

code.talks 2023 - Our journey from Gitflow to Trunk Based Development

Рет қаралды 4,062

code.talks (ehem. Developer Conference)

Күн бұрын

Пікірлер: 8

@Panossa 23 күн бұрын

What I don't understand is how to do anything related to existing code. How do you refactor a part of the existing software with this approach? You can't wrap what you're doing in feature flags if you e.g. rename a class used in the whole software. And renaming a class can break a LOT. And what is the expected response to a commit breaking the trunk? E.g. a commit goes past the code review into the trunk and suddenly feature X stops working. Do you roll back to the last commit on the trunk and push with force flag? That would not always work, especially with something like committed migration scripts that alter the database.

@snorman1911 18 күн бұрын

I'd love some context on what kind of software you're working on. This may work great for a web app, and not so much for something more complicated.

@yanilathouris7655 Ай бұрын

Why create an ephemeral environment from a branch other than trunk? Doesn’t that mean you’re testing/reviewing a version of the code that hasn’t been integrated with other developer’s work?

@sn0kite Ай бұрын

CI / CD is an approach, not a tool. Nothing embodies CI / CD more that adopting trunk based management with Feature Flags.

@illyam689 4 ай бұрын

automatic environment creation is interesting, is there any open source projects that does this already?

@Ludo-o7j Ай бұрын

Hi @illyam689, Unfortunately most of the open source projects will require adaptation work to fit with your building process (eg. vCluster or DevPod). Some providers such as Bunnyshell are offering ready-to-use solutions. It might be interesting to take a look.

@rorycawley 4 ай бұрын

We even bother with short lived branches when you are using feature flags?

@Ludo-o7j Ай бұрын

Hi @rorycawley, Different scenarios might explain the need to still have short-lived branches over feature flags. 1. If a dependency upgrade needs to be performed, features flags won't help. Relying on a short-lived branch to validate the changes in isolation might be easier to manage. 2. If the code needs to be reviewed, having a short-lived branch can help the reviewers by isolating clearly the changes and running automated checks directly on the branch via Pull Requests decorations. 3. While feature flags might be tempting they ultimately add complexity to the code base and therefore should be use with moderation. At the end there is no silver bullet. The approach we have taken works in our context (team, size, product, culture) but might be completely different in yours 😉