Feature flag: 숨을 멈추지 않고 놓아주기

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2배포는 코드가 프로덕션 환경에 도착하는 시점입니다. 릴리스는 누군가가 실제로 사용할 수 있는 때입니다. 두 가지를 혼동하는 것은 모든 배포를 약간 긴장된 순간으로 만드는 가장 빠른 방법 중 하나입니다.
3 
4feature flag는 이 두 순간 사이에 공간을 두는 역할을 합니다. 오늘 배포하고 내일 내부 팀을 위해 시작할 수 있으며, 그 다음에는 파일럿 고객을 위해, 그 다음에는 10%의 사용자를 위해 시작할 수 있습니다. 문제가 발생하면 플래그를 끄십시오. 반드시 전체 릴리스를 롤백할 필요는 없습니다.
5 
6## 플래그는 단순한 if가 아닙니다.
7 
8기술적으로는 `if`인 경우가 많습니다. 문화적으로는 훨씬 더 많습니다.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18그 작은 `if`는 점진적인 출시, 실험, 마이그레이션, 기업 허가 또는 운영 kill switch을 나타낼 수 있습니다. 문제는 잘 관리하지 않으면 2년 동안 코드에 머무르는 기술적 부채가 될 수도 있다는 점이다.
19 
20## OpenFeature는 어디서 나오나요?
21 
22OpenFeature는 feature flag를 공통 API로 평가하기 위한 개방형 사양입니다. 아이디어는 간단합니다. 애플리케이션 코드는 플래그에 사용하는 공급업체나 내부 시스템에 직접적으로 의존해서는 안 됩니다.
23 
24앱에서 다음을 묻습니다.
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34공급자는 SaaS, 파일, 내부 서비스, 플래그 지정, GitOps 구성 등 규칙의 출처를 결정합니다. 어느 날 기능 플래그 지정 백엔드를 변경하면 애플리케이션을 모든 곳에서 다시 작성할 필요가 없습니다.
35 
36이러한 분리는 건축학적 세부 사항처럼 보이지만 프로젝트가 성장함에 따라 느껴집니다.
37 
38## 상황이 전투의 절반입니다
39 
40모든 사람을 위한 켜짐 또는 꺼짐 플래그는 유용하지만 제한적입니다. 상황에 따라 점진적인 전달이 가능합니다.
41 
42- 내부 또는 외부 사용자
43- 무료 또는 기업용 요금제
44- 마을;
45- 조직;
46- 앱 버전
47- 안정적인 트래픽 비율.
48 
49중요한 핵심은 `targetingKey`입니다: 안정적이어야 합니다. 요청이 있을 때마다 변경되면 사용자는 변형 A에 한 번, 변형 B에 한 번 들어갈 수 있습니다. 실험의 경우 끔찍하고 결제의 경우 재앙이 될 수 있습니다.
50 
51## 합리적인 출시
52 
53내가 좋아하는 흐름은 다음과 같습니다.
54 
551. 깃발을 끈 상태로 배치한다.
562. 개발자와 QA를 위한 점화;
573. 파일럿 고객 또는 임차인을 위한 스위치 온;
584. 5% 출시;
595. 25%의 출시;
606. 100% 출시;
617. 이전 코드 및 플래그를 제거합니다.
62 
63자주 잊혀지는 지점이 마지막 지점이다. 임시 플래그에는 사망 날짜가 있어야 합니다. 그것이 영원히 유지된다면, 미래의 모든 리팩터링은 "하지만 이 분기가 여전히 유용한가?"라고 질문해야 할 것입니다.
64 
65## Kill switch: 먼저 준비하세요
66 
67kill switch는 외부 종속성이 문제를 일으키기 시작하거나, 작업이 너무 많은 리소스를 소비하거나, 새로운 논리가 이상한 오류를 생성할 때 사용자를 구해 주는 플래그입니다.
68 
69좋은 kill switch는 다음과 같아야 합니다.
70 
71- 쉽게 찾을 수 있습니다.
72- Runbook에 문서화되어 있습니다.
73- 가끔씩 테스트합니다.
74- 활성화되면 관찰 가능합니다.
75- 파손될 수 있는 부분으로부터 가능한 한 독립적입니다.
76 
77최악의 상황은 사고 중에 플래그가 존재하지만 여전히 작동하는지 아무도 알 수 없다는 것입니다.
78 
79## 관찰 가능성 또는 점진적 전달이 아님
80 
81측정항목을 확인하지 않고 10%에서 기능을 활성화하는 것은 여러 단계를 거쳐야 하는 낙관적일 뿐입니다.
82 
83각 출시는 다음과 같은 간단한 질문에 답해야 합니다.
84 
85- 오류가 증가했나요?
86- 대기 시간이 변경되었나요?
87- 사용자가 흐름을 완료합니까?
88- 티켓이나 재시도가 더 있나요?
89- 변형이 하나의 세그먼트에만 영향을 줍니까?
90 
91OpenFeature 플래그 평가에 대한 후크를 지원합니다. 오류 기록, 측정항목 추가, 평점을 trace에 연결하는 데 유용합니다.
92 
93## 이름 지정 및 소유권
94 
95이름이 중요합니다. `new_ui` 아무 말도 하지 않습니다. `checkout.v2.enabled`에는 훨씬 더 많은 내용이 나와 있습니다.
96 
97각 플래그에 대해 최소한 다음을 표시합니다.
98 
99- 이름;
100- 설명;
101- 소유자;
102- 안전한 기본값;
103- 그것이 존재하는 이유;
104- 제거 날짜 또는 조건.
105 
106소유자 없는 플래그는 거의 항상 아무도 지우지 않는 플래그입니다.
107 
108## 평가할 곳
109 
110프론트엔드, 백엔드 또는 엣지? 상황에 따라 다릅니다.
111 
112플래그가 레이아웃, 복사 또는 온보딩을 위한 것이라면 프런트엔드는 괜찮습니다. 권한, 청구, 한도 또는 민감한 데이터와 관련된 경우 백엔드에 있어야 합니다. 라우팅이나 트래픽이 많은 실험이 포함된 경우 에지가 적합할 수 있습니다.
113 
114간단한 규칙: 프런트엔드는 경험을 향상시킬 수 있지만 그것이 유일한 보안 장벽이 되어서는 안 됩니다.
115 
116## 결론
117 
118feature flag가 잘 이루어지면 생산과의 관계가 달라집니다. 위험을 제거하지는 못하지만 위험을 더 작고 관리하기 쉽게 만듭니다. 조각으로 풀고, 관찰하고, 멈추고, 돌아가고, 배울 수 있습니다.
119 
120OpenFeature는 깔끔한 기반을 추가합니다. 즉, 공통 API, 상호 교환 가능한 공급자, 시스템을 확장하는 더 깔끔한 방법을 추가합니다. 그러나 안전한 기본값, 명확한 이름, 지표, 소유자 및 청결성 등 규율은 귀하의 것입니다.
121 
122가장 좋은 플래그는 침착하게 해제하는 데 도움이 되었다가 더 이상 필요하지 않을 때 사라지는 플래그입니다.
123 
124## 소스
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag: 숨을 멈추지 않고 놓아주기lines 1-131 (END) — press q to close

2배포는 코드가 프로덕션 환경에 도착하는 시점입니다. 릴리스는 누군가가 실제로 사용할 수 있는 때입니다. 두 가지를 혼동하는 것은 모든 배포를 약간 긴장된 순간으로 만드는 가장 빠른 방법 중 하나입니다.

4feature flag는 이 두 순간 사이에 공간을 두는 역할을 합니다. 오늘 배포하고 내일 내부 팀을 위해 시작할 수 있으며, 그 다음에는 파일럿 고객을 위해, 그 다음에는 10%의 사용자를 위해 시작할 수 있습니다. 문제가 발생하면 플래그를 끄십시오. 반드시 전체 릴리스를 롤백할 필요는 없습니다.

6## 플래그는 단순한 if가 아닙니다.

8기술적으로는 `if`인 경우가 많습니다. 문화적으로는 훨씬 더 많습니다.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18그 작은 `if`는 점진적인 출시, 실험, 마이그레이션, 기업 허가 또는 운영 kill switch을 나타낼 수 있습니다. 문제는 잘 관리하지 않으면 2년 동안 코드에 머무르는 기술적 부채가 될 수도 있다는 점이다.

20## OpenFeature는 어디서 나오나요?

22OpenFeature는 feature flag를 공통 API로 평가하기 위한 개방형 사양입니다. 아이디어는 간단합니다. 애플리케이션 코드는 플래그에 사용하는 공급업체나 내부 시스템에 직접적으로 의존해서는 안 됩니다.

24앱에서 다음을 묻습니다.

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34공급자는 SaaS, 파일, 내부 서비스, 플래그 지정, GitOps 구성 등 규칙의 출처를 결정합니다. 어느 날 기능 플래그 지정 백엔드를 변경하면 애플리케이션을 모든 곳에서 다시 작성할 필요가 없습니다.

36이러한 분리는 건축학적 세부 사항처럼 보이지만 프로젝트가 성장함에 따라 느껴집니다.

38## 상황이 전투의 절반입니다

40모든 사람을 위한 켜짐 또는 꺼짐 플래그는 유용하지만 제한적입니다. 상황에 따라 점진적인 전달이 가능합니다.

42- 내부 또는 외부 사용자

43- 무료 또는 기업용 요금제

44- 마을;

45- 조직;

46- 앱 버전

47- 안정적인 트래픽 비율.

49중요한 핵심은 `targetingKey`입니다: 안정적이어야 합니다. 요청이 있을 때마다 변경되면 사용자는 변형 A에 한 번, 변형 B에 한 번 들어갈 수 있습니다. 실험의 경우 끔찍하고 결제의 경우 재앙이 될 수 있습니다.

51## 합리적인 출시

53내가 좋아하는 흐름은 다음과 같습니다.

551. 깃발을 끈 상태로 배치한다.

562. 개발자와 QA를 위한 점화;

573. 파일럿 고객 또는 임차인을 위한 스위치 온;

584. 5% 출시;

595. 25%의 출시;

606. 100% 출시;

617. 이전 코드 및 플래그를 제거합니다.

63자주 잊혀지는 지점이 마지막 지점이다. 임시 플래그에는 사망 날짜가 있어야 합니다. 그것이 영원히 유지된다면, 미래의 모든 리팩터링은 "하지만 이 분기가 여전히 유용한가?"라고 질문해야 할 것입니다.

65## Kill switch: 먼저 준비하세요

67kill switch는 외부 종속성이 문제를 일으키기 시작하거나, 작업이 너무 많은 리소스를 소비하거나, 새로운 논리가 이상한 오류를 생성할 때 사용자를 구해 주는 플래그입니다.

69좋은 kill switch는 다음과 같아야 합니다.

71- 쉽게 찾을 수 있습니다.

72- Runbook에 문서화되어 있습니다.

73- 가끔씩 테스트합니다.

74- 활성화되면 관찰 가능합니다.

75- 파손될 수 있는 부분으로부터 가능한 한 독립적입니다.

77최악의 상황은 사고 중에 플래그가 존재하지만 여전히 작동하는지 아무도 알 수 없다는 것입니다.

79## 관찰 가능성 또는 점진적 전달이 아님

81측정항목을 확인하지 않고 10%에서 기능을 활성화하는 것은 여러 단계를 거쳐야 하는 낙관적일 뿐입니다.

83각 출시는 다음과 같은 간단한 질문에 답해야 합니다.

85- 오류가 증가했나요?

86- 대기 시간이 변경되었나요?

87- 사용자가 흐름을 완료합니까?

88- 티켓이나 재시도가 더 있나요?

89- 변형이 하나의 세그먼트에만 영향을 줍니까?

91OpenFeature 플래그 평가에 대한 후크를 지원합니다. 오류 기록, 측정항목 추가, 평점을 trace에 연결하는 데 유용합니다.

93## 이름 지정 및 소유권

95이름이 중요합니다. `new_ui` 아무 말도 하지 않습니다. `checkout.v2.enabled`에는 훨씬 더 많은 내용이 나와 있습니다.

97각 플래그에 대해 최소한 다음을 표시합니다.

99- 이름;

100- 설명;

101- 소유자;

102- 안전한 기본값;

103- 그것이 존재하는 이유;

104- 제거 날짜 또는 조건.

105

106소유자 없는 플래그는 거의 항상 아무도 지우지 않는 플래그입니다.

107

108## 평가할 곳

109

110프론트엔드, 백엔드 또는 엣지? 상황에 따라 다릅니다.

111

112플래그가 레이아웃, 복사 또는 온보딩을 위한 것이라면 프런트엔드는 괜찮습니다. 권한, 청구, 한도 또는 민감한 데이터와 관련된 경우 백엔드에 있어야 합니다. 라우팅이나 트래픽이 많은 실험이 포함된 경우 에지가 적합할 수 있습니다.

113

114간단한 규칙: 프런트엔드는 경험을 향상시킬 수 있지만 그것이 유일한 보안 장벽이 되어서는 안 됩니다.

115

116## 결론

117

118feature flag가 잘 이루어지면 생산과의 관계가 달라집니다. 위험을 제거하지는 못하지만 위험을 더 작고 관리하기 쉽게 만듭니다. 조각으로 풀고, 관찰하고, 멈추고, 돌아가고, 배울 수 있습니다.

119

120OpenFeature는 깔끔한 기반을 추가합니다. 즉, 공통 API, 상호 교환 가능한 공급자, 시스템을 확장하는 더 깔끔한 방법을 추가합니다. 그러나 안전한 기본값, 명확한 이름, 지표, 소유자 및 청결성 등 규율은 귀하의 것입니다.

121

122가장 좋은 플래그는 침착하게 해제하는 데 도움이 되었다가 더 이상 필요하지 않을 때 사라지는 플래그입니다.

123

124## 소스

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131