아키텍처 다이어그램은 무엇이 존재하는지 보여줍니다. 이제 무엇이 배포되었는지도 보여줍니다. Archyl의 새로운 릴리스 관리를 통해 시스템과 환경 전반의 배포를 추적할 수 있으며, GitHub Actions, 웹훅, REST API를 통한 수집이 가능합니다.

릴리스 관리: 아키텍처 전반의 모든 배포를 추적하세요

두 달 전, 중심 질문이 믿기 어려울 만큼 단순한 포스트모템에 참석했습니다: "결제 서비스의 어떤 버전이 지금 프로덕션에서 실행 중인가?"

네 명이 세 가지 다른 답을 했습니다. 한 명은 GitHub 릴리스 페이지를 확인했습니다. 다른 한 명은 ArgoCD를 열었습니다. 세 번째는 Slack 배포 채널을 스크롤했습니다. 네 번째 — 실제로 배포한 사람 — 은 휴가 중이었습니다.

스타트업이 아니었습니다. 성숙한 CI/CD 파이프라인, 좋은 태깅 관행, Archyl에서 잘 유지된 아키텍처 다이어그램을 가진 팀이었습니다. 다이어그램은 어떤 시스템이 존재하고, 어떻게 연결되며, 어떤 프로토콜을 사용하는지 정확히 알려줬습니다. 다만 어떤 것의 어떤 버전이 실제로 실행 중인지는 알려줄 수 없었습니다. 어디에서도.

그 간극이 한동안 저를 괴롭혔습니다. 아키텍처 문서는 시스템의 구조를 알려줍니다. 배포 이력은 시스템의 상태를 알려줍니다. 이 두 가지는 함께 살아야 합니다. 오늘, 그렇게 됩니다.

아키텍처에 연결된 릴리스

Archyl의 릴리스 관리는 배포를 아키텍처 작업 공간의 일급 객체로 추적합니다. 릴리스에는 버전, 상태, 환경, 변경 로그, 그리고 — 결정적으로 — 속하는 C4 요소에 대한 링크가 있습니다.

마지막 부분이 CI/CD 대시보드와 다른 점입니다. GitHub Actions 실행은 v2.4.0이 배포되었다고 알려줍니다. 그런데 아키텍처 맥락에서 어디에 배포되었나요? 어떤 시스템? 어떤 컨테이너? Archyl의 릴리스는 배포 이벤트를 C4 다이어그램의 시스템과 컨테이너에 직접 연결하여 이에 답합니다.

시스템의 세부 패널을 열면 관계, ADR, API 계약과 함께 최근 릴리스를 볼 수 있습니다. 아키텍처 다이어그램이 살아있는 지도가 됩니다 — 무엇이 존재하는지뿐만 아니라 무엇이 배포되었고 언제인지.

세 가지 수집 방법

릴리스 추적이 더 많은 수동 작업을 의미하길 원하지 않았습니다. 이미 파이프라인을 통해 배포하고 있다면, 릴리스가 Archyl로 자동으로 흘러야 합니다.

GitHub Actions — 배포 워크플로우에 넣을 수 있는 공식 GitHub Action을 게시합니다. 최소 설정은 YAML 두 줄입니다.

- uses: archyl/release-action@v1
  with:
    api-key: ${{ secrets.ARCHYL_API_KEY }}
    version: ${{ github.ref_name }}

끝입니다. 모든 태그된 릴리스가 아키텍처 작업 공간에 나타납니다.

웹훅 — 프로젝트 설정에서 웹훅 엔드포인트를 구성한 다음, GitHub 또는 GitLab의 릴리스 웹훅을 여기에 연결합니다. 새 릴리스가 게시되거나 태그가 푸시되면, Archyl이 이벤트를 수신하고 릴리스 항목을 자동으로 생성합니다.

REST API — Jenkins, CircleCI, Bitbucket Pipelines 또는 기타 CI/CD 도구를 사용하는 팀의 경우, 수집 엔드포인트가 간단한 JSON 페이로드를 수용합니다. API 키로 인증하고, 버전과 메타데이터를 보내면 릴리스가 Archyl에 나타납니다.

환경

모든 배포가 같지는 않습니다. 스테이징으로 푸시하는 것은 일상입니다. 프로덕션으로 푸시하는 것은 이벤트입니다. 릴리스 관리는 둘을 별도로 추적합니다.

환경은 사용자 정의이며 색상 코딩됩니다. "개발", "스테이징", "프로덕션"을 만드세요 — 또는 팀이 사용하는 것을. 각 릴리스는 대상 환경으로 태그됩니다.

타임라인

릴리스 타임라인이 기본 뷰입니다. 릴리스가 월별로 그룹화되어, 역순으로 표시되며, 버전 배지, 환경 태그, 상태 표시기가 있습니다.

각 릴리스 항목은 버전, 상태 (배포됨, 진행 중, 계획됨, 실패, 롤백됨), 환경, 연결된 요소, 소스, 변경 로그를 보여줍니다.

배포 매트릭스

여러 서비스를 여러 환경에서 관리하는 팀을 위해 두 번째 뷰를 만들었습니다: 배포 매트릭스.

행이 시스템과 컨테이너, 열이 환경인 그리드이며, 각 셀은 해당 조합에 배포된 최신 릴리스를 보여줍니다. 한눈에 Account API가 프로덕션에서는 v3.1.0이지만 스테이징에서는 v3.2.0-beta라는 것을 볼 수 있습니다.

매트릭스는 환경 드리프트를 가시화합니다. 스테이징과 프로덕션 버전이 갈라지면 즉시 포착됩니다.

상태 라이프사이클

릴리스가 항상 깔끔하지는 않습니다. 배포가 실패합니다. 릴리스가 롤백됩니다. 전체 라이프사이클을 추적합니다: 계획됨, 진행 중, 배포됨, 실패, 롤백됨.

상태 전환은 CI/CD 통합 사용 시 자동이거나, UI를 통해 릴리스를 만들 때 수동입니다.

아키텍처 요소에 연결

모든 릴리스는 시스템, 컨테이너 또는 둘 다에 연결할 수 있습니다. 이것이 릴리스에 아키텍처 맥락을 부여합니다.

다이어그램에서 연결된 요소는 세부 패널에 릴리스 이력을 표시합니다. 컨테이너를 우클릭하면 관계와 계약뿐만 아니라 배포 타임라인도 볼 수 있습니다. 아키텍처 문서와 운영 현실이 수렴하는 곳입니다.

왜 이것이 중요한가

아키텍처 다이어그램은 항상 시간의 스냅샷이었습니다. 시스템이 무엇인지 보여줍니다. 하지만 시스템이 무엇을 하고 있는지는 보여주지 않습니다. 릴리스 관리는 배포 이력을 그것이 속하는 곳 — 아키텍처 자체 — 에 놓습니다.

시작하기

프로젝트 설정으로 이동하여 릴리스 탭을 엽니다. 통합 방법을 선택하고 설정 가이드를 따르세요. 환경을 만들고, 대상 시스템 또는 컨테이너를 연결하고, 첫 번째 릴리스를 배포하세요.

아키텍처는 구조 이상입니다. 이제 도구가 이를 반영합니다.

아키텍처를 현실에 연결하는 것에 대해 더 알고 싶으신가요? API Contracts가 사양을 다이어그램에 연결하는 방법이나, 아키텍처 변경 요청이 C4 모델에 풀 리퀘스트 워크플로우를 가져오는 방법을 확인하세요.

릴리스 관리: 아키텍처 전반의 모든 배포를 추적하세요 - Archyl Blog