61. Eclipse와 Azure Repos 및 Azure Pipelines 통합하기 (추가편)
<참조> https://azuredevopslabs.com/labs/vstsextend/eclipse/
|
|
개요
이 실습에서는 Java 개발자의 일반적인 엔드투엔드 워크플로우를 볼 수 있다.
Part 1 : Eclipse와 Azure Repos 및 Azure Pipelines 통합하기 1, 2편의 실습을 완료하여 팀 프로젝트를 만들고, Eclipse를 설정하고, ACR에 이미지를 게시하고 애플리케이션을 Azure Web App에 배포하도록 Azure Pipeline을 구성해야 한다.
이 시나리오에서는 실행중인 MyShuttle 애플리케이션을 열고 버그를 발견한다. 그런 다음 탐색 테스트 확장을 사용하여 Azure DevOps 조직 계정에 버그 작업 항목을 만든다. 그런 다음 버그 수정을 위해 코드를 분기한다. 브랜치에서 버그가 수정되면 Pull Request 및 코드 검토를 통해 코드를 병합한다. 그러면 빌드/릴리즈 파이프라인이 자동으로 대기열에 추가되고 수정 사항이 배포된다.
Chrome 용 탐색 테스트 확장 프로그램 설치
이 과제에서는 Chrome에 Exploratory Testing 확장 프로그램을 설치한다. 지침에 따라 브라우저에 확장을 설치한다. 이 예에서는 Chrome 브라우저를 사용하고 있다.
1. 설치가 완료되면 Chrome 툴바의 오른쪽 상단에 비커 아이콘이 나타난다. 클릭하면 UI가 열린다.
2. 설정을 열려면 톱니 바퀴 아이콘을 클릭한다. Connected을 선택하고 Azure DevOps 조직 계정 URL을 입력하고 다음을 클릭한다. 그런 다음 팀 프로젝트를 선택하고 확장하고 기본 팀 (팀 프로젝트와 이름이 동일해야 함)을 선택한다. Save를 클릭한다.
참고 : 팀 이름은 다를 수 있다.
Exploratory Test Extension을 사용하여 버그 기록
이 과제에서는 테스트 세션을 시작하고 MyShuttle 앱에서 버그를 발견한 다음 Azure DevOps Organization에 기록한다.
1. 탐색 테스트 확장의 테스트 확장 도구 모음에서 재생 아이콘을 클릭하여 테스트 세션을 시작한다.
참고 : 테스트 확장 프로그램은 이제 모든 상호 작용을 기록한다. 테스트 아이콘 비커에는 세션이 현재 실행 중임을 나타내는 녹색 점이 있다.
2. 도구 모음에 http://{your web app name}/myshuttledev를 입력하여 애플리케이션으로 이동한다. 사용자 이름으로 fred를 입력하고 암호로 fredpassword를 입력하고 Log In을 클릭한다.
3. 대시 보드 페이지에서 Access Your Fare History를 클릭하여 운임 내역 페이지로 이동한다.
4. 표에서 운임 및 드라이버 열의 합계를 보면 Driver 열의 합계가 잘못되었음을 알 수 있다.
5. 테스트 확장 비커 아이콘을 클릭하고 카메라 아이콘 (이미지 캡처)을 클릭한다.
6. 잘못된 합계로 그리드를 캡처한다. 이미지에 적절하게 주석을 달고 체크 (accept) 아이콘을 클릭한다.
7. 테스트 확장 비커 아이콘을 클릭하고 페이지와 느낌표 (new bug)가 있는 아이콘의 플라이 아웃 (오른쪽 아래)을 클릭한다. 메뉴에서 Create bug를 클릭한다.
8. 제목 상자에 "Driver total incorrect"을 입력하고 Save를 클릭한다.
참고 : 방문한 모든 페이지, 메모, 스크린 샷 및 테스트 세션의 기타 정보가 버그에 대한 세부 정보로 포함되어 있으므로 이러한 세부 정보를 수동으로 추가 할 필요가 없다. 또한 제목 상자 옆에 "1 Similar"라는 버튼이 표시되어야 한다. Azure DevOps는 유사한 제목으로 이미 기록된 버그가 있는지 확인하여 기록되는 중복 버그를 최소화 한다.
9. 버그가 생성되면 테스트 확장 도구 모음에서 중지 버튼을 클릭하여 테스트 세션을 종료한다.
10. Azure DevOps 조직 팀 프로젝트로 이동한다. Boards를 클릭하여 작업 허브로 이동한다. 검색 도구 모음에서 작업 항목 검색 상자에 "driver"를 입력하고 Enter 키를 누르거나 돋보기 아이콘을 클릭한다. 기록한 버그가 표시되어야 한다. 잠시 시간을 내어 재현 단계를 살펴본다.
11. 자신에게 버그를 할당하고 상태를 승인됨으로 변경한다. Save를 클릭한다.
참고 : 이제 원인을 감지하고 버그에 대한 수정 사항을 찾기 위해 소매를 걷어 올릴 때이다. 그러나 코드를 변경하기 전에 branch를 생성한다. Git의 세계에서 팀은 일반적으로 마스터 브랜치 및 기타 작업에서 기능 또는 버그 수정에 대한 변경 사항을 격리하기 위해 새 브랜치를 만든다. 변경 사항을 커밋하고 원격 지점에 푸시한다. 그런 다음 변경 사항이 마스터 브랜치에 병합되기 전에 Pull Request를 통해 검토 및 승인을 위해 나머지 팀에게 제공된다. 모든 풀 요청에 대한 요구 사항을 설정하여 높은 품질의 코드를 보장하고 Branch Policy로 중요한 브랜치를 보호 할 수 있다.
분기 정책 구성
이 태스크에서는 브랜치 정책을 만들어 마스터 브랜치에 품질을 적용한다.
1. Azure DevOps 조직 프로젝트로 이동하고 Repos를 클릭한다.
2. Branches를 선택하고 마스터 브랜치의 줄임표 "..."를 선택한 다음 Branch Policies를 선택한다.
3. Check for linked work items을 선택하고 라디오 단추를 Required로 설정한다.
4. Build validation에서 + (Add new build policy)를 클릭하고 빌드 정의 목록에서 MyShuttleDockerBuild를 선택한 다음 Save를 클릭한다.
참고 : 주석 해결 및 최소 검토자 수와 같은 다른 정책 옵션을 적용하고 병합 옵션(예 : 스쿼싱)을 지정할 수 있다. 기본 검토자를 추가 할 수도 있다.
버그 수정
이 과제에서는 버그를 수정하기 위한 코드 브랜치를 만든다. 그런 다음 브랜치를 체크 아웃하고 버그를 수정하고 코드를 커밋한다.
그런 다음 풀 요청을 생성하여 수정 사항을 마스터에 병합하고 CI/CD 파이프라인이 자동으로 수정 사항을 개발 환경에 배포하는 것을 확인한다.
1. 아직 열려 있지 않은 경우 Eclipse를 연다. MyShuttleDocker 프로젝트를 연다.
2. Team Explorer에서 드롭 다운을 Work Items으로 변경한다. 드롭 다운에 작업 항목이 표시되지 않으면 팀 탐색기 홈 페이지를 통해 Azure DevOps 조직 계정에 연결한다.
3. Boards에 저장된 질의가 없는 경우 Eclipse에서 질의를 생성 할 수 있다. 내 쿼리 폴더를 마우스 오른쪽 단추로 클릭하고 New Query를 선택한다.
4. 기존 쿼리를 두 번 클릭하여 실행할 수 있다. 공유 쿼리 아래에서 Bugs 쿼리를 두 번 클릭하여 프로젝트의 버그 목록을 가져온다.
5. Driver total incorrect 버그를 선택하고 두 번 클릭하여 브라우저에서 연다.
6. 줄임표 버튼 ...을 클릭하고 New branch…를 선택하여 새 브랜치를 만든다.
7. 대화 상자에서 분기 이름을 fixtotalsBug로 변경하고 브랜치 생성을 클릭하다. 작업 항목이 이미 브랜치에 연결되어 있다.
8. Eclipse로 돌아간다. Eclipse의 프로젝트보기에서 프로젝트를 마우스 오른쪽 단추로 선택하고 Team을 선택한 다음 Pull…을 선택하여 방금 만든 새 브랜치를 포함하여 최신 변경 사항을 가져온다. 다음 팝업에서 Finish를 클릭하고 메시지가 나타나면 암호를 입력하여 작업을 완료한다.
9. 새 브랜치로 전환하려면 Team, Switch to…을 선택하고 Other를 선택한다.
10. Remote Tracking을 펼치고 origin/fixtotalbugs 브랜치를 선택하고 체크 아웃을 클릭한다. 결과 대화 상자에서 Check out as a local branch 옵션을 선택하고 다음 창에서 Finish를 클릭하여 작업을 완료한다.
11. src/main/java/com.microsoft.example.servlet을 찾아 LoginServlet 클래스를 연다.
12. 35 행 주변에서 버그의 원인이 무엇인지 확인할 수 있다. totalDriverFee가 계산되고 있지만 driverFeeTotal 세션 속성이 totalFareForDriver로 설정된다 (이는 전형적인 복사/붙여 넣기 오류처럼 보인다.)
이 코드 줄을
|
session.setAttribute("driverFeeTotal", totalFareforDriver); |
다음으로 변경한다.
|
session.setAttribute("driverFeeTotal", totalDriverFee); |
13. 파일을 저장한다. 파일을 마우스 오른쪽 버튼으로 클릭하고 Team->Commit을 선택하여 변경 사항을 적용한다. 커밋 메시지로 Fixing totals bug #{ID of bug}를 입력한다. 커밋 메시지에 # 기호 뒤에 작업 항목의 ID를 입력하면 Azure DevOps는 서버에 푸시 될 때 작업 항목을 커밋과 자동으로 연결한다. 스크린 샷의 예에서 ID는 #728이다. Commit and Push를 클릭하여 변경 사항을 Azure DevOps 조직에 푸시한다.
14. 이제 브랜치의 Azure DevOps에 수정 사항이 푸시되었으므로 Pull Request을 만들 수 있다. 이는 풀 요청에 대한 표준 프로세스에 따라 Azure DevOps에서 수행된다. Repos 허브에서 MyShuttleDocker repo의 파일을 클릭하면 fixtotalsBug 브랜치를 업데이트했다는 알림이 표시되어야 한다. 옆에있는 링크를 클릭하고 Create a pull request 한다.
15. 그런 다음 풀 요청 패널에서 Create를 클릭하여 풀 요청을 만든다. 버그는 커밋과 관련이 있다.
16. PR이 생성되면 빌드가 실행되고 있음을 알 수 있다 (이전에 설정한 브랜치 정책에서 요구하는 빌드 임). 빌드를 완료하는 데 7-10 분 정도 걸린다.
참고 : 병합 충돌이 있는 경우 Azure DevOps는 개요 페이지에서 경고한다. 이 효과에 대한 경고가 없으면 Git은 PR을 대상 브랜치에 자동 병합 할 수 있다. 마스터 브랜치에서 성공적인 빌드를 사용할 수 있을 때만 트리거하도록 릴리즈를 구성했다. 이 빌드는 마스터 브랜치에서 빌드되지 않으므로 이러한 변경 사항은 아직 배포되지 않는다.
17. 파일 탭을 클릭하여 파일 비교를 연다. 변경 사항을 확인한다.
참고 : PR의 코드 또는 파일에 대해 주석을 달 수 있으며 검토 프로세스 동안 팀과 대화 할 수 있다.
18. 풀 요청을 승인하려면 Approve를 클릭한다.
19. 이제 정책이 이행되었으므로 변경 사항을 마스터 (대상 브랜치)에 병합할 PR을 완료 할 수 있다. 병합을 수행하려면 Complete를 클릭한다.
20. 대화 상자에서 기본값을 승인(기본값이 변경됨. 필요 시 두 옵션 체크)하고 Complete merge를 클릭한다.
21. PR 완료는 CI 트리거가 설정된 경우 마스터 브랜치에서 새 빌드를 트리거하고 CD 트리거가 활성화 된 경우 릴리즈를 트리거한다. 활성화되지 않은 경우 Pipelines 아래에서 Builds를 클릭하고 정의에 대한 새 빌드 MyShuttleDockerBuild를 대기열에 추가한다. (트리거 설정이 안되어 있으며 수동으로 빌드 실행이 필요하다.) 또한 버그 작업 항목을 Resolved 상태로 전환한다.
22. 빌드가 완료되면 단위 테스트 및 코드 커버리지 결과와 SonarQube 분석 및 품질 게이트 (SonarQube 통합을 구성한 경우)가 표시된다.
23. 릴리즈를 클릭하고 PR 병합 빌드 완료 이벤트를 CD로 트리거해야하는 최신 릴리즈를 연다. CD가 활성화되지 않은 경우 Pipelines에서 Releases를 클릭하고 정의-MyShuttleDockerRelease에 대한 새 릴리즈를 대기열에 추가한다.
24. 릴리즈 요약 페이지에서 링크된 버그 작업 항목을 볼 수 있다.
25. 커밋을 클릭하면 이 릴리즈에 대한 수신 커밋을 볼 수 있다. 버그를 수정하기 위한 커밋과 마스터로 병합하기 위한 커밋이 있다.
26. MyShuttle 애플리케이션으로 돌아간다. 다시 로그인하여 합계 열이 정확하고 버그가 수정되었는지 확인한다.
