"기능 플래그"란 무엇입니까?

"기능 플래그"란 무엇입니까?

---

높은 확장 성은 여기에 기능 플래그를 언급합니다.

확장 성 독성 5 일 , "기능 플래그의 5 부족"

기능 플래그는 정확히 무엇입니까?

---

'기능 플래그'(또는 기능 토글 )는 애플리케이션의 기능 (하위 섹션)을 쉽게 켜고 끌 수있는 기능입니다.

• 재배포를 통해 또는
• 페이지 / 기능을 라이브로 전환 할 수있는 내부 페이지

예를 들어 부하가 너무 높으면 db 쿼리를 줄여야하는 경우 기능 집합을 다소 줄일 수있는 컨트롤을 사용하는 것이 편리하다고 생각합니다.

이 방법 을 사용하고 싶은 다른 이유가 많이 있습니다 . Continuous Delivery를 활성화하는 주요 이유 중 하나 : 작업을 프로덕션 / 라이브로 푸시하지만 완료 될 때까지 기능을 비활성화 / 토글하는 것입니다. 우리는 종종 '개발 쿠키'를 사용하여 개발팀에게만 미완성 기능을 보여줍니다. 이렇게하면 부분적으로 완료된 작업 (오 예! 더 나은 통합이 있습니까?)을 여러 릴리스 / 배포에 걸쳐 테스트 할 수 있습니다.이를 '토글 해제'(완료)하고 대중에게 공개됩니다.

다음은 ASP.NET MVC 영역에서이 작업을 수행하는 데 도움이되는 간단한 패키지입니다. https://github.com/cottsak/DevCookie (전체 공개 : 저자입니다)

Fowler는 또한 더 많은 세부 사항과 함께 위에 링크 된 것보다 훨씬 긴 기사를 가지고 있습니다.

이 게시물 (Fowler 사이트에서도)은 다양한 유형의 토글 전략을 설명합니다 . DevCookie 는 메인 라인 / 트렁크 기반 전략을 지원 하며 기사에서는 " Release Toggle " 이라고합니다 .

Adil의 답변 은이 인프라 중 일부를 원할 수있는 많은 용어와 이유가 있음을 강조합니다. 이러한 것 중 일부만 필요할 수 있습니다. 예를 들어 간단하고 민첩한 배포 / 배달 워크 플로 만 사용하고 싶을 수 있으므로 간단한 인프라로 충분합니다. 그런 다음 A / B, 코호트 테스트 및 제어 된 롤아웃과 같은 작업을 통해 완전한 #leanstartup 실험으로 이동하려는 경우 이러한 데이터 기반 개발 방법을 별개의 솔루션으로 용이하게 하는 분석 도구 (예 : Heap )를 고려해야합니다. . 위의 모든 작업을 수행하는 토글 인프라는 부풀고 불필요한 복잡성을 유발합니다.

여기까지왔다 면 메인 라인 개발, 기능 전환 및 TEST, QA, SIT, STAND, CROUCH와 같은 기타 어리석은 아이디어에 대한 다른 생각을 좋아할 것 입니다.

---

기능 플래그는 새 코드를 배포하지 않고 구성을 통해 애플리케이션의 일부 기능을 해제하는 기술입니다.

기능 플래그는 기능이 지속적으로 배포되지만 반드시 프로덕션에 "출시"되는 것은 아닌 CI 체계에서 핵심적인 역할을합니다.

여기에 더 많은 정보 :

• http://code.flickr.com/blog/2009/12/02/flipping-out/
• http://techblog.outbrain.com/tag/feature-flags/

-- 편집하다:

기능 플래그 자바 구현 .

---

기능 플래그, 기능 토글, 실험 및 제어 된 롤아웃은 단순하지만 강력한 아이디어의 동의어입니다. 기능 롤아웃에서 별도의 코드가 배포됩니다. 간단히 말해서, 고객 중 누가 해당 기능을 볼 수 있는지를 선택하면서 기능의 커밋을 프로덕션에 적용하는 기능입니다.

그들은 부분적으로 Facebook의 Gatekeeper에 의해 대중화되었습니다 . LinkedIn의 LiX는 또 다른 좋은 예입니다.

이 간단한 아이디어를 수용하면 다음과 같은 많은 모범 사례의 기반이 마련됩니다.

지속적인 배포 / 전달 -하루에 여러 코드를 프로덕션으로 푸시합니다.

트렁크 / 메인 라인 개발 -기능 분기는 오래 지속되는 기능 개발이 아닌 풀 요청에 대해서만 생성되어야합니다.

더 이상 릴리스 기차 는 일을 수렁에 빠뜨리지 않습니다 .

프로덕션의 QA / 성능 테스트 -실제 QA 및 성능 테스트는 프로덕션 트래픽이있는 프로덕션 인프라에 있습니다. 광범위한 성능 랩과 스테이징 환경을 구축하는 데 시간을 낭비하지 마십시오.

실험 -새로운 기능이 KPI에서 바늘을 움직이는 방법을 알아 봅니다.

문제 발생시 핫픽스 또는 코드 롤백 방지 -핫픽스와 코드 롤백은 모두 스트레스가 많고 시간이 오래 걸리며 필요 이상으로 많은 문제를 발생시킵니다. 대신 기능을 끄거나 낮추십시오.

다른 사람들은 오픈 소스 라이브러리를 언급했습니다. Gatekeeper 및 LiX와 같은 전체 솔루션의 좋은 예는 Split 입니다. 저는 Split에서 일합니다.

---

기능 플래그 ( 기능 전환 또는 기능 토글 이라고도 함 )는 필요에 따라 잠재적으로 비용이 많이 드는 기능을 활성화하거나 비활성화하는 스위치입니다 (예 : 사이트가 예기치 않은 트래픽으로 망가진 경우). 이렇게하면 규모를 확장하거나 부하 급증이 사라질 때까지 약간의 시간을 벌 수 있습니다.

다음 은 SWIG 문서의 예입니다 .

---

여기에는 Martin Fowler 게시물 에서 대중화 된 중요하고 기본적인 정의를 따르는 많은 훌륭한 답변이 있습니다 .

이는 "팀이 코드를 변경하지 않고 시스템 동작을 수정할 수 있도록 허용"하는 코드입니다.

그래서 우리는 역사적으로 그것들을 의사 코드로 표현 된 것으로 생각했습니다.

if(app_settings["beta-mode"] == "true")
  showAwesomeNewGui();
else
  sameOldSnoozeFeset();

That's a totally accurate way to think of it, and both Matt and Adil expand on it nicely with a variety of tactical use cases for the feature flag.

But I'd like to offer a revised definition that reflects how reality has evolved in the six years and change since dotnetdev asked the original question. I work for Rollout.io, a feature flag platform, so I've had a front-row seat for this evolution.

Simply put, feature flags aren't any longer just a way to turn bits of functionality on and off in your application. That's like answering "what is an invoice line item" by saying "it's a description and an amount of currency." True, but it doesn't drive at the broader point of the invoice itself.

Feature flags are the tactical bits of an overarching strategic solution in modern software. They're the means by which you defer important decision logic in your code until runtime when you have more information. And, perhaps most importantly, they don't just occur in isolation any longer, with a single check to see if the version number is greater than 2.7 or not; organizations that use them are typically including them as part of a comprehensive, system-wide product approach.

As others have mentioned, Facebook and LinkedIn pioneered this, but in 2018, a whole lot of organizations are doing it. They're deferring decision logic questions for runtime as part of development strategy, operations strategy (or DevOps strategy, if you want), and product strategy. Here are examples of such questions.

• Who should see the new admin screen that we're rolling out, and when?
• What level of membership is required to unlock this Easter egg?
• When should we cutover to the new database?
• Should we put a picture of a cheetah or an eagle on the checkout button to enhance conversions?

To have an application that defers a significant number of such decisions until runtime, you can't throw feature flags into your application in ad-hoc fashion or you'll bury yourself in technical debt. You need, these days, to have a comprehensive feature flag management strategy, which includes a few different components.

• Toggle points are used to switch behavior for new features.
• Multiple toggle points come together to form a toggle router. A toggle router determines the state of a feature.
• Toggle context provides the toggle router the necessary contextual information (e.g., specific user).
• Toggle configuration provides the toggle router information about the environment.

So, in the end, what are feature flags?

Well, they're an important part of a broader strategy to having an application that's adaptable to both technical and market needs.

---

At my company we used to have an own solution for that. We created a service providing a downloadable config (.json) file for every apps. In that config we stored the flags for the features. Based on that config the app can show or hide the current feature. (For example show or hide a menu item on the sidebar).

We also created an internal admin page where we can configure the feature-flags. It worked quite good for a while but after that we would have liked to do user targeting and A/B testing. To develop by own It seemed too much effort, so we chose a third-party solution. As already mentioned here there are many solutions for that.

We chose ConfigCat because it supports customized target groups and percentage-based rollout at once. You can check the supported open-source sdks on github.

---

Feature flags (or feature toggles) allow you to enable features remotely on an application without needing to re-build/re-deploy the application. This allows you to deploy the code to production but not release the feature until you are ready. You are able to target specific users, so you could enable a new feature to your beta users to test.

At our company we've previously used LaunchDarkly and other suggestions from FeatureFlags.io. We've also tried to use Firebase's Remote config to try and make this work however we found it wasn't really fit for this purpose.

We ended up developing our own version called Bullet Train, which we've open sourced. It combines both Feature Flags/Toggles and Remote Config.

---

Feature Flags are used for several purposes. The general idea is to delegate control over which user sees what feature to some remote dashboard or back-office of some sort.

Once a feature is flagged in the code you can now use several methods to determine which user sees it in your application: 1. On/Off - show the feature to all or none of your users. 2. Gradual Release - show the feature only to a percentage of your users, then gradually show it to all users. 3. Targeting - show the feature to specific users based on properties or characteristics of that user.

Tools that help with controlling Feature Flags (booleans) and Feature Configurations (strings, numbers, etc) are usually called Feature Management Platforms There is a great service for Feature Management called Configz.io

---

My understanding is that feature flags help you gate functionality by deciding which users receive certain features.

For example, let's say you only want your beta users to see a new feature. You would "toggle" that feature on for beta users and the rest of your users would not see it.

LDUser user = new LDUser("user@test.com");

boolean showFeature = ldClient.toggle("your.feature.key", user, false);

if (showFeature) {
     // application code to show the feature 
 }
else {
     // the code to run if the feature is off
 }

I'm testing LaunchDarkly's feature flags for some front-end JS A/B tests - seems to be working well. You can also check out this site for feature toggles and feature flag libraries.

---

Feature Flags basically gives you the ability to turn on and off a feature without making any changes on the code or releasing a new version. It's an important solution especially for mobile application developers since they have no control on users to update their application to a new version.

There are several companies giving this service for mobile application developers.

• apptunnel.com
• apptimize.com
• launchdarkly.com

---

At my company we use feature flags for every new feature we introduce in our SaaS app. Apart from the benefits to performance it also allows us to roll out new features gradually - introducing new features to power users first, getting feedback from them and improvising it before we can roll it out to all users.

It also allows us to customize offering to individual users - power users want all features; simple users may just want the basic stuff and may get confused by all the powerful complex features. It also allows our sales team to up-sell.

And of course as others have pointed out, if we find a feature is causing a performance degradation, we can simply turn off that one feature (either for all clients or for the one client who is causing an issue).

참고URL : https://stackoverflow.com/questions/7707383/what-is-a-feature-flag