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

spinny:~/writing $ vim 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~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :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}

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~