32. Azure DevOps를 사용하여 지속적인 전달 채택하기 2편

<참조> https://azuredevopslabs.com/labs/azuredevops/continuousdeployment/

 

 

 

 

이번 글 Azure DevOps를 사용하여 지속적인 전달 채택하기 1편에 이어 과제 4~6의 내용을 마저 정리한다.

 

 

 

 

과제 4: QA에 지속적인 전달 릴리즈 호출하기

1. 브라우저 탭을 열어 Azure DevOps 프로젝트로 돌아간다.

 

 

2. 릴리즈 파이프라인이 준비되었으므로 빌드 및 릴리즈를 호출하기 위해 변경을 커밋해야 한다. 이 랩 과정 중에 이와 같이 약간 변경이 필요하므로 프로세스의 해당 부분을 별도로 유지하려면 "Files - 새 탭에서 링크 열기"를 사용하는 것이 좋다.

 

 

3. PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Views/Shared/_Layout.cshtml로 이동한다.  이것은 사이트의 일반적인 레이아웃을 정의하는 파일이며 배포 후 쉽게 볼 수 있는 변경을 수행하기에 좋은 위치다.

 

 

4. 인라으로 파일을 편집할 수 있도록 Edit을 클릭한다. 

 

 

5. Parts Unlimited Logo 를 찾아 그 뒤에 “v2.0” 이라는 텍스트를 추가한다. 이렇게 하면 배포 후 확인하기에 용이할 것이다. 

 

 

6. 레포지토리로 돌아가 변경사항을 Commit 한다. 이렇게 하면 사전 구성한 빌드 파이프라인에 따라 빌드 개시가 이루어 질 것이다 .

 

 

7. Pipelines 허브로 이동한다. 

 

 

8. PartsUnlimitedE2E에 대한 최신 빌드를 연다. 대기 중이거나 진행 중이거나 또는 이미 완료되었을 수도 있다.

 

 

9. 완료 될 때까지 빌드를 따른다.

 

 

10. Releases 탭을 클릭하면 새 릴리즈가 시작된다.

 

 

11. 릴리즈를 클릭한다. 빌드와 마찬가지로 빌드가 대기 중이거나 진행 중이거나 이미 완료되었을 수 있다.

 

 

12. 성공할 때까지 릴리즈를 따른다.

 

 

13. 결과를 확인하기에 앞서 다음과 같이 SQL 서버에서  방화벽 설정을 해줘야 한다. (본문에는 이 과정이 생략되어 있다.)

먼저 pul-zerobig SQL 서버로 이동한다.

 

Show firewall settings를 클릭한다.

 

Allow Azure services and resources to access this server를 Yes로 설정하고 Save 한다.

 

 

14. 새 브라우저 탭에서 QA 사이트로 이동한다. 사이트 주소는 앱 서비스 이름과 ".azurewebsites.net"이 될 것이다. 이전에 추가된 v2.0이 표시되어야 한다.

 

 

 

 

과제 5: 프로덕션 스테이지에 게이트 릴리즈 생성하기

1. Azure DevOps 브라우저 탭으로 돌아간다.

 

 

2. 릴리즈 파이프라인이 더욱 정교 해짐에 따라 릴리즈 파이프라인 전체의 품질을 보장하기 위해 게이트를 정의하는 것이 중요해졌다. 배포 할 다음 단계는 프로덕션이므로 자동화 된 품질 게이트와 수동 승인자 게이트를 모두 포함해야 한다. 릴리즈 파이프라인 브라우저 탭으로 돌아가 QA 스테이지에서 Clone를 클릭한다. 프로덕션 스테이지는 거의 동일하므로 거의 모든 기존 구성을 재사용 할 수 있다.

 

 

3. 새로운 스테이지는 현재 스테이지 뒤에 추가된다. 이것이 우리가 하고자 하는 것이다. 그러나 QA 배포가 성공한 것으로 간주하려면 배포 후 조건을 정의해야 한다. QA 스테이지에서 Post-deployment conditions를클릭한다.

 

 

4. Gates 옵션을 Enable 한다.

 

 

5. 배포상태가 양호한지 확인하는 데 필요한 거의 모든 것을 자동으로 테스트 할 수 있는 몇 가지 종류의 게이트가 있다. Azure function 또는 REST API의 반환 값, 경고에 대한 Azure 쿼리 또는 Azure DevOps의 작업 항목 쿼리 등과 같은 것일 수 있다. 게이트를 처음으로 평가하기 전에 플랫폼이 지연되는 시간을 구성 할 수도 있다. 이 경우 배포 후 즉시 테스트하도록 0으로 변경한다. 그런 다음 Add | Query Work Items를 클릭한다.

 

 

6. Shared Queries에 대한 Query | Critical Bugs를 선택한다. 모든 중요한 버그가 해결 될 때까지 QA 배포를 성공으로 간주 할 수 없도록 하는 정책을 만들 것이다.

 

 

 

7. Evaluation options을 확장하고 Time between re-evaluation of gates를 5로 업데이트 한다. 이 게이트가 실패하면 현재 버전에서 치명적인 버그가 고정되어 있다는 것을 엔지니어가 확인하는 데 시간이 필요하기 때문에, 그것이 해결될 때까지 5분마다 쿼리를 재평가하기를 원한다. 그러나 이러한 버그가 해결되지 않고 릴리즈가 수동으로 실패하지 않은 경우 이 구성은 1일 후에 자동으로 게이트에 실패한다.

 

 

8. 이제 프로덕션 스테이지로 초점을 맞출 수 있다. Copy of QA를 선택한다.

 

 

9. “Prod”로 이름을 변경한다.

 

 

10. Pre-deployment conditions 버튼을 클릭한다.

 

 

11. Pre-deployment approvals을 Enable하고 Approver로 자신을 추가한다. 여기에서는 QA 배포가 완료 될 때까지 프로덕션 배포를 승인하라는 메시지가 표시되지 않는다. 이 시점에서 이 목록의 누군가는 배포를 프로덕션에 승인해야 한다. 또한 User requesting a release of deployment should not approve 가 선택되어 있다면 박스를 취소한다. 이 랩의 목적에 따라, 요청한 릴리즈를 승인 할 수 있다.

 

 

12. Prod 스테이지의 1 job, 1 task를 클릭한다.

 

 

13. (“-qa” 대신) “-prod”를 반영하도록 App service name을 업데이트 한다.

 

 

14. 릴리즈 파이프라인을 Save 한다.

 

 

15. 새 탭 앞부분의 “PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Views/Shared/_Layout.cshtml”에서 코드베이스 변경 프로세스를 반복한다. 이번에는 버전 번호를 "2.0"에서 "3.0"으로 업데이트 한다. 릴리즈 파이프 라인이 호출된다.

 

 

 

16. 이전과 마찬가지로 QA에 배포 될 때까지 릴리즈를 따른다. 사용 가능한 경우 릴리즈 자체를 따르려면 클릭한다. 

 

 

 

17. 결국 QA 배포에 문제가 발생합니다. 성공적으로 배포되었지만 품질 게이트 중 하나가 실패했다. 해당 단계를 승인하려면 이 문제를 해결해야 한다. View post-deployment gates  버튼을 클릭한다.

 

 

18. Query Work Items 게이트가 실패한 것 같다. 즉, 해결해야하는 치명적인 버그가 있음을 의미한다.

 

 

19. Boards | Queries에서 새로운 탭을 열어 버그로 이동한다.

 

 

20. All 탭의 쿼리 목록을 사용하여 Shared Queries | Critical Bugs 쿼리를 연다. 

 

 

 

21. 클릭하여 버그 하나를 연다.

 

 

 

22. 일반적으로 사이트에서 버그가 수정되었는지 확인하지만 여기서 건너뛰고 Done으로 표시한다. Save를 클릭하고 탭을 닫는다.

 

 

23. 릴리즈 파이프라인 탭으로 돌아간다. 타이밍에 따라 Azure DevOps에서 쿼리를 다시 확인하는 데 최대 5 분이 걸릴 수 있다. 수정되면 버그가 해결되고 릴리즈가 승인된다. 그런 다음 승인을 클릭하여 프로덕션 배포를 승인 할 수 있다.

 

 

24. 배포를 확인한다.

 

 

25. In progress 링크를 클릭하여 릴리즈 워크플로우를 따른다.

 

 

26. 릴리즈가 시작되고 완료되는 데 약간의 시간이 걸릴 수 있다.

 

 

27. 릴리즈가 완료되면 프로덕션 앱 서비스 URL에 대한 새 탭을 연 다. QA URL과 동일해야하지만“-qa”대신“-prod”가 있어야 한다.  v3.0을 주목한다.

 

 

 

 

과제 6: 배포 슬롯(deployment slots)으로 작업하기

1. 브라우저 창을 열어 Azure 포털로 돌아간다.

 

 

2. Azure App Services는 애플리케이션 배포를 위한 병렬 대상인 deployment slots을 제공한다. 배포 슬롯을 사용하는 가장 일반적인 시나리오는 현재 프로덕션 애픞리케이션을 바꾸지 않고 프로덕션 서비스에 대해 애플리케이션을 실행할 준비 단계를 갖추는 것이다. 준비 배포가 검토를 통과하면 버튼을 클릭하여 즉시 프로덕션 슬롯으로 "스왑"할 수 있다. 추가 이점으로, 새 빌드에서 문제가 발견되면 스왑을 신속하게 되돌릴 수 있다. 이전에 작성된 리소스 그룹을 찾아 prod 앱 서비스를 클릭한다. 

 

 

3. Deployment slots 탭을 선택한다. 현재 가격 계층이 슬롯을 지원하지 않는다는 메시지가 표시되면 워크플로우에 따라 이 서비스를 Production 계층 이상으로 업그레이드 한 다음 여기로 돌아온다. Add Slot 옵션을 사용하려면 브라우저를 새로 고쳐야 할 수도 있다.

 

 

4. Add Slot을 클릭한다. production 슬롯은 "기본"슬롯으로 간주되며 사용자 환경에서 별도의 슬롯으로 표시되지 않는다.

 

 

5. Name으로 “staging”이라고 입력하고 기존 배포와 일치하는 Configuration Source를 선택한다. (하나만 있어야 함). 슬롯을 생성하려면 Add를 클릭한다.

 

 

6. Prod  스테이지 파이프라인 편집기를 사용하여 Azure DevOps 탭으로 돌아간다.

 

 

 

7. Deploy Azure App Service task.태스크를 선택한다.

 

 

8. Deploy to Slot… 을 체크하고 Resource group 및 Slot을 전에 생성한 값으로 설정한다.

 

 

9. 릴리즈 파이프라인을 Save 한다.

 

 

10. 레이아웃 템플릿을 “3.0”에서 “4.0”으로 업데이트하여“PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Views/Shared/_Layout.cshtml”의 코드베이스에 대한 변경 사항을 커밋하려면 이전의 워크플로우우를 따른다.

 

 

 

11. 배포를 통해 릴리즈 파이프라인을 따르고 요청이 있을 때 릴리스를 프로덕션에 승인한다.

 

 

 

12. 프로덕션 배포가 완료되면 해당 브라우저 탭을 새로 고친다. 배포가 다른 슬롯으로 푸시 된 이후에는 변경 사항이 없어야 한다.

 

 

13. staging 슬롯으로 새 탭을 연 다. 이는 프로덕션 URL과 동일하지만 도메인 내 앱 서비스 이름에 "-staging"이 추가된다. 이것은 새로운 v4.0을 반영해야 한다.

 

 

14. Azure Portal에 열린 브라우저 창으로 돌아간다. 슬롯 블레이드에서 Swap을 클릭한다.

 

 

15. 여기서 기본 옵션은 정확히 우리가 원하는 것이며, 프로덕션 및 스테이징 슬롯을 교체한다. Swap을 클릭한다. 앱이 slot-level configuration settings (예 : 연결 문자열 또는 "슬롯"으로 표시된 앱 설정)에 의존하는 경우 작업자 프로세스가 다시 시작된다. 이러한 상황에서 작업 중이고 스왑이 완료되기 전에 앱을 예열하려는 경우 Swap with preview 스왑 유형을 선택할 수 있다.

 

 

16. 스테이징 슬롯이 아닌 prod 브라우저 창으로 돌아가서 새로 고친다. 이제 4.0 버전이 된다.