배포 내역

Tuist는 의미 있는 변경 사항이 메인 브랜치에 병합될 때마다 새 버전을 자동으로 게시하는 지속적 릴리스 시스템을 사용합니다. 이 접근 방식은 관리자의 수동 개입 없이도 개선 사항이 사용자에게 신속하게 전달되도록 합니다.

개요

세 가지 주요 구성 요소를 지속적으로 출시하고 있습니다:

• Tuist CLI - 명령줄 도구
• Tuist 서버 - 백엔드 서비스
• 튜이스트 앱 - macOS 및 iOS 앱(iOS 앱은 TestFlight에만 지속적으로 배포됩니다. 자세한 내용은 여기를 참조하세요.

각 컴포넌트에는 메인 브랜치로 푸시할 때마다 자동으로 실행되는 자체 릴리스 파이프라인이 있습니다.

작동 방식

1. 커밋 규칙

기존 커밋](https://www.conventionalcommits.org/)을 사용하여 커밋 메시지를 구성합니다. 이를 통해 툴링이 변경 사항의 특성을 이해하고 버전 범프를 결정하며 적절한 변경 로그를 생성할 수 있습니다.

형식: 유형(범위): 설명

커밋 유형과 그 영향

유형	설명	버전 영향	예
feat	새로운 기능 또는 기능	마이너 버전 범프(x.Y.z)	feat(cli): Swift 6 지원 추가
수정	버그 수정	패치 버전 범프(x.y.Z)	수정(앱): 프로젝트 열기 시 충돌 해결
문서	문서 변경 사항	릴리스 없음	문서: 업데이트 설치 가이드
스타일	코드 스타일 변경	릴리스 없음	스타일: 스위프트포맷을 사용한 포맷 코드
리팩터링	코드 리팩토링	릴리스 없음	refactor(server): 인증 로직 간소화
perf	성능 개선	패치 버전 범프	perf(cli): 종속성 해결 최적화
테스트	테스트 추가/변경	릴리스 없음	테스트: 캐시에 대한 단위 테스트 추가
chore	유지 관리 작업	릴리스 없음	잡일: 종속성 업데이트
ci	CI/CD 변경 사항	릴리스 없음	CI: 릴리스용 워크플로 추가

획기적인 변화

브레이킹 변경은 메이저 버전 범프(X.0.0)를 트리거하며 커밋 본문에 표시해야 합니다:

feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.

2. 변경 감지

각 컴포넌트는 git cliff을 사용합니다:

• 마지막 릴리스 이후의 커밋 분석
• 범위별 커밋 필터링(cli, 앱, 서버)
• 릴리스 가능한 변경사항이 있는지 확인
• 변경 로그 자동 생성

3. 릴리스 파이프라인

릴리스 가능한 변경 사항이 감지된 경우:

1. 버전 계산: 파이프라인이 다음 버전 번호를 결정합니다.
2. 변경 로그 생성: 커밋 메시지에서 변경 로그를 생성하는 git cliff
3. 빌드 프로세스: 컴포넌트 빌드 및 테스트
4. 릴리스 생성: 아티팩트로 GitHub 릴리스가 생성됩니다.
5. 배포: 업데이트는 패키지 관리자(예: CLI용 Homebrew)에 푸시됩니다.

4. 범위 필터링

각 컴포넌트는 관련 변경 사항이 있을 때만 릴리스됩니다:

• CLI: (cli) 범위 또는 범위 없음으로 커밋합니다.
• 앱: (앱) 범위로 커밋
• 서버: (서버) 범위로 커밋합니다.

좋은 커밋 메시지 작성하기

커밋 메시지는 릴리스 노트에 직접적인 영향을 미치므로 명확하고 설명적인 메시지를 작성하는 것이 중요합니다:

Do:

• 현재 시제 사용: "추가된 기능"이 아닌 "기능 추가"
• 간결하지만 상세하게 설명하세요.
• 변경 사항이 컴포넌트별인 경우 범위를 포함하세요.
• 해당되는 경우 참조 문제: fix(cli): 빌드 캐시 문제 해결(#1234)

하지 마세요:

• "버그 수정" 또는 "코드 업데이트"와 같은 모호한 메시지 사용
• 서로 관련이 없는 여러 변경 사항을 하나의 커밋에 혼합
• 속보 변경 정보를 포함하는 것을 잊지 마세요.

획기적인 변화

변경 내용을 중단하려면 커밋 본문에 BREAKING CHANGE: 을 포함하세요:

feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.

릴리스 워크플로

릴리스 워크플로에 정의되어 있습니다:

• .github/workflows/cli-release.yml - CLI 릴리스
• .github/workflows/app-release.yml - 앱 릴리스
• .github/workflows/server-release.yml - 서버 릴리스

각 워크플로:

• 메인으로 푸시에서 실행
• 수동으로 트리거 가능
• 변경 사항 감지를 위해 git 클리프 사용
• 전체 릴리스 프로세스를 처리합니다.

릴리스 모니터링

다음을 통해 릴리스를 모니터링할 수 있습니다:

• GitHub 릴리스 페이지
• 워크플로 실행을 위한 GitHub 작업 탭
• 각 컴포넌트 디렉터리의 변경 로그 파일

혜택

이러한 지속적인 릴리스 접근 방식은 다음과 같은 이점을 제공합니다:

• 빠른 배송: 병합 후 변경 사항이 사용자에게 즉시 전달
• 병목 현상 감소: 수동 릴리스를 기다릴 필요 없음
• 명확한 커뮤니케이션: 커밋 메시지에서 자동화된 변경 로그
• 일관된 프로세스: 모든 구성 요소에 대해 동일한 릴리스 흐름
• 품질 보증: 테스트된 변경 사항만 릴리스됩니다.

문제 해결

릴리스가 실패한 경우:

1. 실패한 워크플로에 대한 GitHub 작업 로그를 확인하세요.
2. 커밋 메시지가 기존 형식을 따르는지 확인하세요.
3. 모든 테스트가 통과되었는지 확인
4. 컴포넌트가 성공적으로 빌드되었는지 확인

즉시 릴리스해야 하는 긴급한 수정 사항입니다:

1. 커밋의 범위가 명확한지 확인
2. 병합 후 릴리스 워크플로우 모니터링
3. 필요한 경우 수동 릴리스를 트리거합니다.

앱 스토어 출시

CLI와 서버는 위에서 설명한 지속적인 릴리스 프로세스를 따르지만, iOS 앱( )은 Apple의 앱 스토어 검토 프로세스로 인해 예외입니다:

• 수동 릴리스: iOS 앱 릴리스는 앱 스토어에 수동으로 제출해야 합니다.
• 검토 지연: 각 릴리스는 1~7일이 소요될 수 있는 Apple의 검토 프로세스를 거쳐야 합니다.
• 일괄 변경: 일반적으로 여러 변경 사항은 각 iOS 릴리스에 함께 번들로 제공됩니다.
• 테스트 플라이트: App Store 출시 전에 TestFlight를 통해 베타 버전을 배포할 수 있습니다.
• 릴리스 노트: 앱스토어 가이드라인에 맞게 작성해야 합니다.

iOS 앱은 여전히 동일한 커밋 규칙을 따르고 변경 로그 생성에 git cliff를 사용하지만 사용자에게 실제로 배포되는 것은 덜 빈번한 수동 일정에 따라 이루어집니다.