릴리스 설정은 프로젝트별로 적용됩니다. 다음을 열어주세요:릴리스,릴리스 설정, 해당 프로젝트를 선택하세요. 총 4개의 화면으로 구성되며, 각 화면에서는 하나의 질문에 대한 답변을 입력합니다.
- 환경
- 릴리스는 어디로 배포되나요? 배포 지점을 추가하고 순서를 정하세요.
- 승인 규칙
- 배포 전에 반드시 충족되어야 할 조건은 무엇인가요? 환경별 승인, 역할, 체크리스트 및 긴급 수정 규칙이 적용됩니다.
- 배포 파이프라인
- 누가 배포하며, Coroid는 어떻게 결과를 확인하나요? 귀사의 파이프라인 또는 Coroid가 배포를 시작하며, 보고용 토큰을 통해 CI/CD가 결과를 확인할 수 있습니다.
- 버전 관리
- 이것은 어떤 버전인가요? 버전의 출처, 빌드에 전달되는 내용, 그리고 Coroid이 실행되는 내용을 확인하는 방식을 알아보세요.
릴리스 설정을 변경할 수 있는 권한은 소유자와 관리자에게만 부여됩니다. 그 외 사용자는 해당 설정을 확인만 할 수 있습니다. 먼저 저장소를 연결해야 하는데, 모든 릴리스는 해당 저장소 내의 커밋을 참조하기 때문입니다.
환경
릴리스가 배포되는 위치와 순서는 무엇인가요?
각 프로젝트는 기본적으로 운영 환경에서 시작됩니다. 스테이징이나 QA 등 추가로 배포할 환경은 생성 버튼을 이용해 추가할 수 있습니다.환경을 추가하세요. 각 환경에 이름을 지정하세요. Coroid는 이름에서 키를 추천하며, 예시로는staging. 해당 키는 CI/CD가 배포 상황을 보고할 때 사용되므로, 파이프라인에서 활용되기 시작한 이후에는 반드시 안정적으로 유지해야 합니다.
순서를 다음과 같이 설정하세요:이후에 실행됨. 아무것도 없는 상태 이후에 실행되는 스테이징 환경과 스테이징 이후에 실행되는 프로덕션 환경을 조합하면 '스테이징 › 프로덕션'이라는 배포 경로가 형성됩니다. 릴리스 페이지에는 이 순서에 따른 배포 트랙이 표시되며, 승인 규칙에 따라 앞단계의 배포가 성공해야만 다음 단계로 진행할 수 있습니다.
승인 규칙
릴리스가 해당 환경에 배포되기 전에 충족되어야 할 조건은 무엇인가요?
상단에서 대상 환경을 선택하세요. 규칙은 환경별로 적용되므로 스테이징 환경은 완화된 기준을 적용하고 프로덕션 환경은 엄격한 기준을 적용할 수 있습니다.
- 필요한 승인 횟수: 승인을 위해 필요한 인원의 수입니다. 0으로 설정하면 검증 절차가 통과되는 즉시 릴리스가 배포됩니다.
- 승인 가능한 사용자: 승인 권한을 가진 조직 내 역할입니다.
- 요청자와 승인자를 분리하기: 배포를 시작한 사람은 해당 배포를 승인할 수 없으며, 릴리스 노트를 편집한 사람도 해당 노트에 대한 승인 권한을 가질 수 없습니다.
- 품질 검사 통과: 항상 활성화됩니다. 프로젝트의 품질 그래프에는
release_validation트리거가 정확한 커밋을 대상으로 실행됩니다. 해당 그래프는 프로젝트의 품질 설정에서 게시할 수 있습니다. - 이전 환경 먼저 적용: 해당 릴리스는 반드시 이전에 배포된 환경에 먼저 배포되어야 합니다.
- 승인된 릴리스 노트: 현재 노트는 승인을 받아야 하며, 이후 수정 시에는 새로운 노트를 사용해야 합니다.
- 체크리스트: 릴리스 페이지에서 담당자가 확인하는 수동 단계로, 예를 들어 "데이터베이스 마이그레이션 검토 완료"와 같은 항목입니다. 항목을 필수 또는 선택 사항으로 지정할 수 있습니다. 필수 항목의 경우 일시적인 예외를 허용할 수도 있습니다. 소유자나 관리자는 예외 사유와 최대 24시간의 유효 기간을 기록하며, 이 예외는 해당 커밋 및 환경에만 적용됩니다.
- 긴급 수정 규칙: 긴급 수정을 위한 완화된 규칙으로, 승인 횟수와 이전 환경 및 노트 승인 여부가 적용됩니다. 품질 검사와 필수 체크리스트 항목은 항상 적용되며, 긴급 수정은 소유자와 관리자만 승인할 수 있습니다.
선택게시 규칙를 눌러 저장하세요. 규칙을 게시하면 새 버전이 생성됩니다. 이전 버전에서 부여된 승인은 더 이상 유효하지 않으므로 진행 중인 릴리스는 다시 승인을 요청합니다. 게시된 규칙이 없는 환경은 검사를 통과할 수 없으며, 화면에 해당 내용이 표시됩니다.
배포 파이프라인
Coroid가 배포 시작 시점과 결과를 어떻게 파악할까요?
상단에서 환경을 선택한 뒤 배포 방식을 지정하세요:
- 내 파이프라인이 자동으로 배포: 기존 프로세스를 그대로 유지합니다. Coroid는 CI/CD에서 배포 정보를 보고하거나, 소유자나 관리자가 릴리스 페이지에 외부 배포 내역을 기록할 때 배포 상황을 기록합니다.
- Coroid가 GitHub Actions 워크플로우를 시작또는Coroid가 GitLab CI/CD 파이프라인을 시작: 프로젝트 저장소가 해당 제공업체에 있을 때 표시됩니다. 릴리스 커밋을 가리키는 브랜치나 태그, GitHub용 워크플로우 파일, 배포를 담당하는 작업의 정확한 이름을 입력하세요. Coroid는 실행을 시작하기 전에 해당 ref를 확인하고, 성공으로 간주하기 전에 지정된 작업을 확인합니다.
다음 항목 아래에배포 보고서환경에 대한 보고서 생성 토큰을 만들어 CI/CD에 비밀로 저장하세요. Coroid는 해당 토큰을 한 번만 표시하며 해시값만 보관합니다. 토큰을 교체하면 기존 토큰은 즉시 무효화됩니다. 동일한 화면에는 파이프라인에서 필요한 엔드포인트, 프로젝트 ID, 환경 키가 표시되며 보고서 수신 여부도 확인할 수 있습니다.배포 이벤트 및 CI 설정에서는 이벤트 형식과 예시를 확인할 수 있습니다.
버전 관리
이번 릴리스의 버전은 무엇이며, 빌드는 어떻게 해당 버전을 적용하나요?
각 릴리스의 버전 출처를 선택할 수 있습니다. Coroid는 다음 버전을 자동으로 제안하고, Coroid는 저장소 내 파일에서 버전 정보를 읽어오며, 파이프라인에서 직접 버전을 보고하기도 합니다. 모든 릴리스에는 순차적으로 증가하는 빌드 번호가 부여됩니다. 해당 화면에는 Coroid가 파이프라인에 전달하는 값이 표시되며, 새 작업을 생성하여 해당 값을 빌드에 추가하도록 요청할 수 있습니다. 또한 각 환경별로 버전 URL을 지정하여 Coroid가 실행 중인 버전을 확인할 수 있도록 합니다.빌드에 버전 반영Docker에는 웹, 서버, iOS, Android 빌드에 대한 상세 정보와 절차가 포함되어 있습니다.
조직 간 설정 이전
설정 내보내기 및 가져오기 기능을 통해 환경, 순서, 파이프라인 구성, 버전 관리 정보, 버전 URL, 게시된 규칙(핫픽스 규칙 포함)을 이전할 수 있습니다. 단, 보고서 생성 토큰과 빌드 번호는 절대 내보내지 않습니다. 가져오기 후에는 새 토큰을 생성해야 하며, 각 프로젝트는 별도의 빌드 번호를 유지합니다.