티스토리 뷰
이번 글에서는 어떻게 Azure DevOps의 6가지 주요 기능을 활용하여 애플리케이션 생명주기를 관리할 수 있는지에 대해 쉽게 이해할 수 있도록 정리한 Subhankar Sarkar님의 "AZURE DEVOPS – MANAGE YOUR APPLICATION LIFECYCLE IN CLOUD" 라는 글을 소개하고자 한다. 이 글을 한글화하는데 흔쾌히 허락해주신 Subhankar Sarkar님에게 다시 한번 감사의 말씀을 전한다. |
ALM(Application Lifecycle Management) 이란?
애플리케이션 라이프사이클 관리(AML)는 컴퓨터 프로그램의 제품 생명주기를 관리하는 것으로 요구사항 관리, 소프트웨어 아키텍처, 컴퓨터 프로그래밍, 소프트웨어 테스트, 소프트웨어 유지보수, 변경 관리, 지속적인 통합, 프로젝트 관리, 릴리스 관리를 포함한다. [출처 위키백과.]
ALM 도구는 아이디어 캡처, 사용자 요구 사항, 작업 계획, 소스 코드 유지, 지속적인 통합 및 지속적인 전달(CI/CD)을 사용한 코드 배포와 같은 소프트웨어 라이프사이클의 모든 측면을 유지할 수 있는 기능을 가져야 한다. 또한 프로젝트의 주요 이해관계자들에게 실시간 프로젝트 통찰력을 제공해야 한다. 우리는 AML 소프트웨어를 소프트웨어 프로젝트/제품 관리 전체를 위한 One-stop 샵으로 생각할 수 있다.
이 게시물에서는 마이크로소프트의 Azure DevOps 제품 및 ALM 솔루션으로서의 기능을 살펴보고 ALM 여정에 사용할 수 있는 방법을 살펴보도록 하겠다.
Azure DevOps란?
한 문장으로, Azure DevOps는 처음부터 끝까지 소프트웨어 제품/프로젝트를 빌드하는 데 필요한 클라우드의 제품 모음이다.
Azure DevOps는 이전에 VSTS(Visual Studio Team System)로 불렸다. 프로젝트를 계획하고 Git, TFVC, Subversion, GitHub와 같은 리포지토리에서 소스 코드를 관리하고 CI/CD 파이프라인 시스템을 통해 클라우드 또는 온 프레미스 리소스에 코드를 배포하는 데 도움을 준다. 또한 개발자, 비즈니스 사용자 및 테스트 엔지니어, 프로젝트 관리자를 위한 협업 플랫폼을 제공하여 작업을 실시간으로 추적하고 제품을 빠르게 출하할 수 있다.
Azure DevOps의 6가지 기둥
Azure DevOps에는 클라우드 상에서 완전한 ALM 제품을 구성하도록 도움을 주는 6 개의 주요 기둥이 있다. Azure DevOps의 주요 요소를 간략하게 살펴 보겠다.
Azure Overview는 팀 속도, CI/CD 결과, 특정 시점에 제기된 결함 수와 해결된 결함 수와 같은 프로젝트에 대한 실시간 통찰력을 제공한다. 내장된 기능으로 관리 대시 보드를 만들 수 있다. 이러한 대시 보드는 위험 및 품질 매트릭스를 사용하여 관리 상태보고에 크게 도움이 된다.
또한 프로젝트에 대한 Wiki 페이지 생성을 지원한다. 위키 페이지는 진행 중이거나 완료된 프로젝트와 관련된 문서/매뉴얼을 만드는 데 사용할 수 있다.
Azure Boards는 모든 작업을 관리하고 계획 할 수 있는 장소이다. 소프트웨어에 대한 모든 아이디어와 비즈니스 요구 사항을 여기에서 캡처 할 수 있다. 에픽, 피처, 사용자 스토리를 만든 다음 이를 추정하고 팀 구성원의 용량을 계획하고 스프린트를 시작할 수 있다. 또한 Kanban 보드, 스프린트 번 다운 차트에서 작업 항목 진행 상황을 실시간으로 볼 수 있다.
Azure Pipelines는 코드의 지속적 통합 및 지속적 전달 (CI/CD)에 사용된다. 코드를 더 빨리 전달할 수 있다. 코드가 개발되고 리포지토리에 커밋되면 빌드 파이프라인에서 빌드가 트리거 된다. 이 빌드 파이프라인은 저장소에서 최신 코드를 가져 와서 빌드 에이전트에서 빌드한다. 빌드가 성공하면 대상 배포 환경에서 릴리스 파이프라인을 사용하여 빌드 아티팩트가 게시된다.
Azure Test Plans은 수동, 자동화 및 부하 테스트 사례를 계획하고 실행하기 위한 것이다. 빌드가 성공하면 테스트 엔지니어는 원하는 기능을 확인하고 검증하기 위해 빌드에서 일련의 테스트를 실행할 수 있다. 또한 Azure Board에서 계획된 테스트 시나리오의 실패에 대한 모든 결함 또는 관찰을 제기하고 기록 할 수 있다.
Azure Artifacts는 사설 피드에서 사설 NuGet, npm, Maven 패키지를 관리한다. Visual Studio 또는 Visual Studio Code와 같은 즐겨 찾는 IDE에 이 피드를 통합하고 개발 중에 이 피드에서 패키지를 복원 할 수 있다. 또한 이 피드를 빌드 파이프라인에 통합하고 이 사설 리포지토리에서 패키지를 복원 할 수 있다. Azure Artifacts는 애플리케이션에서 사용중인 공유 공통 패키지가 많고 이러한 교차 절단 속성의 표준 버전을 제어하려는 경우 많은 도움이 된다.
Azure DevOps를 사용하는 ALM
이제 Azure DevOps의 6 가지 기둥에 대한 상당한 이해를 했으므로 예제를 통해 이러한 모든 요소가 ALM에서 어떻게 도움이되는지 살펴 보겠다. 이 게시물의 시작 부분에 있는 인포 그래픽을 참조한다. 여기에서는 Azure DevOps에서 작동하는 ALM에 대해 매우 간략하게 설명한다.
프로젝트 또는 제품의 초기에는 아이디어 또는 일부 비즈니스 요구 사항으로 시작하고 여러 단계를 거친 후에 사용 가능한 제품의 형태를 취한다. 이 예제에서는 인포 그래픽은
#1 고객이 요구 사항을 제시한다.
#2 비즈니스 분석가 / 제품 소유자가 요구 사항을 분석하고 Azure Boards에서 문서화를 시작한다. 그들은 Epic, Feature 및 사용자 스토리를 만들기 시작한다.
#3 엔지니어링 팀은 작업 예측을 시작하고 스프린트에 대한 사용자 스토리를 계획한다.
#3.1 동시에 테스트 엔지니어는 사용자 스토리의 수용 기준에 따라 Test Plans에서 테스트 계획을 시작한다.
#4 스프린트가 시작되면 개발자는 2단계에서 생성된 백로그에서 사용자 스토리를 선택하고 이를 구현하기 시작한다.
#5 개발자가 개발을 마치면 풀 리퀘스트를 생성하고 코드 검토를 위해 보낸다. 코드 검토자가 만족하면 개발자는 Azure Repos에서 코드를 커밋한다.
#6 CI (지속적 통합)를 사용하여 코드가 Azure Repos에서 커밋되는 즉시 빌드 파이프라인에서 빌드가 트리거된다. CI 빌드는 리포지토리에서 최신 코드를 가져 와서 빌드 에이전트에서 빌드하고, Azure Artifacts의 피드 설정에서 모든 사설 패키지를 복원한다. 단위 테스트를 실행하고 코드 검사 결과를 생성하며 마지막으로 배포를 위한 빌드 산출물을 생성한다. 빌드 파이프라인에 구성된 단계 중 하나가 실패하면 전체 커밋이 거부되고 개발자는 빌드 실패 알림을 받는다. 개발자는 빌드를 수정하고 한 번 더 커밋하면 CI 빌드가 자동으로 트리거된다.
#7 빌드 산출물을 배포 환경으로 이동해야 한다. 빌드 아티팩트의 Release Pipeline 소스는 이전 6단계의 CI 빌드 산출물이며 대상은 이러한 아티팩트를 배포해야하는 서버이다. 이 예제에서는 TESTING 환경 (7.1 단계)을 위해 Azure 클라우드 앱 서비스 및 Azure SQL 데이터베이스에 아티팩트를 배포한다. 배포가 발생하기 전에 게이트 또는 승인 메커니즘을 설정할 수 있으며 이를 통해 승인자가 배포 할 빌드를 선택하고 선택할 수 있다.
#8 빌드가 TESTING 환경에 배포되었으므로 테스트 엔지니어는 빌드 품질을 테스트하고 확인하기 시작한다. Azure Test Plans의 계획 단계 (3.1 단계) 중에 계획된대로 수동, 자동화 및 부하 테스트 집합을 실행한다. 결함이 발견되면 Azure Boards 백로그에 로그인하고 새로운 bug/issue/observation을 만든다. 개발자는 이러한 결함이 계획되고 스프린트로 피드백되면 이러한 결함을 선택하고, 결함을 수정하고 Azure Repos에 커밋하면 이는 결국 Azure Pipelines에서 CI/CD를 트리거 한다.
#9 테스트 엔지니어가 제공되는 빌드 품질 및 기능에 만족하면 이 빌드가 상위 환경으로 승격된다 (9.1 단계). 이 예에서는 비즈니스 사용자가 테스트 할 UAT 환경이다.
#10 비즈니스 사용자는 이제 현재 스프린트에 계획된 모든 기능을 갖춘 UAT 환경에서 새로운 빌드를 얻는다. 비즈니스 사용자는 UAT 환경에서 빌드 및 기능 확인을 시작한다.
#11 비즈니스 사용자가 결함을 발견하면 Azure Boards 백로그에 bug/observation으로 로그인한다. 이러한 결함이 계획되고 스프린트로 피드백되면 개발 및 빌드주기가 계속된다.
#12 비즈니스 사용자가 기능과 빌드 품질에 만족하면 빌드가 PRODUCTION 환경으로 승격된다 (12.1 단계). 이것이 프로덕션에 릴리스되면 최종 사용자가 시스템을 사용하기 시작한다. 프로덕션에서 문제가 발생하면 다시 Azure Boards 백 로그에 Incident/Bug/Issue로 기록된다.
이 계획과 마찬가지로 개발 및 빌드주기는 제품 출하까지 계속된다. 전체 프로세스에서 프로젝트의 주요 이해 관계자는 Azure Overview 대시 보드를 주시하여 위험을 식별하고 완화한다.
마무리
자, 이제 이 게시물의 끝이다. 이 게시물에서는 Azure DevOps의 6 가지 기둥과 이를 활용하여 애플리케이션 수명주기를 관리하는 방법을 살펴 보았다. Azure DevOps는 퍼블릭 클라우드의 브라우저 기반 애플리케이션으로, 수 많은 오픈소스 언어 및 플랫폼과의 통합 및 최고 수준의 지원을 제공한다. Azure DevOps에서 끝까지 안심하고 ALM을 관리 할 수 있다.
한편 Azure DevOps에서 무료 계정을 시작하고 탐색을 시작할 수 있다. Microsoft 계정으로 https://dev.azure.com에 로그인하고 Azure DevOps를 사용하여 클라우드에서 ALM 여정을 시작한다.
Subhankar Sarkar님의 원본글은 "AZURE DEVOPS – MANAGE YOUR APPLICATION LIFECYCLE IN CLOUD"에서 확인할 수 있다. |
'Azure와 함께 하는 DevOps' 카테고리의 다른 글
Azure DevOps를 활용한 Git 기초 및 활용 Part 2 (0) | 2024.08.29 |
---|---|
Azure DevOps를 활용한 Git 기초 및 활용 Part 1 (0) | 2024.08.16 |
76. Azure DevOps - Slack 통합 2편 (0) | 2021.03.22 |
75. Azure DevOps - Slack 통합 1편 (0) | 2021.03.15 |
74. 릴리즈 게이트를 사용하여 배포 제어 3편 (0) | 2021.03.08 |