환경 이해
파이프라인을 사용하면 배포 프로세스의 단계를 자동화할 수 있습니다. 여러 개별 환경에서 단계를 실행해야 하는 경우가 있습니다. 완구 회사에서 프로덕션 환경에 변경 내용을 배포하기 전에 코드 변경 내용을 검토하려고 합니다.
본 단원에서는 Azure Pipelines 환경에서 사용자의 워크플로를 지원하는 방법에 대해 알아봅니다.
여러 환경이 있는 이유는 무엇인가요?
배포 프로세스는 사용 중인 리소스를 포함한 Azure 리소스를 변경합니다. 리소스를 변경하면 배포하는 변경 내용이 예상과 다르게 작동할 수 있으므로 위험이 있습니다. 변경 내용으로 인해 현재 설정이 중단될 수도 있습니다.
문제가 발생할 위험을 최소화하려면 변경 내용을 프로덕션 환경에 배포하기 전에 안전한 방법으로 시험해 보는 것이 좋습니다. 예를 들어 비프로덕션 환경에 변경 내용을 배포할 수 있습니다.
많은 조직에서는 여러 비프로덕션 환경을 구축하여 변경 내용을 프로덕션 환경에 릴리스하기 전에 이러한 환경에 점진적으로 배포합니다. 각 비프로덕션 환경마다 수행하는 목적이 다르며, 특정 품질 기준을 충족해야 다음 환경으로 진행할 수 있습니다. 테스트 실패와 같은 문제가 발생 하면 배포가 중지됩니다. 배포가 각 환경을 따라 진행함에 따라 변경 사항에 대한 신뢰도가 증가합니다.
일반적인 환경은 다음과 같습니다.
개발: 개발 환경은 일반적으로 개발자가에서 변경 내용을 시험해 보고 작업을 빠르게 반복하는 데 사용됩니다.
개발 환경에는 팀 멤버가 아이디어를 쉽게 시험해 볼 수 있도록 최소의 컨트롤이 포함되어 있는 경우가 많습니다. 개발 환경을 사용하여 리소스에 대한 특정 구성 설정을 테스트하거나, 안전한 방식으로 백 엔드 데이터베이스를 사용하여 새 웹 사이트를 설정하는 방법을 확인할 수 있습니다. 성공하지 못한 아이디어가 제거되기 때문에 이러한 변경 내용과 평가판은 배포 프로세스에서 진행되지 않을 수 있습니다.
일부 팀에서는 팀원들이 새 기능에 대한 작업을 하는 동안 서로에게 방해가 되지 않도록 각 팀원마다 별도의 개발 환경을 설정할 수도 있습니다.
개발 환경을 샌드박스 환경이라고도 합니다.
테스트: 테스트 환경은 변경 내용에 대해 수동 또는 자동화된 테스트를 실행하도록 설계되었습니다.
연속 통합 프로세스에서 테스트 환경을 사용할 수 있습니다. 테스트 환경에 대한 변경 내용을 배포한 후 그에 대해 자동화된 테스트를 실행할 수 있습니다. 모든 자동화된 테스트에 통과하면 변경 내용을 프로젝트의 기본 분기에 통합할 수 있습니다. 자동화된 테스트는 일반적으로 새로 배포된 리소스의 정책 위반과 같은 항목과 함께 코어 시스템 기능을 점검합니다.
성능 및 보안 테스트와 같은 특정 유형의 테스트에 대한 테스트 전용 환경을 만들 수도 있습니다.
통합: 통합 환경에서는 다른 시스템과의 통합 지점을 테스트할 수 있습니다.
통합 환경에서 엔드투엔드 트랜잭션을 시뮬레이션할 수 있습니다. 이러한 테스트는 보통 자동으로 실행되지만 많은 조직에서는 이 환경에 대한 수동 테스트도 수행합니다.
통합 환경을 SIT(시스템 통합 테스트) 환경이라고도 합니다.
사용자 승인 테스트: UAT(사용자 승인 테스트) 환경은 수동 유효성 검사에 사용되며, 일반적으로 개발자가 아닌 비즈니스 관련자가 수행합니다. 수동 유효성 검사에서는 한 사람이 솔루션을 진행하고 예상대로 작동하는지 확인하고 필요한 비즈니스 요구 사항을 충족하는지 확인합니다. 그런 다음 배포를 계속할 수 있도록 변경 내용을 승인합니다.
사전 프로덕션: 사전 프로덕션 환경은 리소스 SKU 및 구성이 동일한 프로덕션 환경의 미러인 경우가 많습니다. 변경 내용이 적용되는 중과 그 후에 프로덕션 배포가 어떻게 동작하는지 확인 하기 위한 최종 검사로 사용됩니다. 프로덕션 배포 시 가동 중지 시간을 예측할 수 있는지 여부를 확인하는 데 사용할 수도 있습니다.
프로덕션 전의 환경을 ‘스테이징’ 환경이라고도 합니다.
프로덕션: 프로덕션 환경은 애플리케이션의 최종 사용자가 사용하는 환경입니다. 안전하게 보호하고 최대한 가동 및 실행하고자 하는 라이브 환경입니다.
일부 조직에는 프로덕션 환경이 여러 개 있을 수 있습니다. 예를 들어 여러 지리적 지역에 프로덕션 환경이 있거나 여러 고객 그룹에게 서비스를 제공하고 있을 수 있습니다.
데모: 팀이 최종 사용자에게 애플리케이션을 표시하거나, 교육에 사용하거나, 영업 팀이 잠재 고객에게 특정 기능을 표시하는 데모 환경을 만들 수도 있습니다. 각기 다른 용도로 사용되는 여러 데모 환경을 만들 수도 있습니다. 데모 환경은 일반적으로 가상의 고객 데이터를 포함하는 프로덕션 환경의 축소 복제본입니다.
조직의 환경
이러한 환경의 여러 변형이 있을 수 있습니다. 몇 가지 환경만 사용하는 조직도 있고, 훨씬 많은 환경을 사용하는 조직도 있습니다. 사용하는 환경의 수와 유형은 배포하는 솔루션, 솔루션을 빌드하는 팀의 규모, 워크 로드의 중요도에 따라 달라집니다.
하나의 환경이 앞에 나열된 여러 환경의 역할을 수행하는 경우도 있습니다. 일부는 동시에, 일부는 순차적으로 여러 환경에 배포하는 복잡한 파이프라인이 있을 수 있습니다. 일부 조직에서는 더 이상 사용 되지않는 환경을 자동으로 삭제하거나 프로비저닝을 해제하고 나중에 필요할 때 다시 배포합니다.
조직이 환경 목록으로 선택하는 것과 관계없이, 배포 파이프라인을 따라 진행되면서 변경 사항의 신뢰도를 높이는 것이 목표입니다. 변경 사항이 품질 요구 사항을 충족하지 않는 경우 해당 변경 사항을 체인 내 모든 후속 환경에 배포하는 작업을 중지할 수 있습니다.
완구 회사에서 웹 사이트에 대한 기본 환경 집합으로 시작하기로 결정했습니다. 프로덕션 환경 외에도 ‘Test’라는 비프로덕션 환경을 만듭니다.
Bicep 코드를 테스트 환경에 배포하고 이에 대한 몇 가지 기본 테스트를 실행하도록 파이프라인을 업데이트합니다. 이 작업이 완료되면 코드가 프로덕션 환경에 배포됩니다.
파이프라인 환경
Azure Pipelines에도 환경의 개념이 있습니다. Azure에 보유한 환경을 나타내는 Azure Pipelines 환경을 만듭니다. YAML 파일에서 파이프라인을 정의하는 경우 배포 작업을 특정 환경에 연결합니다. 환경을 사용하여 파이프라인에서 몇 가지 추가 기능을 확보할 수 있습니다.
검사 및 승인
Azure DevOps의 환경에는 검사 및 승인이 구성되어 있을 수 있습니다. 파이프라인 내 작업에서 환경이 사용될 때마다 Azure DevOps는 작업 실행이 시작되기 전에 이러한 검사 및 승인이 완료되도록 합니다.
예를 들어 프로덕션 환경에서 수동 승인을 구성할 수 있습니다. 프로덕션 배포가 시작되기 전에, 지정된 승인자에게 이메일 알림이 전송됩니다. 승인자는 배포가 시작되기 전에 정책과 절차를 준수했는지 수동으로 확인할 수 있습니다. 예를 들어 승인자는 배포를 승인하기 전에 사전 프로덕션 환경에서 모든 것이 제대로 작동하는지 확인할 수 있습니다.
또한 자동화된 검사를 실행하여 최근 배포 후 사전 프로덕션 환경에서 로그 및 오류 비율을 검토할 수 있습니다. 검사를 통해 오류 수가 크게 증가하지 않았음이 확인되면 배포를 진행할 수 있습니다.
배포 기록
Azure Pipelines는 환경에 대한 배포 기록을 추적합니다. 이 기록을 통해 환경에서 시간이 지남에 따라 발생하는 상황을 쉽게 추적할 수 있습니다. 또한 Azure Boards 작업 항목의 특정 기능 요청 또는 리포지토리의 커밋에 대한 배포를 추적할 수 있습니다. 이 기능은 배포에 문제가 발생하여 문제를 일으킨 변경 사항을 파악해야 하는 경우에 유용할 수 있습니다.
보안
환경에 추가적인 보안 제어를 적용할 수 있습니다. 특정 환경을 사용하도록 허용된 파이프라인을 제한할 수 있습니다. 아니면 누군가가 실수로 제품 환경과 상호작용하는 2차 파이프라인을 만들지 못하게 방지할 수 있습니다.
사용자 권한을 적용하여 환경을 관리할 수 있는 사용자를 제어할 수도 있습니다. 구체적인 권한을 통해 사용자는 새 환경을 만들고, 환경을 수정하고, 환경과 그에 대한 배포 기록을 볼 수 있습니다.
참고
파이프라인이 아직 존재하지 않는 환경을 참조하는 경우 Azure Pipelines에서 자동으로 생성됩니다. 환경에 대한 관리 권한을 자동으로 얻을 수 있으므로 이 기능은 Azure DevOps 프로젝트의 보안에 영향을 줄 수 있습니다. Azure DevOps 웹 인터페이스를 통해 환경을 직접 만드는 것이 가장 좋습니다. 따라서 보안을 완벽하게 제어하고 필요하지 않은 권한이 실수로 부여되지 않습니다.
환경에 배포 작업 연결
배포 파이프라인 정의에서 배포 작업을 지정하는 deployment 속성을 만들고 작업이 배포하는 환경의 이름을 지정합니다.
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
예제에서 DeployWebsite 작업은 Test 환경에 연결됩니다.
팁
작업에는 이 모듈의 범위를 벗어나는 배포 전략을 비롯한 다른 속성도 있습니다. 요약 단원에서 자세한 정보 링크를 제공합니다.
환경 및 서비스 연결
여러 환경을 사용 하는 경우 각 환경을 다른 환경과 독립적으로 만들어야 합니다. 예를 들어, 개발 환경의 웹 사이트는 프로덕션 환경 내에서 데이터베이스에 액세스할 수 없습니다.
배포 파이프라인에도 동일한 원칙이 적용됩니다. 개발 환경에 배포하는 데 사용하는 서비스 연결에서 프로덕션 환경에 액세스할 수 없어야 합니다. 이 원칙에 따라 보호 계층을 추가하여 비프로덕션 배포가 프로덕션 환경에 영향을 주지 않도록 합니다.
각 환경에 대해 별도의 서비스 연결을 만들어야 합니다. 각 서비스 연결은 해당 환경에서 사용하는 구독 및 리소스 그룹에만 배포하는 특정 권한이 있는 전용 서비스 주체를 사용해야 합니다.
중요
배포하려는 각 환경마다 별도의 서비스 주체 및 서비스 연결을 사용합니다. 서비스 주체에게만 해당 환경에 배포하는 데 필요한 최소 권한을 부여합니다.
Azure에서 환경을 분리하는 것도 좋습니다. 최소한 각 환경마다 별도의 리소스 그룹을 만들어야 합니다. 대부분의 경우 각 환경마다 별도의 Azure 구독을 만드는 것이 좋습니다. 그러면 각 환경의 구독 내에서 여러 리소스 그룹을 만들 수 있습니다.
사용자와 서비스 주체가 액세스해야 하는 환경에만 액세스할 수 있도록 Azure 역할 할당을 적용합니다. 그리고 프로덕션 환경에 대한 액세스를 소수의 사용자 및 해당 환경에 대한 배포 서비스 주체로 제한해야 합니다.