단일 프로젝트에서 여러 버전의 패키지를 사용하는 이유 및 방법

현대 소프트웨어 개발에서는 특히 대규모 JavaScript 프로젝트에서 종속성을 관리하기 위한 혁신적인 접근 방식이 필요한 경우가 많습니다. 그러한 접근 방식 중 하나는 단일 프로젝트에서 동일한 패키지의 여러 버전을 사용하는 것입니다. 이 방법은 평범해 보이지만 레거시 시스템 지원 보장, 기능 전환 수행 또는 A/B 테스트 촉진과 같은 다양한 요구 사항을 해결합니다.

이 블로그 게시물에서는 기능 전환 및 A/B 테스트에 중점을 두고 여러 버전의 패키지를 사용하는 이유를 살펴보고 Bit가 이 복잡한 프로세스를 어떻게 단순화할 수 있는지 살펴보겠습니다.

동일한 패키지의 여러 버전을 사용하는 이유는 무엇입니까?

1. 레거시 코드 및 점진적 업데이트

레거시 시스템은 이전 버전의 종속성에 의존하는 경우가 많습니다. 새 버전을 도입하면 비호환성이 발생할 수 있습니다. 여러 버전을 사용하면 이전 시스템을 안정적으로 유지하면서 새로운 기능이 업데이트된 라이브러리를 활용할 수 있습니다.

1. 기능 전환

기능 전환을 통해 개발자는 코드베이스를 수정하지 않고도 특정 기능의 가용성을 제어할 수 있습니다. 이 접근 방식은 기능을 점진적으로 출시하거나 그 영향을 테스트할 때 특히 유용합니다.

• 릴리스 토글: 코드가 메인 브랜치 내에서 병합 및 테스트되는지 확인하면서 기능의 공개 릴리스를 연기합니다.

• 실험 전환:(A/B 테스팅): 최적의 구현을 결정하기 위해 다양한 사용자 세그먼트로 기능을 테스트할 수 있습니다.

• 운영 토글: 새로운 코드를 배포하지 않고도 기능을 활성화하거나 비활성화할 수 있는 기능을 운영 팀에 제공합니다.

기능 전환에 라이브러리 업그레이드 또는 핵심 구성 요소 변경과 같은 중요한 변경이 포함된 경우 여러 버전의 패키지 또는 구성 요소가 필요할 수 있습니다.

사전 출시 버전으로 비트 구성 요소에 태그 지정

Bit는 버전이 출시될 준비가 되지 않았음을 나타내기 위해 의미 체계 버전 대신 해시로 구성 요소의 버전을 지정하는 bit snap 명령을 제공합니다(따라서 이 명령은 약간 다른 빌드 파이프라인도 실행합니다).

예:

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

그러나 해시를 구성 요소 버전으로 사용하더라도 해당 목적, 상위 릴리스 버전 또는 구성 요소 기록의 이 "분기"에 추가 반복이 있는지 여부에 대한 정보는 제공되지 않습니다.

비트 스냅은 git 커밋에 대한 비트 비유로 유용하지만 프로덕션에 통합되어야 하는 실험적 릴리스 버전에는 유용하지 않습니다.

더 많은 정보를 제공하려면 시험판 옵션을 사용하는 것이 좋습니다. 예:

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

여러 버전의 패키지 관리

여러 버전의 패키지/비트 구성 요소를 사용할 때 종속성 별칭이 핵심입니다. 이 접근 방식을 통해 팀은 동일한 프로젝트 내에서 여러 패키지 버전을 유지할 수 있습니다.

bit tag forms/sign-in -m "add SSO option" --increment prerelease --prerelease-id beta

별칭 이름을 사용하면 버전을 쉽게 구별할 수 있습니다.

{
 "dependencies": {
  "@my-org/my-scope.forms.sign-in": "0.0.1",
  "@my-org/my-scope.forms.sign-in-sso": "npm:@my-org/my-scope.forms/sign-in@0.0.2-beta.0",
}

자세히 알아보기

• 비트 문서
• 비트플랫폼

위 내용은 단일 프로젝트에서 여러 버전의 패키지를 사용하는 이유 및 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!