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

소프트웨어 및 서비스의 지속적 배포와 제공 방법에 관해 알아보았지만, 사실 이 둘은 세 개 요소 중 두 개에 해당합니다. DevOps 사례는 지속적인 통합, 배포 및 제공을 달성하기 위한 것입니다.

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

그러면 자동화된 테스트로 각 팀 멤버의 통합을 확인할 수 있습니다. 이러한 테스트는 변경 및 추가 작업을 수행할 때마다 코드가 “정상” 상태인지 확인하는 데 도움이 됩니다. 테스트는 파이프라인 호출에 포함됩니다. 이 단원은 통합된 테스트 및 전달 파이프라인에 중점을 두므로 잠시 후 파이프라인에 대해 설명하겠습니다.

지속적인 업데이트 파이프라인

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

이 파이프라인을 단계별로 살펴보겠습니다.

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

• 그런 다음 통합 테스트 또는 엔드투엔드 테스트와 같은 단위 테스트가 실행되고, 이상적으로는 이러한 테스트 결과가 요청 당사자에게 다시 전달됩니다.

• 아마도 이 시점에서 리포지토리의 코드에서 비밀, 취약성 및 구성 측면이 검사됩니다.

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

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

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

연속 통합 및 지속적인 업데이트용 도구: Azure Pipelines

연속 통합 및 지속적인 업데이트를 사용하려면 올바른 도구가 필요합니다. Azure Pipelines은 코드 작성 및 일관된 테스트를 자동화하는 데 사용할 수 있는 Azure DevOps Services의 일부입니다. 또한 Azure Pipelines를 사용하여 클라우드와 온-프레미스에서 모두 Azure 서비스, 가상 머신 및 기타 대상에 코드를 배포할 수 있습니다.

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

Azure Pipelines는 가상 머신 또는 컨테이너와 같은 컴퓨팅 부분에서 실행되고, Windows, Linux 및 macOS를 실행하는 빌드 에이전트를 제공합니다. 또한 테스트, 보안 및 코드 품질 플러그인과 통합됩니다. 마지막으로 쉽게 확장할 수 있으므로 사용자 고유의 자동화를 Azure Pipelines로 가져올 수 있습니다.

파이프라인은 YAML 구문을 사용하거나 Azure Portal의 클래식 사용자 인터페이스를 통해 정의됩니다. YAML 파일을 사용하는 경우 코드와 함께 해당 파일을 저장할 수 있습니다. 파이프라인은 또한 Docker 이미지 또는 Node.js 프로젝트를 빌드하는 파이프라인처럼 파이프라인을 쉽게 만드는 데 사용할 수 있는 템플릿을 제공합니다. 기존 YAML 파일을 다시 사용할 수도 있습니다.

YAML 파일을 사용하든 클래식 인터페이스를 사용하든, 다음과 같은 기본 단계를 따릅니다.

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

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

클래식 인터페이스를 통해서만 사용할 수 있는 작업 그룹과 같은 YAML 및 다른 작업을 사용하는 경우에만 사용할 수 있는 컨테이너 작업 실행 등의 몇 가지 기능이 있습니다.

Azure Pipeline 구성

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

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

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

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

파이프라인은 원하는 만큼 단순하거나 복잡할 수 있습니다. Azure DevOps 학습 경로를 사용하여 빌드 애플리케이션에서 파이프라인 생성 및 사용에 대한 훌륭한 자습서가 있습니다.

환경 추적 가능성

안정성과 관련하여 파이프라인의 다른 한 가지 측면이 있습니다. 특정 빌드 인스턴스와 함께 프로덕션에서 실행되는 항목과 상관관계를 지정할 수 있는 방식으로 파이프라인을 구성할 수 있습니다. 특정 PR 또는 코드 변경으로 빌드를 다시 추적할 수 있어야 합니다. 이는 문제에 적용된 변경 내용을 확인하려고 할 때 인시던트 중이나 인시던트 후 검토 중에 크게 유용할 수 있습니다. 일부 CI/CD 시스템(예: Azure Pipelines)을 사용하면 이 작업을 쉽게 수행할 수 있는 반면, 다른 시스템에서는 모든 스테이지에 걸쳐 일종의 “빌드 ID”를 전달하는 파이프라인을 수동으로 구성해야 합니다.