docs: Trunk-based development use case tutorial #8867
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
|
|
||
| Regardless of the specific strategy, Unleash feature flag management capabilities are designed to support a wide range of trunk-based development styles, empowering you to implement the best strategy for your teams. | ||
|
|
||
| ### Microservices vs. Monoliths |
There was a problem hiding this comment.
This is bit of a hairy topic. I think all the points you've listed here can be challenged because they depend on a lot of things, like how well the code itself is structured and how source control is done. Are you mentioning this for completeness?
Not against this, just not sure where we're going with the thought
There was a problem hiding this comment.
This was suggested to be mentioned so I asked a customer what their thoughts on this topic was in relation to feature flags. Microservices vs. monoliths is not directly linked to trunk-based with feature flags, but I think this is a snippet that could be expanded to its own post and maybe linked from this doc to the future one. Definitely a provocative conversation-starter topic.
|
|
||
| #### Leverage Tagging and Metadata | ||
|
|
||
| In addition to meaningful names, apply relevant tags and metadata to your feature flags in Unleash. This metadata can include information such as: |
There was a problem hiding this comment.
Metadata? Like in the description of the flag?
| - Per-customer release | ||
| - General release | ||
|
|
||
| To target users accordingly, let's create an [activation strategy](/reference/activation-strategies). This Unleash concept defines who will be exposed to a particular flag. Unleash comes pre-configured with multiple activation strategies that let you enable a feature only for a specified audience, depending on the parameters under which you would like to release a feature. |
There was a problem hiding this comment.
Small detail here but a flag that's on in Unleash always has an activation strategy. If you haven't changed that in anyway it's set to 100% rollout, so you'll need to delete or just edit that strategy
|
|
||
| Unleash provides a powerful mechanism for safely managing and controlling these features in production, enabling enterprises to deliver software faster and with greater reliability. Effective feature flag management ensures that trunk-based development supports continuous delivery without compromising stability. In this tutorial, we’ll leverage Unleash to manage trunk-based development in your codebase. | ||
|
|
||
| ## How to Implement Trunk-Based Development with Feature Flags |
There was a problem hiding this comment.
Could we do sentence case for these please? 🙏 🙈
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I think we could give a more realistic example here than the 'simple' tag, since we want to promote best practices.
|
|
||
| ### Merge Every Commit | ||
|
|
||
| The most frequent approach to trunk-based development is merging every commit directly into the main branch. This strategy maximizes the rate of continuous integration and delivery, as changes are integrated into the trunk as soon as they are ready. Some advantages are: |
There was a problem hiding this comment.
Is it really the "most frequent approach"? What's that based on? Seems like a strange claim to make, and it's not necessarily useful.
maybe something like "the most straightforward approach"? "The simplest approach"? Though, of course, if you have sources, cite away! 😄
There was a problem hiding this comment.
I wouldn't call this an absolute and can be based on team size: https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/
I like "the most straightforward approach" or simplest approach.
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
website/docs/feature-flag-tutorials/use-cases/trunk-based-development.md
Outdated
Show resolved
Hide resolved
| Develop a clear and consistent naming convention for your feature flags. This will help maintain clarity and make it easier to understand the purpose and context of each flag. Some recommended elements to include in your flag names: | ||
|
|
||
| - The feature or functionality the flag is associated with | ||
| - The environment or user segment the flag is intended for (e.g., "prod", "beta", "mobile\*users") |
There was a problem hiding this comment.
I'm not sure about this point. especially as it relates to Unleash. Features usually move through multiple envs. And where is a feature destined for if it isn't "prod"? Isn't that where all features go when they grow up? Same with "beta". Surely it's only beta until it's ready?
I'm not sure about "mobile users", but ... that might be okay?
By the way, what's with mobile\*users? What's the asterisk doing? Should it be an underscore or a hyphen?
Co-authored-by: Melinda Fekete <[email protected]>
About the changes
Trunk-based development preview
Gearing up to publish the Trunk-Based Development use case tutorial.
Closes #
Important files
Discussion points