Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-08-13 13:48:59 +02:00
Code Issues Projects Releases Wiki Activity

docs: Update what-is-a-feature-flag.mdx

Browse Source 
Fixed link to the State of DevOps Report
This commit is contained in:
Yash Malik 2025-07-24 17:34:33 +05:30 committed by GitHub
parent 8943cc0a3d
commit 8c78783585
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/docs/topics/what-is-a-feature-flag.mdx
View File

@ -14,7 +14,7 @@ In this guide, we’ll introduce you to the basics of feature flags and why so m
*The easiest way to explain why developers use feature flags is to understand the story of why [Ivar Østhus](https://github.com/ivarconr),
our CTO, created the Unleash feature flag service in the first place. Here's Ivar in his own words:*
> In 2014, I was working as a software developer at FINN.no, Norway’s largest online marketplace. Getting new features into production was a pain, so, as a developer, I looked around and wondered if I could write some code to make it easier. My initial goal was to protect features under development, allowing our team to transition to [trunk-based development](https://www.getunleash.io/blog/how-to-implement-trunk-based-development-a-practical-guide)—a practice recommended according to the [State of DevOps Report](https://www.getunleash.io/blog/guide-to-feature-flags#:~:text=State%20of%20DevOps%20Report).
> In 2014, I was working as a software developer at FINN.no, Norway’s largest online marketplace. Getting new features into production was a pain, so, as a developer, I looked around and wondered if I could write some code to make it easier. My initial goal was to protect features under development, allowing our team to transition to [trunk-based development](https://www.getunleash.io/blog/how-to-implement-trunk-based-development-a-practical-guide)—a practice recommended according to the [State of DevOps Report](https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report).
>
> Even back at that time, we embraced agility with an automated delivery pipeline which made fixing bugs a breeze, but frequent feature releases? Not so much. Building features takes time, and waiting weeks for production testing felt wasteful.
> We used feature branches, a common approach, to isolate unfinished features. However, this created a tangled web of problems: