릴리스 관리
릴리스 관리는 배포를 아키텍처 워크스페이스의 일급 객체로 추적합니다. 모든 릴리스는 C4 요소에 연결되어, 다이어그램에서 실제로 실행 중인 것을 실시간으로 확인할 수 있습니다.
핵심 개념
릴리스
릴리스는 환경에 배포된 특정 버전을 나타냅니다. 각 릴리스에는 다음 정보가 있습니다:
| 필드 | 설명 |
|---|---|
| 버전 | 시맨틱 버전 태그 또는 식별자 (예: v2.4.0, 3.12.0-rc.2) |
| 상태 | 배포 라이프사이클에서의 현재 상태 |
| 환경 | 대상 환경 (프로덕션, 스테이징 등) |
| 변경 로그 | 이 릴리스에서 변경된 내용 |
| 소스 | 릴리스 생성 방법 (수동, API, GitHub Action, Webhook) |
| 연결된 요소 | 이 릴리스가 속하는 시스템 또는 컨테이너 |
환경
환경은 배포 대상을 나타냅니다. 사용자 정의 가능하며 색상으로 구분됩니다.
일반적인 구성:
- Development → Staging → Production
- Dev → QA → Pre-prod → Production
워크플로우에 필요한 만큼의 환경을 만들 수 있습니다. 각 릴리스에는 대상 환경이 태그됩니다.
상태 라이프사이클
릴리스는 다음 상태를 거칩니다:
| 상태 | 설명 |
|---|---|
| 계획됨 | 릴리스가 존재하지만 아직 배포되지 않음. 예정된 버전 추적에 유용. |
| 진행 중 | 배포가 진행 중. CI/CD 통합에 의해 자동 설정. |
| 배포됨 | 릴리스가 대상 환경에서 가동 중. |
| 실패 | 배포가 실패함. 시도의 기록으로 남음. |
| 롤백됨 | 릴리스가 배포되었지만 이후 되돌려짐. |
릴리스 추적 설정
1. 환경 만들기
- 프로젝트의 설정으로 이동
- 릴리스 탭 열기
- 환경 아래에서 환경 추가 클릭
- 이름을 입력하고 색상 선택
- 드래그하여 배포 단계 순서로 정렬
2. 기본 연결 대상 구성
릴리스가 기본적으로 연결될 시스템과 선택적으로 컨테이너를 설정:
- 릴리스 설정 탭에서 기본 연결 대상 찾기
- 드롭다운에서 시스템 선택
- 선택적으로 해당 시스템 내 컨테이너 선택
- 이 대상은 수집된 릴리스가 요소를 지정하지 않을 때 사용됨
3. 통합 방법 선택
Archyl은 릴리스를 자동으로 수집하는 세 가지 방법을 지원합니다.
통합 방법
GitHub Actions
공식 Archyl GitHub Action을 배포 워크플로우에 추가합니다.
최소 설정:
- uses: archyl/release-action@v1
with:
api-key: ${{ secrets.ARCHYL_API_KEY }}
version: ${{ github.ref_name }}
전체 구성:
- uses: archyl/release-action@v1
with:
api-key: ${{ secrets.ARCHYL_API_KEY }}
version: ${{ github.ref_name }}
environment: production
system-id: <your-system-uuid>
container-id: <your-container-uuid>
changelog: "Bug fixes and performance improvements"
status: deployed
이 액션은 배포 성공 시 버전, 커밋 SHA, 환경, 변경 로그를 Archyl에 전송합니다.
Webhook
GitHub 또는 GitLab에서 릴리스 이벤트를 수신하도록 Webhook 수집을 구성합니다.
- 릴리스 설정 탭에서 Webhook 활성화
- 표시된 Webhook URL 복사
- GitHub 또는 GitLab에서 해당 URL을 가리키는 새 Webhook 추가
- Release 또는 Tag push 이벤트 유형 선택
구성 옵션:
| 설정 | 설명 |
|---|---|
| 태그 패턴 | 릴리스를 생성할 태그 필터 (예: v*는 v로 시작하는 태그) |
| 기본 환경 | Webhook으로 생성된 릴리스에 할당되는 환경 |
| Webhook 시크릿 | 페이로드 검증을 위한 공유 시크릿 |
새 릴리스가 게시되거나 일치하는 태그가 푸시되면, Archyl이 자동으로 릴리스 항목을 생성합니다.
REST API
HTTP 요청이 가능한 모든 CI/CD 도구(Jenkins, CircleCI, Bitbucket Pipelines, 커스텀 파이프라인 등)에서 사용 가능합니다.
엔드포인트: POST /api/v1/projects/:projectId/releases
헤더:
Authorization: Bearer <api-key>
Content-Type: application/json
페이로드:
{
"version": "v2.4.0",
"status": "deployed",
"changelog": "Added payment retry logic",
"environmentId": "<environment-uuid>",
"systemId": "<system-uuid>",
"containerId": "<container-uuid>",
"sourceUrl": "https://github.com/org/repo/releases/tag/v2.4.0"
}
설정 탭에는 API 키와 요소 ID가 자동 입력된 복사 가능한 코드 스니펫이 표시됩니다.
뷰
릴리스 타임라인
기본 뷰입니다. 릴리스는 월별로 최신순으로 그룹화됩니다. 각 항목에는 다음이 표시됩니다:
- 버전 배지
- 상태 인디케이터
- 환경 태그 (색상 구분)
- 연결된 시스템 또는 컨테이너
- 소스 (GitHub Action, Webhook, API, 수동)
- 상대 타임스탬프
릴리스를 클릭하면 전체 변경 로그, 날짜, 소스 링크가 포함된 상세 패널이 열립니다.
필터링:
- 환경별 (예: 프로덕션 배포만 표시)
- 상태별 (예: 실패한 배포만 표시)
- 연결된 요소별
배포 매트릭스
여러 서비스를 여러 환경에서 관리하는 팀을 위한 그리드 뷰입니다.
- 행 — 시스템 및 컨테이너
- 열 — 환경
- 셀 — 해당 조합에 배포된 최신 릴리스
매트릭스를 통해 환경 드리프트를 한눈에 파악할 수 있습니다. 스테이징과 프로덕션 버전이 다를 경우 즉시 알 수 있습니다.
릴리스를 아키텍처에 연결
모든 릴리스는 시스템, 컨테이너 또는 둘 다에 연결할 수 있습니다.
자동 연결
GitHub Actions나 Webhook을 사용할 때 릴리스는 설정에서 구성된 기본 대상에 연결됩니다. system-id와 container-id를 지정하여 릴리스별로 대상을 재정의할 수 있습니다.
수동 연결
UI를 통해 릴리스를 만들 때:
- 새 릴리스 클릭
- 버전, 상태, 변경 로그 입력
- 대상 시스템 및/또는 컨테이너 선택
- 환경 선택
- 만들기 클릭
다이어그램에서 보기
C4 다이어그램에서 아무 요소나 우클릭하여 상세 패널을 엽니다. 연결된 릴리스는 관계, ADR, API 계약과 함께 릴리스 섹션에 표시됩니다. 요소에는 가장 최근 릴리스 버전과 환경이 표시됩니다.
수동 릴리스 만들기
모든 릴리스가 파이프라인에서 오는 것은 아닙니다. 수동으로 릴리스를 만들려면:
- 릴리스 탭으로 이동
- 새 릴리스 클릭
- 버전을 입력하고 상태와 환경 선택
- 변경 로그 작성 (Markdown 지원)
- 시스템 및/또는 컨테이너에 연결
- 만들기 클릭
수동 릴리스는 타임라인에서 소스가 수동으로 표시됩니다.
모범 사례
시맨틱 버전 관리 사용
- 시맨틱 버전으로 릴리스 태그 (예:
v1.2.3) - 비프로덕션 릴리스에는 프리릴리스 식별자 포함 (예:
v2.0.0-rc.1) - 환경 간 버전 문자열 일관성 유지
모든 환경 추적
- 모든 배포 단계에 대한 환경 생성
- 스테이징을 건너뛰지 마세요 — 배포 매트릭스는 전체 파이프라인을 보여줄 때 가장 유용합니다
- 매트릭스 뷰를 사용하여 환경 드리프트 조기 발견
수집 자동화
- 수동 입력 대신 GitHub Actions나 Webhook 사용
- 통합을 한 번 설정하면 모든 배포가 자동으로 기록됨
- 수동 생성은 핫픽스나 예외적인 배포에 한정
변경 로그 작성
- 모든 릴리스에 의미 있는 변경 로그 포함
- 무엇이 변경되었고 왜 변경되었는지 요약
- 가능하면 관련 이슈나 풀 리퀘스트에 링크
적절한 수준에 연결
- 전체 애플리케이션 배포 시 시스템에 연결
- 시스템 내 개별 서비스 배포 시 컨테이너에 연결
- 일관성 유지 — 관례를 정하고 따르기
다음 단계
- API 계약 — API 사양 문서화
- 아키텍처 인사이트 — 아키텍처 문제 감지
- 아키텍처 변경 요청 — 검토 워크플로우를 통한 변경 제안