TeamCity 로 AWS + GitHub + .NET Continuous Integration 만들어보기 (2)

지난 글에 이어서

모든 branch는 자동 빌드 시킨다

회사에서는 ASP.NET 환경 MVC 5 를 사용하고 있다. 1 Solution이 n개의 프로젝트를 가지고 있고, 그 중에 몇 개가 사이트 프로젝트로 나뉘어져 있는 상황.
1 사이트 = 1 솔루션 = 1 github repository 일 경우 에는 가장 쉬운 결론이 날 수도 있다.
하지만 환경이라는게 꼭 그렇게 단순하지만은 않다.

MSBuild.exe %slnPath% /t:Build /p:Configuration=Release /p:TargetFramework=v4.0 /p:OutDir=%outRootPath%  

위 Build Script를 실행하게 되면, %slnPath% (솔루션 경로) 의 Solution을 Build 하여 %outRootPath% 경로로 Release mode로 게시된 파일들이 들어가게 된다. 이 Solution을 Build 하게 되면 여러 개의 사이트가 Deploy 된 상태가 된다.

All Branches Auto Build 환경 구성

기본적으로 TeamCity 에서는 MS Build 를 지원해주고 있다. TeamCity에서 프로젝트를 생성하고, VCS 를 GitHub으로 등록하고,

Git 등록시 중요한 부분

Branch specification: 부분에서

+:refs/heads/*

+:refs/pull/(*)/head

로 진행하면 GitHub Repository의 모든 Branch(위), 모든 Pull Requests(아래)에 대하여 Build Configurations 를 진행할 수 있다.

develop 혹은 master만 진행하고자 한다면 branch specification 부분을 변경하면 된다.

+:refs/heads/develop

+:refs/heads/master

모두 Build 하고, Master만 뺄 수도 있다.

+:refs/heads/*

-:refs/heads/master

참조 : https://confluence.jetbrains.com/display/TCD9/Working+with+Feature+Branches

github 설정 이후 생성한 프로젝트의 Build Configurations 를 등록한다.
Auto Build

하나의 빌드 설정에 되도록이면 많은 일들을 할 수 있게 두어야 한다. 이유는 무료는 20개 밖에 못 만드니깐!!!

하지만 Dependency를 잘 생각하고, To Do에 대한 계획을 정확하게 세워야 한다. 빌드가 실패 하면 그것에 대한 처리를 어떻게 해야 할지도 생각 해봐야 하기 때문이다.

스크린샷에서와 같이 Auto build 설정에는 4가지 일을 하게 한다.

  1. 초기화 (배포 폴더의 Cleanup)
    • 코드 변경시마다 추가/삭제 되는 파일들 때문에 Publish 폴더의 CleanUp
  2. MS Build를 통한 Build
    • MS Build를 이용하여 Build Script 실행
  3. Test 코드들을 Testing
    • MS Test 코드로 작성된 Unit Testing Code 들을 테스트 한다.
  4. Copy static files
    • Solution에 속해 있지 않는 정적 파일들을 배포 폴더로 복사 해주는 역할을 한다.

1. CleanUp

배포 폴더=%outRootPath를 잡은 곳에 대해서 항상 CleanUp을 수행하도록 했다. 파일이 변동될 때는 Update 뿐만 아니라 Delete도 변동사항이 되어버리는데, 실제 서버는 Delete 파일에 대한 처리를 정확하게 하지 않아서 그리고 가끔 bin 폴더의 같은 이름 다른 어셈블리로 인한 현상 때문에 시간을 허비하는 일들을 경험했기에 그냥 깨끗하게 폴더 CleanUp을 시켜버린다.

덕분에 추가 Assemblies 관리는 특별하게 해야한다. 사내에서 사용하는 3rd Assemblies 같은 경우에는 나중에 4단계의 copy static files 할 때 처리 하도록 한다.

해당 Build 설정은 command line 을 통해 작성 했다. windows 서버라면 unix 계열의 rm / -rf 와 같은 무지막지한 명령어인 rd [경로] /s/q 를 사용하여 깨끗하게 지워버린다.
그리고 mkdir [경로] 를 통해 NEW 폴더를 생성하여 CleanUp 시켜버렸다.

2. MS Build

맨 위의 MS Build 스크립트를 실행하는게 아니라 TeamCity 에서는 MS Build를 지원한다. MS Build 그림에서와 같이 outDir 쪽을 TeamCity Parameters 로 등록해두어서 사용 했다.

3. Test

TeamCity(Version 9.1.6)는 착하게도(?) Visual Studio Test 를 지원한다.
Visual Studio Test 는 해당 테스트 프로젝트의 DLL을 경로로 넣으면 자동으로 테스팅 해주는 내용이다.
개인적으로 Visual Studio Test 보단 nUnit 같은 3rd party test framework 들을 이용하는게 더 좋다고 생각한다. 경로를 잘 지정해서 [테스트 프로젝트 파일이름].dll 을 넣으면 Test를 진행한다.

4. Copy Static Files

Visual Studio로 보통 웹사이트를 작업하면 보통 /images 같은 정적 폴더(Static Folders) 들을 솔루션에 등록시키지 않고 사용한다.
솔루션에 다 등록시켜서 사용하면 프로젝트 파일의 일이 끊임없이 발생 될 것이다. 그래서 게시(Deploy)할 때 빌드 된 파일들을 넘기고, 이후에 /images 와 같은 정적 폴더들을 %outRootPath 와 같은 곳에 Copy 시켜주는 Script 를 실행한다.

이 부분은 역시 Command Line 의 Custom Script를 통해 진행했다.

Build 전략

빌드가 성공 했다면 다행이지만, 실패 했을 때의 처리를 어떻게 해야 할지 생각해봐야 한다. 전체 branches 에 대한 빌드를 수행시켜 놨기 때문에, 특정 branch 들은 Build Fail 이 날 확률이 높아진다. 해당 branch 전략을 어떻게 가져갈지에 따라서 생각하는 방향이 다르겠지만, Build Fail 이 일어났다면 팀원들에게 notification이 갈 수 있도록 해야한다. 너무 잦은 notify 는 필요하지 않기 때문에 회사 및 팀에서의 의견 교환을 통해 적절한 수준으로 계획해야 한다.

Ssemi

Read more posts by this author.