CI에 대해서 기억해보자면,
2004년쯤의 프로젝트에서 시작된다.
비교적 대규모의 프로젝트로 6-7개 업무가 각각의 빌드를 수행하고,
이를 통합하여 하나의 시스템이 돌아기는 형태였는데,
이때 구현 된것은 형상관리도구로부터 소스를 받아서 빌드 스크립트를 돌리고 배포 가능한 형태로 떨구는 작업까지였다.
(소스를 받아오고 컴파일 하는데 걸리는 시간은 미미했지만 정작 컨테이너를 내리고 올리는데 걸리는 시간이 거의 전부를 차지했다.)
그러나 한줄 엔터로 구현해 놓은 이 스크립트를 빌드담당자가 돌리고, 결과 확인하고, 조치하는데 자주 밤을 새고 있었다.
물론 개발자들이 작업을 하지 않는 시간대에 일을 해야 하다보니 애로사항도 있었고,
빌드가 실패한 경우에 당사자가 아니니 대응도 못하고 시간만 허비하는 경우도 많았다.
그리고 몇년이 지나서 CI 서버 도구에 대해서 알게 되었고,
지속적으로 관심을 가지면서 여기까지 오게되었다.
CI가 무엇을 목표로 하는지, 왜 필요한지 이해는 하고 있지만
현재까지 남아있는 현장(?)의 한계를 생각해보면
- 단위테스트 작성에 대한 부담감이 크다.
테스트 작성에 대한 점진적인 지침이 제시되어야 하는데, 통상 코칭 역할을 해야할 위치에 사람이 적절하지 못한 경우가 많다.
( 일이 2배가 된다고 생각하는 경우가 많다. ) - 시스템 및 기능테스트에 어려움을 느낀다.
소요시간이 지나치게 소모되는 경우도 있고,
이종의 복잡한 환경이 결합되면서 테스트 자동화에 대한 실마리를 찾지 못하는 경우가 있다.
예를 들어 X-Internet 기술을 사용하는 제품의 경우 웹 시뮬레이션 도구로는 한계가 있다. - 품질검사 도구에 대한 표준 정책 부재
유용하게 제공되는 품질검사 도구들이 있지만 무작위적으로 도입하기에는 다소 버거울 경우가 많다.
예를 들어 CCN이 얼마인 경우를 문제로 볼것인가,
또는 Code Inspection Rule을 어떻게 가져갈것인가 등에 대한 판단을 수행해줄 주체가 없는 경우가 잦다. - 지속적인 DB 통합의 어려움
DB를 일반 소스와 같이 형상관리 대상으로 고려하지 못하는 환경적인 측면도 있고,
DB 내의 방대한 샘플 데이터를 재구축하는데 따르는 부담,
DB를 이용하는 프로그램 간의 의존관계가 지나치게 묶여있는 경우가 많다.
CI라는 개념이 좀더 Agile한 개발과 가치, 그리고 삶의 질을 높여주는데 도움이 될것이라는 점에서
보다 많은 사람들이 혜택을 누릴수 있으면 좋겠다.
지속적인 통합 - 소프트웨어 품질을 높이고 위험을 줄이기
위키북스
Continuous Integration:Improving Software Quality and Reducing Risk
Paul M. Duvall, Stephen M. Matyas III, Andrew Glover / 최재훈 역 2008
- CI란?
팀 구성원들이 자신이 한 일을 자주 통합하는 SW개발 실천방법.
- CI의 특징
버전관리저장소로 연결
빌드 스크립트
피드백 메커니즘
통합 프로세스
- CI가 제공하는 가치
위험을 줄여준다
결함을 조기에 발견하고 수정할수 있다.
SW건강성을 측정할수 있다.
반복적인 수작업을 줄여준다
보다 가치있는 일을 할수 있게 해준다.
언제 어느때라도 배포 가능한 SW를 생성한다
배포가능한 SW는 고객의 눈에 보이는 / 손에 잡히는 자산이다.
프로젝트 가시성을 높여준다
효과적인 의사결정을 돕는다.
전체적인 품질의 추이를 인지할수 있도록 돕는다.
개발팀이 SW 제품에 대해 자신감을 갖게 해준다.
변경한 코드가 미칠 영향력에 대한 우려가 줄고 더 자신있게 변경할 수 있다.
- CI가 해결할수 있는 위험요소는 어떤 것들인가
배포가능한 SW의 부재
"내 컴퓨터에서는 되는데요"
"버튼을 안눌렀어요"
뒤늦은 결함발견
"회귀테스트"
프로젝트 가시성의 부재
"제가 남긴 메모 보셨나요?"
저품질의 SW
코딩표준준수
- 왜 도입하지 않는가
CI 시스템의 유지보수 부하
수작업 시간과 비교하라
변경할게 많다
점진적 도입
빌드 실패가 잦다
개인 빌드를 수행하라
추가적인 장비/SW 비용
CI가 없을때의 비용과 비교하라
- 언제 도입할까?
초기가 Best
후반이라면 작은것부터 점진적으로
- 효과적인 CI를 위한 실천지침
코드를 자주 커밋하세요
조금씩 자주 바꾸세요
깨진코드를 커밋해선 안됩니다
개인빌드를 돌리세요
빌드가 깨지면 즉시 고치세요
프로젝트를 위해 최우선으로 할 일입니다.
자동화된 개발자 테스트를 작성하세요
테스트와 검사는 모두 통과해야 합니다
품질을 높여줍니다.
개인 빌드를 돌리세요
깨진 코드는 가져오지 마세요
- 빌드시간이 오래걸린다 -> 빌드메트릭 진단이 필요함
전용 통합빌드장비 사용하기
장비의 사양을 높이기
테스트 성능을 개선하기
빌드구조를 최적화 / 분산하기
- 지속적인 DB 통합
로컬 DB Sandbox 사용
DB자산을 버전관리하여 공유할것
빌드자동화
DB수정권한을 개발자에게
DBA를 팀의 일원으로 만들기 -> 성능향상, 정규화, 가치부가적인 개선업무에 할당.
- 테스트 자동화
단위 테스트
SW내 작은 요소(클래스)의 행동 검증. DB와 같은 외부의존성에 기대지 않음.
컴포넌트 테스트(하위 테스트)
시스템의 일부를 검증. 외부 의존성을 포함.
시스템 테스트
웹페이지, 웹서비스 종점, GUI가 처음부터 끝까지 설계된 대로 작동하는지를 검증
ex) JWebUnit
기능테스트( 인수테스트)
애플리케이션의 기능성을 클라이언트의 관점에서 테스트
ex) selenium
- 지속적인 검사
코드 복잡도 : Cyclomatic Complexity Number
10보다 큰 CCN을 가진 메소드는 상대적으로 결함발생 위험이 높음.
- 지속적인 배포
label 붙이기
clean 환경 만들기
빌드후 label 추가
TEST 수행
빌드 피드백 보고 / 또는 롤백
- 지속적인 피드백
적절한
사람
정보과부하 주의.
정보
시기
방법
적절한 의사소통 메커니즘을 고르고, 어떻게, 누구에게 정보를 보낼지 선택하는 것
ex) 브라우저, 모니터, 소리, 이메일, 메신저
- CI의 미래
빌드가 빨리 이루어지고, 깨지지 않았으면 좋겠다.
"개발자는 단지 버전관리 시스템에 수정한 코드를 커밋하기만 하면 된다."
저장소에 등록되기 전에 미리 통합빌드를 수행하고 성공한 경우에만 커밋처리...
이 글은 스프링노트에서 작성되었습니다.