검토 및 자동화

영구 환경 및 CI 검토

4단계 마법사로 공유 영구 환경을 만들고, CI 워크스페이스 프로필을 설정하고, 다섯 개의 CI 탭에서 병합 이벤트를 검토하고, 검증된 후보를 Console에서 승격합니다.

고객 관리자플랫폼 운영자

마지막 업데이트 2026년 6월 18일

영구 환경 및 CI 검토는 공유 검증을 위한 Console 소유 워크플로입니다. 고객이 오래 유지되는 QA, UAT, 데모, 스테이징 또는 클라이언트 검토 런타임을 필요로 하고 변경 사항을 승격하기 전에 코드 검토와 QA를 통과시키려 할 때 사용합니다.

이러한 워크플로는 개인 개발자 워크스페이스와 다릅니다. 영구 환경은 정책, 청구, 지원, 이벤트 기록이 있는 공유 고객 런타임입니다. CI 워크스페이스 프로필은 병합 이벤트에서 브라우저, 데이터베이스, 코드 인텔리전스 또는 대상 환경 확인이 필요할 때 Console이 사용하는 라우트 소유 검토 또는 QA 런타임 프로필입니다.

두 화면 모두 Console 왼쪽 레일에 있습니다. Environments는 공유 런타임과 그 후보를 소유하고, CI & Review는 라우트, 병합 이벤트, 실행, 공급자 핸드오프를 소유합니다. 두 화면은 서로 연결되어 있어 컨텍스트를 잃지 않고 환경과 그 검토 기록 사이를 이동할 수 있습니다.

시작하기 전에

• 환경과 CI 프로필을 만들려면 고객 관리자 또는 플랫폼 운영자 역할이 필요합니다.
• 검증하려는 리포지토리와 브랜치는 연결된 Git 공급자를 통해 도달할 수 있어야 합니다. 공급자 연결은 고객 관리자 설정을, 데이터베이스 시드는 백업 및 복원 소스를 참조하세요.
• 라우트가 소스 브랜치 전용인지 영구 환경을 대상으로 하는지 결정하세요. 그 선택에 따라 실행되는 확인 항목이 달라집니다.

영구 환경 만들기

Environments를 열고 Create environment를 선택합니다. Console은 상단에 단계 레일이 있는 4단계 마법사를 엽니다: Source, Runtime, Policy, Review. 오른쪽의 실시간 시작 패널에는 현재 선택 항목이 표시되고 아직 차단 중인 필수 항목이 나열됩니다.

1. Source. 고객 범위를 선택하고, 환경 이름을 지정하고, 리포지토리 URL과 소스 브랜치를 확인합니다. Console은 여기서 공급자 액세스를 확인합니다. 변경 사항이 둘 이상의 리포지토리에 의존하는 경우 리포지토리 스택을 활성화하여 런타임 리포지토리와 제품 리포지토리가 순서대로 체크아웃되도록 합니다.
2. Runtime. 영구 환경 프로필, 템플릿 패밀리, 워크스페이스 대상, 런타임 크기를 선택합니다. 프로필은 백업 워크스페이스에 대해 예상되는 Java, Gradle, Tomcat, 라이선스 번들을 포함하여 WebCentral 버전 가정을 설정합니다.
3. Policy. 시드 소스(데이터베이스 백업), 노출, 데이터베이스 마이그레이션 엔진을 설정합니다. 대상과 일치하는 마이그레이션 엔진을 선택합니다: Flyway, ARCHIBUS DUW 또는 마이그레이션 비활성화.
4. Review. 시작 계획을 확인합니다. 검토 그리드는 프로필, 리포지토리 모드, 크기, 데이터베이스 백업을 요약합니다. 필요한 모든 항목이 갖춰지면 Create environment를 선택합니다.

생성이 시작되면 Console은 환경 레코드를 만들고 선택한 대상이 지원하는 경우 백업 워크스페이스를 시작합니다. 그런 다음 환경 카드는 영구 워크스페이스, 후보 및 현재 버전, 환경 업데이트 상태, 런타임 바로 가기, 이벤트 기록을 표시합니다.

영구 환경은 개인 개발 워크스페이스보다 더 오래 켜진 상태를 유지하도록 설계되었습니다. 런타임 크기와 가격 기간을 신중하게 선택하고, 이벤트 기록을 사용하여 백업 워크스페이스, Tomcat 라우트, 데이터베이스 시드, 승격 상태가 언제 준비되는지 확인하세요.

소스 리포지토리 또는 WAR와 일치하는 WebCentral 버전 프로필을 사용하세요. 특히 현재 기본값 대신 Tomcat 8.5 또는 Tomcat 9가 필요한 이전 WebCentral 버전의 경우 그렇습니다. 이러한 프로필이 런타임 설정에 어떻게 매핑되는지는 워크스페이스 프리셋을 참조하세요.

환경 런타임 바로 가기 열기

영구 워크스페이스가 존재한 후에는 환경 카드 작업을 사용합니다:

원시 로그를 지원 티켓에 붙여넣지 마세요. 대신 표시되는 상태, 실행 ID, 워크스페이스 이름, 타임스탬프, 정제된 오류 텍스트를 공유하세요.

환경 런타임을 두 단계로 업데이트하기

후보 버전이 영구 런타임에 적용될 준비가 되면 Console은 공유 환경이 실수로 재시작되지 않도록 신중한 2단계 업데이트를 사용합니다.

1. Request environment update. 이는 영구 워크스페이스 업데이트를 승인하고 요청됨으로 표시합니다. Console은 업데이트가 시작할 준비가 되었지만 아직 실행 중인 환경을 건드리지 않았음을 표시합니다.
2. Start environment update. 이는 영구 워크스페이스 업데이트를 시작하고 런타임 결과를 기다립니다. Console은 상태를 실행 중으로 옮기고, 영구 런타임이 승격된 버전에 도달하면 적용됨으로 옮깁니다.

환경 카드는 현재 업데이트 상태와 각 단계에 대한 짧은 설명, 그리고 무엇이 변경되었는지 확인할 수 있는 런타임 증거 행을 표시합니다.

CI 워크스페이스 프로필 만들기

CI & Review를 열고 Create CI profile을 선택합니다(상단 작업 표시줄에서는 Create CI/profile입니다). Console은 동일한 단계 레일 형태의 4단계 마법사를 엽니다: Source, Runtime, Policy, Review. 작업 영역에서는 Source route, Workspace runtime, Run policy, Review and create로 표시됩니다.

1. Source route. 고객, 공급자, 리포지토리, 브랜치, 그리고 선택적 대상 환경을 선택합니다. 대상 환경을 선택하면 나중에 대상 확인이 켜집니다. 변경 사항에 런타임 리포지토리와 제품 또는 종속성 리포지토리가 필요한 경우 리포지토리 스택 프로필을 적용합니다.
2. Workspace runtime. 워크스페이스 형태를 선택합니다: review, QA, review plus QA 또는 destination QA. CI 템플릿, 워크스페이스 대상, 크기를 선택합니다.
3. Run policy. 보존, 아티팩트, 실행되는 단계, QA 범위, 데이터베이스 마이그레이션 엔진을 설정합니다. WebCentral 버전 프로필과 데이터베이스 백업을 선택합니다. 검토는 일반적으로 높은 추론을 사용하고, QA는 일반적으로 결정론적 확인이 증거를 수집한 후 낮은 추론을 사용합니다.
4. Review and create. 검토 그리드에서 라우트 프로필을 확인한 다음 Create CI profile을 선택합니다.

CI 워크스페이스 프로필을 저장해도 개인 개발자 워크스페이스가 만들어지지 않습니다. 병합 이벤트나 테스트 실행에 검토 또는 QA 워크스페이스가 필요할 때 Console이 사용하는 라우트 메타데이터를 만듭니다. 가벼운 실행은 브라우저, 데이터베이스, 코드 인텔리전스 도구가 필요하지 않은 경우 워크스페이스 없이 Console 러너를 계속 사용할 수 있습니다.

라우트에 대상 영구 환경이 없어도 Console은 소스 브랜치 QA를 실행할 수 있습니다. 코드 검토는 Console 병합 이벤트, 공급자 풀 리퀘스트 또는 명시적 diff에서 시작되므로 검토자가 실제 변경 세트와 병합 게이트를 볼 수 있습니다. 검증할 환경 구성이 없으므로 대상 환경 확인은 건너뜁니다.

다섯 개의 CI & Review 탭

CI & Review 작업 영역은 메인 패널 위에 다섯 개의 탭으로 구성되며, 각 탭에는 실시간 카운트가 있습니다:

탭 위에는 선택한 병합 이벤트의 단계 파이프라인을 보여주는 워크플로 스트립이 표시됩니다: Intake, Review, QA, Target QA, Merge. 각 단계는 open, waiting, skipped 또는 waiting on checks와 같은 자체 상태를 표시합니다.

소스 브랜치 전용 대 대상 환경

소스 브랜치 전용 라우트는 선택된 영구 환경 없이 코드 검토와 러너 QA를 실행합니다. 그 모드에서 Console은 의도적으로 대상 환경 확인을 건너뛰고 Target QA 단계는 skipped로 표시됩니다.

선택된 영구 환경이 있는 라우트는 대상 환경 확인을 추가합니다. 코드 검토와 러너 QA가 통과한 후 Console은 병합 또는 승격을 진행하기 전에 선택한 환경 기본값에 대해 후보를 검증합니다.

대상 환경 확인은 승격 후 중요한 환경 기본값을 사용합니다. 여기에는 데이터베이스 유형, 데이터베이스 백업, 마이그레이션 엔진, 워크스페이스 대상, 템플릿, 도구 체인, 워크스페이스 매개변수, 그리고 구성된 경우 라이선스 재정의가 포함됩니다.

라우트가 이전 WebCentral 버전을 사용하는 경우 영구 환경, 소스 QA 프로필, 대상 QA 프로필에서 동일한 버전 프로필을 유지하세요. 이렇게 하면 검토 증거, 브라우저 스모크 테스트, 최종 승격 확인이 동일한 런타임 가정에서 실행됩니다.

공급자 핸드오프 설정하기

Provider handoff 탭을 열고 라우트를 로드하여 관리형 공급자 연결을 등록하거나 확인합니다. Console은 검토 계층을 소유합니다. 공급자 연결을 통해 검토 및 QA 댓글을 게시하고, 상태 피드백을 보내고, 병합 이벤트를 수신할 수 있습니다.

이 탭에서 다음을 수행할 수 있습니다:

• 관리형 연결 저장. 공급자 앱, 서비스 후크 또는 token://..., k8s://secret/key, OpenBao/Vault 참조와 같은 승인된 자격 증명 참조를 등록합니다. Console은 일회성 공급자 토큰이나 앱 비밀번호를 수락하여 Console 토큰 저장소, Kubernetes Secret 또는 OpenBao/Vault에 저장할 수도 있습니다. 저장 후 Console은 자격 증명 미리 보기만 표시합니다.
• 자격 증명 교체. 토큰이 만료되거나 교체될 때 Rotate credential을 사용합니다. 그 후 연결 확인을 실행합니다.
• 자격 증명 취소. 연결 레코드를 유지하되 새 자격 증명 참조가 추가될 때까지 게시를 중지하려면 Revoke credential을 사용합니다.
• 웹훅 설치 또는 조정. 병합 이벤트 업데이트가 Console에 도달하도록 Install webhook을, 드리프트된 후크를 복구하려면 Reconcile webhook을, 이벤트를 중지하려면 Remove webhook을 사용합니다. 웹훅을 설치하기 전에 라우트를 저장하거나 선택하세요.
• 연결 확인. 검토, 상태 또는 댓글 게시를 위해 라우트에 의존하기 전에 Check connection을 사용하여 상태를 확인합니다.

준비 상태 패널은 라우트 메타데이터, 공급자 서비스, 설치 대상, 자격 증명 소스, 허용된 작업, Console 레코드, 공급자 상태를 차례로 안내하므로 어떤 단계가 아직 누락되었는지 확인할 수 있습니다.

공급자 토큰, 원시 자격 증명 페이로드, 비공개 배포 비밀을 라우트 이름, 설명, QA 메모 또는 라우트 지침에 넣지 마세요.

병합 이벤트 검토하기

병합 이벤트는 Console의 일반적인 검토 단위입니다. 병합 이벤트는 공급자 웹훅, 워크스페이스 핸드오프 또는 수동 Console 등록에서 발생할 수 있습니다.

1. CI & Review를 엽니다.
2. Merge events 탭에서 병합 이벤트를 선택합니다.
3. Review in Console을 열어 소스 브랜치, 대상 브랜치, 공급자 링크, 기능 항목, 검토자 목록, 스택된 변경 사항을 봅니다.
4. 검토자를 할당하거나 사용자 지정 검토자를 추가하고 검토자 메모를 업데이트합니다.
5. 라우트가 준비되면 Start review & QA를 선택합니다.
6. 워크플로 스트립을 관찰합니다: Intake, Review, QA, Target QA, Merge.

스택된 변경 사항이 감지되면 Console은 안전하게 표시할 수 있는 경계가 있는 스택 미리 보기와 파일별 컨텍스트를 표시합니다. 공급자 링크는 보조 컨텍스트로만 사용하세요.

Archibot 검토와 러너 QA는 별도로 또는 함께 실행할 수 있습니다. 검토는 코드, 스택 diff 컨텍스트, 누락된 테스트, 위험한 경로, 문서 영향에 중점을 둡니다. QA는 브라우저 스모크, 데이터베이스 확인, 선택한 테스트 명령, 도구 체인 검증, 워크스페이스 로그와 같은 실행 증거에 중점을 둡니다. Archibot 검토 및 QA 봇이 어떻게 구성되는지는 Console Bots를 참조하세요.

실행을 중지해야 하는 경우 Evidence and logs 탭의 실행에서 Cancel run을 사용합니다. Console은 실행을 취소됨으로 표시합니다.

병합 및 승격

Console은 사람에 의한 병합을 기본값으로 유지합니다.

Merge in Console을 사용할 수 있으려면:

• 검토자 승인이 기록되어 있어야 합니다.
• 요청된 코드 검토 단계가 통과해야 합니다.
• 요청된 러너 QA 단계가 통과해야 합니다.
• 대상 환경이 선택된 경우 대상 환경 확인이 통과해야 합니다.

병합이 완료된 후 검증된 후보는 선택한 영구 환경의 승격 후보가 될 수 있습니다. 최신 CI 실행과 대상 환경 확인이 후보 버전과 일치할 때만 Environments에서 Promote candidate를 사용하세요. 승격된 후에는 위에서 설명한 2단계 환경 업데이트를 사용하여 실행 중인 런타임에 적용합니다.

로그, 증거, Shared Drive

CI & Review와 Environments는 Console에 이벤트 기록을 보관합니다. Evidence and logs 탭의 실행 타임라인을 사용하여 단계 변경, 작업 이름, 대상 환경 상태, 정제된 로그 줄을 확인하세요.

일반적인 실행 로그 보존 기간을 넘어 지원팀이 증거를 필요로 할 때 Save to Shared Drive를 사용합니다. 이를 위해서는 계정에 쓰기 가능한 드라이브가 필요합니다. 오래 유지되는 증거는 정제되고 고객 승인을 받은 상태로 유지하세요. 범위가 지정된 드라이브 액세스가 어떻게 작동하는지는 워크스페이스 Archibot 및 Shared Drive를 참조하세요.

검토자는 병합하기 전에 Console에서 세 가지 질문에 답할 수 있어야 합니다:

• 스택된 diff를 포함하여 무엇이 변경되었는가?
• 어떤 검토, QA, 대상 확인이 실행되었는가?
• 나중에 실행에 지원 검토가 필요한 경우 정제된 증거는 어디에 있는가?

공유하지 마세요:

• API 키, 공급자 토큰, 웹훅 비밀, 쿠키 또는 초대 링크.
• Kubernetes Secret, Pod 환경 변수, kubeconfig 또는 Coder 토큰.
• 원시 데이터베이스 URL, 원시 백업 내용 또는 라이선스 파일.
• 비공개 대화 기록 또는 고객 데이터 덤프.

일반적인 차단 요인

지원 핸드오프

지원을 위해 다음을 포함하세요:

• 고객 계정과 환경 이름.
• 병합 이벤트 ID 또는 CI 실행 ID.
• 소스 브랜치, 대상 브랜치, 표시되는 경우 공급자 병합 요청 번호.
• 차단된 단계.
• 정제된 Console 오류 또는 로그 요약.

원시 자격 증명, 비밀이 포함된 전체 로그, 비공개 데이터베이스 데이터 또는 일회성 링크를 포함하지 마세요. 전체 증거 체크리스트는 지원 핸드오프를 참조하세요.