Career Skills_P3 - Ch31. 지속적 통합(Continuous Integration)

소프트웨어를 빌드하고 이를 배포하기 위해 테스트하고 패키징하는 과정은 느리고 고통스럽고 따분한 데다 에러도 많이 난다. 그런데 지속적 통합은 이 과정을 자동화해주며 빠른 피드백을 제공한다.

 

| 과거의 코드 빌드 방법 |

옛날에는 개발자로 일하다보면 소스 코드 사본을 얻어야 할 때도 있었다. 해당 소프트웨어를 지난 5년간 관리해온 구루가 보여주는 마법의 주문을 보아야만 주체적으로 일할 수 있었다(저자는 닭을 잡아서 원을 그리며 뒤로 걷고 별 모양 주변에 촛불을 밝힌 다음 단축기를 누르면 소프트웨어 완성본이 튀어나왔다라는 비유로 표현함..). 이런 식의 소프트웨어 개발 및 빌드 방법에는 몇 가지 큰 문제가 있었다. 개발자가 각기 다른 방식으로 소프트웨어를 빌드하면 같은 버전의 코드를 가지고 완전히 다른 소프트웨어를 만들어낼 가능성이 무척 컸다. 그리고 각자의 컴퓨터에 각기 다른 버전의 외부 라이브러리가 설치되어 있을 수도 있다. 여러 개발자가 수일 혹은 수주에 걸쳐서 엉망인 체크인하다가 마침내 누군가 빌드하려고 할 대 코드가 망가졌다는 걸 알게 되면 일이 아주 재미있어진다.

 

 

| 그리고 빌드 서버가 등장한다 |

중앙 빌드 서버를 사용하는 야간 빌드 덕에 모두가 동기화될 수 있었다. 그 대신 야간 빌드에 문제가 생기면 그 문제부터 해결해야 했다. 하지만 심각한 문제도 여전히 존재했다. 피드백 주기가 더 짧아져야 했다. 

 

 

| 마침내 지속적 통합으로 |

어떻게 해야 새 코드를 소스 제어에 체크인할 때마다 코드를 빌드할 수 있을까? 답은 지속적 통합 서버였다. 개발자들은 피드백 주기를 더 줄이기 위해 코드 베이스의 빌드 시간을 줄이는 작업에 돌입했다. 

지속적 통합은 처음 한 번만 체크인해두면 단위 테스트, 정적 코드 분석기 같은 코드 품질 평가 실행이 동시에 이루어지는 수준까지 진화했다. 피드백 주기가 짧아지도록 개발자들이 코드를 최대한 빨리 자주 체크인하게 하는 부분이 가장 어려웠다. 그리고 여전히 이 부분이 가장 큰 장애물로 남아 있다.

 

 

| 지속적 통합 작업 흐름 샘플 |

코드 체크인

코드 체크인과 함께 작업 흐름이 시작된다. 물론 모든 이들의 빌드를 망가뜨리는 사고를 치지 않도록 감히 메인 저장소에 코드를 체크인하기 전에 로컬 컴퓨터에서 빌드를 실행하고 모든 단위 테스트를 실행했어야 한다. 

 

새 빌드 시작

빌드 서버에 있는 CI 소프트웨어가 모니터링하던 소스 제어 브랜치의 변화를 막 감지했다. CI 서버가 새로운 빌드를 시작한다. 

 

코드 체크아웃

새 빌드가 시작되면 최신 수정 사항부터 가져온다. 자신이 넣은 코드를 비롯해 브랜치에 일어난 모든 변화를 내려받고 작업 디렉터리에 넣는다.

코드 컴파일

빌드 스크립트가 실제로 코드를 컴파일하고 빌드하기 시작하는 시점이다, 빌드 스크립트는 소스 코드 빌드 명령을 실행한다. 외부 라이브러리를 비롯해 코드 컴파일에 필요한 모든 것을 링크한다.

코드가 컴파일되지 않으면 빌드는 거기서 멈추고 에러가 보고된다. 이런 상황을 빌드가 깨졌다고 한다. 좋지 않은 상황이다.

 

정적 분석기 실행

코드가 제대로 빌드되었다면 정적 분석기가 실행되어서 코드 품질을 측정한다. 무슨 말인지 몰라도 괜찮다. 코드를 살펴보고 발생할 것 같으 에러나 모범 사례 위반을 찾는 도구라고 생각하면 된다.

분석기에서 나온 결과는 빌드가 완료되었을 때 보고할 수 있게 저장된다. 정적 분석기에서 산출한 코드 품질 점수가 기준에 미치지 못하면 빌드가 실패하도록 설정할 수 있는 경우도 있다. 

 

단위 테스트 실행

다른 데 문제가 없다면 단위 테스트를 시작할 단계다. 컴파일된 코드를 대상으로 단위 테스트가 실행되고 나중을 위해 결과는 기록된다. 단위 테스트를 통과하지 못하면 보통 빌드 자체가 실패한다.

 

결과 보고

마침내 빌드의 결과가 보고될 시점이다. 보고서에는 빌드가 성공했는지 실패했는지, 실행하는 데 시간이 얼마나 걸렸는지를 비롯해 코드 품질 기준, 단위 테스트 등에 관한 정보가 담긴다. 문서도 아마 빌드에 의해 자동으로 생성될 것이다. 결과를 이메일로 팀원들에게 보내도록 설정할 수 있다, 실패했을 때만 보내게 할 수도 있다. 대부분의 CI 소프트웨어 프로그램은 최신 빌드의 결과를 볼 수 잇는 웹 인터페이스도 갖추고 있다. 

 

소프트웨어 패키징

이제 빌드 소프트웨어는 배포하거나 설치할 수 있는 형태로 패키징된다. 여기에는 컴파일된 코드와 더불어 외부 리소스나 의존성을 어떤 구조로 묶어서 배포 또는 설치가 가능한 형태로 만드는 과정이 포함된다. 모든 파일을 포함하는 파일 구조를 만든 후 전체를 압축하기도 한다.  이 시점에서 소프트웨어의 버전을 표시하기 위해 소스 제어에 태그를 추가하기도 한다.

 

코드의 선택적 배포(지속적 배포)

마지막 단계는 선택 사항이다. 사실 패키징 단계도 선택적이라고 볼 수 있다. 하지만 지속적 배포를 시행하는 팀이 점점 늘어나는 추세다. 지속적 배포란 테스트 목적으로 코드를 특정 환경에 직접 배포해보는 것이다. 정말 용감하다면 바로 생산하기도 한다.

 

완료

새 코드가 체크인될 때마다 자동으로 코드를 빌드하고 문제를 확인하고 배포 준비를 한다는게 핵심이다. 

 

 

| CI 서버와 소프트웨어 |

지속적 통합에서 한 가지 핵심적인 컴포넌트 바로 CI 소프트웨어다. CI 소프트웨어가 없다면 맞춤 스크립트를 써야 한다. 그 말은 빌드 서버를 직접 프로그래밍해야 한다는 뜻이다. 다행히 CI 소프트웨어 구축의 가치를 빠르게 깨달은 똑똑한 개발자가 많았다. CI 소프트웨어는 지속적 통합의 일반적인 작업 대부분을 자동화해준다. 이 책이 쓰인 시점(2019)에서 가장 널리 사용된다고 생각하는 몇 가지만 소개하겠다. 

 

젠킨스(Jenkins)

저자가 즐겨 쓰는 CI 소프트웨어다. 원래는 자바 환경에서 CI를 할 수 있게 만들어진 자바 프로그램이었다. 하지만 사용하기 쉬운 데다 유명세까지 얻으면서 다른 대부분의 기술에서도 쓸 수 있게 되었다. 젠킨스는 자체적으로 웹서버를 갖추고 있어서 설치하고 실행하기가 정말 쉽고 플러그인도 많다.

 

허드슨(Hudson)

오라클이 관리하며 저자는 허드슨이 젠킨스만 못하다고 생각한다. 허드슨을 만들었던 코슈케 가와구치를 필두로 한 허드슨 개발팀 대부분이 젠킨스롤 옮겨오기도 했다.

 

트레비스 CI(Travis CI) 

깃허브에 호스팅된 프로젝트에서 CI를 실행할 수 있도록 만든 소프트웨어다. 깃허브에 호스팅된 프로젝트가 많아서 인기를 끌게 되었다. 설계도 훌륭하고 사용하기도 쉽다. 게다가 빌드 서버를 유지 보수할 필요가 없어져서 좋다.

 

TFS(Team Foundation Server)

마이크로소프트 개발 도구를 사용하는 업체에서 일한다면 TFS를 사용해 지속적 통합을 할 수 있다. 하지만 저자의 경험상 TFS 에서 제공하는 서비스는 지나치게 단순화되어있고 다른 유명한 소프트웨어들에 비해 경쟁력도 떨어진다고 한다. 하지만 단순한 걸 원하고 꼭 마이크로소프트의 솔루션이 필요한 사람에게는 TFS 가 맞을 수도 있다.

 

팀시티(TeamCity)

인기 CI 중 하나다. 젯브레인스(JetBrains)라는 영리 회사가 만들었다. 무료 버전이 있긴 하지만 이 또한 라이선스 제품이다. 그러므로 조금 더 전무적인 지원을 받을 수 있는 제품을 찾는 사람에게 좋다. 많은 .Net 팀이 팀시티를 CI 서버로 쓴다.

 

더?

인기 있는 CI 서버 중 극히 일부만 소개했다. 하지만 그 외에도 서버가 많다. 모든 선택지를 알고 싶다면 저자의 블로그에서 더 자세한 목록을 확인해보기 바란다.