지속적인 통합-빠른 가이드

지속적인 통합은 2000 년에 처음 소개되었으며 Cruise Control. 수년에 걸쳐 지속적 통합은 모든 소프트웨어 조직에서 핵심 관행이되었습니다. 이것은 소프트웨어 프로그램의 모든 코드 변경에 대해 빌드 및 후속 테스트가 수행되도록 개발 팀에 요청하는 개발 관행입니다. 이 개념은 빌드 라이프 사이클에서 늦게 발생하는 문제를 찾는 문제를 제거하기위한 것입니다. 개발자가 격리 작업을하고 충분히 통합하지 않는 대신 코드 변경 및 빌드가 격리되지 않도록하기 위해 지속적 통합이 도입되었습니다.

왜 지속적인 통합인가?

지속적인 통합은 모든 소프트웨어 개발 프로세스에서 매우 중요한 부분이되었습니다. 지속적인 통합 프로세스는 소프트웨어 개발 팀의 다음 질문에 답하는 데 도움이됩니다.

모든 소프트웨어 구성 요소가 제대로 작동합니까? – 때로는 시스템이 너무 복잡해져 각 구성 요소에 대해 여러 인터페이스가있을 수 있습니다. 이러한 경우 모든 소프트웨어 구성 요소가 서로 원활하게 작동하는지 확인하는 것이 항상 중요합니다.
통합 목적으로 코드가 너무 복잡합니까? – 지속적 통합 프로세스가 계속 실패하면 코드가 너무 복잡 할 가능성이 있습니다. 그리고 이것은 적절한 디자인 패턴을 적용하여 코드를 덜 복잡하고 유지 관리하기 쉽게 만드는 신호가 될 수 있습니다.
코드가 확립 된 코딩 표준을 준수합니까? – 대부분의 테스트 케이스는 코드가 적절한 코딩 표준을 준수하는지 항상 확인합니다. 자동화 된 빌드 후에 자동화 된 테스트를 수행하면 코드가 원하는 모든 코딩 표준을 충족하는지 확인하는 것이 좋습니다.
자동화 된 테스트가 얼마나 많은 코드를 다루나요? – 테스트 케이스가 코드의 필수 기능을 다루지 않으면 코드를 테스트 할 필요가 없습니다. 따라서 작성된 테스트 케이스가 애플리케이션의 모든 주요 시나리오를 포함하도록 보장하는 것이 항상 좋은 방법입니다.
최근 변경 후 모든 테스트가 성공적 이었습니까? – 테스트가 실패하면 코드 배포를 진행할 필요가 없으므로 코드가 배포 단계로 이동할 준비가되었는지 확인하는 것이 좋습니다.

워크 플로우

다음 이미지는 소프트웨어 개발 프로젝트에서 전체 지속적 통합 워크 플로우가 작동하는 방식에 대한 빠른 워크 플로우를 보여줍니다. 이에 대해서는 다음 장에서 자세히 살펴 보겠습니다.

따라서 위의 워크 플로를 기반으로하면 일반적으로 지속적 통합 프로세스가 작동하는 방식입니다.

먼저 개발자가 코드를 버전 관리 저장소에 커밋합니다. 한편, 통합 빌드 머신의 Continuous Integration 서버는 변경 사항에 대해 소스 코드 저장소를 폴링합니다 (예 : 몇 분마다).
커밋이 발생한 직후 Continuous Integration 서버는 버전 제어 저장소에서 변경 사항이 발생했음을 감지하므로 Continuous Integration 서버는 저장소에서 코드의 최신 사본을 검색 한 다음 소프트웨어를 통합하는 빌드 스크립트를 실행합니다.
Continuous Integration 서버는 빌드 결과를 지정된 프로젝트 멤버에게 이메일로 보내 피드백을 생성합니다.
그런 다음 해당 프로젝트의 빌드가 통과되면 단위 테스트가 수행됩니다. 테스트가 성공하면 스테이징 또는 프로덕션 서버에 코드를 배포 할 준비가 된 것입니다.
Continuous Integration 서버는 계속해서 버전 제어 저장소의 변경 사항을 폴링하고 전체 프로세스가 반복됩니다.

소프트웨어 부분은 지속적인 통합 프로세스에서 가장 중요한 부분입니다. 이 장에서는 전체 지속적인 통합 프로세스에 필요한 소프트웨어에 중점을 둡니다.

소스 코드 저장소

소스 코드 저장소는 모든 소스 코드와 모든 변경 사항을 유지하는 데 사용됩니다. 소스 코드 리포지토리 관리에 가장 많이 사용되는 두 가지는 Subversion이고 Git이 가장 최근에 많이 사용되는 시스템입니다. 이제 시스템에 Git을 설치하는 방법을 살펴 보겠습니다.

시스템 요구 사항

기억	2GB RAM (권장)
디스크 공간	설치용 200MB HDD. 프로젝트 소스 코드를 저장하려면 추가 스토리지가 필요하며 이는 추가되는 소스 코드에 따라 다릅니다.
운영 체제 버전	Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X에 설치할 수 있습니다.

Git 설치

Step 1 − Git의 공식 웹 사이트는 https://git-scm.com/. 링크를 클릭하면 다음 스크린 샷과 같이 Git 공식 웹 사이트의 홈페이지로 이동합니다.

Step 2 − Git을 다운로드하려면 화면을 아래로 스크롤하고 다운로드 섹션으로 이동하여 다운로드를 클릭하십시오.

Step 3 − Windows 링크를 클릭하면 Git 다운로드가 자동으로 시작됩니다.

Step 4− 다운로드 한 Git 용 .exe 파일을 클릭합니다. 우리의 경우 Git-2.6.1-64-bit.exe 파일을 사용하고 있습니다. 다음 화면에 나타나는 실행을 클릭하십시오.

Step 5 − 다음 화면에 나타나는 다음 버튼을 클릭합니다.

Step 6 − 다음 화면에서 다음을 클릭하여 일반 라이선스 계약에 동의합니다.

Step 7 − Git 설치 위치를 선택하십시오.

Step 8 − 다음을 클릭하여 설치해야하는 기본 구성 요소를 수락합니다.

Step 9 − Windows에서 Git을 사용할 것이므로 'Windows 명령 프롬프트에서 Git 사용'옵션을 선택합니다.

Step 10 − 다음 화면에서 기본 설정 인 'Checkout Windows-style, commit Unix-style line endings'를 수락하고 다음을 클릭합니다.

Step 11 − 다음 화면에서 Git 설치를위한 시스템으로 Windows를 사용하고 있으므로 'Windows 기본 콘솔 창 사용'옵션을 선택합니다.

이제 설치가 시작되고 설치가 완료되면 Git 구성을위한 후속 단계를 수행 할 수 있습니다.

Git 구성

Git이 설치되면 Git의 초기 구성을위한 구성 단계를 수행해야합니다.

가장 먼저해야 할 일은 Git에서 ID를 구성한 다음 사용자 이름과 이메일을 구성하는 것입니다. 이것은 모든Git commit이 정보를 사용하고 생성을 시작하는 커밋에 불변 적으로 구워집니다. 명령 프롬프트를 열고 다음 명령을 입력하여이를 수행 할 수 있습니다.

git config –global user.name “Username”
git config –global user.email “emailid”

다음 스크린 샷은 이해를 돕기위한 예입니다.

이 명령은 실제로 Git의 구성 파일을 그에 따라 변경합니다. 설정이 적용되었는지 확인하려면 다음 명령을 실행하여 Git 구성 파일의 설정을 나열 할 수 있습니다.

git config --list

다음 스크린 샷에 출력 예가 나와 있습니다.

지속적 통합 서버

전체 지속적 통합 파이프 라인에 필요한 다음으로 중요한 소프트웨어는 지속적 통합 소프트웨어 자체입니다. 다음은 업계에서 가장 일반적으로 사용되는 지속적 통합 소프트웨어입니다.

Jenkins− 이것은 많은 개발 커뮤니티에서 사용하는 오픈 소스 연속 통합 소프트웨어입니다.
Jet Brains TeamCity − 이것은 가장 널리 사용되는 상업용 연속 통합 소프트웨어 중 하나이며 대부분의 회사는 연속 통합 요구에이 소프트웨어를 사용합니다.
Atlassian Bamboo− 이것은 Atlassian Pvt라는 회사에서 제공하는 또 다른 인기있는 지속적 통합 소프트웨어입니다. Ltd.

위에서 언급 한 모든 소프트웨어는 지속적인 통합을 위해 동일한 모델에서 작동합니다. 이 튜토리얼의 목적을 위해 우리는Jetbrains TeamCity Continuous Integration 서버의 경우.

TeamCity 설치

다음은 컴퓨터에 Jet Brains TeamCity를 설치하기위한 단계 및 시스템 요구 사항입니다.

시스템 요구 사항

기억	4GB RAM (권장)
디스크 공간	설치용 1GB HDD. 각 프로젝트의 빌드 작업 공간을 저장하려면 추가 스토리지가 필요합니다.
운영 체제 버전	Windows, Linux, Mac OS X에 설치할 수 있습니다.

설치

Step 1 − TeamCity의 공식 웹 사이트는https://www.jetbrains.com/teamcity/. 주어진 링크를 클릭하면 다음 스크린 샷과 같이 TeamCity 공식 웹 사이트의 홈 페이지로 이동합니다. 페이지를 검색하여 TeamCity에 필요한 소프트웨어를 다운로드 할 수 있습니다.

Step 2 − 다운로드 한 .exe가 실행 목적으로 사용되고 있습니다. TeamCity-9.1.6.exe. 실행 파일을 두 번 클릭 한 다음 팝업되는 다음 화면에서 실행을 클릭합니다.

Step 3 − 다음을 클릭하여 설정을 시작합니다.

Step 4 − '동의 함'버튼을 클릭하여 사용권 계약에 동의하고 설치를 진행합니다.

Step 5 − 설치할 위치를 선택하고 다음을 클릭합니다.

Step 6 − 설치를위한 기본 구성 요소를 선택하고 다음을 클릭합니다.

설치 프로세스가 시작됩니다. 완료되면 구성 프로세스가 수행됩니다.

Step 7− 실행할 서버의 포트 번호를 선택하십시오. 가장 좋은 방법은 다음과 같은 다른 포트를 사용하는 것입니다.8080.

Step 8− 다음으로 TeamCity를 실행해야하는 계정을 묻습니다. 시스템 계정을 선택하고 다음을 클릭합니다.

Step 9− 다음으로 시작해야하는 서비스를 요청합니다. 기본 설정을 수락하고 다음을 클릭합니다.

TeamCity 구성

설치가 완료되면 다음 단계는 TeamCity 구성입니다. 이 소프트웨어는 브라우저에서 다음 URL을 검색하여 열 수 있습니다.

http://locahost:8080

Step 1− 첫 번째 단계는 TeamCity에서 수행 할 빌드 위치를 제공하는 것입니다. 원하는 위치를 선택하고 진행 버튼을 클릭합니다.

Step 2− 다음 단계는 모든 TeamCity 인공물을 저장할 데이터베이스를 지정하는 것입니다. 튜토리얼의 목적에 따라Internal (HSQLDB), 테스트 목적으로 제품을 사용할 때 가장 적합한 내부 데이터베이스입니다.

그러면 TeamCity가이를 시작하고 실행하는 데 필요한 모든 단계를 처리합니다.

Step 3− 다음으로 라이센스 계약에 동의하라는 메시지가 표시됩니다. 동일한 내용을 수락하고 계속을 클릭하십시오.

Step 4− TeamCity 소프트웨어에 로그인하는 데 사용할 관리자 계정을 생성해야합니다. 필요한 세부 정보를 입력하고 '계정 만들기'버튼을 클릭합니다.

이제 TeamCity에 로그인됩니다.

빌드 도구

빌드 도구는 프로그램이 특정 방식으로 빌드되도록하는 도구입니다. 이 도구는 일반적으로 프로그램을 적절한 방식으로 빌드하는 데 필요한 작업 목록을 수행합니다. 우리의 예에서 우리는.Net program , 우리는 MSBuild빌드 도구로. MSBuild 도구는 프로젝트를 빌드하는 데 사용되는 작업 목록이 포함 된 빌드 파일을 확인합니다. 웹 구성 프로젝트에 대한 일반적인 빌드 파일을 살펴 보겠습니다.

다음은 고려해야 할 빌드 파일의 주요 섹션입니다.

IIS 설정

다음 설정은 포트 번호, 웹 서버의 경로 및 응용 프로그램 실행시 필요한 인증 유형을 결정하는 데 사용됩니다. 이러한 설정은 중요한 설정이며 자습서의 뒷부분에서 배포를 수행하는 방법을 배울 때 MSBuild 명령을 통해 변경됩니다.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

이 프로젝트를 실행하는 데 필요한 모든 종속 바이너리가 무엇인지 빌드 서버에 알리는 데 사용됩니다.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net Framework 버전

그만큼 TargetFrameworkVersion프로젝트가 작동하는 데 필요한 .Net 버전을 알려줍니다. 이는 빌드 서버에이 기능이 없으면 빌드가 실패하기 때문에 절대적으로 필요합니다.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

배포 환경 – Amazon

이 자습서에서는 지속적 통합 서버가 Amazon에 애플리케이션을 배포 할 수 있는지 확인합니다. 이를 위해 다음과 같은 인공물이 제자리에 있는지 확인해야합니다.

데이터베이스 서버

배포를 위해 데이터베이스 서버가 Amazon에 있는지 확인하려면 다음 단계를 수행하십시오.

Step 1 − Amazon 콘솔로 이동 − https://aws.amazon.com/console/.

자격 증명으로 로그인하십시오. Amazon 사이트에서 무료 ID를 신청하면 Amazon의 일부 리소스를 무료로 사용할 수있는 프리 티어를 가질 수 있습니다.

Step 2 − RDS 섹션으로 이동하여 데이터베이스를 생성합니다.

Step 3 − 다음 팝업 화면에서 인스턴스를 클릭합니다.

Step 4 − 클릭 Launch DB 나타나는 다음 화면에서 옵션.

Step 5 − SQL Server 탭을 선택한 다음 SQL Server Express에 대한 선택 옵션을 선택합니다.

Step 6 − Amazon에서 제공하는 프리 티어 데이터베이스를 사용하고 있는지 확인하려면 다음 세부 정보를 입력해야합니다.

Step 7 − 모든 필드가 채워지면 다음 단계 버튼을 클릭합니다.

Step 8 − 다음 화면이 나타나면 모든 기본 설정을 수락하고 Launch DB Instance.

Step 9− 그러면 DB가 성공적으로 시작되었다는 화면이 표시됩니다. 같은 페이지에 DB 인스턴스를 볼 수있는 버튼이 있습니다. 링크를 클릭하면DB Instance 설정 중입니다.

잠시 후 위 화면의 상태가 변경되어 DB 인스턴스가 성공적으로 생성되었음을 알립니다.

웹 서버

다음 단계는 웹 애플리케이션을 호스팅 할 Amazon에 웹 서버를 만드는 것입니다. 이 작업은 후속 단계에 따라 수행 할 수 있습니다.

Step 1 − Amazon Console로 이동 − https://aws.amazon.com/console/.

자격 증명으로 로그인하십시오. 신청할 수 있습니다.free id on the Amazon site,이를 통해 Amazon의 일부 리소스를 무료로 사용할 수있는 프리 티어를 가질 수 있습니다.

Step 2 − 다음으로 이동 EC2 section 웹 서버를 만듭니다.

Step 3 − 다음 화면에서 인스턴스 시작을 클릭합니다.

Step 4 − Windows 클릭 – Microsoft Windows Server 2010 R2 Base.

Step 5 − 선택 t2.micro옵션은 프리 티어의 일부입니다. 딸깍 하는 소리Next: Configure Instance Details.

Step 6 − 다음 화면이 나타나면 기본 설정을 수락하고 옵션을 선택합니다. Next: Add Storage.

Step 7 − 다음 화면에서 기본 설정을 수락하고 옵션을 선택합니다. Next: Tag Instance.

Step 8 − 다음 화면에서 기본 설정을 수락하고 옵션을 선택합니다. Next: Configure Security Group.

Step 9 − 다음 화면에서 기본 설정을 수락하고 옵션을 선택합니다. Review and Launch.

Step 10 − 다음 화면이 나타나면 시작을 클릭합니다.

Step 11− 다음 화면이 나타나면 키 페어를 생성하라는 메시지가 표시됩니다. 이것은 나중에 서버에 로그인하는 데 사용됩니다. 키 쌍을 생성하고Launch Instance.

이제 인스턴스가 Amazon에서 설정됩니다.

프로젝트에서 일이 잘못 될 가능성이 있습니다. CI를 효과적으로 연습하면 나중에 프로젝트가 개발주기에 들어갈 때가 아니라 진행 과정의 모든 단계에서 어떤 일이 발생하는지 파악할 수 있습니다. CI는 위험 발생시 위험을 식별하고 완화하는 데 도움이되므로 구체적인 증거를 기반으로 프로젝트 상태를보다 쉽게 평가하고보고 할 수 있습니다.

이 섹션에서는 지속적 통합을 사용하여 피할 수있는 위험에 집중할 것입니다.

어떤 프로젝트에서든 관리해야하는 많은 위험이 있습니다. 개발 라이프 사이클 초기에 위험을 제거하면 시스템이 실제로 작동 할 때 이러한 위험이 나중에 문제로 발전 할 가능성이 줄어 듭니다.

위험 1 – 배포 가능한 소프트웨어 부족

“It works on my machine but does not work on another”– 이것은 아마도 모든 소프트웨어 조직에서 접하는 가장 일반적인 문구 중 하나 일 것입니다. 매일 소프트웨어 빌드에 수행되는 변경 사항이 많기 때문에 때때로 소프트웨어 빌드가 실제로 작동하는지 여부에 대한 확신이 거의 없습니다. 이 우려에는 다음과 같은 세 가지 부작용이 있습니다.

소프트웨어를 구축 할 수 있는지에 대한 확신이 거의 또는 전혀 없습니다.
소프트웨어를 내부 (예 : 테스트 팀) 또는 외부 (예 : 고객)로 제공하기 전에 긴 통합 단계.이 기간 동안 다른 작업은 수행되지 않습니다.
테스트 가능한 빌드를 생성하고 재현 할 수 없습니다.

해결책

IDE와 빌드 프로세스 간의 긴밀한 결합을 제거합니다. 소프트웨어 통합을 위해서만 별도의 시스템을 사용하십시오. 소프트웨어를 빌드하는 데 필요한 모든 것이 버전 제어 저장소에 포함되어 있는지 확인하십시오. 마지막으로 지속적 통합 시스템을 만듭니다.

Continuous Integration 서버는 버전 제어 저장소의 변경 사항을 감시하고 저장소 변경 사항을 감지하면 프로젝트 빌드 스크립트를 실행할 수 있습니다. 지속적 통합 시스템의 기능은 테스트를 통해 빌드를 실행하고, 검사를 수행하고, 개발 및 테스트 환경에 소프트웨어를 배포하는 것을 포함하도록 향상 될 수 있습니다. 이렇게하면 항상 작동하는 소프트웨어가 있습니다.

“Inability to synchronize with the database”– 때때로 개발자는 개발 중에 데이터베이스를 빠르게 재 작성할 수 없어 변경하기가 어렵습니다. 종종 이것은 데이터베이스 팀과 개발 팀이 분리되어 있기 때문입니다. 각 팀은 자신의 책임에 초점을 맞추고 서로간에 거의 협력하지 않습니다. 이 우려에는 다음과 같은 세 가지 부작용이 있습니다.

데이터베이스 또는 소스 코드를 변경하거나 리팩토링하는 것에 대한 두려움.
다른 테스트 데이터 세트로 데이터베이스를 채우는 데 어려움이 있습니다.
개발 및 테스트 환경 (예 : 개발, 통합, QA 및 테스트)을 유지 관리하는 데 어려움이 있습니다.

해결책

위의 문제에 대한 해결책은 버전 제어 저장소에서 모든 데이터베이스 아티팩트의 배치가 수행되도록하는 것입니다. 즉, 데이터베이스 스키마와 데이터를 다시 만드는 데 필요한 모든 것, 즉 데이터베이스 생성 스크립트, 데이터 조작 스크립트, 저장 프로 시저, 트리거 및 기타 데이터베이스 자산이 필요합니다.

데이터베이스와 테이블을 삭제하고 다시 생성하여 빌드 스크립트에서 데이터베이스와 데이터를 다시 빌드합니다. 다음으로 저장 프로 시저와 트리거를 적용하고 마지막으로 테스트 데이터를 삽입합니다.

데이터베이스를 테스트 (및 검사)합니다. 일반적으로 구성 요소 테스트를 사용하여 데이터베이스와 데이터를 테스트합니다. 경우에 따라 데이터베이스 별 테스트를 작성해야합니다.

위험 2 – 수명주기 후반에 결함 발견

여러 개발자가 소스 코드를 자주 변경하는 경우가 너무 많기 때문에 코드에서 나중에 발견 할 수있는 결함이 발생할 가능성이 항상 있습니다. 이러한 경우 소프트웨어에서 나중에 결함이 발견 될수록 결함을 제거하는 데 더 많은 비용이 들기 때문에 큰 영향을 미칠 수 있습니다.

해결책

Regression Testing− 이것은 모든 소프트웨어 개발주기에서 가장 중요한 측면이며 다시 테스트하고 테스트합니다. 소프트웨어 코드에 중대한 변경 사항이있는 경우 모든 테스트가 실행되었는지 확인하는 것이 절대적으로 필요합니다. 그리고 이것은 Continuous Integration 서버의 도움으로 자동화 될 수 있습니다.

Test Coverage− 테스트 케이스가 코드의 전체 기능을 다루지 않는 경우 테스트 할 필요가 없습니다. 애플리케이션을 테스트하기 위해 생성 된 테스트 케이스가 완전하고 모든 코드 경로가 테스트되었는지 확인하는 것이 중요합니다.

예를 들어 테스트해야하는 로그인 화면이있는 경우 성공적인 로그인 시나리오가있는 테스트 케이스를 가질 수 없습니다. 사용자가 사용자 이름과 암호의 다른 조합을 입력 한 다음 이러한 시나리오에서 어떤 일이 발생하는지 확인해야하는 부정적인 테스트 케이스가 있어야합니다.

위험 3 – 프로젝트 가시성 부족

수동 커뮤니케이션 메커니즘은 적시에 적절한 사람들에게 프로젝트 정보를 배포하기 위해 많은 조정이 필요합니다. 옆에있는 개발자에게 문의하여 최신 빌드가 공유 드라이브에 있음을 알리는 것이 다소 효과적이지만 확장이 잘되지는 않습니다.

이 정보가 필요한 다른 개발자가 있고 휴식 중이거나 사용할 수없는 경우에는 어떻게합니까? 서버가 다운되면 어떻게 알림을 받습니까? 일부는 전자 메일을 수동으로 보내 이러한 위험을 완화 할 수 있다고 생각합니다. 그러나 우연히 이해 관계자를 제외시킬 수 있고 일부는 당시의 전자 메일에 액세스하지 못할 수 있기 때문에 정보가 적시에 적절한 사람들에게 전달되도록 보장 할 수 없습니다.

해결책

이 문제에 대한 해결책은 다시 Continuous Integration 서버입니다. 모든 CI 서버에는 빌드가 실패 할 때마다 자동 이메일이 트리거되는 기능이 있습니다. 모든 주요 이해 관계자에게이 자동 알림을 통해 모든 사람이 소프트웨어의 현재 상태에 대해 알 수 있습니다.

위험 4 – 저품질 소프트웨어

결함이 있고 잠재적 인 결함이 있습니다. 소프트웨어가 제대로 설계되지 않았거나 프로젝트 표준을 따르지 않거나 유지 관리가 복잡한 경우 잠재적 인 결함이 발생할 수 있습니다. 때때로 사람들은 이것을 코드 나 디자인 냄새, 즉 "무언가 잘못되었을 수있는 증상"이라고 부릅니다.

일부는 저품질 소프트웨어가 전적으로 지연된 프로젝트 비용 (배송 후)이라고 생각합니다. 지연된 프로젝트 비용 일 수 있지만 소프트웨어를 사용자에게 제공하기 전에 다른 많은 문제가 발생하기도합니다. 지나치게 복잡한 코드, 아키텍처를 따르지 않는 코드, 중복 된 코드-모두 일반적으로 소프트웨어의 결함으로 이어집니다. 이러한 코드와 디자인 냄새가 결함으로 나타나기 전에 발견하면 시간과 비용을 절약 할 수 있으며 소프트웨어 품질을 높일 수 있습니다.

해결책

CI 소프트웨어와 통합 할 수있는 코드 품질 검사를 수행하는 소프트웨어 구성 요소가 있습니다. 이는 코드가 실제로 적절한 코딩 지침을 준수하는지 확인하기 위해 코드가 빌드 된 후에 실행될 수 있습니다.

소스 제어, 소스 코드 관리 시스템 또는 개정 제어 시스템이라고도하는 버전 제어 시스템은 파일의 여러 버전을 유지하기위한 메커니즘이므로 파일을 수정할 때 이전 개정판에 계속 액세스 할 수 있습니다.

최초의 인기있는 버전 제어 시스템은 SCCS(소스 코드 제어 시스템) 1970 년대로 거슬러 올라갑니다. 이것은 다음으로 대체되었습니다.RCS, 개정 제어 시스템 이상 CVS, 동시 버전 시스템.

이제 가장 많이 사용되는 버전 제어 시스템은 다음과 같습니다. Subversion 과 Git. 먼저 버전 관리 시스템을 사용해야하는 이유를 살펴보고 다음으로 소스 코드를 삽입하는 방법을 살펴 보겠습니다.Git source code repository system.

버전 관리 시스템의 목적

소스 제어보다 버전 제어라는 용어를 사용하는 한 가지 이유는 버전 제어가 소스 코드만을위한 것이 아니기 때문입니다. 소프트웨어 생성과 관련된 모든 단일 아티팩트는 버전 제어를 받아야합니다.

Developers should use it for source code − 기본적으로 모든 소스 코드는 버전 관리 시스템에 저장되어야합니다.

Related artefacts− 모든 시스템은 데이터베이스 스크립트, 빌드 및 배포 스크립트, 문서, 라이브러리 및 애플리케이션에 대한 구성 파일, 컴파일러 및 도구 모음 등과 같은 소스 코드와 관련된 아티팩트를 갖게됩니다. 이 모든 것은 전체 개발 및 배포 프로세스를 보완하며 버전 관리 시스템에 저장되어야합니다.

애플리케이션에 대한 모든 정보를 소스 제어에 저장하면 애플리케이션이 실행되는 테스트 및 프로덕션 환경을 더 쉽게 다시 만들 수 있습니다. 여기에는 애플리케이션의 소프트웨어 스택 및 환경, DNS 영역 파일, 방화벽 구성 등을 구성하는 운영 체제에 대한 구성 정보가 포함되어야합니다.

최소한 애플리케이션의 바이너리와 이들이 실행되는 환경을 다시 만드는 데 필요한 모든 것이 필요합니다. 목표는 프로젝트 수명의 어느 시점에서든 변경 될 수있는 모든 것을 통제 된 방식으로 저장하는 것입니다. 이를 통해 프로젝트 기록의 어느 시점에서든 개발 환경에서 프로덕션 환경에 이르는 전체 시스템 상태의 정확한 스냅 샷을 복구 할 수 있습니다.

팀의 모든 사람이 동일한 설정을 쉽게 사용할 수 있도록 개발 팀의 개발 환경에 대한 구성 파일을 버전 제어에 보관하는 것도 도움이됩니다. 분석가는 요구 사항 문서를 저장해야합니다. 테스터는 테스트 스크립트와 절차를 버전 관리에 보관해야합니다. 프로젝트 관리자는 릴리스 계획, 진행률 차트 및 위험 로그를 여기에 저장해야합니다.

즉, 팀의 모든 구성원은 프로젝트와 관련된 문서 나 파일을 버전 관리에 저장해야합니다.

소스 코드 버전 관리 시스템을위한 Git 작업

이 섹션에서는 이제 Git을 버전 관리 시스템으로 사용하는 방법에 중점을 둡니다. 버전 관리 시스템에 코드를 업로드하고 변경 사항을 관리하는 방법에 중점을 둡니다.

데모 애플리케이션

이 전체 튜토리얼의 목적을 위해 우리는 간단한 Web ASP.Net전체 지속적 통합 프로세스에 사용될 애플리케이션. 이 연습을 위해 전체 코드 세부 사항에 집중할 필요는 없습니다. 프로젝트가 수행하는 작업에 대한 개요 만 있으면 전체 지속적인 통합 프로세스를 이해하는 데 충분합니다. 이 .Net 애플리케이션은Visual Studio Integrated Development Environment.

다음 스크린 샷은 Visual Studio 환경의 솔루션 구조입니다. 메인 코드가있는 매우 간단한 웹 애플리케이션입니다.Demo.aspx 파일.

Demo.aspx 파일의 코드는 다음 프로그램에 표시됩니다.

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

코드는 매우 간단하며“Continuous Integration”문자열을 브라우저에 출력합니다.

Google Chrome에서 프로젝트를 실행하면 다음 스크린 샷과 같이 출력됩니다.

소스 코드를 Git으로 이동

최종 사용자가 Git 사용 방법에 대한 지식을 더 명확하게 알 수 있도록 명령 줄 인터페이스에서 소스 코드를 Git으로 이동하는 방법을 보여줄 것입니다.

Step 1 − 초기화 Git Repository. 명령 프롬프트로 이동하여 프로젝트 폴더로 이동하여 명령을 실행하십시오.git init. 이 명령은 필요한 Git 파일을 프로젝트 폴더에 추가하여 저장소에 업로드해야 할 때 Git에서 인식 할 수 있도록합니다.

Step 2− Git 저장소에 추가해야하는 파일 추가. 이것은 다음을 발행하여 수행 할 수 있습니다.git add command. 점 옵션은 Git에 프로젝트 폴더의 모든 파일을 Git 저장소에 추가해야 함을 알려줍니다.

Step 3− 마지막 단계는 프로젝트 파일을 Git 저장소에 커밋하는 것입니다. 이 단계는 모든 파일이 이제 Git의 일부인지 확인하는 데 필요합니다. 실행할 명령은 다음 스크린 샷에 나와 있습니다. 그만큼–m option 파일 업로드에 대한 설명을 제공하는 것입니다.

이제 Git에서 솔루션을 사용할 수 있습니다.

다음은 지속적인 통합을위한 몇 가지 주요 기능 또는 사례입니다.

Maintain a single source repository− 모든 소스 코드는 단일 저장소에 보관됩니다. 이렇게하면 소스 코드가 여러 위치에 흩어져있는 것을 방지 할 수 있습니다. 다음과 같은 도구Subversion and Git 소스 코드를 유지하는 데 가장 많이 사용되는 도구입니다.
Automate the build− 소프트웨어 빌드는 자동화 될 수있는 방식으로 수행되어야합니다. 수행해야하는 여러 단계가있는 경우 빌드 도구가이를 수행 할 수 있어야합니다. .Net의 경우 MSBuild가 기본 빌드 도구이고 Java 기반 애플리케이션의 경우 다음과 같은 도구가 있습니다.Maven and Grunt.
Make your build self-testing− 빌드는 테스트 가능해야합니다. 빌드가 발생한 직후 테스트 케이스를 실행하여 소프트웨어의 다양한 기능에 대해 테스트를 수행 할 수 있는지 확인해야합니다.
Every commit should build on an integration machine− 통합 머신은 빌드 서버이며 빌드가이 머신에서 실행되는지 확인해야합니다. 이는 모든 종속 구성 요소가 Continuous Integration 서버에 있어야 함을 의미합니다.
Keep the build fast− 빌드는 몇 분 안에 이루어집니다. 빌드 단계가 제대로 구성되지 않았 음을 의미하므로 빌드가 발생하는 데 몇 시간이 걸리지 않아야합니다.
Test in a clone of the production environment− 빌드 환경은 본질적으로 프로덕션 환경과 비슷해야합니다. 이러한 환경간에 큰 차이가있는 경우 빌드 서버를 통과하더라도 프로덕션에서 빌드가 실패 할 수 있습니다.
Everyone can see what is happening − 구축, 테스트 및 배포의 전체 프로세스가 모두에게 표시되어야합니다.
Automate deployment− 지속적인 통합은 지속적인 배포로 이어집니다. 빌드가 스테이징 또는 프로덕션 환경에 쉽게 배포되도록하는 것이 절대적으로 필요합니다.

다음은 지속적인 통합을위한 가장 중요한 요구 사항 목록입니다.

Check-In Regularly− 지속적 통합이 제대로 작동하기위한 가장 중요한 관행은 소스 코드 저장소의 트렁크 또는 메인 라인에 자주 체크인하는 것입니다. 코드 체크인은 적어도 하루에 두 번 이상 이루어져야합니다. 정기적으로 체크인하면 다른 많은 이점이 있습니다. 변경 사항을 더 작게 만들어 빌드를 중단 할 가능성이 적습니다. 이는 후속 빌드에서 실수가 발생할 때 되돌릴 소프트웨어의 최신 버전이 알려져 있음을 의미합니다.

또한 코드 리팩토링에 대해 더 잘 훈련하고 동작을 보존하는 작은 변경 사항을 고수하는 데 도움이됩니다. 많은 파일을 변경하는 변경 사항이 다른 사람의 작업과 충돌 할 가능성을 줄이는 데 도움이됩니다. 이를 통해 개발자는 마지막으로 커밋 된 버전으로 되돌려 아이디어를 시도하고 폐기 할 수 있습니다.
Create a Comprehensive Automated Test Suite− 포괄적 인 자동화 테스트 제품군이없는 경우 빌드를 통과하면 애플리케이션을 컴파일하고 어셈블 할 수 있다는 의미 일뿐입니다. 일부 팀의 경우 이것은 큰 단계이지만 애플리케이션이 실제로 작동하고 있다는 확신을 제공하기 위해 일정 수준의 자동화 된 테스트를 수행하는 것이 필수적입니다.

일반적으로 Continuous Integration에서 수행되는 테스트에는 3 가지 유형이 있습니다. unit tests, component tests, 및 acceptance tests.

단위 테스트는 애플리케이션의 작은 부분을 격리하여 테스트하기 위해 작성되었습니다. 일반적으로 전체 응용 프로그램을 시작하지 않고 실행할 수 있습니다. 그들은 데이터베이스 (응용 프로그램에있는 경우), 파일 시스템 또는 네트워크를 공격하지 않습니다. 프로덕션과 같은 환경에서 애플리케이션을 실행할 필요가 없습니다. 단위 테스트는 매우 빠르게 실행되어야합니다. 대규모 애플리케이션의 경우에도 전체 제품군을 10 분 이내에 실행할 수 있어야합니다.

구성 요소 테스트는 응용 프로그램의 여러 구성 요소 동작을 테스트합니다. 단위 테스트와 마찬가지로 항상 전체 애플리케이션을 시작할 필요는 없습니다. 그러나 데이터베이스, 파일 시스템 또는 기타 시스템 (스텁 아웃 될 수 있음)에 충돌 할 수 있습니다. 구성 요소 테스트는 일반적으로 실행하는 데 더 오래 걸립니다.
Keep the Build and Test Process Short − 코드를 빌드하고 단위 테스트를 실행하는 데 너무 오래 걸리면 다음과 같은 문제가 발생합니다.
- 사람들은 전체 빌드를 중지하고 체크인하기 전에 테스트를 실행합니다. 실패한 빌드가 더 많이 발생하기 시작할 것입니다.
- 지속적 통합 프로세스는 빌드를 다시 실행할 수있을 때까지 여러 커밋이 발생했을 정도로 오래 걸리므로 어떤 체크인이 빌드를 중단했는지 알 수 없습니다.
- 사람들은 소프트웨어가 빌드되고 테스트가 실행될 때까지 오래 기다려야하기 때문에 체크인 빈도가 줄어 듭니다.
Don’t Check-In on a Broken Build− 지속적인 통합의 가장 큰 실수는 손상된 빌드를 확인하는 것입니다. 빌드가 중단되면 담당 개발자가 수정을 기다리고 있습니다. 그들은 가능한 한 빨리 파손의 원인을 파악하고 수정합니다. 이 전략을 채택하면 항상 파손의 원인을 파악하고 즉시 수정할 수있는 최상의 위치에있을 것입니다.

동료 중 한 명이 체크인하여 빌드를 망가 뜨린 경우 문제를 해결할 수있는 최상의 기회를 얻으려면 문제에 대한 명확한 실행이 필요합니다. 이 규칙을 어기면 빌드를 수정하는 데 시간이 더 오래 걸립니다. 사람들은 빌드가 깨지는 것을 보는 데 익숙해지고, 빌드가 항상 깨져있는 상황에 매우 빠르게 접하게됩니다.
Always Run All Commit Tests Locally Before Committing− 항상 애플리케이션 용으로 설계된 테스트를 CI 서버에서 실행하기 전에 먼저 로컬 컴퓨터에서 실행해야합니다. 이는 올바른 테스트 케이스가 작성되었는지 확인하고 CI 프로세스에 실패가있는 경우 실패한 테스트 결과 때문입니다.
Take Responsibility for All Breakages that Result from Your Changes− 변경 사항을 커밋하고 작성한 모든 테스트는 통과했지만 다른 테스트가 중단되면 빌드가 여전히 중단됩니다. 일반적으로 이는 애플리케이션에 회귀 버그를 도입했음을 의미합니다. 변경 한 결과로 통과하지 못한 모든 테스트를 수정하는 것은 사용자의 책임입니다. CI의 맥락에서 이것은 분명해 보이지만 실제로는 많은 프로젝트에서 일반적인 관행이 아닙니다.

다양한 프로그래밍 언어에 사용할 수있는 다양한 빌드 도구가 있습니다. 가장 많이 사용되는 빌드 도구는 다음과 같습니다.Ant for Java 과 MSBuild for .NET. 사용자 지정 셸 또는 배치 스크립트 세트 대신 소프트웨어 빌드를 위해 특별히 설계된 스크립팅 도구를 사용하는 것이 일관되고 반복 가능한 빌드 솔루션을 개발하는 가장 효과적인 방법입니다.

그렇다면 시작하는 데 빌드 프로세스가 필요한 이유는 무엇입니까? 우선, 지속적 통합 서버의 경우 빌드 프로세스는 작업하기 쉽고 원활하게 구현해야합니다.

.Net에 대한 빌드 파일의 모양에 대한 간단한 예를 들어 보겠습니다.

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

위의 코드에 대해 다음과 같은 측면에주의해야합니다.

대상은 빌드 이름으로 지정됩니다. 여기서 대상은 빌드 프로세스에서 수행해야하는 논리적 단계의 모음입니다. 여러 대상을 가질 수 있으며 대상간에 종속성이있을 수 있습니다.
타겟에는 빌드 프로세스가 시작될 때 표시 될 옵션 메시지가 유지됩니다.
그만큼 MSBuild task 빌드해야하는 .Net 프로젝트를 지정하는 데 사용됩니다.

위의 예는 매우 간단한 빌드 파일의 경우입니다. 연속 통합에서는 전체 빌드 프로세스가 원활하게 진행되도록이 파일이 최신 상태로 유지됩니다.

.Net에서 솔루션 구축

.Net 용 기본 빌드 도구는 MSBuild이며 .Net 프레임 워크와 함께 제공됩니다. 시스템의 프레임 워크에 따라 관련 MSbuild 버전을 사용할 수 있습니다. 예를 들어 .Net 프레임 워크가 기본 위치에 설치되어있는 경우MSBuild.exe 다음 위치에 파일-

C:\Windows\Microsoft.NET\Framework\v4.0.30319

샘플 프로젝트를 빌드하는 방법을 살펴 보겠습니다. 샘플 프로젝트가 다음 폴더에 있다고 가정 해 보겠습니다.C:\Demo\Simple.

MSBuild를 사용하여 위의 솔루션을 빌드하려면 다음 프로그램과 같이 명령 프롬프트를 열고 MSBuild 옵션을 사용해야합니다.

msbuild C:\Demo\Simple\Simple.csproj

위의 예에서 csproj.Net에 특정한 프로젝트 파일입니다. csproj 파일에는 소프트웨어가 제대로 빌드하는 데 필요한 정보가 있는지 확인하는 모든 관련 정보가 포함되어 있습니다. 다음은 MSBuild 명령의 출력 스크린 샷입니다.

빌드가 성공하고 오류가없는 한 출력 경고에 대해 걱정할 필요가 없습니다.

이제 MSBuild 파일의 특정 측면을 살펴보고 의미를 살펴 보겠습니다. 이러한 측면은 지속적인 통합주기에서 알아야 할 중요합니다.

빌드 스크립트는 전체 지속적인 통합주기의 일부가 될 솔루션을 빌드하는 데 사용됩니다. Visual Studio의 일부로 생성되는 일반 빌드 스크립트를 살펴 보겠습니다..Net샘플 솔루션을 위해. 빌드 스크립트는 간단한 솔루션이라 할지라도 꽤 큰 것이므로 가장 중요한 부분을 살펴 보겠습니다. 기본적으로 빌드 스크립트는 Visual Studio의 기본 솔루션과 동일한 이름의 파일에 저장됩니다. 따라서 우리의 경우 파일을 열면Simple.csproj, 솔루션을 빌드하는 데 사용할 모든 설정이 표시됩니다.

사용 된 MSBuild 버전에 대한 종속성-다음 설정은 CI 서버에 설치된 MSBuild 파일을 사용합니다.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

솔루션을 올바르게 구축하기 위해 필요한 파일 – ItemGroup태그에는 프로젝트를 성공적으로 빌드하는 데 필요한 모든 필수 .Net 파일이 포함됩니다. 이러한 파일은 그에 따라 빌드 서버에 상주해야합니다.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

사용할 웹 서버 설정은 무엇입니까? 지속적인 배포 주제를 방문하면 MSBuild가 이러한 설정을 재정의하고 선택한 서버에 배포하는 데 어떻게 사용되는지 확인할 수 있습니다.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

다음으로 중요한 단계는 솔루션이 빌드 서버에서 빌드되는지 확인하는 것입니다. 첫 번째 부분은 수동 단계입니다. 연속 통합 도구를 사용하기 전에 먼저 빌드가 클라이언트 시스템에서 수행 된 것과 동일한 방식으로 빌드 서버에서 실행되는지 확인해야하기 때문입니다. 이를 위해 다음 단계를 구현해야합니다.

Step 1− 전체 솔루션 파일을 서버에 복사합니다. 빌드 서버로 사용할 Amazon 인스턴스 서버를 만들었습니다. 따라서 전체 서버에 수동 복사를 수행하십시오..Net 서버에 솔루션.

Step 2− 프레임 워크가 서버에 있는지 확인합니다. 클라이언트 컴퓨터의 .Net framework 4.0에서 응용 프로그램을 컴파일 한 경우 서버 컴퓨터에도 설치되어 있는지 확인해야합니다. 그러니 위치로 이동C:\Windows\Microsoft.NET\Framework 서버에서 원하는 프레임 워크가 있는지 확인하십시오.

Step 3 − 이제 서버에서 MSBuild를 실행하고 어떤 일이 발생하는지 살펴 보겠습니다.

좋습니다. 오류가 발생한 것 같습니다. 지속적인 통합에 대한 한 가지 중요한 교훈은 빌드가 빌드 서버에서 작동하는지 확인해야한다는 것입니다. 이를 위해 모든 필수 소프트웨어가 빌드 서버에 설치되어 있는지 확인해야합니다.

.Net의 경우 다음과 같은 구성 요소를 설치해야합니다. Visual Studio Redistributable package. 이 패키지에는 작업에 필요한 모든 파일이 포함되어 있습니다..Net서버에 구축 할 응용 프로그램입니다. 이제 빌드 서버에서 다음 설치 단계를 수행해 보겠습니다.

Step 4 − 실행 파일을 더블 클릭하여 설치를 시작합니다.

Step 5 − 다음 단계에서 라이선스 약관에 동의하고 설치를 클릭합니다.

Step 6 − 이제 MSBuild를 실행할 때 다음과 같은 MSBuild를 호출 할 때 추가 매개 변수를 포함해야합니다. p:VisualStudioversion = 12.0. 이렇게하면 MSBuild가 이전 단계에서 다운로드 한 파일을 참조합니다.

이제 솔루션이 제대로 빌드되었음을 알 수 있으며 기준 프로젝트가 서버에서 올바르게 빌드된다는 것도 알 수 있습니다.

다음 주요 측면은 기준 코드가 Git 인 소스 코드 저장소 관리 서버에 체크인되었는지 확인하는 것입니다. 이렇게하려면 다음 단계를 따라야합니다.

Step 1− Git에 업로드 할 수 있도록 저장소를 초기화합니다. 이것은gitinit 명령. 따라서 프로젝트 폴더로 이동하여git init 명령.

Step 2− 다음 단계는 Git에서 파일 준비라고합니다. 이렇게하면 Git에 추가해야하는 프로젝트 폴더의 모든 파일이 준비됩니다. 당신은git add다음 스크린 샷에 표시된대로 명령. '.' 표기법은 디렉토리 및 하위 디렉토리의 모든 파일이 커밋에 포함되어야 함을 나타내는 데 사용됩니다.

Step 3 − 마지막 단계는 파일을 Git 리포지토리에 커밋하여 이제 본격적인 Git 리포지토리가되도록하는 것입니다.

이제 Git 저장소에 소스 코드가 있고 모든 초기 코드가 빌드 서버에서 작동하므로 Continuous Integration 서버에서 프로젝트를 만들 차례입니다. 이는 다음 단계를 통해 수행 할 수 있습니다.

Step 1− TeamCity 소프트웨어에 로그인합니다. Continuous Integration 서버의 URL로 이동하십시오-http://localhost:8080/login.html.

관리자 자격 증명을 입력하고 서버에 로그인합니다.

Step 2− 로그인하면 홈 화면이 나타납니다. 딸깍 하는 소리Create Project 새 프로젝트를 시작합니다.

Step 3− 프로젝트 이름을 지정하고 생성을 클릭하여 프로젝트를 시작합니다. 우리의 경우 다음 스크린 샷과 같이 프로젝트 이름을 'Demo'로 지정합니다.

Step 4− 다음 단계는 프로젝트에서 사용될 Git 저장소를 언급하는 것입니다. Continuous Integration 환경에서 CI 서버는 Git 지원 저장소에서 코드를 가져와야합니다. 이전 단계에서 프로젝트 폴더를 Git 사용 저장소로 이미 활성화했습니다. TeamCity에서 VCS 루트를 생성해야합니다. 이를 위해VCS Roots 프로젝트의 메인 화면에서.

Step 5 − 다음에 나타나는 화면에서 Create VCS root 다음 스크린 샷과 같이.

Step 6 − 다음 화면이 나타나면 다음 단계를 수행하십시오. −

VCS 유형을 Git으로 언급하십시오.
VCS 루트의 이름을 지정하십시오. 이것은 친숙한 이름 일 수 있습니다. 우리는 이름을App.
가져 오기 URL을 다음과 같이 지정하십시오. C:\Demo\Simple - 이것은 out git 활성화 된 저장소.
화면을 아래로 스크롤하면 연결 테스트 버튼이 표시됩니다. Git 사용 저장소에 성공적으로 연결할 수 있는지 확인하려면 클릭하십시오.

Step 7 − 생성을 클릭하면 다음 이미지와 같이 등록 된 저장소가 표시됩니다.

Step 8− 다음 단계는 프로젝트를 빌드하는 데 사용할 빌드 구성을 만드는 것입니다. 프로젝트 화면으로 이동TeamCity → General Settings. 빌드 구성 만들기를 클릭합니다.

Step 9− 다음 화면에서 빌드 구성의 이름을 지정하십시오. 우리의 경우 우리는 그것을 다음과 같이 명명했습니다.DemoBuild 그런 다음 만들기를 클릭합니다.

Step 10 − 다음 화면이 나타나면 다음을 선택하라는 메시지가 표시됩니다. VCS repository이전 단계에서 생성되었습니다. 그러니 이름을 선택하세요‘App’ 첨부를 클릭합니다.

Step 11− 이제 팝업되는 다음 화면에서 빌드 단계를 구성해야합니다. 따라서 'configure build steps manually'하이퍼 링크.

Step 12 − 다음 빌드 화면에서 다음 세부 정보를 입력해야합니다 −

Runner 유형을 MSBuild로 선택합니다.
단계 이름에 대한 선택적 이름을 제공하십시오.
빌드해야하는 파일의 이름을 지정하십시오. 이전 섹션에서 MSbuild를 지정하면 일반적으로 다음과 같은 옵션이 제공됩니다.Simple.csproj. 여기에서 동일한 사항을 지정해야합니다.
MSBuild 버전을 'Microsoft Build Tools 2013'으로 선택합니다.
선택 MSBuild ToolsVersion 12.0.
페이지를 아래로 스크롤하여 설정을 저장합니다.

Step 13 − 다음 화면에서 실행을 클릭합니다.

현재 진행중인 애플리케이션 빌드가 표시됩니다.

성공적인 화면이 표시되어야합니다. 이는 솔루션이 제대로 구축되고 있다는 좋은 신호입니다.

또한 빌드 로그로 이동하여 다음 스크린 샷에 표시된대로 Continuous Integration 서버에서 다루는 모든 단계를 볼 수 있습니다.

이제 Git에 기본 코드가 있고 Continuous Integration 서버에 대한 링크가 있으므로 마지막으로 Continuous Integration의 첫 번째 단계가 작동하는 것을 볼 수 있습니다. 이는 연속 통합 서버에서 트리거와 같은 작업을 정의하여 수행되며 전체 연속 통합 프로세스를 가능한 한 원활하게 만듭니다. Visual Studio에서 코드를 변경해 보겠습니다.

Step 1 − 다음으로 이동 Demo.aspx Visual Studio에서 페이지를 열고 페이지 제목을 변경합니다.

Step 2 − 다음을 통해 Git 저장소를 쿼리하면 git status 명령을 내리면 실제로 Demo.aspx 파일이 수정되었습니다.

이제 코드의 모든 변경이 지속적 통합 서버에서 빌드를 트리거해야합니다. 이를 위해 다음과 같이 변경해야합니다.

Step 3 − 프로젝트 대시 보드로 이동하여 트리거 섹션을 클릭하고 Add new trigger.

Step 4 − 나타나는 다음 화면에서 VCS trigger, 리포지토리에 체크인 할 때 빌드가 트리거되도록 트리거를 만드는 데 사용됩니다.

Step 5 − 클릭 Show Advanced Options 다음 스크린 샷에 표시된 옵션이 선택되었는지 확인합니다.

Step 6− 저장을 클릭합니다. 이제 다음 스크린 샷과 같이 성공적으로 등록 된 트리거를 볼 수 있습니다.

Step 7− 이제 코드를 Git 저장소에 체크인하고 어떤 일이 발생하는지 살펴볼 시간입니다. 이제 명령 프롬프트로 이동하여git add 변경된 파일을 준비하는 명령입니다.

Step 8 − 이제 git commit 명령을 실행하면 변경 사항이 Git 저장소로 푸시됩니다.

Step 9 − 이제 프로젝트 개요 화면으로 이동하면 새 빌드가 트리거되고 실행 된 것을 볼 수 있습니다.

만약 당신이 Change log Tab, 당신은 git comment 빌드를 트리거했습니다.

한 번 더 해보겠습니다. 다시 한 번 변경하겠습니다.Demo.aspx파일. 수행하자git add 명령 및 git commit 다음 커밋 메시지가있는 명령.

이제 TeamCity의 프로젝트 대시 보드에서 빌드가 자동으로 트리거되는 것을 볼 수 있습니다.

빌드에 성공 메시지가 표시됩니다.

이제 변경 사항이 커밋 될 때 사용 된 'Second commit'메시지가 표시됩니다. git repository.

이제 지속적 통합 프로세스의 첫 번째 부분을 성공적으로 완료했습니다.

빌드 실패 알림은 빌드가 실패 할 때마다 트리거되는 이벤트입니다. 빌드가 실패 할 때마다 모든 주요 사용자에게 알림이 전송됩니다. 이러한 경우에 가장 먼저해야 할 일은 실패한 빌드에 시간을 투자하여 빌드가 통과되었는지 확인하는 것입니다. 다음 단계는 빌드 알림이 TeamCity에 배치되었는지 확인하는 데 사용됩니다.

다음은 TeamCity에서 이메일 알림을 설정하는 단계입니다.

Step 1− TeamCity에서 프로젝트 대시 보드로 이동하여 오른쪽 상단 모서리에있는 관리를 클릭합니다. 그런 다음Email Notifier왼쪽에 링크. 이 링크를 클릭하여 이메일에 대한 일반 설정을 불러옵니다.

Step 2 − 다음 단계는 유효한 정보를 입력하는 것입니다. SMTP Server. Gmail은 누구나 사용할 수있는 무료 SMTP 기능을 제공합니다. 따라서 다음 스크린 샷과 같이 표시되는 다음 화면에 이러한 세부 정보를 입력 할 수 있습니다.

SMTP 호스트 – smtp.gmail.com
SMTP 포트 번호 – 465
및 SMTP 로그인에서 이메일 메시지 보내기 – 유효한 Gmail ID 여야합니다.
SMTP 비밀번호 – 해당 Gmail ID의 유효한 비밀번호
보안 연결 – SSL로 설정

Step 3 − 클릭 Test Connection설정이 제대로 작동하는지 확인하기 위해서입니다. 그런 다음Save 설정을 저장합니다.

Step 4− 다음 단계는 사용자에 대한 빌드 알림을 활성화하는 것입니다. 첫 번째 작업은 이러한 빌드 알림을받을 사용자를 만드는 것입니다. 프로젝트 대시 보드로 이동하여Users Option.

Step 5− 새 사용자를 생성합니다. 필요한 사용자 이름과 암호를 입력하십시오. 그런 다음 화면 하단에있는 사용자 생성 버튼을 클릭합니다.

Step 6 − 이제이 새로운 사용자 ID와 비밀번호로 TeamCity 시스템에 로그인하십시오.

Step 7− 로그인하면 사용자의 일반 설정이 표시됩니다. 이메일 알리미 섹션에서 편집을 클릭하십시오.

Step 8 − 나타나는 다음 화면에서 Add new rule.

Step 9 − 새 규칙 추가에서 다음 두 옵션을 선택한 다음 저장을 클릭합니다.

선택한 프로젝트에서 빌드 – 데모 프로젝트를 선택합니다.
'빌드 실패'확인란을 활성화합니다.

이 두 가지 옵션을 활성화하면 이제 데모 프로젝트의 빌드가 실패 할 때마다 사용자에게 이메일 알림이 전송됩니다. demouser.

Step 10− 이제 잘못된 빌드를 트리거하여이 동작을 살펴 보겠습니다. Visual Studio에서demo.aspx.cs 파일을 작성하고 잘못된 코드 줄을 추가하십시오.

Step 11 − 이제 다음을 수행하여 Git에서 코드를 체크인합니다. git add 과 git commit.

이제 프로젝트 대시 보드에서 빌드가 자동으로 트리거되고 다음 스크린 샷과 같이 빌드가 실패했음을 알 수 있습니다.

Gmail ID로 로그인하면 demouser, 다음 스크린 샷과 같이 실제로 빌드 실패 알림이 표시됩니다.

지속적인 통합의 핵심 측면 중 하나는 항상 빌드가 어떻게 수행되고 있는지 확인하고, 중요한 메트릭을 수집하고, 이러한 결과를 문서화하고, 지속적인 빌드를 통해 지속적인 피드백을 생성하는 것입니다.

이러한 메트릭을 적용하면 어떤 이점이 있습니까?

Not Committing Code Enough− 개발자가 버전 관리 저장소에 코드를 자주 커밋하지 않는 경우 통합 빌드가 느려질 수 있습니다. 빌드 기간을 줄이기 시작하려면 통합 빌드 환경에 대한 높은 수준의 분석을 수행하여 병목 현상을 확인하십시오.

다음으로 결과를 분석하고 가장 적절한 개선 사항을 결정한 다음 빌드 프로세스를 변경하여 빌드 기간을 줄이십시오. 마지막으로 빌드 기간을 재평가하여 추가 개선이 필요한지 확인합니다.
Improve Test Performance− 제대로 작동하는 CI 시스템에서도 자동화 된 테스트를 실행하면 통합 빌드 시간의 대부분이 소요됩니다. 이러한 테스트의 성능을 평가하고 개선하면 빌드 기간을 크게 줄일 수 있습니다.
Infrastructure Issues− 시스템 인프라로 인해 통합 빌드가 느리다는 것을 발견 할 수 있습니다. 네트워크 성능이 느리거나 성능이 느린 가상 사설망 연결이있을 수 있습니다.

지리적으로 분산 된 시스템과 신뢰할 수없는 하드웨어 또는 소프트웨어도 성능 문제를 유발할 수 있습니다. 구축 기간을 줄이기 위해 인프라 리소스를 조사하고 개선합니다.

메트릭

다음은 Continuous Integration 서버에서 사용할 수있는 몇 가지 메트릭입니다.

TeamCity가 제공하는 기능을 살펴 보겠습니다.

가장 간단한 형태의 메트릭 중 하나는 프로젝트 대시 보드에서 사용할 수있는 것입니다. 여기서 핵심 요소는 각 빌드의 기간을 기록하는 것입니다. 각 빌드의 기간이 빌드중인 코드에 비해 불균형 적으로 증가하기 시작하면 문제가 될 수 있습니다. 따라서 이것은 취할 수있는 하나의 피드백이며 그 원인은 CI 서버의 리소스가 부족하여 서버의 용량을 늘려야 할 수 있습니다.

TeamCity는 CI 서버에 실제로 인프라와 관련된 문제가 있는지 확인할 수있는 기능이 있습니다. 에서admin dashboard TeamCity에서 Disk Usage 각 빌드에서 얼마나 많은 디스크 공간이 사용되는지 확인합니다.

더 자세한 정보가 필요한 경우 TeamCity는 diagnostics button에 대한 자세한 정보를 제공 할 수 있습니다. CPU and Memory CI 서버에서 활용되고 있습니다.

빌드 메트릭의 상세보기

시간이 지남에 따라 특정 프로젝트의 빌드에 대한 자세한보기를 보려면 프로젝트 빌드의 일부로 사용할 수 있습니다. 프로젝트 빌드 화면에서 통계 화면으로 이동하면 빌드가 수행되는 방식에 대한 다양한 통계 및 차트가 제공됩니다.

지속적인 통합의 주요 기능 중 하나는 on-going testingCI 서버에서 빌드 한 모든 코드를 보유합니다. CI 서버에서 빌드를 수행 한 후에는 필요한 코드를 테스트하기 위해 테스트 케이스가 제자리에 있는지 확인해야합니다. 모든 CI 서버에는 단위 테스트 케이스를 실행하는 기능이 있습니다.CI suite. 에.Net, 단위 테스트는 .Net framework 동일한 것을 CI 서버에도 통합 할 수 있습니다.

이 장에서는 테스트 케이스를 정의하는 방법을 .Net빌드가 완료된 후 TeamCity 서버에서이 테스트 케이스를 실행하도록합니다. 이를 위해 먼저 샘플 프로젝트에 대해 정의 된 단위 테스트가 있는지 확인해야합니다.

이를 위해서는 다음 단계를 최대한주의하여 따라야합니다.

Step 1− 단위 테스트에서 사용할 솔루션에 새 클래스를 추가해 보겠습니다. 이 클래스는 "연속 통합"문자열을 보유하는 이름 변수를 갖습니다. 이 문자열은 웹 페이지에 표시됩니다. Simple Project를 마우스 오른쪽 버튼으로 클릭하고 메뉴 옵션을 선택합니다.Add → Class.

Step 2 − 클래스 이름을 다음과 같이 지정하십시오. Tutorial.cs 화면 하단의 추가 버튼을 클릭합니다.

Step 3− Tutorial.cs 파일을 열고 다음 코드를 추가합니다. 이 코드는 다음과 같은 문자열을 생성합니다.Name, 생성자에서 문자열 값에 이름을 다음과 같이 할당합니다. Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 − 우리의 Demo.aspx.cs이 새 클래스를 사용하려면 파일. 이 파일의 코드를 다음 코드로 업데이트하십시오. 따라서이 코드는 이제 위에서 만든 클래스의 새 인스턴스를 만듭니다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 − 우리 demo.aspx 파일을 참조하십시오. tp.Name 변수는 aspx.cs 파일.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

이러한 변경 사항에 대해 코드가 제대로 작동하는지 확인하기 위해 Visual Studio에서 코드를 실행할 수 있습니다. 컴파일이 완료되면 다음 출력이 표시됩니다.

Step 6− 이제 단위 테스트를 프로젝트에 추가 할 차례입니다. 오른쪽 클릭Solution 메뉴 옵션을 선택하십시오 Add → New Project.

Step 7 − 다음으로 이동 Test 오른쪽에서 Unit Test Project. 이름 지정DemoTest 확인을 클릭합니다.

Step 8 − 귀하의 Demo Test project, Simple 프로젝트 및 필요한 항목에 대한 참조를 추가해야합니다. testing assemblies. 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 메뉴 옵션을 선택하십시오.Add Reference.

Step 9 − 다음 화면이 나타나면 프로젝트로 이동하여 Simple Reference 확인을 클릭합니다.

Step 10 − 클릭 Add Reference 다시 어셈블리로 이동하여 Web검색 상자에서. 그런 다음 참조를 추가하십시오.System.Web.

Step 11 −에서 Unit Test file, 다음 코드를 추가하십시오. 이 코드는 Tutorial 클래스에 문자열 이름 변수가 있는지 확인합니다. 또한 이름이 "지속적 통합"의 값과 같아야한다는 사실을 주장합니다. 이것은 우리의 간단한 테스트 케이스가 될 것입니다.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12− 이제 Visual Studio에서 테스트를 실행하여 작동하는지 확인하겠습니다. Visual Studio에서 메뉴 옵션을 선택합니다.Test → Run → All Tests.

테스트를 실행하면 Visual Studio의 왼쪽에 테스트가 성공적으로 실행 된 것을 볼 수 있습니다.

TeamCity 내에서 지속적인 테스트 활성화 – 이제 모든 테스트 사례가 준비되었으므로이를 Team City 서버에 통합 할 때입니다.

Step 13−이를 위해 프로젝트 구성에서 빌드 단계를 생성해야합니다. 프로젝트 홈으로 이동하여 구성 설정 편집을 클릭하십시오.

step 14 − 그런 다음 빌드 단계 → MS 빌드로 이동하여 다음 스크린 샷과 같이 빌드 단계 추가를 클릭합니다.

다음 화면이 나타나면 다음 값을 추가하십시오.

Visual Studio 테스트로 러너 유형을 선택합니다.
선택적 테스트 단계 이름을 입력하십시오.
테스트 엔진 유형을 다음과 같이 선택하십시오. VSTest.
테스트 엔진 버전을 다음과 같이 선택하십시오. VSTest2013.
테스트 파일 이름에서 위치를 다음과 같이 제공하십시오. DemoTest\bin\Debug\DemoTest.dll - 기억 DemoTest단위 테스트가 포함 된 프로젝트의 이름입니다. 그만큼DemoTest.dll 첫 번째 빌드 단계에서 생성됩니다.
화면 끝에서 사용할 수있는 저장을 클릭합니다.

이제 프로젝트에 대한 2 개의 빌드 단계가 있습니다. 첫 번째는 애플리케이션 코드와 테스트 프로젝트를 빌드하는 빌드 단계입니다. 다음은 테스트 케이스를 실행하는 데 사용됩니다.

Step 15− 이제 전체 빌드 프로세스가 트리거 될 수 있도록 Git에서 모든 코드를 체크인 할 때입니다. 유일한 차이점은 이번에는git add 과 git commit 명령에서 Demo parent folder 다음 스크린 샷과 같이.

이제 빌드가 트리거되면 테스트가 통과되었음을 나타내는 초기 출력이 표시됩니다.

Step 16 − 테스트 통과 결과를 클릭하고 테스트 탭으로 이동하면 UnitTest1이 실행되었고 통과되었음을 확인할 수 있습니다.

연속 검사는 실제 테스트가 실행되기 전에 코드에 대해 수행되는 검사의 자동화 된 코드 검토 프로세스입니다. 소프트웨어 검사와 테스트에는 미묘한 차이가 있습니다. 테스트는 동적이며 기능을 테스트하기 위해 소프트웨어를 실행합니다. 검사는 미리 정의 된 규칙 집합을 기반으로 코드를 분석합니다.

검사자 (또는 정적 및 동적 분석 도구)는 팀이 준수해야하는 식별 된 표준 (일반적으로 코딩 또는 디자인 메트릭)에 따라 지시됩니다. 검사 대상의 예로는 코딩 "문법"표준, 아키텍처 레이어링 준수, 코드 복제 등이 있습니다.

지속적인 검사는 발견과 수정 사이의 시간을 줄여줍니다. 다양한 연속 검사 도구를 사용할 수 있습니다. 이 예에서는NCover 3.xTeamCity와 통합되어 있습니다. 지속적인 검사를 수행하는 방법과 그것이 우리를 위해 무엇을 할 수 있는지 봅시다.

NCover 다운로드 및 설치

NCover는 다운로드 및 설치가 필요한 별도의 제품입니다. NCover를 다운로드하려면 다음 링크를 클릭하고 32 비트 설치 프로그램을 다운로드하십시오.http://www.ncover.com/info/download.

다운로드 한 설치 프로그램을 실행하고 설치 프로그램이 시작된 후 다음을 클릭합니다.

라이센스 계약에 동의하고 다음을 클릭하십시오.

기본 구성 요소를 수락하고 다음을 클릭합니다.

설치를 시작하려면 설치 버튼을 클릭하십시오.

마침 버튼을 클릭하여 설치를 완료합니다.

로 이동하여 처음으로 NCover 설치를 시작하십시오. C:\Program Files (x86)\NCover\ NCover.Explorer.exe. 처음으로 평가판 키를 설치하기 만하면됩니다. 이는 간단한 과정입니다.

NCover를 사용하도록 TeamCity에서 프로젝트 구성

Step 1 − 프로젝트 홈 화면으로 이동하여 구성 설정 편집을 클릭합니다.

Step 2 − 빌드 단계로 이동하여 편집을 클릭하십시오. TestStep. 연속 검사는 정의 된 단위 테스트와 함께 실행되어야합니다.

Step 3 − .Net Coverage 섹션에서 .Net Coverage Tool. 그리고 다음 설정을 선택합니다.

.Net Coverage 도구를 NCover (3.x)로 선택하십시오.
x86 플랫폼
v4.0 버전
NCover의 경로 (C : \ Program Files (x86) \ NCover)
다른 설정은 그대로 둡니다.

Step 4 − 저장을 클릭합니다.

Step 5 − 이제 프로젝트의 메인 화면으로 이동하여 실행을 클릭합니다.

Step 6− 빌드가 실행되면 테스트 통과를 클릭합니다. 이제 코드 커버리지 화면이 표시되고 많은 메트릭 지표가 표시됩니다.

Step 7 − 이제 Code Coverage 탭을 클릭하여 코드 분석에 대한 자세한 정보를 얻을 수 있습니다.

Step 8 − 클릭 fullcoveragereport.html. 이제 수행 된 검사에 대한 전체 종합 보고서를 받게됩니다..Net code.

지속적인 데이터베이스 통합은 프로젝트의 버전 관리 저장소에 변경 사항이 적용될 때마다 데이터베이스를 재 구축하고 데이터를 테스트하는 프로세스입니다.

데이터베이스 통합에서 일반적으로 데이터베이스 통합과 관련된 모든 아티팩트-

버전 제어 시스템에 있어야합니다.
엄격함을 테스트하고 정책 준수 여부를 검사 할 수 있습니다.
빌드 스크립트를 사용하여 생성 할 수 있습니다.

지속적인 데이터베이스 통합에 참여할 수있는 활동은 다음 중 하나 일 수 있습니다.

Drop a Database − 데이터베이스를 삭제하고 관련 데이터를 제거하여 동일한 이름의 새 데이터베이스를 생성 할 수 있습니다.

Create a new Database − DDL (데이터 정의 언어)을 사용하여 새 데이터베이스를 생성합니다.

Insert the Initial Data − 배송시 시스템에 포함 할 것으로 예상되는 초기 데이터 (예 : 룩업 테이블)를 삽입합니다.

Migrate Database and Data − 정기적으로 데이터베이스 스키마와 데이터를 마이그레이션합니다 (기존 데이터베이스를 기반으로 시스템을 생성하는 경우).

Modify Column Attributes − 요구 사항 및 리팩토링을 기반으로 테이블 열 속성 및 제약 조건을 수정합니다.

Modify Test Data − 여러 환경에서 필요에 따라 테스트 데이터를 변경합니다.

따라서 Continuous Database 예제에서 다음 단계를 수행 할 것입니다.

MS SQL Server 데이터베이스와 해당 테이블을 생성합니다.
SQL Server Management Studio에서 스크립트를 생성합니다. 이 데이터베이스 스크립트는 데이터베이스에서 테이블을 설정하는 데 사용됩니다.
이 데이터베이스에 액세스하기 위해 ASP.Net 프로젝트에 코드를 작성합니다.
TeamCity의 프로젝트에서이 스크립트를 실행하는 단계를 생성합니다.
스크립트를 Git에 체크인합니다.

이전 섹션에서 생성 한 AWS 데이터베이스에서이 작업을 수행하는 단계입니다.

Step 1− MS SQL Server 데이터베이스와 해당 테이블을 생성합니다. SQL Server Management Studio를 열고 간단한 데이터베이스와 테이블을 만들어 보겠습니다. 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고New Database.

Step 2 − 이름을 Demodb 확인을 클릭하십시오

Step 3 − 새 데이터베이스에서 마우스 오른쪽 버튼을 클릭하고 새 테이블을 생성합니다.

Step 4 − 테이블에 원하는 열을 추가 할 수 있습니다.

Step 5 − 테이블을 저장하고 이름을 Demotb.

Step 6 − 이제 테이블을 마우스 오른쪽 버튼으로 클릭하고 메뉴 옵션을 선택합니다. Script Table as → Drop and Create to → File.

Step 7 − 데모 프로젝트 폴더에 파일을 다음과 같이 저장하십시오. Sample.sql.

이것이 데이터베이스 스크립트의 모습입니다. 먼저 기존 테이블이있는 경우 삭제 한 다음 테이블을 다시 만듭니다.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 − 이제 빠르게 변경하겠습니다. ASP.Net code 새 데이터베이스를 참조합니다.

Step 9 −에서 Tutorial.cs 당신의 파일 Demo project, 다음 코드 줄을 추가합니다. 이 코드 줄은 데이터베이스에 연결하고 서버 버전을 가져와 이름 변수에 버전 이름을 저장합니다. 이 Name 변수를Demo.aspx.cs 파일을 통해 Response.write 명령.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 − 다음 코드를 Demo.aspx.cs 파일이 SQL Server 버전을 표시하는지 확인합니다.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

이제 코드를 실행하면 브라우저에 다음과 같은 출력이 표시됩니다.

Step 11− 이제 TeamCity에서 데이터베이스 스크립트를 호출하는 단계를 추가하겠습니다. 프로젝트 대시 보드로 이동하여Edit Configuration Settings.

Step 12 − 빌드 단계로 이동하여 Add build step.

다음 옵션을 선택합니다 (MS SQL Server 클라이언트가 CI 서버에 설치되어 있어야 함).

실행기 유형은 명령 줄이어야합니다.
선택적 단계 이름을 제공하십시오.
실행은 매개 변수와 함께 실행 가능해야합니다.
명령 실행 파일은 C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe
명령 매개 변수는 -S WIN-50GP30FGO75 -i Sample.sql. 여기서 –S는 SQL Server 인스턴스의 이름을 제공합니다.

Step 13 − 저장을 클릭합니다.

이제 확인해야 할 것은 빌드 순서입니다. 빌드 순서가 다음과 같은지 확인해야합니다.

Step 14 − 빌드 단계를 재정렬하는 옵션을 선택하여 빌드 순서를 변경할 수 있습니다.

데이터베이스 설정이 먼저되어야합니다. 따라서 이것은 데이터베이스를 새로 만드는 데 사용됩니다.
다음은 애플리케이션 빌드입니다.
마지막으로 테스트 설정.

Step 15 − 이제 git add 과 git commit 명령하도록 Sample.sql파일이 Git에 체크인됩니다. 그러면 빌드가 자동으로 트리거됩니다. 그리고이 빌드는 통과해야합니다.

이제주기에서도 지속적인 데이터베이스 통합 측면을 갖춘 본격적인 빌드주기가 있습니다. 다음 섹션에서는이를 더 자세히 살펴보고 지속적 배포를 살펴 보겠습니다.

이제 로컬 SQL Server로이 작업을 수행 했으므로 동일한 단계를 반복 할 수 있습니다. AWS MS SQL이전 섹션 중 하나에서 생성 된 서버. Microsoft SQL Server에 연결하려면 다음 규칙을 통해 연결해야합니다.

Step 16− 먼저 AWS에서 데이터베이스 인스턴스에 할당 된 이름이 무엇인지 확인합니다. AWS에 로그인 할 때 데이터베이스 섹션 아래의 RDS 섹션으로 이동합니다.

Step 17 − 다음 화면이 나타나면 DB 인스턴스를 클릭합니다.

step 18− 데이터베이스를 클릭하고 엔드 포인트를 기록해 둡니다. 다음 스크린 샷에서는demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 − 이제 데이터베이스에 연결하려면 SQL Server Management Studio, 연결을 다음과 같이 지정해야합니다. demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (인스턴스 이름과 포트 번호 사이에 사용 된 쉼표에 유의하십시오).

다음 스크린 샷은 데이터베이스에 대한 성공적인 연결을 보여줍니다.

그런 다음 모든 동일한 단계를 반복 할 수 있습니다. 그만큼Sqlcmd command 다음과 같습니다-

이 동일한 명령은 TeamCity의 데이터베이스 빌드 단계에서 대체 할 수 있습니다. 실행할 때sqlcmd command, 테이블은 AWS의 SQL Server 데이터베이스에 자동으로 생성됩니다.

자동화 된 빌드 및 반복 가능한 빌드. 자동화 된 테스트 및 반복 가능한 테스트. 테스트 카테고리 및 테스트 빈도. 지속적인 검사. 지속적인 데이터베이스 통합. 효과적인 CI 환경을 만들기위한 이러한 일련의 작업은 주로 한 가지 주요 이점을 제공합니다. 즉, 어떤 환경에서든 언제든지 작동하는 소프트웨어를 릴리스하는 것입니다.

이전 장에서 다음 세그먼트를 모두 완료했습니다.

코드를 만들었습니다.
TeamCity에서 적절한 빌드를 확인했습니다.
데이터베이스 통합 프로세스를 만들었습니다.
성공적인 테스트를 수행했습니다.

이제 남은 것은 자동화 된 배포를 수행하여 전체 프로세스를 완료하는 것입니다.

우리의 경우 자동화 된 배포의 경우 다음 단계를 따라야합니다.

배포 서버에서 IIS가 설치되어 있는지 확인하십시오.
IIS 사용자에게 데이터베이스에 대한 액세스 권한이 있는지 확인하십시오.
사이트를 빌드 할 때 게시하는 데 사용할 게시 프로필을 만듭니다.
자동 배포를 수행하도록 MSBuild 명령을 변경해야합니다.
TeamCity를 자동화하여 자동 게시를 수행합니다.
할 git commit 모든 파일이 Git에 있는지 확인하십시오.

Step 1− 로컬 IIS 서버를 구성합니다. 로컬 또는 원격 IIS 서버가있는 경우 다음 구성을 수행하여 응용 프로그램을 배포 할 수 있습니다. 배포를 자동화 된 방식으로 수행하기 전에 수동으로 수행 할 수 있는지 확인하는 것이 항상 좋은 방법입니다.

Step 2 − Windows 2012 서버에서 서버 관리자로 이동하여 역할 및 기능 추가를 클릭합니다.

Step 3 − 다음 화면이 나타나면 다음을 클릭합니다.

Step 4 − 다음 화면에서 역할 기반 또는 기능 기반 설치를 선택하고 다음을 클릭합니다.

Step 5 − 기본 서버를 선택하고 다음을 클릭합니다.

Step 6 − 웹 서버 역할을 선택하고 다음을 클릭합니다.

Step 7 − 다음 화면이 나타나면 다음을 클릭합니다.

Step 8 − 나타나는 다음 화면에서 다시 다음을 클릭합니다.

Step 9 − 다음 팝업 화면에서 다음을 클릭합니다.

Step 10 − 마지막 화면에서 설치 버튼을 클릭하여 IIS를 설치할 수 있습니다.

IIS가 설치되면 인터넷 정보 서비스를 열어 열 수 있습니다.

Step 11 − 응용 프로그램 풀을 클릭하면 다음과 같은 이름의 풀이 표시됩니다. DefaultAppPool. 다음 단계에서 SQL Server에 액세스 할 수 있어야합니다.

Step 12 − ASP.Net 응용 프로그램을 MS SQL Server 응용 프로그램에 연결해야하는 경우 기본 응용 프로그램 풀에 대한 액세스 권한을 SQL Server 인스턴스에 부여해야합니다. Demodb 데이터 베이스.

Step 13− SQL Server Management Studio를 엽니 다. 로그인으로 이동하여 마우스 오른쪽 버튼을 클릭하고 메뉴 옵션을 선택합니다.New Login.

다음 화면에서 다음 매개 변수를 업데이트하고 확인을 클릭하십시오.

IIS APPPOOL \ DefaultAppPool로 로그인 이름.
기본 데이터베이스 – 이것은 demodb 인 데이터베이스 여야합니다.

Step 14 − 만들기 Publish Profile. 게시 프로필은 Visual Studio에서 MS Build 및 모든 CI Server와 함께 사용할 수있는 배포 패키지를 만드는 데 사용됩니다. 이렇게하려면 Visual Studio에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 게시 메뉴 옵션을 클릭합니다.

Step 15 − 다음 화면이 나타나면 새 게시 프로필 생성을 선택하고 이름을 지정합니다. DemoDeployment. 그런 다음 다음 버튼을 클릭합니다.

다음에 나타나는 화면에서 다음 값을 추가하십시오.

게시 방법을 웹 배포로 선택합니다.
서버를 localhost로 입력하십시오.
사이트 이름을 기본 웹 사이트 / 데모로 입력합니다.
도착 URL을 다음과 같이 입력하십시오. http://localhost/Demo

그런 다음 다음 버튼을 클릭합니다.

Step 16 − 다음 화면에서 다음을 클릭합니다.

Step 17 − 최종 화면이 나타나면 게시 버튼을 클릭합니다.

이제 당신이 가면 C:\Demo\Simple\Properties\PublishProfiles 프로젝트의 위치에 새로운 publish profile xml file만들어진. 이 게시 프로필 파일에는 응용 프로그램을 로컬 IIS 서버에 게시하는 데 필요한 모든 세부 정보가 포함됩니다.

Step 18− 이제 MSBuild 명령을 사용자 지정하고 위의 게시 프로필을 사용하여 어떤 일이 발생하는지 살펴 보겠습니다. MSBuild 명령에서 다음 매개 변수를 지정합니다.

Deploy on Build is true – 빌드가 성공적으로 완료되면 자동 배포가 트리거됩니다.
그런 다음 위 단계에서 사용 된 게시 프로필을 사용하도록 언급합니다.
Visual Studio 버전은 사용중인 Visual Studio 버전에 대한 MSBuild 배포 기능에 언급됩니다.

위의 명령을 실행하면 MSBuild가 빌드 및 배포 프로세스를 트리거합니다. 당신이 주목할 것은 우리의Default Website IIS 서버에서.

이제 사이트를 탐색하면 http://localhost/Demo/Demo.aspx 다음 출력이 표시됩니다. 즉, MSBuild가 웹 사이트에 성공적으로 배포했음을 의미합니다.

Step 19 − TeamCity를 통한 자동화 – 이제 위에서 언급 한 단계에 따라 MSBuild를 사용하여 애플리케이션을 배포하는 작업을 TeamCity 서버에 추가해야합니다.

Step 20 − 프로젝트 대시 보드로 이동하여 Edit Configuration Settings.

Step 21 − 빌드 단계로 이동하여 빌드 단계 추가를 클릭합니다.

다음 옵션을 선택하십시오-

러너 유형은 MSBuild 여야합니다.
선택적 단계 이름 제공
빌드 경로를 Simple / Simple.csproj로 입력합니다.
MSBuild 버전을 Microsoft Build Tools 2013으로 유지
MSBuild 도구 버전을 12.0으로 유지
명령 줄을 / p : DeployOnBuild = true / p : PublishProfile = DemoDeployement / p : VisualStudioVersion = 12.0으로 입력합니다.

Step 22 − 저장을 클릭합니다.

빌드 단계에서 배포 단계가 체인의 마지막 단계인지 확인합니다.

Step 23 − 이제 마지막으로 git commit, 모든 파일이 Git에 있고 TeamCity에서 사용할 수 있는지 확인합니다.

축하합니다. 애플리케이션에 대한 완전한 지속적 통합주기를 성공적으로 설정했습니다.이주기는 언제든지 실행할 수 있습니다.

지금까지 배운 모든 교훈을 바탕으로 지속적인 통합의 모범 사례를 최종 검토해 보겠습니다.

Maintain a code repository− 이것은 가장 기본적인 단계입니다. 모든 예제에서 모든 것은 코드베이스에서 게시 프로필, 데이터베이스 스크립트에 이르기까지 Git 저장소에서 관리됩니다. 항상 모든 것이 코드 저장소에 보관되도록해야합니다.
Automate the build− MSBuild를 사용하여 게시 프로필을 사용하여 빌드를 자동화하는 방법을 살펴 보았습니다. 이는 지속적인 통합 프로세스의 핵심 단계입니다.
Make the build self-testing − 단위 테스트 케이스를 그대로 유지하여 빌드를 테스트 할 수 있는지 확인하고 이러한 테스트 케이스는 Continuous Integration 서버에서 실행할 수있는 방식이어야합니다.
Everyone commits to the baseline every day− 이것이 지속적인 통합의 핵심 원칙입니다. 전체 프로세스가 끝날 때까지 누가 빌드를 망가 뜨리는 지 확인하는 데 아무런 의미가 없습니다.
Every commit (to baseline) should be built− 애플리케이션에 대한 모든 커밋은 성공적으로 빌드되어야합니다. 어떤 이유로 든 빌드가 실패하면 빌드가 통과되도록 코드를 변경해야합니다.
Keep the build fast− 빌드가 느린 경우 전체 연속 통합 프로세스에 문제가 있음을 나타냅니다. 빌드는 항상 지속 시간으로 제한되어야하며, 가급적이면 10 분을 넘지 않아야합니다.
Everyone can see the results of the latest build− TeamCity 대시 보드는 모든 사람에게 통과 또는 실패한 모든 빌드에 대한보기를 제공합니다. 이는 지속적 통합 프로세스에 관련된 모든 사람들에게 좋은 통찰력을 제공합니다.