Continuous Integration의 장점 1

황당한 사태가 벌어져도 당황할 필요 없다.

불과 몇 초전에 발생했던 황당한 사태 입니다.

사용자 삽입 이미지오늘 하루도 정말 열심히 일했고 할 만큼 했다는 생각이 들어서 최종적으로 커밋을 깔끔하게 집에 갈 생각이었습니다. 그런데 왠 걸.. FAILED 메시지가 구글톡에 전해졌습니다. 아 놔~~ 집에 가고 싶은데.. ㅠ.ㅠ

대나무(Bamboo) 숲으로 들어가서 고장난 빌드 로그를 살펴봤습니다. 이런!! 테스트가 죄다(는 아니지만 상당히 많이) 깨졌군요.

사용자 삽입 이미지
헐.. 60개가 넘는 테스트가 한 방에… 그것도 바로 전까지 모두 Success 였는데.. 흠~ 예전 같으면 갑자기 어깨가 굳고 눈동자가 커지면서 조급해졌을텐데, 이젠 좀 CI랑 친해졌는지 더이상 두려워지지 않고 차근 차근 로그를 보고 깨진 테스트를 로컬(이클립스와 콘솔에서 메이븐으로)에서 실행해 봅니다.

그리고 문제의 원인을 발견합니다. 문제의 원인은 분명 이전에 커밋한 코드와 방금 커밋하기 전 코드 사이에서 생겨난 겁니다. 왜냐면 바로 전 단계의 빌드는 Success였기 때문이죠.

문제의 원인은 간단했습니다. 스프링 XML 설정파일에서 빈 이름을 잘못 설정했기 때문입니다. 그래서 모든 통합테스트들이 깨졌고, 단위테스트들은 살아남았던 겁니다. 이걸 계기로 통합테스트가 총 몇 갠지도 덤으로 알 수 있게 됐네요. ㅋㅋ

어쨋거나 중요한 건 CI가 주는 장점 한 가지. 바로 버그 발생 원인 탐사 범위를 좁혀준다는 거… 매우 귿입니다.

이젠 그만 집으로 ㄱㄱㄱ

CI 도입하기

CI의 가치

  • Risk를 줄여줌.
  • 손수 처리해야 하는 반복작업 줄여줌.
  • 언제 어디서나 배포가능한 소프트웨어 만들어줌.
  • 프로젝트 가시성을 높여줌.
  • 프로젝트 팀원들의 소프트웨어 제품에 대한 자신감 상승.

CI를 사용하는데 방해가 되는 요인

  • CI 시스템 관리 때문에 부가된 오버헤드.
    • 할 일이 많아보이지만, 사실 빌드, SCM, Test 들은 CI와 상관없이 존재해야만 하는 것들이다.
  • 너무 많은 변화를 요구함.
    • 점진적으로 도입하는 방법 선택가능.
  • 맨날 빌드 실패해.
    • 개발자가 private build를 실행해보지도 않았거나, 테스트 하지 않은 소스를 올려서 그렇다.
  • 하드웨어/소프트웨어 비용
    • CI에 필요한 별도의 서버나 소프트웨어 비용이 나중에 버그 발견하고 고치는 비용에 비하면 싼거다.
  • 개발자에게 추가 작업이 요구된다.
    • 인정. 그래도 자동화 도구가 있으니까..

지속적으로Continuous 통합하려면 어떻게 해야하나? I Build So Consistently (IBSC 외우기 좋으라고 만든 말)

  • Indentify
  • Build
  • Share
  • Continuous

CI를 언제 어떻게 도입해야 하는가?

  • 프로젝트 초기에하는게 좋다.
  • 프로젝트 후반에 도입한다면 점진적으로 해야한다. 변화를 싫어하기 때문에..

Integration의 진화

  • 역사는 지겨워서 pass

CI가 다른 개발 방법들과 어떤 충분관계를 가지는가?

  • 개발자 테스트
  • 코딩 표준 정착
  • 리팩터링
  • 작은 배포
  • Collective Ownership

CI를 설치하는데 걸리는 시간은?

  • 프로젝트 시작할 때 하면 몇 시간이면 되지만, 프로젝트 도중에 하려면 몇 일이 걸릴 수도 있다.

CI와 당신

  • 자주 커밋하라.
  • 깨진 코드는 커밋하지 말아라.
  • 깨진 빌드는 그 즉시 고쳐라.
  • 자동화된 개발자 테스트를 작성하라.
  • 모든 테스트와 조사Inspection를 통과해야 한다.
  • 개인 빌드를 실행하라.
  • 깨진 코드는 받지 말아라.

참조 : Continuouse Integration

마침 프로젝트 초기니까.. 도입해야겠군요.

CI 시나리오

참조 : Continuous Integration(아마존 별 다섯)

Countinuous Integration은 다음과 같이 매우 간단한 원리로 동작합니다.

1. 개발자가 코드를 버전 관리 저장소에 커밋한다. 그 즉시, 통합 빌드 머신에 있는 CI 서버는 저장소의 변경사항을 꺼내온다.

2. 커밋이 완료 된 후, CI 서버는 버전 관리 저장소에 발생한 변화를 확인하고, 저장소에서 최신 버전의 소스를 받은 뒤에 소프트웨어를 통합하는 빌드를 실행한다.

3. CI 서버는 이메일로 빌드의 결과를 프로젝트 구성원에게 알려준다.

4. CI 서버는 계속해서 버전 관리 저장소의 변화를 주시한다.

사용자 삽입 이미지
개발자
    해야할 작업을 완료하는데 필요한 코드들을 변경한 뒤, 개인적인 빌드(이 빌드에는 버전 관리 저장소에서 최신 코드를 업데이트 하는 과정이 포함되어 있다.)를 수행한다. 그 뒤에 자신의 소스를 버전 관리 저장소에 커밋을 한다. 이 순간까지는 위에서 살펴봤던 CI 프로세스에 어떠한 영향도 끼치지 않는다. 왜냐면, 통합 빌드는 버전 관리 저장소에 변경사항이 적용 된 후에 실행될 테니까.. 이 일들은 모두 IDE를 통해서 할 수도 있고 그냥 콘솔에서도 할 수 있다.

버전 관리 저장소
    CI를 하려면 반드시 필요하다. 사실, CI를 하지 않더라도, 버전 관리 저장소는 모든 프로젝트에서 필수요소다. 버번 관리 저장소의 목적은 소스 코드와, 소프트웨어 Asset(문서 같은)의 변경 사항을 관리하기 위한 것이다. CVS, Subversion, Perforce, PVCS, ClearCase, MKS, Visual SourceSafe 같은 여러 종류의 소프트웨어 형상 관리 툴SCM이 있다.

CI 서버
    CI 서버는 버전 관리 저장소에 커밋이 발생할 때마다 통합 빌드를 수행한다. CI 서버가 버전 관리 저장소를 알 수 있도록 설정해야 한다. CI 서버는 정해진 추기 마다 빌드를 수행하도록 설정할 수도 있다. CI 서버는 보통 빌드 결과를 알려주는 게시판을 제공한다. CI를 하기 위해서 반드시 CI 서버를 사용해야 하는 것은 아니다. 수작업으로 해도 된다.(굳이 라이터를 놔두고 부싯돌로 불을 켜야 하나 -_-;;) 다수의 CI 서버가 무료로 오픈소스 형태로 제공된다. CruiseControl, …

빌드 스크립트
    빌드 스크립트는 여러 스크립트의 집합체로, 컴파일, 테스트, inspect, 소프트웨어 배포 등을 위해서 사용한다. Ant, NAnt, make, Rake, Maven, Raven등을 사용할 수 있다. 소프트웨어 빌드 사이클을 자동화 할 수 있는 수단을 제공하지만 그들 스스로 지속적인 통합CI을 수행하지는 못한다.

피드백 매카니즘
    CI의 주요 목적은 통합 빌드에 대한 결과를 생성하는 것이다. 가능한한 빨리 빌드 결과를 알고 싶을 것이다. 문제를 빨리 발견할수록 빨리 고칠 수 있을테니까.. 이메일, 문자SMS, RSS등으로 결과를 받을 수 있다.

통합 빌드 머신
    오직 소프트웨어 통합을 위한 별도의 머신이다.이 머신에서 CI 서버와 CI 서버가 주시할 버전 관리 저장소를 돌린다.

ps : visa 카드만 오면… 바로 지를 책 중 1