릴리스가 운에 맡겨져서는 안 됩니다.

빌드 출처, 의존성, 접근 권한 경계

파이프라인은 외부 패키지, 빌드 도구, 그리고 흔히 광범위한 접근 권한을 다룹니다. 저희는 이러한 신뢰 체인을 파악하고, 신뢰할 수 없는 변경 사항의 검사를 프로덕션 권한이 있는 단계로부터 분리합니다. 실행 환경에는 제한된 권한과 확인 가능한 초기 상태가 필요합니다. 자격 증명은 통제된 방식으로 제공되며, 아티팩트나 빌드 로그에 노출되어서는 안 됩니다.

공개된 아티팩트에 대해서는 소스 코드 버전, 의존성, 완료된 검사 내역을 추적할 수 있어야 합니다. 구성 요소 목록은 이후 알려진 취약점을 평가하는 데 도움이 되지만, 이를 통해 악용 가능성이 자동으로 확인되는 것은 아닙니다. 서명과 출처 증빙은 이를 수신하는 환경에서도 검증할 때에만 효과가 있습니다. 따라서 저희는 생성, 저장, 검증 방식을 함께 정하고, 차단된 구성 요소나 침해된 접속 정보를 어떻게 처리할지 합의합니다.

데이터베이스 스키마와 애플리케이션 버전을 함께 배포하기

단계적 롤아웃에서는 이전 버전과 새 버전의 애플리케이션이 동시에 실행될 수 있습니다. 즉시 삭제된 데이터베이스 열이나 변경된 메시지 형식은 이전 버전을 손상시킬 수 있습니다. 따라서 저희는 호환 가능한 중간 상태를 계획합니다. 새로운 구조를 추가하고, 데이터를 통제된 방식으로 이전하며, 호출하는 쪽을 전환한 다음에야 더 이상 필요하지 않은 부분을 제거합니다. 백그라운드 작업과 외부 소비자도 이러한 검토에 포함됩니다.

기능 플래그는 기능의 배포와 활성화를 분리할 수 있습니다. 다만 명확한 책임 소재, 테스트 변형, 계획된 만료일이 필요합니다. 그렇지 않으면 가능한 상태의 수가 계속 늘어납니다. 각 승인마다 어떤 버전이 함께 작동하는지, 애플리케이션을 되돌리는 것이 여전히 허용되는지가 기록됩니다. 되돌릴 수 없는 데이터 변경에는 실행 파일 아티팩트를 단순히 교체하는 것과는 다른 전략이 필요합니다.

릴리스 신호와 개발 흐름 개선

기술적으로 성공한 배포가 곧 성공한 릴리스는 아닙니다. 릴리스 후 저희는 선정된 핵심 트랜잭션, 오류율, 응답 시간을 모니터링합니다. 단계적 롤아웃은 영향을 받는 사용자 범위를 제한할 수 있지만, 이를 위해서는 적합한 아키텍처와 의미 있는 측정 지점이 필요합니다. 중단 임계값과 책임자는 변경 전에 미리 정해 두어, 시간에 쫓기는 상황에서 기준을 새로 논의하지 않아도 되도록 합니다.

프로세스 개선을 위해 저희는 리뷰 대기 시간, 파이프라인 소요 시간, 잦은 중단, 실패한 변경 이후 복구에 드는 작업량을 살펴봅니다. 이 정보는 개별 개발자의 순위를 매기기 위한 것이 아니라 전체 흐름을 개선하기 위한 것입니다. 빌드가 짧아도 그 이후 승인 여부가 며칠씩 불분명하게 남아 있다면 큰 의미가 없습니다. 따라서 개발, 보안, 운영 부문이 함께 조치의 우선순위를 정하고, 실제 병목 지점을 기준으로 그 효과를 점검합니다.