DevOps (디브옵스)

소프트웨어 컨설턴트가 가장 좋아하는 진언은 제기 된 질문에 "의존한다"고 대답하는 것입니다. 소프트웨어 컨설턴트가 자리를 차지하지 않는 것을 좋아하기 때문이 아닙니다. 소프트웨어의 질문에 대한 진정한 대답은 아무도 없기 때문입니다. 절대적인 옳고 그름은 없지만, 오히려 반대의 균형이 있습니다.

예를 들어 웹 애플리케이션 개발의 두 가지 주요 학교인 SPA(단일 페이지 애플리케이션) 및 서버 쪽 애플리케이션을 살펴보세요. 한편, 사용자 환경은 SPA를 사용하는 것이 더 나은 경향이 있으며 웹 서버에 대한 트래픽 양을 최소화하여 정적 호스팅처럼 간단한 것으로 호스트할 수 있습니다. 반면에 SPA는 개발 속도가 느리고 테스트하기가 더 어려운 경향이 있습니다. 어떤 것이 올바른 선택입니까? 글쎄, 그것은 당신의 상황에 따라 달라집니다.

클라우드 네이티브 애플리케이션은 동일한 이분법의 면역성이 없습니다. 개발 속도, 안정성 및 확장성 측면에서 명확한 장점이 있지만 관리하기가 훨씬 더 어려울 수 있습니다.

몇 년 전만 해도 개발에서 프로덕션으로 애플리케이션을 이동하는 프로세스가 한 달 이상 걸리는 것은 드문 일이 아니었습니다. 회사는 6개월 또는 매년 주기로 소프트웨어를 출시했습니다. 예전 Windows 10의 지속적인 업데이트 이전에 받아들여졌던 출시 주기를 이해하기 위해서는 Microsoft Windows 예를 보면 충분합니다. Windows XP와 Vista 사이에 5년이 지났고, Vista와 Windows 7 사이에 3년이 더 지났습니다.

소프트웨어를 빠르게 출시할 수 있다는 것은 빠르게 움직이는 회사들이 상대적으로 느린 경쟁업체들에 비해 큰 시장 우위를 점할 수 있다는 것이 이제 꽤 확립되었습니다. 이러한 이유로 Windows 10의 주요 업데이트는 이제 약 6개월마다 업데이트됩니다.

비즈니스에 가치를 제공하기 위해 더 빠르고 신뢰할 수 있는 릴리스를 가능하게 하는 패턴과 사례를 DevOps라고 합니다. 애플리케이션을 지정하는 것부터 해당 애플리케이션을 제공하고 운영하는 것까지 전체 소프트웨어 개발 수명 주기에 걸쳐 다양한 아이디어로 구성됩니다.

DevOps는 마이크로 서비스 전에 등장했으며 DevOps가 프로덕션에서 애플리케이션 하나뿐 아니라 많은 애플리케이션을 더 쉽게 릴리스하고 작동하도록 하려면 DevOps가 없었다면 더 작고 목적에 더 적합한 서비스를 향한 이동이 가능하지 않았을 것입니다.

그림 10-1 - DevOps 및 마이크로 서비스.

좋은 DevOps 사례를 통해 실제로 애플리케이션을 운영하는 작업의 산 아래에서 질식하지 않고 클라우드 네이티브 애플리케이션의 장점을 실현할 수 있습니다.

DevOps에는 황금 망치가 없습니다. 고품질 애플리케이션을 릴리스하고 운영하기 위한 완전하고 포괄적인 솔루션을 판매할 수 있는 사람은 아무도 없습니다. 이는 각 애플리케이션이 다른 모든 애플리케이션과 크게 다르기 때문입니다. 그러나 DevOps를 훨씬 덜 어려운 제안으로 만들 수 있는 도구가 있습니다. 이러한 도구 중 하나를 Azure DevOps라고 합니다.

Azure DevOps

Azure DevOps에는 긴 혈통이 있습니다. Team Foundation Server가 처음 온라인으로 이동한 시점과 다양한 이름 변경(Visual Studio Online 및 Visual Studio Team Services)을 통해 그 뿌리를 추적할 수 있습니다. 그러나 수년간 그것은 이전 버전들보다 훨씬 뛰어나게 되었다.

Azure DevOps는 다음과 같은 5가지 주요 구성 요소로 나뉩니다.

그림 10-2 - Azure DevOps.

Azure Repos - TFVC(Team Foundation Version Control) 및 업계에서 가장 선호하는 Git을 지원하는 소스 코드 관리입니다. 끌어오기 요청은 변경 내용에 대한 논의를 촉진하여 소셜 코딩을 가능하게 하는 방법을 제공합니다.

Azure Boards - 사용자가 가장 적합한 워크플로를 선택할 수 있도록 하는 문제 및 작업 항목 추적 도구를 제공합니다. 스크럼 및 Kanban 스타일의 개발을 지원하는 템플릿을 포함하여 미리 구성된 여러 템플릿이 함께 제공됩니다.

Azure Pipelines - Azure 와의 긴밀한 통합을 지원하는 빌드 및 릴리스 관리 시스템입니다. 빌드는 Windows에서 Linux, macOS에 이르는 다양한 플랫폼에서 실행할 수 있습니다. 빌드 에이전트는 클라우드 또는 온-프레미스에서 프로비전될 수 있습니다.

Azure 테스트 계획 - 테스트 계획 기능에서 제공하는 테스트 관리 및 예비 테스트 지원을 통해 QA 담당자가 남아 있지 않습니다.

Azure Artifacts - 회사에서 자체, 내부, NuGet 버전, npm 등을 만들 수 있는 아티팩트 피드입니다. 중앙 집중식 리포지토리의 오류가 있는 경우 업스트림 패키지의 캐시 역할을 하는 이중 용도로 사용됩니다.

Azure DevOps의 최상위 조직 구성 단위를 프로젝트라고 합니다. 각 프로젝트 내에서 Azure Artifacts와 같은 다양한 구성 요소를 켜고 끌 수 있습니다. 이러한 각 구성 요소는 클라우드 네이티브 애플리케이션에 대해 서로 다른 이점을 제공합니다. 가장 유용한 세 가지는 리포지토리, 보드 및 파이프라인입니다. 사용자가 GitHub와 같은 다른 리포지토리 스택에서 소스 코드를 관리하지만 여전히 Azure Pipelines 및 기타 구성 요소를 활용하려는 경우 완벽하게 가능합니다.

다행히 개발 팀은 리포지토리를 선택할 때 많은 옵션을 제공합니다. 그 중 하나는 GitHub입니다.

GitHub Actions (GitHub 액션)

2009년에 설립된 GitHub는 프로젝트, 설명서 및 코드를 호스팅하는 데 널리 사용되는 웹 기반 리포지토리입니다. Apple, Amazon, Google 및 주류 기업과 같은 많은 대형 기술 회사에서 GitHub를 사용합니다. GitHub는 Git이라는 오픈 소스 분산 버전 제어 시스템을 기본으로 사용합니다. 그런 다음 결함 추적, 기능 및 끌어오기 요청, 작업 관리 및 각 코드 베이스에 대한 wiki를 비롯한 고유한 기능 집합을 추가합니다.

GitHub가 발전함에 따라 DevOps 기능도 추가되고 있습니다. 예를 들어 GitHub에는 자체 CI/CD(연속 통합/지속적인 업데이트) 파이프라인이 있습니다 GitHub Actions. GitHub Actions는 커뮤니티 기반 워크플로 자동화 도구입니다. 이를 통해 DevOps 팀은 기존 도구와 통합하고, 새 제품을 혼합 및 일치시키고, 기존 CI/CD 파트너를 포함하여 소프트웨어 수명 주기에 연결할 수 있습니다."

GitHub에는 4,000만 명 이상의 사용자가 있으며, 이는 세계에서 가장 큰 소스 코드 호스트입니다. 2018년 10월에 Microsoft는 GitHub를 구입했습니다. Microsoft는 모든 개발자가 연결하고 확장할 수 있는 개방형 플랫폼 으로 GitHub를 유지하겠다고 약속했습니다. 그것은 독립적 인 회사로 계속 운영하고 있습니다. GitHub는 엔터프라이즈, 팀, 전문가 및 무료 계정에 대한 계획을 제공합니다.

소스 제어

클라우드 네이티브 애플리케이션에 대한 코드를 구성하는 것은 어려울 수 있습니다. 단일 거대한 애플리케이션 대신 클라우드 네이티브 애플리케이션은 서로 통신하는 더 작은 애플리케이션의 웹으로 구성되는 경향이 있습니다. 컴퓨팅의 모든 항목과 마찬가지로 최상의 코드 정렬은 여전히 열려 있는 질문입니다. 다양한 종류의 레이아웃을 사용하는 성공적인 애플리케이션의 예가 있지만 두 가지 변형이 가장 많이 사용되는 것 같습니다.

실제 소스 제어 자체에 들어가기 전에 적절한 프로젝트 수를 결정할 가치가 있습니다. 단일 프로젝트 내에는 여러 리포지토리 및 빌드 파이프라인에 대한 지원이 있습니다. 보드는 좀 더 복잡하지만 단일 프로젝트 내의 여러 팀에 작업을 쉽게 할당할 수 있습니다. 단일 Azure DevOps 프로젝트에서 수백, 심지어 수천 명의 개발자를 지원할 수 있습니다. 이렇게 하면 모든 개발자가 작업할 수 있는 단일 위치를 제공하고 개발자가 어느 프로젝트가 있는지 확실하지 않은 경우 하나의 애플리케이션을 찾는 혼동을 줄일 수 있으므로 가장 좋은 방법입니다.

Azure DevOps 프로젝트 내에서 마이크로 서비스에 대한 코드를 분할하는 것이 약간 더 어려울 수 있습니다.

그림 10-3 - 하나의 리포지토리와 여러 리포지토리

마이크로서비스별 저장소

언뜻 보기에 이 방법은 마이크로 서비스에 대한 소스 코드를 분할하는 가장 논리적인 접근 방식처럼 보입니다. 각 리포지토리에는 하나의 마이크로 서비스를 빌드하는 데 필요한 코드가 포함될 수 있습니다. 이 방법의 장점은 쉽게 볼 수 있습니다.

1. 애플리케이션을 빌드하고 유지 관리하는 지침은 각 리포지토리의 루트에 있는 추가 정보 파일에 추가할 수 있습니다. 리포지토리를 뒤집을 때 이러한 지침을 쉽게 찾을 수 있으므로 개발자의 스핀업 시간이 줄어듭니다.
2. 모든 서비스는 서비스의 이름을 알고 쉽게 찾을 수 있는 논리적 위치에 있습니다.
3. 빌드는 소유 리포지토리를 변경할 때만 트리거되도록 쉽게 설정할 수 있습니다.
4. 리포지토리에 들어오는 변경 횟수는 프로젝트에서 작업하는 소수의 개발자로 제한됩니다.
5. 개발자가 읽고 쓸 수 있는 리포지토리를 제한하여 보안을 쉽게 설정할 수 있습니다.
6. 리포지토리 수준 설정은 소유 팀에서 다른 사용자와 최소한의 논의를 통해 변경할 수 있습니다.

마이크로 서비스의 핵심 아이디어 중 하나는 서비스를 사일로화하고 서로 분리해야 한다는 것입니다. 도메인 기반 디자인을 사용하여 서비스의 경계를 결정할 때 서비스는 트랜잭션 경계 역할을 합니다. 데이터베이스 업데이트는 여러 서비스에 걸쳐서는 안 됩니다. 이 관련 데이터 컬렉션을 제한된 컨텍스트라고 합니다. 이 아이디어는 마이크로 서비스 데이터를 나머지 서비스와 분리되고 자율적인 데이터베이스로 격리하여 반영됩니다. 소스 코드까지 이 아이디어를 전달하는 것은 매우 합리적입니다.

그러나 이 방법은 문제가 없는 것은 아닙니다. 우리 시대의 더 거친 개발 문제 중 하나는 종속성을 관리하는 것입니다. 평균 node_modules 디렉터리를 구성하는 파일 수를 고려합니다. 다음과 같은 create-react-app 새로운 설치는 수천 개의 패키지를 가져올 가능성이 높습니다. 이러한 종속성을 관리하는 방법에 대한 질문은 어렵습니다.

종속성이 업데이트되면 다운스트림 패키지도 이 종속성을 업데이트해야 합니다. 아쉽게도 개발 작업이 필요하므로, node_modules 디렉터리가 단일 패키지의 여러 버전을 가지게 되며, 각각은 약간 다른 주기로 버전이 지정된 다른 패키지의 종속성으로 작동합니다. 애플리케이션을 배포할 때 어떤 버전의 종속성을 사용해야 하나요? 현재 프로덕션 중인 버전인가요? 현재 베타 버전이지만 소비자가 프로덕션에 사용할 때까지 프로덕션 중일 가능성이 있는 버전은 무엇인가요? 마이크로 서비스만 사용하여 해결되지 않는 어려운 문제

다양한 프로젝트에서 의존하는 라이브러리가 있습니다. 마이크로 서비스를 각 리포지토리에 하나씩 분할하면 내부 리포지토리인 Azure Artifacts를 사용하여 내부 종속성을 가장 잘 해결할 수 있습니다. 라이브러리용 빌드는 내부 사용을 위해 최신 버전을 Azure Artifacts로 푸시합니다. 새로 업데이트된 패키지에 종속되려면 다운스트림 프로젝트를 수동으로 업데이트해야 합니다.

서비스 간에 코드를 이동할 때 또 다른 단점이 있습니다. 마이크로 서비스로 애플리케이션의 첫 번째 분할이 100% 정확하다고 생각하는 것이 좋지만, 현실은 거의 우리가 서비스 부문 실수를하지 않을 정도로 선견지명입니다. 따라서 기능을 작동하는 코드는 서비스에서 서비스로, 리포지토리에서 리포지토리로 이동해야 합니다. 한 리포지토리에서 다른 리포지토리로 도약하면 코드의 기록이 손실됩니다. 특히 감사의 경우 코드 조각에 대한 전체 기록이 매우 중요한 경우가 많습니다.

최종적이고 가장 중요한 단점은 변경 사항을 조정하는 것입니다. 실제 마이크로 서비스 애플리케이션에서는 서비스 간에 배포 종속성이 없어야 합니다. 느슨한 결합이 있으므로 어떤 순서로든 서비스 A, B 및 C를 배포할 수 있어야 합니다. 그러나 실제로는 여러 리포지토리를 동시에 교차하는 변경을 하는 것이 바람직한 경우가 있습니다. 몇 가지 예로는 보안 허점을 닫기 위해 라이브러리를 업데이트하거나 모든 서비스에서 사용하는 통신 프로토콜을 변경하는 것이 포함됩니다.

리포지토리 간 변경을 수행하려면 각 리포지토리에 대한 커밋을 연속적으로 수행해야 합니다. 각 리포지토리의 각 변경 내용은 끌어오기 요청 및 별도로 검토해야 합니다. 이 작업은 조정하기 어려울 수 있습니다.

많은 리포지토리를 사용하는 대안은 모든 소스 코드를 하나의 거대한 단일 리포지토리에 함께 배치하는 것입니다.

단일 리포지토리

이 방법에서는 단일 리포지토리라고도 하며 모든 서비스에 대한 모든 소스 코드가 동일한 리포지토리에 배치됩니다. 처음에 이 방법은 소스 코드를 다루기 어려울 수 있는 끔찍한 생각처럼 보입니다. 그러나 이러한 방식으로 작업할 때 몇 가지 현저한 이점이 있습니다.

첫 번째 장점은 프로젝트 간의 종속성을 보다 쉽게 관리할 수 있다는 것입니다. 프로젝트는 일부 외부 아티팩트 피드를 사용하는 대신 서로 직접 가져올 수 있습니다. 즉, 업데이트가 즉각적이고 충돌하는 버전은 개발자의 워크스테이션에서 컴파일 시간에 찾을 수 있습니다. 실제로 일부 통합 테스트는 왼쪽으로 이동합니다.

이제 프로젝트 간에 코드를 이동할 때 파일을 다시 작성하지 않고 이동한 것으로 감지되므로 기록을 유지하는 것이 더 쉬워졌습니다.

또 다른 장점은 서비스 경계를 넘어 단일 커밋에서 수행할 수 있는 광범위한 변경 사항입니다. 이 활동은 개별적으로 검토할 수 있는 수십 개의 변경 내용이 있는 오버헤드를 줄입니다.

안전하지 않은 프로그래밍 사례 또는 문제가 있는 API 사용을 감지하기 위해 코드의 정적 분석을 수행할 수 있는 많은 도구가 있습니다. 다중 리포지토리 환경에서 각 리포지토리를 반복하여 문제를 찾아야 합니다. 단일 리포지토리를 사용하면 모든 분석을 한 곳에서 실행할 수 있습니다.

단일 리포지토리 접근 방식에는 여러 가지 단점이 있습니다. 가장 걱정스러운 것 중 하나는 단일 리포지토리가 있으면 보안 문제가 제기된다는 것입니다. 리포지토리의 콘텐츠가 서비스 모델당 리포지토리에서 유출되는 경우 손실된 코드의 양은 최소화됩니다. 단일 리포지토리를 사용하면 회사가 소유한 모든 것이 손실될 수 있습니다. 과거에는 이러한 일이 발생하고 전체 게임 개발 노력을 탈선시키는 많은 예가 있었습니다. 여러 리포지토리가 있으면 노출 영역이 적어지며 이는 대부분의 보안 사례에서 바람직한 특성입니다.

단일 리포지토리의 크기는 신속하게 관리가 불가능해질 수 있습니다. 이는 몇 가지 흥미로운 성능 영향을 제공합니다. 원래 Windows 팀의 개발자 환경을 개선하기 위해 설계된 Git용 가상 파일 시스템과 같은 특수 도구를 사용해야 할 수도 있습니다.

종종 단일 리포지토리를 사용하기 위한 인수는 Facebook 또는 Google이 소스 코드 정렬에 이 메서드를 사용한다는 인수로 귀결됩니다. 이러한 회사에 대한 접근 방식이 충분히 좋은 경우, 확실히, 그것은 모든 회사에 대한 올바른 접근 방식입니다. 실상은 페이스북이나 구글만큼 큰 규모로 운영되는 회사는 거의 없다는 것입니다. 이러한 규모에서 발생하는 문제는 대부분의 개발자가 직면하게 될 문제와 다릅니다. 거위에게 좋은 것은 거위에게 좋지 않을 수 있습니다.

결국 두 솔루션 중 하나를 사용하여 마이크로 서비스에 대한 소스 코드를 호스트할 수 있습니다. 그러나 대부분의 경우 단일 리포지토리 운영의 관리 및 엔지니어링 부담은 별로 메리트가 없습니다. 여러 리포지토리를 통해 코드를 분할하면 문제를 더 잘 분리하고 개발 팀 간의 자율성을 장려할 수 있습니다.

표준 디렉터리 구조

단일 및 여러 리포지토리에 관계없이 각 서비스에는 자체 디렉터리가 있습니다. 개발자가 프로젝트 간을 빠르게 교차할 수 있도록 하는 최상의 최적화 중 하나는 표준 디렉터리 구조를 유지하는 것입니다.

그림 10-4 - 표준 디렉터리 구조

새 프로젝트를 만들 때마다 올바른 구조를 배치하는 템플릿을 사용해야 합니다. 이 템플릿에는 기본 추가 정보 파일 및 azure-pipelines.yml같은 유용한 항목도 포함될 수 있습니다. 모든 마이크로 서비스 아키텍처에서 프로젝트 간의 높은 분산으로 인해 서비스에 대한 대량 작업이 더 어려워집니다.

여러 소스 코드 디렉터리를 포함하는 전체 디렉터리에 대한 템플릿을 제공할 수 있는 많은 도구가 있습니다. Yeoman 은 JavaScript 세계에서 인기가 있으며 GitHub는 최근 동일한 기능을 많이 제공하는 리포지토리 템플릿을 출시했습니다.

작업 관리

모든 프로젝트에서 작업을 관리하는 것은 어려울 수 있습니다. 앞에는 최적의 개발자 생산성을 보장하기 위해 설정해야 하는 워크플로 종류에 대한 수많은 질문이 있습니다.

클라우드 네이티브 애플리케이션은 기존 소프트웨어 제품보다 작거나 최소한 더 작은 서비스로 나뉩니다. 이러한 서비스와 관련된 문제 또는 작업 추적은 다른 소프트웨어 프로젝트와 마찬가지로 중요합니다. 어느 누구도 일부 작업 항목을 추적하지 못하거나 문제가 제대로 기록되지 않았음을 고객에게 설명하고 싶지 않습니다. 보드는 프로젝트 수준에서 구성되지만 각 프로젝트 내에서 영역을 정의할 수 있습니다. 이를 통해 여러 구성 요소에서 문제를 분석할 수 있습니다. 전체 애플리케이션에 대한 모든 작업을 한 곳에 유지하는 이점은 작업 항목을 한 팀에서 다른 팀으로 쉽게 이동할 수 있다는 것입니다.

Azure DevOps에는 미리 구성된 인기 있는 템플릿이 많이 포함되어 있습니다. 가장 기본적인 구성에서 알아야 할 것은 백로그의 내용, 사람들이 작업하는 작업 및 수행된 작업입니다. 작업 우선 순위를 지정하고 완료된 작업을 고객에게 보고할 수 있도록 소프트웨어 빌드 프로세스에 대한 가시성을 확보해야 합니다. 물론, 간단한 프로세스to dodoing에 충실하는 소프트웨어 프로젝트는 거의 없습니다done. 사람들이 프로세스와 같은 QADetailed Specification 단계를 추가하기 시작하는 데는 그리 오래 걸리지 않습니다.

Agile 방법론의 가장 중요한 부분 중 하나는 정기적으로 자기 성찰입니다. 이러한 검토는 팀이 직면한 문제 및 개선 방법에 대한 인사이트를 제공하기 위한 것입니다. 이는 개발 프로세스를 통해 문제와 기능의 흐름을 변경하는 것을 의미하는 경우가 많습니다. 따라서 추가 단계로 보드의 레이아웃을 확장하는 것은 완벽하게 정상입니다.

보드의 단계가 유일한 조직 도구는 아닙니다. 보드의 구성에 따라 작업 항목의 계층 구조가 있습니다. 보드에 표시할 수 있는 가장 세분화된 항목은 작업입니다. 우선 작업에는 제목, 설명, 우선 순위, 남은 작업량의 예상 및 다른 작업 항목 또는 개발 항목(분기, 커밋, 끌어오기 요청, 빌드 등)에 연결할 수 있는 기능이 포함됩니다. 작업 항목을 애플리케이션의 여러 영역과 다양한 반복(스프린트)으로 분류하여 쉽게 찾을 수 있습니다.

그림 10-5 - Azure DevOps의 작업.

설명 필드는 예상하는 일반 스타일(굵게, 기울인 밑줄 및 취소선)과 이미지를 삽입하는 기능을 지원합니다. 이렇게 하면 작업 또는 버그를 지정할 때 사용할 수 있는 강력한 도구가 됩니다.

작업은 더 큰 작업 단위를 정의하는 기능으로 롤업할 수 있습니다. 기능은 서사시로 통합될 수 있습니다. 이 계층 구조에서 작업을 분류하면 대규모 기능이 롤아웃하는 데 얼마나 가까운지 훨씬 쉽게 이해할 수 있습니다.

그림 10-6 - Azure DevOps의 작업 항목입니다.

Azure Boards의 문제에 대한 다양한 종류의 견해가 있습니다. 아직 예약되지 않은 항목이 백로그에 표시됩니다. 그런 다음, 해당 항목들을 스프린트에 할당할 수 있습니다. 스프린트는 일정 수량의 작업이 완료될 것으로 예상되는 시간 상자입니다. 이 작업에는 작업뿐만 아니라 티켓 확인도 포함될 수 있습니다. 일단 거기, 전체 스프린트는 스프린트 보드 섹션에서 관리할 수 있습니다. 이 보기는 작업의 진행 상황을 보여주며, 지속적으로 업데이트되는 스프린트 성공 여부에 대한 예측을 제공하는 번다운 차트를 포함합니다.

그림 10-7 - Azure DevOps의 보드.

지금까지 Azure DevOps의 Boards에는 강력한 기능이 있다는 것이 분명합니다. 개발자가 진행 중인 일의 상태를 쉽게 확인할 수 있습니다. 프로젝트 관리자는 예정된 작업과 기존 작업에 대한 개요를 볼 수 있습니다. 관리자의 경우 자원 및 용량에 대한 많은 보고서가 있습니다. 아쉽게도 클라우드 네이티브 애플리케이션이라고 해서 작업 추적의 필요성을 없애주는 마법 같은 것이 아닙니다. 그러나 작업을 추적해야 하는 경우 Azure DevOps보다 환경이 더 나은 몇 가지 장소가 있습니다.

CI/CD 파이프라인

소프트웨어 개발 수명 주기에서 연속 통합(CI) 및 지속적 배포(CD)의 출현만큼 혁신적인 변화는 거의 없었습니다. 변경 사항이 반영되면 바로 프로젝트의 소스 코드에 대해 자동화된 테스트를 빌드하고 실행하여 실수를 조기에 발견할 수 있습니다. 연속 통합 빌드가 도입되기 전에는 리포지토리에서 코드를 가져와 테스트를 통과하지 못했거나 빌드할 수도 없다는 사실을 알게 되는 것은 드문 일이 아닙니다. 이로 인해 중단의 원인을 추적하게 되었습니다.

일반적으로 프로덕션 환경에 소프트웨어를 배송하려면 광범위한 설명서와 단계 목록이 필요했습니다. 이러한 각 단계는 오류가 발생하기 쉬운 프로세스에서 수동으로 완료해야 했습니다.

그림 10-8 - 검사 목록.

연속 통합의 자매는 새로 빌드된 패키지가 환경에 배포되는 지속적인 업데이트입니다. 수동 프로세스는 개발 속도에 맞게 확장할 수 없으므로 자동화가 더 중요해집니다. 검사 목록은 모든 사용자보다 더 빠르고 정확하게 동일한 작업을 실행할 수 있는 스크립트로 대체됩니다.

지속적인 배달이 제공되는 환경은 테스트 환경일 수도 있고, 많은 주요 기술 회사에서 수행하는 것처럼 프로덕션 환경일 수도 있습니다. 후자는 사용자에 대한 프로덕션을 중단하지 않을 것이라는 확신을 줄 수 있는 고품질 테스트에 대한 투자가 필요합니다. 지속적인 통합이 코드에서 문제를 조기에 포착하는 것과 마찬가지로, 지속적인 배포도 배포 프로세스에서 문제를 조기에 포착합니다.

빌드 및 배달 프로세스 자동화의 중요성은 클라우드 네이티브 애플리케이션에 의해 강조됩니다. 배포가 더 빈번해지고 여러 환경에서 이루어지기 때문에 수동으로 배포하기가 거의 불가능합니다.

Azure Builds

Azure DevOps는 연속 통합 및 배포를 그 어느 때보다 쉽게 만들 수 있는 도구 집합을 제공합니다. 이러한 도구는 Azure Pipelines 아래에 있습니다. 그 중 첫 번째는 대규모 YAML 기반 빌드 정의를 실행하기 위한 도구인 Azure Builds입니다. 사용자는 자체 빌드 머신을 가져오거나(빌드에 꼼꼼하게 환경을 설정해야 하는 경우) Azure 호스팅 가상 머신의 지속적으로 새로 고쳐진 풀에서 머신을 사용할 수 있습니다. 이러한 호스트된 빌드 에이전트는 .NET 개발뿐만 아니라 Java에서 Python, iPhone 개발까지 모든 것을 위한 광범위한 개발 도구와 함께 미리 설치됩니다.

DevOps에는 모든 빌드에 대해 사용자 지정할 수 있는 다양한 기본 빌드 정의가 포함되어 있습니다. 빌드 정의는 azure-pipelines.yml라는 파일에 정의되어 있으며, 소스 코드와 함께 버전 관리가 가능하도록 리포지토리에 체크인됩니다. 이렇게 하면 변경 내용을 해당 분기에만 체크 인할 수 있으므로 분기에서 빌드 파이프라인을 훨씬 쉽게 변경할 수 있습니다. 전체 프레임워크에서 ASP.NET 웹 애플리케이션을 빌드하는 예제 azure-pipelines.yml 는 그림 10-9에 나와 있습니다.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

그림 10-9 - 샘플 azure-pipelines.yml

이 빌드 정의는 레고 세트를 빌드하는 것만큼 간단하게 빌드를 만드는 여러 가지 기본 제공 작업을 사용합니다(거대한 밀레니엄 팔콘보다 간단). 예를 들어 NuGet 작업은 NuGet 패키지를 복원하는 반면 VSBuild 태스크는 Visual Studio 빌드 도구를 호출하여 실제 컴파일을 수행합니다. Azure DevOps에는 수백 가지 작업을 사용할 수 있으며, 커뮤니티에서 유지 관리되는 작업은 수천 개 이상 있습니다. 실행하려는 빌드 작업이 무엇이든 간에 누군가가 이미 빌드한 것일 수 있습니다.

수동으로, 체크 인하거나, 일정에 따라 또는 다른 빌드를 완료하여 빌드를 트리거할 수 있습니다. 대부분의 경우 각 체크인에 대해 빌드를 수행하는 것이 바람직합니다. 다른 빌드가 리포지토리의 다른 부분이나 다른 분기에 대해 실행되도록 빌드를 필터링할 수 있습니다. 이렇게 하면 풀 리퀘스트에 대해 테스트를 줄여서 빠른 빌드를 실행하는 것과 매일 밤 메인 브랜치에 대해 전체 회귀 테스트 제품군을 실행하는 등의 시나리오를 사용할 수 있습니다.

빌드의 최종 결과는 빌드 아티팩트라고 하는 파일의 컬렉션입니다. 이러한 아티팩트를 빌드 프로세스의 다음 단계로 전달하거나 Azure Artifacts 피드에 추가할 수 있으므로 다른 빌드에서 사용할 수 있습니다.

Azure DevOps 소프트웨어 릴리스

빌드는 소프트웨어를 배송 가능한 패키지로 컴파일하는 작업을 처리하지만 지속적인 배달을 완료하려면 아티팩트를 테스트 환경으로 푸시해야 합니다. 이를 위해 Azure DevOps는 릴리스라는 별도의 도구를 사용합니다. 릴리스 도구는 빌드에서 사용할 수 있었지만 "단계"라는 개념을 도입한 것과 동일한 작업 라이브러리를 사용합니다. 단계는 패키지가 설치된 격리된 환경입니다. 예를 들어 제품은 개발, QA 및 프로덕션 환경을 사용할 수 있습니다. 코드는 자동화된 테스트를 실행할 수 있는 개발 환경으로 지속적으로 전달됩니다. 이러한 테스트가 통과되면 수동 테스트를 위해 릴리스가 QA 환경으로 이동합니다. 마지막으로 코드는 모두에게 표시되는 프로덕션으로 푸시됩니다.

그림 10-10 - 릴리스 파이프라인

빌드의 각 단계는 이전 단계의 완료에 의해 자동으로 트리거될 수 있습니다. 그러나 대부분의 경우 이는 바람직하지 않습니다. 코드를 프로덕션으로 이동하려면 다른 사람의 승인이 필요할 수 있습니다. 릴리스 도구는 릴리스 파이프라인의 각 단계에서 승인자를 허용하여 이를 지원합니다. 특정 사용자 또는 사용자 그룹이 프로덕션으로 전환하기 전에 릴리스에서 로그오프하도록 규칙을 설정할 수 있습니다. 이러한 게이트는 수동 품질 검사를 허용하고 프로덕션 환경에 들어가는 항목을 제어하는 것과 관련된 모든 규정 요구 사항을 준수할 수 있습니다.

모두가 빌드 파이프라인을 갖습니다.

많은 빌드 파이프라인을 구성하는 데 비용이 들지 않으므로 마이크로 서비스당 하나 이상의 빌드 파이프라인을 사용하는 것이 유리합니다. 이상적으로 마이크로 서비스는 모든 환경에 독립적으로 배포할 수 있으므로 관련 없는 코드의 질량을 해제하지 않고도 각 서비스를 자체 파이프라인을 통해 릴리스할 수 있게 하는 것이 완벽합니다. 각 파이프라인에는 각 서비스에 대한 빌드 프로세스의 변형을 허용하는 자체 승인 집합이 있을 수 있습니다.

릴리스 버전 관리

릴리스 기능을 사용하는 한 가지 단점은 체크 인 azure-pipelines.yml 파일에 정의할 수 없다는 것입니다. 분기별 릴리스 정의를 갖는 것부터 프로젝트 템플릿에 릴리스 골격을 포함시키는 데에는 여러 가지 이유가 있습니다. 다행히 일부 단계 지원을 빌드 구성 요소로 전환하는 작업이 진행 중입니다. 이를 다단계 빌드라고 하며 이제 첫 번째 버전을 사용할 수 있습니다.