기능 로고는 간단한 기술로 소프트웨어에 새로운 기능이나 행위가 있는지 전환할 수 있습니다.
본고에서 나는 왜 이것이 듣기에 그렇게 미친 생각이 아닌지, 간단한 기능 표지, 서로 다른 유형의 기능 표지와 각 표지를 촉발하는 서로 다른 방식을 어떻게 실현하는지 토론하고자 한다.
주의: 만약 용어인'표지'가 당신을 곤혹스럽게 한다면 그것을 전환이나 스위치로 간주하십시오.그것은 바람에 흩날리는 직물이 아니라 볼 변수를 가리킨다.

왜 기능 표지를 사용합니까?

언뜻 보기에는 로고의 생각이 좀 이상하게 들린다. 어쨌든, 기능을 사용하지 않으려면, 왜 코드부터 시작해야 하는가?
우선, 생산 환경에서 한 사용자에게 좋은 방법은 더욱 광범위한 데이터 집합이나 상호작용에 적합하지 않을 수 있다.베타 사용자 전용 유형의 기능 로고를 정의하고 싶을 수도 있습니다. 그 중 하나는 정상적으로 작동할 수 있다는 것을 증명할 때까지 일부 사용자에게만 사용됩니다.

그 다음으로 많은 제품들이 정성스럽게 조화로운 "오프라인"날짜를 가지고 있다.새로운 코드가 생산 중에 미리 발표되어 추가적인 위험을 줄이고 신기한 날짜가 왔을 때 기능을 활성화하기를 원할 수도 있습니다.
마지막으로 운영 환경에 코드를 자주 게시하는 경우 대규모 기능(EPIC이라고도 함)을 완료하는 데 시간이 오래 걸리면 지점 관리가 어려울 수 있습니다.다른 지점을 관리하는 데 더 많은 시간을 들일 것이며, 주기적으로 오류를 조기 발견할 수 있는 생산력과 기회를 잃게 될 것입니다.기능 플래그를 사용하면 생산에서 일부 기능을 오프라인 상태로 발표할 수 있지만, 전체 기능이 준비되기 전에 QA 또는 베타 환경에서 테스트하십시오.

실현 기능 표지

그렇다면 특징 표지는 실제로 어떤 모습일까?

private static IResumeAnalyzer GetResumeAnalyzer()
{
    // Check whatever configuration management this application uses
    if (ConfigHelper.GetBoolean("UseNewAnalyzer"))
    {
        return new RewrittenAnalyzer();
    }
    else
    {
        return new ResumeAnalyzer();
    }
}

위의 예시에서 우리는 응용 프로그램 프레임워크에 의존하는 모든 프로필에서 설정을 추출합니다.UseNewAnalyzer의 값이true로 설정되면 RewrittenAnalyzer 이 사용되고 그렇지 않으면 이전 버전이 사용됩니다.
매우 간단한 코드지만, 네트워크 효과는 우리로 하여금 파일을 바꾸게 하고, 응용 프로그램의 행위는 완전히 다르다.언어와 배치 환경에 따라 프로그램을 다시 시작할 필요가 없을 수도 있습니다.

기능 플래그를 구성하는 방법

기능 플래그를 구성 파일에서 제거할 필요가 없습니다.서로 다른 장면에서 또 많은 다른 선택이 의미가 있을 수 있다.
기능 플래그의 일반적인 트리거는 다음과 같습니다.

구성 파일의 값 기반(위 예 참조)

데이터베이스 테이블

의 값 기반

어떤 날짜(또는 일련의 날짜 사이)에서 활발하거나 활발하지 않다

테스트 버전 사용자에게만 유효

일정 비율의 시간 또는 무작위용 호자 집합(일반적으로 a/B 테스트에 사용)

외부 웹 서비스 호출을 기반으로 되돌아오는 값

외부 서비스 관리(예: Launch Darkly

기능 표지에 대한 반대 의견

좋습니다. 특성 표지는 오프라인 배치 코드나 코드를 특정한 호적집에 배치하는 것을 더욱 쉽게 합니다.이것은 듣기에 품질에 매우 좋은 것 같지만, 무엇을 따져야 합니까?
무료는 없습니다. 기능 표시를 통해 다음과 같은 몇 가지 핵심 영역에서 가격을 지불할 수 있습니다.

테스트

테스트가 더욱 어렵고 지루해졌습니다. 테스트 활성화 기능과 정지 기능을 확보해야 하기 때문입니다.나는 일부 단체가 이전에 기능 표지를 사용하고 활동 상태에서만 기능을 테스트한 다음에 오프라인 상태에서 기능을 배치할 때 미리 보기 환경이 경직되는 것을 본 적이 있다.
그 밖에 각종 기능이 상호작용하고 모든 기능이 전환된다면 서로 다른 기능 상태의 모든 조합을 테스트해야 한다.이것이 바로 내가 현재 생산에서 완전히 온라인 또는 영구적으로 효력을 상실하고 있는 기능의 낡은 기능 표지를 삭제하는 것을 강력히 건의하는 이유이다.

데이터베이스 아키텍처

기존 테이블에 영향을 주는 데이터베이스 마이그레이션 스크립트에 의존하는 새로운 기능이 있다면, 이 기능이 오프라인 상태일 때, 오래된 데이터가 어떻게 작동하는지, 이 기능이 온라인에서 오프라인 상태(반대로)로 바뀌어야 한다면, 어떤 상황이 발생할지, 그리고 여러 가지 다른 문제를 고려해야 합니다.
일반적으로 가장 좋은 방법은 새로운 기능 전환을 배치하여 데이터를 이전하는 것이다. 설령 이것이 오프라인 상태일지라도 모든 상황에서 불가능하다.
또는 기능 버전을 수정 중인 테이블의 열에 저장하여 새 기능과 연관된 행, 기존 작업 방식과 연관된 행을 구분할 수 있습니다.이것은 새로운 기능 상태로의 이동과 새로운 기능 상태로부터의 이동을 제어하는 데 도움이 되지만 복잡도는 비용이 매우 높다.

구성 관리

더 많은 설정 비용은 현재 모든 환경을 관리하고 모든 환경의 모든 기능의 상태를 추적하는 데 약간의 어려움을 겪고 혼란이나 다른 문제를 초래할 수 있음을 의미한다.

다음 단계

최종적으로 미리 출시해야 하는 주요 장기적인 베타 기능이나 빠른 롤백 옵션이 필요하고 코드 변경/배치가 필요 없는 일정한 위험이 있는 변경에 대해 기능 표지는 고려할 만한 일이다.
C#의 기능 플래그에 대한 자세한 내용은 을 참조하십시오.
비록 나는 확실히 어떤 상황에서 기능 표지를 사용했지만, 나는 사용자에게 영향을 주지 않는 상황에서 새로운 코드의 생산 중의 효과를 테스트하기 위해 Scientist 시리즈 라이브러리를 사용하는 것을 더욱 좋아한다.

이 프로세스에 대한 자세한 내용은 을 참조하십시오.

무피해자 참새 테스트와 과학자.순액

마테 엘란드・ 2019년 8월 31일・ 4분 읽기

#testing #dotnet #devops #codequality

바울이 Unsplash에 있는 재킷 사진.