Jenkins를 이용해 지속적인 통합(CI)을 적용해보자 part 1
현재 진행하고 있는 개인 프로젝트에서 최근에 신규 개발 이슈가 막바지에 접어들게 되어 서버 배포를 적용하기 전 CI에 대해 알아보게 되었습니다. IT 회사를 다니고 있지만 근무 중에는 서버 배포에 관해 작업을 일절 할 수 없는 환경이라 이번 CI 적용이 처음인 저에겐 많은 시행착오를 가져다 주었습니다.
많이 헤맸던 만큼 구현에 성공하고 나서 큰 보람을 느낄 수 있었고 반복적인 일을 자동화 시킨 후 이전 과는 다르게 매우 편리한 환경을 구축하게 된 경험을 공유하고자 합니다 :)
CI(Continuous-Integration) 는 무엇인가요?
CI 란 우리말로 지속적인 통합 이라고 하며 개발자들이 빠른 주기로 작업한 내용을 통합 브랜치에 통합하고 빌드하는 개발 방식을 의미합니다. 이러한 개념이 탄생하게 된 배경에는 기존의 소프트웨어 개발 방식에서 찾아볼 수 있습니다.
폭포수 모델
소프트웨어 개발 방법론 중에서 가장 오랫동안 사용되었던 것은 폭포수 모델 입니다. 제조 과정의 방법론을 그대로 반영한 모델 중에 하나이며 모든 절차가 한 방향으로만 진행됩니다. 기능 개발 중에는 테스트를 거치지 않고 커밋을 하게 되며 모든 개발 이슈가 완료 된 후 가장 마지막에 통합하여 테스트를 거친 후 배포를 합니다.
이러한 폭포수 모델은 기능 개발 중엔 어떠한 추가나 수정을 하지 않기 때문에 요구사항이 자주 변경되는 프로젝트 에 적합하지 않으며
수 많은 이슈가 과정의 가장 마지막에 한꺼번에 터진다 는 큰 단점을 안고 있음에도 불구하고 오랜 시간동안 활용되어 왔습니다.
하지만 현 시대에 사용자의 요구사항은 날이 갈수록 늘어나고 그 수준 또한 높아지고 있습니다. 이러한 상황에서 폭포수 모델로는 한계점을 맞이할 수 밖에 없었고, 대안으로 애자일 방법론 이 등장하게 됩니다.
애자일 방법론
빠르고 쉽다 라는 의미를 가지며 애자일 방법론의 핵심은 빠르고 유연하게 발전되는 소프트웨어 개발을 통해 목표를 지속적으로 수정해 나가는 것 입니다. 폭포수 모델과는 달리 새로운 요구사항을 기능 개발 중에도 기꺼이 받아들이며 고객을 만족시키기 위해 소프트웨어를 빠르고 지속적으로 배포 를 합니다. 좋은 기술과 설계를 위해서 끊임없이 관심을 가지며 이를 위해 서로간의 긴밀한 의사소통을 지향 합니다.
애자일 방법론에서는 기능과 모듈 별로 구분이 되며 설계, 개발, 테스트가 동시에 수행되기 때문에 빠르고 유연하게 요구사항을 대처할 수 있습니다.
많은 개발자들이 애용하는 버전 관리 시스템인 Git 의 경우 브랜치 전략 을 제공하여 하나의 프로젝트에 여러 개발 건을 브랜치 마다 나누어 동시에 진행할 수 있는 환경을 제공하고 있습니다.
애자일 방법론 그대로, 수 많은 코드의 변경이력이 생겨나고 그만큼 여러 사람이 작업한 내용을 병합하려면 당연히 오류가 많이 발생할 수 밖에 없습니다.
오류의 발생을 줄이기 위해 코드리뷰나 단위테스트, 빌드 등의 추가적인 작업이 필요하며 이 모든 것이 통과하면 Approve 를 받고 master 나
develop 등의 브랜치로 통합(Integration) 을 하게 됩니다. 일련의 과정은 아래의 그림과 같습니다.
최근 대부분의 소프트웨어 개발이 애자일 방법론을 채택하고 있으며 빠른 배포를 기반으로 진행되다 보니 코드 퀄리티를 위한 단위 테스트를 자동으로 실행시켜주며, 오류 발생 여지가 있는 부분들은 찾아내 주는 CI의 필요성 이 점차 대두되기 시작합니다.
이러한 CI를 구성을 하기 전 필요한 요소는 무엇이 있을까요?
CI에 필요한 도구들은 어떤 것이 있을까?
버전관리 시스템
CI를 구성할 때 가장 기본이 되는 요소는 버전관리 시스템 입니다. 회사에서 업무를 볼 때도, 집에서 개인 프로젝트를 진행할 때에도 대부분의 개발자들은 SVN, Git, 또는 GitLab 등을 활용하여 코드의 변경 이력을 기록하고 형상관리를 하고 있습니다.
버전 관리 시스템에서 관리가 되지 않는 소스코드는 수정이나 병합이 자동화 되어있지 않기 때문에 개발의 효율성은 당연히 떨어지게 되고 이러한 상황에서 CI를 적용하는 것 또한 의미가 없게 됩니다.
CI 도구 선택
CI 도구의 핵심은 스크립트 언어를 통해 다양한 작업을 수행하는 것입니다. 해당 스크립트 명령어를 통해 소스코드를 버전관리 시스템으로 부터 주기적으로 업데이트 받으며 수정 된 코드에 대한 빌드와 테스트 수행을 자동으로 실행할 수 있도록 컨트롤하는 역할을 합니다.
대표적인 CI 도구로는 Jenkins, Team City, Travis CI 등이 존재합니다. 유명 오픈소스 이며 Travis CI 보다 많은 레퍼런스가 있다는 장점이 있어 Jenkins 를 선택하게 되었습니다.
빌드 자동화 툴
소스코드를 컴파일 하고 실행 파일인 war 또는 jar 파일을 생성하는 여러 단계를 자동화 한 것을 빌드 자동화 라고 합니다.
프로젝트 마다 차이가 있겠지만, 수정사항에 따라 빌드가 하루에 수 백번 발생하는 프로젝트도 존재합니다. 빌드를 자동화 한다면
많은 시간을 절약시켜 줌과 동시에 컴파일 오류, 통합 에러, 또는 빌드 에러가 조기에 발견이 가능합니다.
대표적인 빌드 자동화 툴로는 Maven, Ant, Gradle 이 있습니다.
테스트 자동화 툴
빌드 자동화 툴을 활용하여 컴파일이나 통합, 빌드 에러를 모두 잡아냈다면 해당 기능이 요구사항에 맞게 작동을 하는지 단위 테스트 를 통해 다양한 시나리오 별로 검증이 필요합니다. 테스트는 개발자가 일일히 작성해야 하는 수작업으로 진행되기 때문에 시간이 오래 걸리며 반복적인 일입니다.
테스트를 자동화 하는 일은 상당히 어렵고 엄청난 노력이 들어가지만 이러한 테스트 과정을 자동화 한다면 배포에 걸리는 시간을 대폭 감소시켜 줄 수 있습니다.
Java 언어로 개발하고 있다면 JUnit 과 같은 툴이 대표적인 테스트 자동화 툴입니다.
현재 저의 개인 프로젝트에 적용한 것들 위주로 작성을 했지만 이 외에도 소나큐브 라는 정적 분석 툴, 바이너리 관리 도구 등 다양한 요소들이 존재하니 위에 소개한 내용 이외의 것도 추가적으로 적용해보는 것도 좋을 듯 합니다!
CI를 통해 얻을 수 있는 장점은 무엇이 있을까?
쉽고 편리한 통합
기존 폭포수 모델 처럼 통합을 자주 하지 않는다면 이 후에 머지 과정에서 발생한 수 없이 많은 이슈를 해결하기 위해 엄청난 시간을 소요하게 될 수 있습니다. 하지만 CI를 적용한다면 커밋이 발생할 때마다 통합 브랜치에 통합하고 추가적으로 테스트까지 진행하기에 이슈가 발생한다면 즉시 알 수 있게 됩니다.
이슈의 조기 발견
위에서도 언급했듯이, CI를 적용함으로써 가장 크게 얻을 수 있는 이득입니다. 머지 이슈, 통합이슈가 그때 그때 발견이 되며 빌드에 실패했을 때도 즉시 알람을 통해 공유가 가능합니다. 이슈를 빠르게 확인한다면 수정작업도 바로 가능하기 때문에 소스코드에 대한 높은 퀄리티를 유지할 수 있게 됩니다.
효율적인 개발
CI가 적용된 프로젝트는 빌드, 테스트, 소스코드 통합, 배포가 자동으로 이루어지기 때문에 개발자들은 이러한 과정을 신경쓰지 않아도 되기에 오롯이 개발에만 집중하게 됩니다. 이는 빠른 개발로 이어지게 되며 여러 팀으로 나누어 일하는 것도 가능하게 됩니다.
이렇게 CI를 적용해 보기 전 알아두어야 할 개념에 대해 정리를 해보았습니다. 다음 part 2 포스팅에서는 저의 프로젝트에 CI를 어떻게 적용하게 되었는지 한번 알아보는 시간을 가지도록 하겠습니다!!
Project Github URL
Referenced by
-
초보자를 위한 젠킨스 2 활용 가이드 2/e 지속적인 통합과 배포 : 니킬 파타니아 지음
https://book.naver.com/bookdb/book_detail.nhn?bid=14048938 -
Jenkins Official documentation
https://www.jenkins.io/doc/