GitLab-CI (Continuous Integration) 소개 & 도입당시 경험담

CI ( Continuous Integration ) 란

개발자가 각각 개발한 소스코드를 모아서 한꺼번에 통합 빌드의 과정을 특정 시점이 아니라 주기적으로 수행함으로써 통합에서 발생하는 오류를 사전에 해결하고 이러한 과정들에 소요되는 시간을 줄이기 위한 기법

CI 이란?

소프트웨어 개발에서 유지보수로 연결되는 지점은 소스관리/빌드/배포의 활동이 됩니다. 물론, 소스코드 수정이 발생되기는 하지만, 소스관리/빌드/배포의 활동이 주로 발생하기 마련이며, 이는 유지보수 시점에 확실한 절차와 방법을 필요로 합니다. 개발 시점에 이러한 활동을 지원하는 기법 중에 CI (Continuous Integration)가 있으며, 이는 오래 전부터 소프트웨어 개발에 있어서 위험을 줄이는 방식으로 사용되고 있었습니다.

CI 라는 용어가 직접적으로 사용되지는 않았지만, 1993년 Mattew Pittman이 쓴 'Lessons Learned in Managing Object-Oriented Development'라는 논문[참조 1]에서 "예정된 통합(scheduled integration)" 이라는 용어를 사용하고 있으며, 이는 CI를 수행할 때의 한가지 이슈에 대해 완벽한 테스트의 부족을 언급하고 있습니다. 즉, CI가 단순히 소스코드의 빌드와 배포만을 의미하지 않고 그 안에는 소스코드를 검증할 수 있는 방법이 분명 필요하다는 것을 말하고 있습니다.

코드 컴플리트(Code Complete)라는 책을 쓴 Steve McConnell은 1996년 'Daily Build and Smoke Test'[참조 2]라는 글에서 Microsoft사에서 일일 빌드 체계를 통해서 통합에 대한 위험을 격감사키고, Smoke Testing을 통해서 품질을 확보하고 있다는 내용을 언급하고 있습니다. 특히, 일일 빌드는 프로젝트에서 심장 박동(heartbeat)에 비유한 Jim MacCarthy의 말을 인용하여 일일 빌드(daily build)를 하지 않는다면, 그 프로젝트는 죽은 것과 같다고 표현하고 있습니다. 1990년대 후반부터는 XP(Extreme Programming)에서 CI를 기법으로 채용했으며(참조 : http://www.extremeprogramming.org/rules/integrateoften.html), Martin Fowler의 Continuous Integration이라는 글에서 본격적인 CI 기법에 대한 기본 원칙이 만들어지기 시작헀습니다.^[각주:1]

CI는 경험하지 않고선 이해하기 힘들다

형상관리 항목에 대한 선정과 형상관리 구성 방식 결정

빌드/배포 자동화 방식

단위테스트/통합테스트 방식

이 세 가지를 모두 고려하여 유기체처럼 결합되고 자동화된 프로세스를 구성해야하는데 참 말이 쉽다

경험을 얘기해볼까 한다

"비전공(무역학과)출신, 입사 후 6개월" 

막막함이 눈 앞에 서리던 당시의 얘기다

밤 12시 퇴근이 익숙할 무렵

필자는 업무외에 프로젝트를 자주했다

Xen, ①Git서버, ②버전정책 에 이이서 

이번엔 '③빌드자동화' 였다

앞서 빌드 프로젝트를 진행하다 개발자로 전향한 동료가 있어 도움을 요청하였다

빌드동작은 CI 의 일부란 것을 알게 되었고

그렇게 처음 접한 CI tool은 'GO' 였다

'커밋된 내용을 git 서버로 Push하게되면 컴파일하고 빌드한다' 라는 설명과

Web에서 빌드상태는 이렇게 보고 빌드스크립트는 이런식으로 작성이 되었구나 

딱 그 정도만 이해를 이해를 할 수 있었다 

그런데 이것만으로는 업무에 도움이 될 것 같지 않았다

또한 매 커밋마다 수행할 과정, 그 자체가 현실과 동떨어져 있었다

* 부연설명

CI 툴에서 프로세스를 수행하는 주기는 기본적으로 두 가지 (커밋마다, 데일리 빌드)이다

1. Commit ( Default )

2. Daily build

3.  Event Base ( ex. 고객사 요청시 )

실 업무에 효용이 있기 위해선

패치 & 릴리즈 & 고객사 요청시와 RC(Release Candidate) 선출작업시에 

빌드와 패키징 업무를 수행할 게 필요하다 생각했다 

즉, 사람이 하던 실제 Process를 컴퓨터가 하도록 해보자는 것이다

그래서 CI 프로세스 수행주기에 있어 Event Base를 커버하여야 했다

( 도구에서 지원하지 않기에 머리를 굴려야 하는 부분이다 )

또 추후 결합될 녀석을들 위해 연계부위를

아래의 이유로 CI 툴도 젠킨슨 & GO -> Gitlab & Gitlab CI로 변경했다

BTS( Redmine ), Confluence, Gitlab,  XEN, 젠킨슨, GO · · · 프로젝트 한 번에 대시보드 하나가 늘어난다

 관리point가 늘어나는 것은 관리자도 후대에게도 부담스러운 일이다

그래서 한 번에 합쳐진 (Gitlab <->) Gitlab CI를 선택했다

계획을 수립하는 것도 쉽지않은 일이었다

빌드와 패키징 전과정을 파악하고

개발자에게 빌드 & 패키징을 어떻게 하는지 묻고 배워

컴포넌트 컴파일 패키징

DB 설치

총괄 패키징 등

전 동작을 커맨드라인화했다

9개의 Project가 이런 저런 동작을 거쳐 몇 개의 패키지와 배포 파일로 만들어 지는 것이다 

0

중간보고에 이어 

최종보고를 하게 되었다

완료 보고

ㅠㅠ

콤포넌트의 버전을 세팅하고 빌드동작을 수행하면

지금까지 사람이 해왔던 일을 컴퓨터가 하는 것이다 

저장소와 빌드서버만으로는 'CI'라 할 수 없기에

 이후 정적분석 & 새로생긴 패키지 & 환경구성 & 검증 등 ( UI 테스팅파트는 설계 중 )

여러 업무를 수행하도록 수정 및 추가하였다

수차례 수정했던 첫 Pipeline 설계서

It works well !

완성하고 4개월정도 매장을 당했다가

 제대로 조명받고 지금은 열일하고 있다

( 내가 만든 피조물은 내 자식과 같다, 하염없이 자랑스럽다 )

stage : Setting_env

* ora : ORACLE ( Repo )

* pg : PotsgreSQL ( Repo )

* new : 설치방식 - 신규설치

* patch :  설치방식 : 패치

내가 떠난 후에도 사명을 다하길

아참, 오래 전에 이 녀석의 이름을 지어놨다

"피그렛"

Piglet - MFO Tester

PS. 가볍게 읽을 수 있도록 작성하고 싶었지만 주제가 그럴 수 없나보다

gitlab-ce 에는 수준 높은 파이프라인을 확인 할 수 있다

1. CI (Continuous Integration) 이란? - http://www.nextree.co.kr/p10799/ [본문으로]