2016년 3월 2일 수요일

Continuous Integration (지속적인 통합)

소프트웨어 공학에서 ‘지속적인 통합(continuous integration, CI)’이라 함은, 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이다. 최근에는 SW가 복잡해지고 고품질의 SW가 요구되는 반면, 개발팀 입장에서는 짧은 개발 기간과 지리적으로 멀리 떨어져 있는 등 여러 가지 도전 과제에 직면해 있다. 이러한 환경에서 주목받고있는 ‘지속적인 통합’은 초기에 작은 단위로 그리고 자주 통합해, 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백사이클을 짧게 하여 SW개발의 품질과 생산성을 향상시키는 것이다. 

다시 말해,모든 개발을 완료한 뒤에 품질관리를 적용하는 고전적인 방법을 대체하는 방법으로서, 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는 것을 그 목적으로 한다. 락플레이스의 윤종민 수석을 통해 더 자세한 설명과 적용 방법에 대해 알아보았다. 

<락플레이스 윤종민 수석연구원>


● 지속적 통합이란 무엇인가? 
● 지속적 통합을 위한 솔루션 및 도구 소개 
● 지속적 통합 도입 사례 소개 


Q: ‘지속적 통합’이란 구체적으로 무엇을 뜻하나요? 
소프트웨어 개발자에게 개발 방법론이란, 일종의 ‘네비게이션’과 같습니다. 원하는 결과를 얻기 위해 ‘어떤 경로를 택할 것인가’에 대한 선택이기 때문이죠. 요즘의 개발자들이 많은 관심을 가지고 있는 방법론은 XP. 즉 Extreme Programming일 것입니다. XP가 주장하는 것 중에는 정말 extreme한 내용도 있기 때문에, 이 방법론의 유효성을 두고 십 수년간 논쟁이 끊이지 않고 있는데요. 논란이 확산됨에 따라 XP의 Best Practices 중 일부는 다른 진영에서도 인정을 받게 되었습니다. 그 중, 지속적인 통합(CI)은 한 두 문장으로 설명하기에는 쉽지 않지만, 다음과 같이 정의할 수 있습니다. 

 소프트웨어 빌드를 만들어내는 절차를 쉽게 하고 안정화 하기 위한 실천방법의 집합체  
 팀의 구성원들이 자신들의 작업한 내용을 자주 통합하는 개발 지침  


즉, 각각의 개발자가 자신이 수정한 소스 코드를 되도록 자주, 소스 코드 저장소에 커밋하고, 다른 사람이 수정한 소스 코드는 없는지 수시로 확인하는 일련의 행동을 의미합니다. 

『소프트웨어 공학의 사실과 오해』(로버트 L 글래스) 에서 보면, “소프트웨어 개발 중 발생하는 오류의 절반이 모듈의 15%에서 발견된다”라고 나와있는데요. 이는 공동으로 소프트웨어를 개발 할 때, 모듈 전체에 개발자가 골고루 분배되지 않고, 특정 부분에 몰리게 된다는 것입니다. 하지만, 커밋할때 마다 모든 팀원에게 공지를 할 수는 없기 때문에 수시로 변경 사항을 확인하는 것이 가장 좋은 방법입니다. 그러기 위해서 이러한 과정을 도와주는 소프트웨어를 사용하게 되는데요, ‘Jenkins’가 대표적으로 활용되는 소프트웨어라고 할 수 있습니다.

이러한 젠킨스(Jenkins)를 소개하기에 앞서, 지속적인 통합을 도와 주는 소프트웨어는 어떤 기능을 가지고 있어야 하는지 먼저 말씀드리겠습니다. 

● CI 서버: 빌드 프로세스를 관리하는 서버 
→ Jenkins, Hudson, CruiseControl.NET, TeamCity 

● SCM(Source Code Management): 소스코드 형상 관리 시스템으로 소스코드의 개정과 백업 절차를 자동화 하여 수정 과정을 도와 줄 수 있으며, 여러 사람이 같은 프로젝트에서 공동 개발을 진행할 때, 각자가 수정한 부분을 팀원 전체와 동기화 할 수 있도록 도와 주는 도구
→ Git, Subversion, Mercurial 등 

● Build Tool: 컴파일, 테스트, 정적 분석 등을 실시해 동작 가능한 소프트웨어를 생성하는 도구로 개발하는 언어에 맞는 빌드 툴
→ Ant, Maven, MSBuild, Make, Gradle 등 

● Test Tool: 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로 빌드 툴의 스크립트에서 실행한다. 일반적으로 테스트란 단위 테스트를 이야기하며, 단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는 것으로, 개발자가 작성한 코드로 특정 기능을 테스트 해 보는 것이 일반적이다. 
 Junit, CppUnit, CppTest, MSTest, Selenuim 등 

● Test Coverage Tool: 테스트 코드가 대상 소스에 대해 어느 정로를 커버하는지 분석하는 도구로, 코드 라인과 백운율을 통해 리포팅한다. 단위 테스트를 수행할 때, 테스트 커버리지를 분석하기 위해 부가적으로 사용하는 툴이다. 
 Emma, Coberura, TestCocoon 등 

● Inspection Tool: 프로그램을 실행하지 않고, 소스코드 자체로 품질을 판단할 수 있는 정적 분석 도구로, 코딩 표준 준수, 코드 메트릭, 중복 코드, 코드 인스펙션등을 확인한다. 
→ CheckStyle, FindBugs, Cppcheck, Valgrind 

<그림 1> 지속적인 통합 절차
 
자료: http://www.nextree.co.kr/p3452

댓글 없음 :

댓글 쓰기