이전

다음

연습 - 끌어오기 요청 만들기

완료됨

이 단원에서는 모든 사람이 내 작업을 활용할 수 있도록 끌어오기 요청을 제출하고 변경 내용을 main 분기에 병합하는 프로세스를 연습합니다.

Azure Pipelines를 사용하여 빌드 파이프라인 만들기에서는 Space Game 웹 사이트의 기본 빌드 파이프라인을 정의한 build-pipeline이라는 Git 분기를 만들었습니다. 빌드 정의는 azure-pipelines 파일에 있다는 걸 기억하세요.

분기는 빌드 아티팩트를 생성하지만 해당 작업은 build-pipeline 분기에만 존재합니다. 분기를 main 분기에 병합해야 합니다.

끌어오기 요청은 다른 개발자에게 코드를 검토할 준비가 되었음을 알려주며 필요한 경우 변경 내용을 다른 분기(예:main 분기)에 병합하려고 합니다.

시작하기 전에 Mara, Andy와 함께 확인해보겠습니다.

Andy: 안녕하세요, Mara. Azure에서 실행 중인 빌드 파이프라인이 있죠. 웹 사이트에 기능을 추가하고 있는데 직접 빌드 프로세스를 확인하고 싶어요. 확인할 준비가 되었을까요?

Mara: 물론이죠. 제가 분기에 파이프라인을 만들었습니다. 끌어오기 요청을 만들고 main에 병합해서 Andy도 파이프라인을 사용할 수 있도록 하는 건 어떨까요?

Andy: 그거 좋네요. 살펴보겠습니다.

분기 만들기 및 시작 코드 추가

이전 모듈에서 빌드한 빌드 파이프라인을 사용할 수 있지만 code-workflow라는 새 분기를 만들어 보겠습니다. 이 분기는 main 기반으로 하므로 처음부터 프로세스를 연습할 수 있습니다.

1. Visual Studio Code에서 통합 터미널을 엽니다.

2. main 분기로 전환합니다.

   git checkout main
   

3. GitHub의 최신 버전 코드가 있는지 확인합니다.

   git pull origin main
   

4. code-workflow라는 분기를 만듭니다.

   git checkout -B code-workflow
   

   -b 인수는 새 분기가 없는 경우 새로 만들도록 지정합니다. 기존 분기로 전환하려면 -b 인수를 생략합니다.

   기본적으로 새 분기는 git checkout 명령을 실행한 이전 분기를 기반으로 빌드됩니다. 여기서 부모 분기는 main입니다. 그러나 부모 분기는 다른 분기(예: 다른 사용자가 시작한 기능 분기 중 빌드하거나 실험하려는 분기)일 수 있습니다.

   이제 나만의 로컬 분기에 있기 때문에 필요한 모든 변경 작업을 마음 놓고 수행할 수 있습니다. 작업 중인 분기를 확인하려면 git branch -v를 실행합니다.

5. 파일 탐색기에서 azure-pipelines.yml을 열고 해당 내용을 다음으로 바꿉니다.

   trigger:
   - '*'
   
   pool:
     vmImage: 'ubuntu-20.04'
     demands:
     - npm
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - $(buildConfiguration)'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration $(buildConfiguration)'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - $(buildConfiguration)'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
       zipAfterPublish: true
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   이 구성은 이전 모듈에서 만든 기본 구성과 유사합니다. 간단하게 보여 드리기 위해 프로젝트의 릴리스 구성만 빌드합니다.

GitHub에 분기 푸시

여기서 code-workflow 분기를 GitHub로 푸시하고 Azure Pipelines가 애플리케이션을 빌드하는 것을 봅니다.

1. 터미널에서 git status를 실행하여 분기에 존재하는 커밋되지 않은 작업을 확인합니다.

   git status
   

   azure-piplines.yml이 수정된 것으로 표시됩니다. 곧 분기에 커밋할 예정이지만 먼저 Git에서 해당 파일을 추적하고 있는지 즉, 파일을 스테이징하고 있는지 확인해야 합니다.

   git commit을 실행할 때에는 스테이징된 변경 내용만 커밋됩니다. 그런 다음 git add 명령을 실행하여 azure-pipelines.yml을 준비 영역 또는 인덱스에 추가합니다.

2. 다음 git add 명령을 실행하여 준비 영역에 azure-piplines.yml을 추가합니다.

   git add azure-pipelines.yml
   

3. 다음 git commit 명령을 실행하여 스테이징된 파일을 code-workflow 분기로 커밋합니다.

   git commit -m "Add the build configuration"
   

   -m 인수는 커밋 메시지를 지정합니다. 커밋 메시지는 변경된 파일의 기록에 포함되며, 검토자가 변경 내용을 이해하는 데 도움이 되고 향후 유지 관리자가 시간이 지남에 따라 파일이 어떻게 변경되었는지 파악할 수 있습니다.

   팁

   가장 적절한 커밋 메시지는 “이 커밋을 적용하면...”으로 문장을 시작합니다.

   -m 인수를 생략하면 Git은 변경을 자세히 확인할 수 있는 텍스트 편집기를 표시합니다. 이 옵션은 여러 줄에 걸쳐 있는 커밋 메시지를 지정하려는 경우에 유용합니다. 첫 번째 빈 줄까지의 텍스트는 커밋 제목을 지정합니다.

4. git push 명령을 실행하여 code-workflow 분기를 GitHub의 리포지토리로 푸시하거나 업로드합니다.

   git push origin code-workflow
   

5. 선택적 단계로, Azure Pipelines의 프로젝트로 이동하여 실행되는 빌드를 추적합니다.

   해당 빌드를 CI 빌드라고 합니다. 파이프라인 구성에서는 트리거를 사용하여 빌드 프로세스에 참여하는 분기를 제어합니다. 여기에서 “*”는 모든 분기를 지정합니다.

   trigger:
   - '*'
   

   나중에 필요한 분기에서만 빌드하려면 파이프라인 구성을 제어하는 방법을 확인할 수 있습니다.

   빌드가 완료되고 빌드된 웹 애플리케이션이 포함된 아티팩트를 생성하는 것을 볼 수 있습니다.

끌어오기 요청 만들기

여기에서 분기에 대해 끌어오기 요청을 만듭니다.

1. 브라우저에서 GitHub에 로그인합니다.

2. mslearn-tailspin-spacegame-web 리포지토리로 이동합니다.

3. 분기 드롭다운 목록에서 code-workflow 분기를 선택합니다.

   

4. 끌어오기 요청을 시작하려면 참가를 선택하고 끌어오기 요청 열기를 선택합니다.

   

5. 베이스가 Microsoft 리포지토리가 아니라 포크된 리포지토리를 지정하는지 확인합니다.

   여기서 선택한 항목은 아래 그림과 같습니다.

   

   Important

   Microsoft 리포지토리에 변경 내용을 병합할 수 없기 때문에 이 단계가 중요합니다. 베이스 리포지토리가 MicrosoftDocs가 아닌 GitHub 계정을 가리키는지 확인합니다.

   MicrosoftDocs에 대해 끌어오기 요청을 종료하는 경우 끌어오기 요청을 닫고 이와 같은 단계를 반복하면 됩니다.

   포크된 리포지토리에서 작업 중이기 때문에 이 프로세스에는 추가 단계가 있습니다. 포크가 아니라 사용자 고유의 리포지토리를 사용하여 직접 작업하는 경우 main 분기가 기본적으로 선택됩니다.

6. 끌어오기 요청의 제목 및 설명을 입력합니다.

   • 제목:

     Azure Pipelines 구성

   • 설명:

     이 파이프라인 구성은 애플리케이션을 빌드하고 릴리스 구성을 위한 빌드를 생성합니다.

7. 끌어오기 요청을 완료하려면 끌어오기 요청 만들기를 선택합니다.

   이 단계에서는 어떤 코드도 병합하지 않고, main 분기에 병합할 변경 사항을 제안했음을 다른 사용자에게 알립니다.

   

   끌어오기 요청 창이 표시됩니다. Azure Pipelines의 빌드 상태가 끌어오기 요청의 일부로 나타나도록 구성된 것을 볼 수 있습니다. 이렇게 하면 사용자와 다른 사용자에게 빌드 상태가 실행 중인 것으로 표시될 수 있습니다.

   

   분기를 GitHub로 푸시할 때와 마찬가지로, 끌어오기 요청은 기본적으로 Microsoft Azure Pipelines를 트리거하여 애플리케이션을 빌드합니다.

   팁

   빌드 상태가 바로 표시되지 않으면 잠시 기다리거나 페이지를 새로 고칩니다.

8. 필요에 따라 세부 정보 링크를 선택한 다음, 파이프라인을 통해 이동할 때 빌드를 추적합니다.

   프로세스의 다음 단계(예: QA)에 빌드를 전달할 수 있습니다. 나중에 변경 내용을 QA 랩 또는 프로덕션까지 푸시하는 파이프라인을 구성할 수 있습니다.

9. GitHub에서 끌어오기 요청으로 돌아갑니다.

   빌드가 완료될 때까지 기다립니다. 이제 끌어오기 요청을 병합할 준비가 완료되었습니다.

   

10. Merge pull request(끌어오기 요청 병합)를 선택하고 Confirm merge(병합 확인)를 선택합니다.

11. GitHub에서 code-workflow 분기를 삭제하려면 분기 삭제를 선택합니다.

    

    끌어오기 요청을 병합한 후에는 GitHub에서 분기를 삭제하는 것이 안전합니다. 사실, 분기가 더 이상 필요하지 않으므로 일반적인 방법입니다. 변경 내용이 병합되고 GitHub 또는 명령줄에서 변경 내용에 대한 세부 정보를 찾을 수 있습니다. 병합된 분기를 삭제하면 현재 활성 상태인 작업만 볼 수 있습니다.

    Git 분기는 수명이 짧습니다. 분기를 병합한 후에는 해당 분기에 추가 커밋을 푸시하지 않거나 두 번째로 병합하지 않습니다. 대부분의 경우에는 새 기능 또는 버그 수정을 시작할 때마다 main 분기를 기반으로 한 클린 분기로 시작합니다.

    GitHub에서 분기를 삭제해도 해당 분기가 로컬 시스템에서 삭제되지는 않습니다. 삭제하려면 -d 스위치를 git branch 명령으로 전달합니다.

변경 빌드 횟수는 몇 번인가요?

해답은 빌드 구성이 정의되는 방식에 따라 달라집니다. Azure Pipelines를 사용하면 빌드를 수행할 이벤트를 지정하는 트리거를 정의할 수 있습니다. 어떤 분기를 빌드할지 또는 어떤 파일이 빌드를 트리거할지 제어할 수 있습니다.

예를 들어 Git 분기에서 변경 내용이 GitHub에 푸시될 때 빌드를 수행하려는 경우를 가정해보겠습니다. 그러나 프로젝트의 docs 폴더에 있는 파일만 변경되는 경우에는 빌드가 발생하지 않도록 하려고 합니다. 빌드 구성에 trigger 섹션을 포함하고 싶을 수 있습니다.

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

기본적으로 모든 분기의 한 파일에 변경 내용이 푸시될 때 빌드가 트리거됩니다.

CI(연속 통합) 빌드는 분기에 대한 변경 내용을 푸시할 때 실행되는 빌드입니다.

PR(끌어오기 요청) 빌드는 끌어오기 요청을 열거나 기존 끌어오기 요청에 대한 추가 변경 내용을 푸시할 때 실행되는 빌드입니다.

code-workflow 분기를 통해 변경된 내용은 다음과 같은 세 가지 조건으로 빌드됩니다.

• CI 빌드는 code-workflow 분기에 변경 내용을 푸시할 때 발생합니다.
• main 분기에 대해 code-workflow 분기에 대해 끌어오기 요청을 열면 PR 빌드가 발생합니다.
• 최종 CI 빌드는 끌어오기 요청이 main 분기에 병합된 후에 발생합니다.

PR 빌드를 사용하면 제안된 변경 내용이 main 또는 다른 대상 분기에 병합된 후 제대로 작동하는지 확인할 수 있습니다.

최종 CI 빌드는 PR이 병합된 후 변경 내용이 여전히 유효한지 확인합니다.

원하는 경우 Azure Pipelines로 이동하여 최종 CI 빌드가 main 분기에서 발생하는 것을 볼 수 있습니다.

계속