테스트 자동화 및 전달 파이프라인

소프트웨어 및 서비스의 지속적 배포와 제공 방법에 관해 알아보았지만, 사실 이 둘은 세 개 요소 중 두 개에 해당합니다. DevOps 사례는 지속적인 통합, 전달 및 배포를 달성하기 위한 것입니다. 이러한 사례는 일반적으로 해당 순서대로 빌드되며, 각 사례는 이전의 사례에 따라 달라집니다.

이제 백업한 다음, 첫 번째 요소인 통합을 논할 차례입니다. 통합은 배포 전에 제공되는 개발 프로세스의 일부입니다. DevOps는 팀 멤버가 단일 “주” 또는 “트렁크” 코드베이스를 포함하는 공유 리포지토리에 코드를 자주 통합하는 개발 방법을 권장합니다. 목표는 모든 사람이 배포될 코드에 기여하는 것이며, 각자 별도의 복사본에서 작업하다가 마지막 순간에 모든 것을 한 번에 모으는 것을 피하는 것입니다.

그러면 자동화된 테스트로 각 팀 멤버의 통합을 확인할 수 있습니다. 이러한 테스트는 변경 및 추가 작업을 수행할 때마다 코드가 “정상” 상태인지 확인하는 데 도움이 됩니다. 테스트는 일반적으로 파이프라인이라고 하는 작업의 일부입니다. 이 단원의 나머지 부분에서는 통합 테스트 및 배달 파이프라인에 중점을 둡니다.

지속적인 전달 파이프라인

지속적인 전달 배포 모델에서 자동화된 테스트의 역할을 이해하려면 전달 파이프라인에 맞는 위치를 확인해야 합니다. 지속적인 업데이트 파이프라인은 개발 프로세스 중에 변경 내용이 프로덕션 환경에 배포되기 전 수행되는 단계 코드 세트의 구현입니다. 다음은 간소화된 전달 파이프라인의 샘플 단계를 그래픽으로 나타낸 것입니다.

이 파이프라인을 단계별로 안내합니다.

• 파이프라인의 인스턴스는 끌어오기 요청을 사용하여 코드 또는 인프라 변경 사항이 코드 리포지토리로 커밋될 때 시작됩니다.

• 다음으로 단위 테스트가 실행되고 통합 또는 엔드 투 엔드 테스트가 자주 수행됩니다. 결과는 끌어오기 요청을 연 개발자에게 다시 전달됩니다.

• 이 단계에서는 리포지토리의 코드에서 비밀, 취약성 및 잘못된 구성을 검색하는 경우가 많습니다.

• 모든 항목이 확인되면 코드가 빌드되고 배포용으로 준비됩니다.

• 그런 다음 코드가 테스트 환경에 배포됩니다. 사전 프로덕션 솔루션을 검사할 수 있도록 검토자에게 새 배포에 대한 알림을 받을 수 있습니다. 그런 다음 검토자는 프로덕션으로의 승격을 승인하거나 거부합니다. 그러면 프로덕션에 코드를 릴리스하는 배포 프로세스의 마지막 부분이 시작됩니다.

이 파이프라인에서 통합과 배포 사이의 설명을 볼 수 있습니다. 강조 표시된 표식은 포함된 논리 및 자동화 또는 잠재적으로 사람의 개입을 통해 파이프라인을 중지할 수 있는 몇 가지 논리적 위치를 가리킵니다.

지속적인 통합 및 전달을 위한 도구: Azure Pipelines 및 GitHub Actions

연속 통합 및 지속적인 업데이트를 사용하려면 올바른 도구가 필요합니다. Microsoft Azure 빌드 및 배포하기 위한 두 가지 자사 CI/CD 옵션인 Azure Pipelines(Azure DevOps 일부) 및 GitHub Actions을 제공합니다. 둘 다 코드 빌드 및 일관성 테스트를 자동화할 수 있으며 둘 다 클라우드 및 온-프레미스의 Azure 서비스, 가상 머신 및 기타 대상에 배포할 수 있습니다. 소스 코드가 이미 GitHub 있는 경우 많은 팀이 GitHub Actions 채택하는 반면, Azure Pipelines 여전히 Azure DevOps 표준화된 팀에게 강력한 선택입니다.

이 단원의 나머지 부분에서는 Azure Pipelines 중점을 두지만, 용어가 다르더라도 GitHub Actions 비슷한 수준의 아이디어를 사용합니다. GitHub Actions 워크플로에는 작업 및 단계가 포함되며, 액션은 재사용 가능한 자동화를 패키지하고, 실행기는 작업을 실행하며, 환경은 배포를 보호할 수 있습니다.

파이프라인(코드 또는 구성)에 대한 입력은 GitHub 또는 다른 Git 공급자와 같은 버전 제어 시스템에 상주합니다.

Azure Pipelines 가상 머신 또는 컨테이너와 같은 컴퓨팅에서 실행되며 Windows, Linux 및 macOS를 실행하는 Microsoft 호스팅 빌드 에이전트를 제공합니다. 빌드 환경에 대한 모든 권한이 필요한 경우 자체 호스팅 에이전트를 등록할 수도 있습니다. 테스트, 보안 및 코드 품질 플러그 인과의 통합도 제공합니다. 마지막으로 쉽게 확장할 수 있으므로 고유한 자동화를 Azure Pipelines 가져올 수 있습니다.

파이프라인은 Git 리포지토리의 코드와 함께 저장된 YAML 구문을 사용하여 정의됩니다. YAML 파이프라인은 새 프로젝트에 권장되는 방법입니다. Azure DevOps 클래식 사용자 인터페이스는 레거시 파이프라인에도 사용할 수 있지만 대부분의 새로운 기능(컨테이너 작업 및 많은 고급 기능 포함)은 YAML 전용입니다. 또한 파이프라인은 Docker 이미지 또는 Node.js 프로젝트의 템플릿과 같이 파이프라인을 쉽게 만드는 데 사용할 수 있는 템플릿을 제공합니다. 기존 YAML 파일을 다시 사용할 수도 있습니다.

파이프라인을 설정하기 위한 기본 단계는 다음과 같습니다.

1. Git 리포지토리를 사용하도록 Azure Pipelines 구성합니다.
2. azure-pipelines.yml 파일을 편집하여 빌드를 정의합니다(또는 레거시 파이프라인의 경우 클래식 편집기를 사용하여).
3. 코드를 버전 제어 리포지토리로 푸시합니다. 이 작업은 파이프라인을 트리거하여 코드를 빌드하고 테스트합니다.

코드를 업데이트, 빌드 및 테스트한 후에는 원하는 모든 대상에 배포할 수 있습니다.

Azure 파이프라인 생성

파이프라인은 다음으로 구성됩니다.

• 작업: 작업은 단일 빌드 에이전트에서 실행되는 작업 또는 단계의 그룹화입니다. 작업은 실행을 예약할 수 있는 가장 작은 작업 구성 요소입니다. 한 작업의 모든 단계는 순차적으로 실행됩니다. 이러한 단계는 소프트웨어 빌드 또는 컴파일, 테스트를 위한 샘플 데이터 준비, 특정 테스트 실행 등을 포함하여 필요한 모든 작업일 수 있습니다.

• 단계: 스테이지는 관련 작업의 논리적 그룹화입니다.

모든 파이프라인에는 적어도 한 개의 단계가 있습니다. 여러 단계를 사용하여 파이프라인을 주요 부분으로 구성하고 파이프라인에서 확인을 일시 중지하고 수행할 수 있는 지점을 표시합니다.

파이프라인은 필요에 따라 단순하거나 복잡할 수 있습니다. Azure DevOps의 Build applications with 학습 경로를 참조하여 파이프라인 생성 및 사용에 대한 자습서를 확인하세요.

환경 추적 가능성

안정성과 관련하여 파이프라인의 다른 한 가지 측면이 있습니다. 특정 빌드 인스턴스와 함께 프로덕션에서 실행되는 항목과 상관관계를 지정할 수 있는 방식으로 파이프라인을 구성할 수 있습니다. 이상적으로 빌드를 특정 끌어오기 요청 또는 코드 변경으로 다시 추적할 수 있어야 합니다. 이 추적성은 인시던트 중에 중요하며, 이후에 문제에 기여한 변경 사항을 식별하려고 할 때 인시던트 후 검토 중에 중요합니다. 일부 CI/CD 시스템(예: Azure Pipelines 및 GitHub Actions)은 이 상관 관계를 간단하게 만드는 반면, 다른 CI/CD 시스템은 모든 단계를 통해 빌드 ID를 전파하는 파이프라인을 수동으로 생성해야 합니다.