연속적으로 빌드 및 배포

많은 개발자가 참여하는 복잡한 소프트웨어 프로젝트의 경우 여러 코드 부분을 통합하는 프로세스는 오래 걸리고 예측하기 힘듭니다. 그러나 프로젝트를 연속적으로 빌드하고 배포하면 이 프로세스를 보다 효율적이고 안정적으로 수행할 수 있습니다.

CI(연속 통합)는 코드를 가능한 한 자주 공유 리포지토리에 통합하는 프로세스입니다. 코드 통합 중에는 빌드 중단이나 테스트 실패를 통해 코드에 오류가 있음을 적시에 확인할 수 있습니다.

Martin Fowler는 연속 통합을 위한 방법을 다음과 같이 세부적으로 설명하고 있습니다.

• 단일 소스 리포지토리를 유지 관리합니다.

• 빌드를 자동화합니다.

• 빌드를 자립적으로 만듭니다.

• 하루에 한 번 이상 체크 인합니다.

• 각 체크 인을 CI 서버에서 빌드합니다.

• 빌드를 빠르게 유지합니다.

• 프로덕션 환경의 복제본에서 테스트합니다.

• 누구나 가장 최신의 실행 파일을 쉽게 얻을 수 있도록 합니다.

• 현재 진행되고 있는 작업을 항상 파악하고 있습니다.

• 배포를 자동화합니다.

자세한 내용은 Martin Fowler의 웹 사이트에서 Continuous Integration 페이지를 참조하십시오.

Visual Studio ALM(Application Lifecycle Management)은 소프트웨어 개발의 전 과정을 쉽게 관리할 수 있도록 해 주며 연속 통합 방법을 지원합니다. Visual Studio ALM의 기능을 이용하면 프로젝트에서 예기치 않은 지연, 비용 초과 및 실행 위험을 방지할 수 있습니다.

항목 내용

• 종속성 관리

• Visual Studio 2010의 연속 통합

• 준비 및 시작

• 버전 제어

• Build

• 테스트 및 배포

• 프로젝트 통합 및 정보 교환

종속성 관리

코드 간에는 종속성이 있으므로 코드를 통합하는 것은 복잡한 과정입니다. 예를 들어 화면에 원을 그리는 라이브러리에서는 시스템 수학 라이브러리의 Sqrt() 메서드를 사용해야 합니다. Sqrt() 메서드가 변경되면 그에 따라 라이브러리를 업데이트해야 합니다. 하드웨어와 운영 체제는 팀 프로젝트보다는 변경되는 빈도가 적지만 환경의 변경 사항을 무시하면 막대한 결과를 초래할 수 있습니다. 코드를 가능한 한 빨리 통합하면 코드가 올바른 가정을 기초로 하는지 여부와 계획한 대로 동작하는지 여부를 확인할 수 있습니다.

코드의 변경 사항은 다른 방식으로 종속성에 영향을 줄 수 있습니다. 다음 그림에서는 두 가지 상황을 보여 줍니다. 왼쪽의 예에서는 비교적 고립된 변경 사항을 보여 줍니다. 그러나 오른쪽의 예에서는 종속성이 커서 잠재적인 영향이 더 클 수 있는 변경 사항을 보여 줍니다.

다음 그림에서는 코드를 연속적으로 통합하고 업그레이드하지 않고 계속해서 변경할 경우에 미칠 수 있는 복합적인 영향을 보여 줍니다.

1단계에서는 코드 블록 h가 변경되어 해당하는 모든 종속 코드 블록 a, b, d, e 및 f가 영향을 받을 수 있습니다. 2단계에서는 코드 블록 a와 b가 모두 변경됩니다. 팀이 1단계와 2단계 사이에서 통합을 수행하지 않으면 블록 a 및 b는 더 이상 유효하지 않게 될 수 있습니다. 3단계에서는 코드 블록 f가 변경됩니다. 팀이 2단계와 3단계에서 통합을 수행하지 않았다면 이 시점에서 코드 블록 b는 영향을 받고, 변경된 후, 다시 영향을 받은 것이 됩니다. 따라서 코드 블록 b를 수정해야 하는 상황이 될 수 있습니다.

Visual Studio 2010의 연속 통합

Visual Studio ALM에서는 연속 통합을 지원하기 위한 통합 도구 집합을 제공합니다. 다음 그림에서 보여 주는 것과 같이 이러한 도구에는 버전 제어, 빌드, 테스트, 랩 환경에 배포, 작업 항목 추적 및 데이터 웨어하우징 기능이 포함되어 있습니다.

먼저, Team Foundation 버전 제어를 사용하여 분기, 변경 집합 및 이들 간의 통합을 관리할 수 있습니다. 각 팀 멤버는 작업 영역을 사용하여 개별적으로 작업할 수 있습니다. 자세한 내용은 분기 및 병합 및 팀 프로젝트에 사용할 수 있도록 작업 영역 만들기을 참조하십시오.

두 번째로, Team Foundation Build를 사용하여 자동화된 분산 시스템에서 소프트웨어를 컴파일, 테스트 및 배포할 수 있습니다. 이전 그림에서처럼 Team Foundation Build에는 두 종류의 빌드가 있습니다. 한 종류는 연속 빌드 형식을 사용하여 개발 분기를 빌드합니다. 다른 종류는 제어된 체크 인 빌드 형식을 사용하여 Main 분기를 빌드합니다. Visual Studio Team Foundation Server에서 지원되는 빌드 형식은 수동, 연속(체크 인이 수행될 때마다 트리거됨), 롤링(이전 빌드가 완료될 때까지 체크 인 누적), 제어된 체크 인 및 일정의 다섯 가지가 있습니다. 자세한 내용은 기본 빌드 정의 만들기, Team Foundation Build 시스템 이해 및 제어된 체크 인 빌드에 의해 제어되는 보류 중인 변경 내용 체크 인을 참조하십시오.

세 번째로, Visual Studio ALM의 랩 관리 기능은 빌드를 정의하고 실제 환경과 가상 랩 환경 모두에 배포하는 데 유용합니다. 특정 환경에서 런타임에 발생하는 통합 오류를 파악하기 위해 빌드를 랩 환경에 배포한 다음 이 빌드에 대해 테스트 도구 모음을 실행할 수 있습니다. 자세한 내용은 응용 프로그램 수명 주기에 가상 랩 사용을 참조하십시오.

또한 팀 멤버의 컴퓨터, 빌드 컴퓨터 및 랩 환경 내부에서도 Visual Studio ALM의 테스트 기능을 사용할 수 있습니다. 첫 번째로, 개발자의 컴퓨터에서 테스트 도구 모음을 실행하면 최근에 만들거나 변경된 코드와 관련된 문제를 파악할 수 있습니다. 두 번째로, 빌드 컴퓨터에서 테스트를 실행하면 다른 코드와 통합할 때의 문제를 파악할 수 있습니다. 세 번째로, 랩에서 테스트를 실행하면 팀에서 구성하는 특정 환경과 관련된 문제를 파악할 수 있습니다. 자세한 내용은 방법: 응용 프로그램을 빌드한 후 예약된 테스트 구성 및 실행을 참조하십시오.

참고

테스트를 실행하면 테스트 사례를 통해 검사할 수 있는 코드 범위를 파악하는 데 사용할 수 있는 코드 검사 메트릭을 생성할 수 있습니다. 그러나 코드 검사를 사용하여 테스트 완료 여부나 품질을 측정할 수는 없습니다. 자세한 내용은 방법: 자동화된 테스트에 대한 테스트 설정을 사용하여 코드 검사 구성을 참조하십시오.

네 번째로, Visual Studio Team Foundation Server는 작업 항목을 저장하는 리포지토리입니다. 팀 멤버에게 할당되는 버그 또는 작업과 같은 작업 항목을 만들고 관리하고 추적할 수 있습니다. 코드 통합 중 빌드가 중단되면 팀에서는 가능한 한 즉시 문제를 수정해야 합니다. 빌드 중단에 대한 작업 항목을 만들도록 Team Foundation Server를 구성할 수 있습니다. 자세한 내용은 버그, 작업 및 기타 작업 항목 추적을 참조하십시오.

마지막으로, Team Foundation Server 및 SQL Server Analysis Services용 웨어하우스의 데이터베이스는 Team Foundation Server의 하위 시스템에서 제공되는 모든 데이터를 집계하고 연결합니다. 이러한 하위 시스템에는 버전 제어, 빌드, 테스트, 배포 및 작업 항목 추적이 포함됩니다. 따라서 팀에서는 연속 통합의 전 과정을 시각화할 수 있습니다. 자세한 내용은 관계형 웨어하우스 데이터베이스를 사용하여 Visual Studio ALM에 대한 보고서 생성를 참조하십시오.

준비 및 시작

팀에서는 다음 순서에 따라 연속 통합과 Team Foundation Server를 사용하기 시작할 수 있습니다.

1. Team Foundation 버전 제어를 사용하여 코드를 단일 코드베이스에 통합합니다.

2. Team Foundation Build에서 수동 빌드 형식을 만듭니다.

3. 자동화된 테스트 사례를 실행하여 빌드 품질을 확인합니다. 적절한 테스트 도구 모음이 없으면 자리 표시자 테스트 사례를 만들고 자동화된 테스트 사례를 몇 가지 가져옵니다. 이 테스트 도구 모음은 이후의 테스트에 자리 표시자로 사용할 수 있습니다.

4. 빌드에서 생성된 결과 이진 파일을 공유 위치에 전달합니다. 이 전략은 테스트 중 나타나는 문제를 진단하는 데 유용합니다.

5. Microsoft Test Manager를 사용하여 특정 환경에서 런타임에 발생하는 통합 오류를 파악합니다.

버전 제어

버전 제어 시스템에서는 코드에 대한 공유 리포지토리를 제공합니다. 소규모 팀에서는 단일 분기를 사용하여 작업할 수 있습니다. 그러나 일반적으로는 여러 버전의 코드를 개발하고 여러 중요 시점에서 프로젝트를 릴리스해야 하므로 둘 이상의 분기를 사용하여 작업하면 보다 융통성이 있습니다. 코드 분기를 만들고 병합하는 방법에 대한 자세한 내용은 CodePlex 웹 사이트의 Team Foundation Server Branching Guide 2.0 페이지를 참조하십시오.

Build

연속 통합에서 빌드 시스템은 테스트 및 배포할 수 있는 실행 가능한 구성 요소를 생성합니다. 또한 빌드 시스템에서는 컴파일 오류 및 경고 형태로 피드백을 제공합니다. 이러한 오류는 프로젝트 소스에 변경 내용이 있을 때 발생합니다.

Team Foundation Build에서는 다음과 같은 빌드 형식을 제공합니다.

• 수동 - 팀 멤버가 빌드를 큐에 대기시킵니다.

• 연속 - 버전 제어 분기에 체크 인하는 과정을 통해 빌드가 큐에 대기하게 됩니다.

• 롤링 - 이전 빌드가 완료될 때까지 빌드가 누적됩니다.

• 제어된 체크 인 - 전송된 변경 내용이 성공적으로 병합 및 빌드되는 경우에만 체크 인이 수락됩니다.

• 일정 - 정의된 일정에 따라 빌드가 수행됩니다.

자세한 내용은 기본 빌드 정의 만들기를 참조하십시오.

성공적인 연속 통합 구현을 위해 팀 멤버에게 필요한 사항

팀 멤버는 빌드 소요 시간이 10분을 넘지 않도록 소스를 구성해야 합니다. 대규모 프로젝트의 경우에는 이것이 가능하지 않을 수 있습니다. Team Foundation Server를 사용하면 팀에서 코드베이스의 여러 하위 집합을 빌드하는 다양한 빌드 정의를 구성할 수 있습니다. 빌드에 오랜 시간이 소요될 경우에는 롤링 빌드 형식을 사용하여 변경되지 않은 코드에 대한 이진 파일을 연속적으로 생성합니다.

빌드가 중단되면 팀에서는 즉각 빌드를 수정해야 합니다. Main 분기가 잘못된 역방향 통합으로 인한 영향을 받지 않는다면 대부분의 빌드 중단은 작업 분기에서의 잘못된 체크 인이나 주요 분기에서의 정방향 통합에서 비롯됩니다. 일정 기간 동안 빌드 중단을 해결하는 작업을 한 팀 멤버에게 할당한 다음 각 팀 멤버에게 이 작업을 번갈아가며 할당하는 것이 좋습니다.

하루에 실행할 빌드 수

코드를 연속적으로 통합할 경우 모든 분기에서 발생하는 각 체크 인에 대해 연속 빌드를 실행할 수 있습니다. 새로 체크 인된 코드와는 독립적으로 롤링 빌드를 실행할 수도 있습니다. 자세한 내용은 기본 빌드 정의 만들기 및 실행 중인 빌드의 진행률 모니터링을 참조하십시오.

Team Foundation Server에서 코드 빌드 속도를 향상시키는 방법

증분 빌드를 수행하도록 빌드 정의를 구성하면 빌드 속도를 향상시키는 데 유용합니다. 빌드 로그를 사용하여 속도가 느리며 개선이 가능한 빌드 부분을 찾을 수 있습니다. 자세한 내용은 증분 빌드를 위한 Team Foundation Build 구성을 참조하십시오.

Team Foundation Build를 통한 연속 통합 확장 방법

빌드 컨트롤러와 빌드 에이전트를 사용하면 연속 통합 주기를 확장할 수 있습니다.

자세한 내용은 Team Foundation Build 시스템 이해를 참조하십시오.

테스트 및 배포

연속 통합에 적절한 테스트 및 배포 방법

다음 그림에서는 Visual Studio ALM의 테스트 및 배포 기능을 연속 통합에 맞게 조정하는 방법을 보여 줍니다.

먼저, 코드를 연속적으로 통합할 때 빌드 자체에서 코드 관련 문제를 찾을 수 있습니다. 빌드는 컴파일에 성공하기도 하고 실패하기도 하는데 이러한 정보는 사용한 컴파일러에서 제공됩니다. 컴파일러에서 생성된 오류 및 경고 메시지를 모두 포함하는 빌드 보고서를 생성할 수 있습니다. Visual Studio ALM에서는 빌드 보고서를 통해 이 빌드에서 수정된 버그, 이 빌드에 포함된 변경 집합 및 빌드 중 코드 분석이 실행되었는지 여부 등의 정보도 얻을 수 있습니다. Visual Studio ALM을 사용하면 코드 디자인이 팀에서 정의한 규칙을 따르는지 여부를 확인할 수 있습니다. 자세한 내용은 방법: 레이어 다이어그램에 대해 .NET 코드 유효성 검사를 참조하십시오.

두 번째로, 단위 테스트를 실행하여 코드 관련 문제를 찾을 수 있습니다. 이러한 테스트에서는 컴파일러와 다른 방법으로 문제를 진단합니다. 컴파일러 규칙은 코드 구문 및 언어 구문과 관련된 문제를 확인합니다. 반면 빌드가 완료된 후 빌드에 대해 실행할 수 있는 단위 테스트에서는 코드의 기능 요소를 확인할 수 있습니다. 이러한 단위 테스트는 단위 테스트 집합이 지정된 경우 빌드에 대한 코드 검사 등의 메트릭도 제공합니다. 자세한 내용은 방법: 자동화된 테스트에 대한 테스트 설정을 사용하여 코드 검사 구성을 참조하십시오.

Microsoft Test Manager를 사용하면 테스트를 실행할 수 있는 특정 환경을 구성할 수 있습니다. 격리된 단위 테스트에서는 기능 수준의 확인이 가능합니다. 그러나 환경에는 다음과 같은 중요한 특징이 있습니다.

• 환경에 따라 코드 작동 방식에 영향이 있을 수 있습니다. 예를 들어 네트워크 설정 및 토폴로지는 랩 관리 환경이 없으면 테스트하기 어려울 수 있습니다.

• 특정 환경에 코드를 배포하는 작업을 자동화하면 팀이 배포에 소비하는 시간을 줄이고 배포 반복 수를 늘릴 수 있습니다.

자세한 내용은 How to: Create an Environment from Virtual Machine Templates 및 테스트를 실행하거나 데이터를 수집할 테스트 컴퓨터 설정을 참조하십시오.

연속 통합을 사용할 수 있도록 테스트 도구 모음을 구성하는 방법

테스트가 너무 많으면 빌드 완료가 지연되므로 연속 빌드에 가장 중요한 테스트 도구 모음을 실행할 수 있습니다. 이러한 테스트는 현재 반복에 대해 실행해야 합니다.

야간에 또는 예약된 빌드 주기에 따라 이전 빌드의 테스트와 이전 스프린트의 기능을 확인하는 전체 테스트 과정을 실행할 수 있습니다.

연속 통합이 테스트 팀에 주는 영향

연속 통합은 테스트 팀이 잘못된 빌드로 작업하고 이를 설치하느라 시간을 낭비하지 않도록 오류가 있는 빌드를 식별하는 데 도움이 됩니다.

프로젝트 통합 및 정보 교환

연속 통합을 구현하는 데 관련된 작업은 상당 부분 프로젝트 크기에 따라 달라질 수 있습니다. 팀은 프로젝트의 첫 번째 스프린트에서 연속 통합 작업을 정의하고 예약해야 합니다.

단계에서 연속 통합을 채택하려는 경우 먼저 자동화된 빌드를 구현할 수 있습니다. 그런 다음 실행 중인 단위 테스트를 포함하도록 자동화된 빌드를 수정할 수 있습니다. 마지막으로, 테스트한 빌드를 랩 환경에 배포하는 기능을 추가하고, 이 환경 내에서 테스트를 실행하여 환경에 따라 코드에 영향이 미칠지 여부를 확인할 수 있습니다.