다음을 통해 공유


지속적인 통합을 사용하여 소프트웨어 개발 현대화

코드가 개발, 업데이트 또는 제거될 때 이러한 변경 내용을 기본 코드 분기에 통합하는 직관적이고 안전한 방법을 사용하면 개발자가 가치를 제공할 수 있습니다.

개발자는 작은 코드 변경을 수행하고 이러한 변경 사항을 코드 리포지토리에 푸시하며 품질, 테스트 범위 및 발생한 버그에 대한 거의 즉각적인 피드백을 얻을 수 있습니다. 이 프로세스를 통해 더 빠르고 자신감을 갖고 위험을 줄이면서 작업할 수 있습니다.

CI(연속 통합)는 소프트웨어 개발 팀을 위한 자동화된 빌드, 테스트 및 피드백 메커니즘을 제공하기 위해 소스 제어 시스템 및 소프트웨어 배포 파이프라인을 통합하는 방법입니다.

연속 통합 프로세스는 엔지니어가 코드 변경 사항을 통합할 준비가 되었음을 CI 시스템에 알리기 위해 GitHub 끌어오기 요청을 생성할 때 시작됩니다. 이상적으로 통합 프로세스는 여러 기준 및 테스트를 기준으로 코드의 유효성을 검사합니다. 그런 다음 요청한 엔지니어에게 이러한 테스트 상태에 대한 피드백을 제공합니다.

기준 검사 및 테스트가 잘 진행되면 통합 프로세스는 업데이트된 소프트웨어를 배포할 자산을 생성하고 단계별로 작성합니다. 이러한 자산에는 컴파일된 코드와 컨테이너 이미지가 포함됩니다.

연속 통합은 다음 작업을 수행하여 고품질 소프트웨어를 더 빠르게 제공하는 데 도움이 될 수 있습니다.

  • 코드에 대해 자동화된 테스트를 실행하여 주요 변경 사항을 조기에 감지합니다.
  • 코드 분석을 실행하여 코드 표준, 품질 및 구성을 확인하세요.
  • 규정 준수 및 보안 검사를 실행하여 소프트웨어에 알려진 취약성이 없는지 확인합니다.
  • 승인 또는 기능 테스트를 실행하여 소프트웨어가 예상대로 작동하는지 확인하십시오.
  • 감지된 문제에 대해 빠른 피드백을 제공합니다.
  • 해당하는 경우 업데이트된 코드가 포함된 배포 가능한 자산 또는 패키지를 생성합니다.

파이프라인과의 연속 통합 자동화

지속적인 통합을 달성하려면 소프트웨어 솔루션을 사용하여 프로세스를 관리, 통합 및 자동화합니다. 일반적인 방법은 연속 통합 파이프라인을 사용하는 것입니다.

연속 통합 파이프라인에는 다음을 제공하는 소프트웨어(종종 클라우드 호스팅)가 포함됩니다.

  • 자동화된 테스트를 실행하기 위한 플랫폼입니다.
  • 규정 준수 검사.
  • 보고.
  • 연속 통합 프로세스를 구성하는 다른 모든 구성 요소입니다.

대부분의 경우 파이프라인 소프트웨어는 소스 제어에 연결되므로 끌어오기 요청이 생성되거나 소프트웨어가 특정 분기에 병합될 때 연속 통합 파이프라인이 실행됩니다. 소스 제어 통합은 끌어오기 요청에 대해 직접 CI 피드백을 제공할 수 있는 기회도 제공합니다.

Azure Pipelines 또는 GitHub Actions와 같은 많은 솔루션은 연속 통합 파이프라인 기능을 제공합니다.

소스 제어와 파이프라인 통합

연속 통합 파이프라인과 소스 제어 시스템의 통합은 빠른 셀프 서비스 코드 기여를 가능하게 하는 핵심입니다.

CI 파이프라인은 새로 생성된 끌어오기 요청에서 실행됩니다. 파이프라인에는 모든 테스트, 보안 평가 및 기타 검사가 포함됩니다. CI 테스트 결과는 품질에 대한 거의 실시간 피드백을 허용하기 위해 끌어오기 요청에 직접 표시됩니다.

또 다른 인기 있는 방법은 현재 빌드 상태를 표시하기 위해 소스 제어에 표시할 수 있는 작은 보고서나 배지를 작성하는 것입니다.

다음 이미지는 GitHub와 Azure DevOps 파이프라인 간의 통합을 보여 줍니다. 이 예제에서는 끌어오기 요청을 만들면 Azure DevOps 파이프라인이 트리거됩니다. 파이프라인 상태가 끌어오기 요청에 표시됩니다.

GitHub 리포지토리의 Azure DevOps 상태 배지 스크린샷

자동화된 테스트 통합

연속 통합의 핵심 요소는 개발자가 코드에 기여할 때 코드를 지속적으로 빌드하고 테스트하는 것입니다. 끌어오기 요청을 생성할 때 즉시 테스트하면 커밋이 기능을 망가뜨리는 변경을 도입하지 않았다는 빠른 피드백을 받을 수 있습니다. 장점은 연속 통합 파이프라인의 테스트가 테스트 기반 개발 중에 실행되는 테스트와 동일할 수 있다는 것입니다.

다음 코드 조각은 Azure DevOps 파이프라인의 테스트 단계를 보여 줍니다. 이 단계에는 다음 두 가지 작업이 있습니다.

  • 첫 번째 작업은 인기 있는 Python 테스트 프레임워크를 사용하여 CI 테스트를 실행합니다. 이러한 테스트는 Python 코드와 함께 소스 제어에 상주합니다. 테스트 결과는 test-results.xml파일로 이동합니다.
  • 두 번째 작업은 테스트 결과를 사용하고 Azure DevOps 파이프라인에 통합 보고서로 게시합니다.
- script: |
    pip3 install pytest
    pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
    continueOnError: true

- task: PublishTestResults@2
    displayName: 'Publish Test Results'
    inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Python $(python.version)'

다음 이미지는 Azure DevOps 포털에 표시되는 테스트 결과를 보여 줍니다.

Azure DevOps 포털의 Azure DevOps 파이프라인 테스트 스크린샷

실패한 테스트

실패한 테스트는 일시적으로 배포를 차단하고 발생한 상황에 대한 심층 분석으로 이어져야 합니다. 또한 실패한 테스트는 테스트를 개선하거나 테스트 실패의 원인이 된 변경 사항을 개선해야 합니다.

빌드 상태 게시

많은 개발자는 리포지토리에 상태 배지를 표시하여 코드 품질이 높다는 것을 보여 줍니다. 다음 이미지는 GitHub의 오픈 소스 프로젝트에 대한 추가 정보 파일에 표시되는 Azure Pipelines 배지를 보여 줍니다.

GitHub의 추가 정보 파일에 있는 Azure Pipelines 배지의 스크린샷

빌드 시간 최적화

더 빠른 빌드를 수행하려면 다음을 수행할 수 있습니다.

  • 성능 요구 사항을 충족하는 에이전트를 선택합니다. 올바른 빌드 머신을 선택하여 빌드 속도를 향상합니다. 빠른 머신은 시간과 분 사이의 차이를 만들 수 있습니다. 파이프라인이 Azure Pipelines에 있는 경우 Microsoft 호스팅 에이전트를 사용하여 작업을 실행할 수 있습니다. Microsoft 호스팅 에이전트를 사용하는 경우 유지 관리 및 업그레이드가 처리됩니다. 자세한 내용은 Microsoft 호스팅 에이전트를 참조하세요.

  • 빌드 서버 위치 최적화: 코드를 빌드할 때 데이터가 유선으로 전송됩니다. 빌드에 대한 입력은 소스 제어 리포지토리 및 아티팩트 리포지토리에서 가져옵니다. 컴파일된 아티팩트, 테스트 보고서, 코드 검사 결과 및 디버그 기호를 포함하여 빌드 프로세스의 출력을 복사해야 합니다. 이러한 복사 작업을 신속하게 실행하는 것이 중요합니다. 사용자 고유의 빌드 서버를 사용하는 경우 빌드 서버가 원본 및 대상 위치 근처에 있는지 확인합니다. 빠른 업로드 및 다운로드는 전체 빌드 시간을 줄일 수 있습니다.

  • 빌드 서버 확장: 단일 빌드 서버는 소규모 제품에 충분할 수 있습니다. 제품의 크기와 범위 및 제품 작업 팀 수가 증가함에 따라 단일 서버로는 충분하지 않을 수 있습니다. 한도에 도달하면 여러 머신에서 수평으로 인프라 크기를 조정합니다. 자세한 내용은 에이전트 풀 만들기 및 관리를 참조하세요.

  • 빌드 최적화:

    • 병렬 작업을 추가하여 빌드 프로세스 속도를 향상합니다. 병렬 작업을 구성하고 결제하는 방법에 대한 자세한 내용은 를 참조하세요.

    • 특히 통합 및 UI 테스트를 실행할 때 많은 시간을 절약하는 병렬 테스트 도구 모음 실행을 사용하도록 설정합니다. 자세한 내용은 모든 테스트 실행기를 병렬로 테스트 실행을 참조하세요.

    • 여러 빌드 에이전트를 통해 빌드를 확장할 수 있는 승수 개념을 사용합니다. 자세한 내용은 파이프라인에서 작업 지정을 참조하세요.

    • 통합, UI 및 스모크 테스트를 릴리스 파이프라인으로 이동하는 것이 좋습니다. 릴리스 파이프라인으로 이동하면 빌드 속도와 빌드 피드백 루프의 속도가 향상됩니다.

    • NuGet 또는 Maven과 같은 패키지 관리 솔루션에 빌드 아티팩트를 게시합니다. 패키지 관리 솔루션에 게시하면 빌드 아티팩트를 더 쉽게 다시 사용할 수 있습니다.

워크플로에 맞게 빌드 형식 구현

조직에서 빌드 시간을 최적화하기 위해 여러 종류의 빌드를 만들도록 선택할 수 있습니다. 가능한 빌드는 다음과 같습니다.

  • CI(연속 통합) 빌드: 이 빌드의 목적은 코드가 컴파일되고 단위 테스트가 실행되도록 하는 것입니다. 이 빌드는 각 커밋에서 트리거됩니다. 프로젝트의 하트비트 역할을 하며 팀 im_imagestely 품질 피드백을 제공합니다. 자세한 내용은 파이프라인을 트리거하는 이벤트 지정을 참조 하세요.

  • 야간 빌드: 야간 빌드의 목적은 코드를 컴파일하는 것뿐만 아니라 각 빌드에서 비효율적일 수 있는 더 큰 테스트 스위트를 주기적으로 실행하는 것입니다. 일반적으로 이러한 테스트에는 통합, UI 또는 스모크 테스트가 포함됩니다. 자세한 내용은 파이프라인의 일정 구성을 참조하세요.

  • 릴리스 빌드: 이 빌드는 테스트를 컴파일하고 실행하는 것 외에도 코드가 빌드될 때마다 필요하지 않은 API 설명서, 규정 준수 보고서, 코드 서명 및 기타 단계를 컴파일합니다. 이 빌드는 최종적으로 프로덕션 환경에 배포하기 위해 릴리스 파이프라인에 푸시되는 골든 복사본을 제공합니다.

조직에서 필요한 빌드 유형은 팀과 조직의 완성도, 작업 중인 제품의 종류 및 배포 전략을 포함한 요인에 따라 달라집니다.

GitHub 또는 Azure DevOps를 사용하여 연속 통합 파이프라인을 만드는 방법을 알아봅니다.

리포지토리에 배지를 표시하는 방법을 알아봅니다.