[Jenkins] 1장 - 지속적 통합이란? (Feat. 폭포수 모델, 애자일, 스크럼)

초보를 위한 젠킨스 2 활용 가이드 2/e를 읽고, 정리한 글입니다. 

 

목차

· 소프트웨어 개발 주기

· 폭포수 모델

· 애자일 방법론

· 스크럼 프레임워크

· 지속적 통함

· CI의 구성 요소

· CI 사용의 장점

---

 

잦은 변경에 빠르게 대응할 수 있는 소프트웨어 배포 솔루션으로 애자일 방법론이 전세계적으로 성장했다. 그 결과 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery) 방법론은 사람들의 관심을 받게 되엇다. 이런 방법론을 통해 이슈의 조기 발견, 지저분한 코드가 상용 코드에 들어가는 것을 막고, 빠르게 배포하여 생산성을 향상시키고 있다.

 

소프트웨어 개발 주기

---

· 소프트웨어 개발 주기(SDLC, Software Development Life Cycle)는 소프트웨어 개발의 계획, 개발, 테스트, 배포 단계를 총칭한다. 각 세부 단계는 다음과 같다.

 

1. 요구 사항 분석

2. 설계

3. 구현

4. 테스트

5. 진화

 

각 단계는 이전 단계의 결과물을 이용한다.

 

요구 사항 분석

· 전체 과정 중 첫 번째 단계로, 비즈니스 조직이 프로젝트에서 달성해야 하는 요구 사항을 분석한다.

· 요구 사항은 조직 내부에서 나올 수 있고, 외부 고객으로부터 주어질 수도 있다.

· 요구 사항의 성질과 범위를 결정하는 것도 포함된다.

· 수집된 정보를 바탕으로 새로운 시스템을 만들 것인지, 기존 시스템을 업그레이드할 것인지 결정해서 제안한다. 

· 프로젝트의 비용과 프로젝트로 얻을 수 있는 결과가 계산되고, 프로젝트의 목표를 설정한다.

 

설계

· 두 번째 단계로, 시스템 아키텍트와 설계자가 정교하게 구현해야 할 기능들을 정리하고 프로젝트 전체 계획을 세운다.

· 프로세스 그림이나 전체적인 인터페이스, 레이아웃 디자인, 여러 종류의 문서가 결정된다.

 

구현 

· 세 번째 단계로, 프로젝트 매니저가 어떤 일을 할지 결정해서 개발자에게 분배한다.

· 개발자들은 설계 단계에서 정의된 과제와 목표에 따라 개발을 진행한다.

 

테스트

· 네 번째 단계로, 모든 기능이 구현된 후 테스트 팀이 이 역할을 맡는다.

· 소프트웨어의 모든 모듈을 테스트하고, 이 과정에서 버그가 발견될 경우 이슈로 기록된다.

· 테스트에 실패한 내용은 개발 팀에서 빠르게 수정하고, 테스트가 완료된 코드는 프로덕션 환경에 배포된다.

 

진화

· 마지막 단계로, 진화 혹은 유지 보수를 한다.

· 사용자나 고객으로부터 수집된 피드백을 분석해 개발, 테스트, 새로운 기능이나 버그를 수정하는 패치를 릴리스하는 사이클이 반복된다.

 

폭포수 모델

---

· 한 방향으로 쭉 흘러가는 방식으로 제조업에서 사용되는 방식을 소프트웨어 업계에서 차용했다.

- 명확하게 정의된 절차가 한 방향으로 진행된다.

- 각 단계가 SDLC와 유사해 직관적으로 이해할 수 있다.

 

· 폭포수 모델의 단계는 다음과 같다.

1. 요구 사항 분석

2. 시스템 설계

- 이 작업이 끝난 후 어떤 추가나 수정도 허용되지 않는다. 즉, 개발이 시작된 이후에는 시스템 설계에 어떤 수정도 발생하지 않는다.

3. 구현

- 개발이 시작된다. 개발이 끝나면 소스코드를 통합한다. 이때 다양한 통합 이슈가 발생하고 수정된다.

4. 테스트

5. 배포

6. 유지 보수

- 사용자나 고객으로부터 수집된 피드백을 분석해 개발, 테스트, 새로운 기능이나 버그를 수정하는 패치를 릴리스하는 주기가 반복된다.

 

단점

1. 실제로 동작하는 소프트웨어가 SDLC의 마지막에 가서야 완성되는데, 대부분의 경우 이 결과물이 1년 전후의 시간이 지나면 더 이상 동작하지 않는다.

2. 불확실성이 매우 크다.

3. 새로운 요구 사항이 자주 발생하는 전자상거래 영역의 경우에 적합하지 않다.

4. 전체 개발이 끝난 후에야 통합이 진행된다. 그 결과 수많은 통합 이슈가 가장 마지막 단계가 돼서야 발견된다.

5. 역추적이 불가능하다.

6. 각 단계에서 진행 현항을 알기 힘들다.

 

장점

1. 요구 사항이 문서로 잘 정리되고 변하지 않는다.

2. 관리자, 테스트 팀, 개발 팀, 빌드, 릴리스 팀과 배포 팀을 유지할 자원이 충분히 주어진다.

3. 기술이 고정돼 잘 변하지 않는다.

4. 모호한 요구 사항이 존재하지 않는다. 요구사항이 요구 사항 분석 단계 이후 새로 발생하지 않는다.

 

애자일 방법론

---

· 폭포수 방법론의 대안으로 자리잡고 있는 방법론이다.

· 애자일이란 빠르고 쉬움을 뜻한다. 애자일 방식의 핵심은 빠르고 유연하며 조금씩 발전되는 소프트웨어 개발을 통해 목표를 계속 수정해나가는 것이다.

· SOT(self-organized team)의 협업을 통해 소프트웨어가 개발되는 방법론이다.

- SOT: 모든 구성원이 참여해 문제를 정의하고 해결하는 팀이다. 기존의 관리자-개발자 방식과 다르게 개발자도 참여해 문제를 분석하고 일정을 조율한다.

 

열두 가지 애자일 원칙

1. 고객을 만족시키지 위해 소프트웨어를 빠르고 지속적으로 배포한다.

2. 새로운 요구 사항은 개발 후기에도 기꺼이 받아들인다.

3. 동작 가능한 소프트웨어를 몇 달 주기가 아닌 몇 주 주기로 배포한다.

4. 업무 담당자와 개발자 간 긴밀한 소통을 지향한다.

5. 믿을 수 있는 동기부여된 개인들로 구성된 팀이 소프트웨어를 개발한다.

6. 직접 만나 얼굴을 보며 이야기하는 것이 최선의 의사소통이다.

7. 동작하는 소프트웨어가 가장 중요한 진척의 척도다.

8. 일정한 속도를 유지함으로써 지속 가능한 개발을 추구한다.

9. 좋은 기술과 설계를 향해 지속적으로 관심을 기울인다.

10. 단순함(하지 않는 일을 늘리는 기법)을 중요시한다.

11. SOT를 추구한다.

12. 새로운 환경에 지속적으로 적응한다.

 

애자일 방법록의 동작 방식

· 애자일 방법론에서 소프트웨어 애플리케이션은 여러 가지의 기능과 모듈로 분류된다. 그리고 이런 기능이 이터레이션(iteration)을 반복하며 배포된다.

· 각 이터레이션은 3주 동안 진행되며 계획 세우기, 요구 사항 분석, 설계, 코딩, 단위 테스트, 사용자 인수 테스트를 동시에 진행하는 복합 기능 팀이 이를 수행한다.

- 이를 통해 특정 기간에 할 일이 없어 놀고 있는 팀원이 생기지 않는다(폭포수 모델에서는 구현까지 테스트 인원이 놀게 된다).

 

애자일 방법론

· 요구 사항이나 설계에 쓰이는 시간이 없다. 대신 프로젝트의 범위를 대략적으로 정할 최소한의 시간만 사용해 추상적인 계획을 세운다.

· 이터레이션은 시간 계획에 따라 한 달로 설정되거나, 성숙한 프로젝트의 경우 한 주로 잡히기도 한다.

· 하나의 이터레이션에서 기능의 개발, 테스트, 릴리스를 완료하는 것이 목표다.

· 이터레이션이 마무리될 때 새 기능의 데모를 진행하고, 고객에 새 기능에 만족하면 프로덕션 서버에 반영된다.

- 데모에서 고객이 만족하지 못하면 해당 기능은 백로그로 들어가고, 우선순위가 다시 매개져 이후의 이터레이션이서 구현된다.

· 개발과 테스트를 동시에 진행하는 것도 가능하다. 하나의 이터레이션에서 하나 이상의 기능을 동시에 구현하고 테스트하는 것도 가능하다.

 

애자일 방법론의 장점

1. 기능의 빠른 구현과 데모

- 소프트웨어 프로젝트가 기능으로 구분되는데, 모든 기능의 집합을 백로그라 한다.

- 하나 혹은 그 이상의 기능을 한 주 혹은 한 달 동안 구체화하고 배포하는 것이 주요 개념이다.

2. 적은 리소스 소요

- 개발, 테스트, 빌드, 릴리스, 배포 팀이 따로 구분되지 않는다. 대신 하나의 팀이 얀 여덟 명으로 구성되고, 각각의 구성원은 모든 역할을 수행할 수 있다. 

3. 팀워크 향상과 상호 교육

- 한 팀에 여덟 명 정도의 소수 인원만 있어 각 팀원이 역할을 바꿔가며 프로젝트를 진행하고, 이 과정에서 서로가 모두의 경험을 공유하며 배운다.

4. 요구 사항이 자주 변경되는 프로젝트에 적합 

- 소프트웨어를 기능별로 묶어서 구분하므로, 각 기능은 짧은 시간에 개발되고 배포된다. 따라서 기능을 변경하거나, 제거해도 전체 프로젝트에 큰 영향을 주지 않는다.

5. 최소한의 문서

- 방대한 문서 대신 동작하는 소프트웨어 전달을 목표로 한다. 문서는 있지만 전체 기능에 관한 문서만 있다.

6. 계획이 없거나 최소한의 계획

- 기능이 하나씩 구현되기 때문에 방대한 계획은 존재하지 않는다.

7. 동시 개발

- 하나 혹은 그 이상의 기능의 집합으로 구성된 이터레이션이 순차적으로 혹은 동시에 진행된다.

 

스크럼 프레임워크

---

· 스크럼은 복잡한 소프트웨어를 개발하고 유지하는 애자일 방법론에 기반을 둔 프레임워크다.

- 단순한 절차가 아닌, 정해진 역할과 임무, 팀으로 이뤄진 프레임워크다.

 

· 스크럼 프레임워크에서는 개발 팀이 어떻게 개발할지를 결정한다. 직면한 문제를 개발 팀이 가장 잘 안다는 전제를 기반으로 한다.

· 스크럼 팀은 SOT이기에 누가 무엇을 할지 결정하고 어떻게 문제를 해결할지 결정하는 팀 리더가 존재하지 않는다.

 

스크럼 프레임워크의 주요 용어

· 스프린트: 유용하고 릴리스 가능한 결과를 생산하는 데 할당된 기간을 의미한다. 이전 스프린트가 끝나면 곧바로 새 스프린트가 시작된다. 하나의 스프린트는 스크럼의 지식에 따라 2주부터 한 달까지 변동 가능하다.

· 프로덕트 백로그: 개발할 소프트웨어에 필요한 모든 기능의 집합을 의미한다. 끊임없이 변동 가능하다.

- 즉, 고객이나 팀 구성원이 언제든지 새로운 목록을 프로덕트 백로그에 추가하거나 삭제할 수 있다.

· 스프린트 백로그: 스프린트에서 진행하기로 결정된 기능의 집합이다.

· 인크리먼트: 전체 프로덕트 백로그 중 이번 스프린트에서 완료된 기능과 이전 모든 스프린트에서 완료된 기능을 의미한다.

· 개발 팀: 스프린트 마지막에 릴리스 가능한 인크리먼트를 개발하는 역할을 한다. 오직 개발 팀만 인크리먼트를 만든다. 

· 프로덕트 오너: 스크럼 팀과 그 외 사람들의 중재자다. 프로덕트 오너는 스크럼 팀의 외부 담당자로서 고객사, 인프라스트런처 팀, 관리자, 그외 스크럼과 관계된 모든 사람과의 의사소통을 담당한다.

· 스크럼 마스터: 스크럼을 이해시키고 진행하는 역할을 맡는다. 스크럼의 이론과 역할 및 올바른 수행 방법을 주지시키는 방법으로 이 역할을 수행한다.

 

스크럼의 동작 방식

· 프로덕트 오너와 스크럼 마스터와 스크럼 팀은 소프트웨어 기능을 만들기 위해 엄격한 절차를 따른다.

 

 

스트린트 계획

· 스크럼 팀이 이번 스프린트 주기에 포함시킬 기능을 결정하는 기회다.

· 개발자들이 주도한다.

· 계획을 세운 후 스크럼 마스터와 프로덕트 오너에게 보여준다. 스크럼 마스터는 모든 팀원이 스프린트 계획을 짜는데 참여하게 하는 역할을 해야 한다.

· 정해진 시간 안에 이뤄지는 행위로, 한 달짜리의 스프린트라면 약 8시간 정도가 투입된다.

· 회의 시간에 개발 팀이 고려할 사항: 

1. 기존 백로그의 기능이나 신규로 백로그에 추가된 기능 중 이번 스프린트에 작업될 기능 목록

2. 이전 스프린트의 팀의 작업 실적

3. 개발 팀의 예상 능력

 

스트린트 주기

· 스프린트 주기 기간 동안 개발자는 단순히 스프린트 계획을 통해 이번 스프린트에 작업하기로 결정된 기능을 구현한다.

- 스프린트 기간은 결정된 작업량에 따라 2주에서 한 달 사이로 정해진다.

 

일간 스크럼 회의

· 스크럼 회의는 매일 진행한다.

· 회의 시 개발 팀이 어제 달성한 작업을 논의하고, 오늘 작업할 내용을 말한다. 작업을 진행하는 데 있어 막히는 부분도 논의한다.

· 개발 팀은 스크럼 회의 이외의 회의에는 참여하지 않는다.

· 스프린트 진척을 관리한다. 스크럼 팀은 남은 작업량을 추적해 스프린트 목표 달성 가능성을 예측한다.

 

스프린트 리뷰

· 개발 팀이 작업을 끝낸 기느으이 데모를 진행한다.

· 프로덕트 오너는 프로덕트 백로그를 최신으로 변경한다. 이 변경 작업은 제품이 실제 사용되는 환경에서 성능이나 사용성에 의해 변경된다.

· 스프린트 리뷰는 한 달짜리 스프린트를 기준으로 했을 때 4시간이 소요된다.

 

스프린트 회고

· 잘된 점과 개선이 필요한 점을 논의해 다음 스프린트에서 개선할 점을 결정한다.

· 주로 스프린트 리뷰와 스프린트 계획 사이에 한다.

 

 

지속적 통합(Continuous Integration)

---

· 빠른 주기로 작업한 내용을 통합 브랜치에 통합하고, 빌드하는 개발 방식을 의미한다.

- 통합: 개인이 작업한 코드를 공용 작업 환경에 올리는 것을 의미한다. 이 과정은 개인 브랜치를 중앙 브랜치에 병합하는 과정으로 이뤄진다. 개인 브랜치를 원격 브랜치 올린다고 표현하기도 한다.

 

· CI의 필요성: 통합 과정에서 발생하는 이슈를 가능한 빨리 발견할 수 있다.

- 아래 CI 사이클에서 발생하는 다양한 이슈를 확인하자.

CI 절차

· 코드가 잘못 반영되거나 개발자가 수동으로 빌드할 때 실수를 하면 빌드는 실패한다. 

· 개발자가 개인 개발 활경을 통합 환경에 맞게 주기적으로 리베이스하지 않으면 통합 이슈가 발생한다.

· 코드가 단위 테스트케이스나 통합 테스트케이스를 통과하지 못하면 테스트 이슈가 발생한다.

 

CI를 이용한 애자일

· 애자일 개발 방법론은 빠른 배포를 기반으로 하며, CI는 애자일에서 필요한 속도를 얻는 데 도움을 준다.

- 기능을 개발할 때 코드를 여러 번 수정하게 되고, 이 과정에서 코드를 반영하고, 버전 관리 시스템에서 변경 사항을 가져오고, 소스코드를 빌드하고, 단위 테스트를 진행하고, 통합하고, 통합된 코드를 빌드하고, 이를 묶어 배포하는 등 여러 과정을 수행한다. CI 환경에서는 젠킨스 같은 도구를 이용해 모든 과정을 빠르게 에러 없이 진행할 수 있다.

- 알람을 추가하면 팀원이 빌드, 통합, 배포 실패를 빨리 알아차릴수 있어 더 빠른 대응을 할 수 있다. 

 

CI의 구성 요소

---

다음은 CI 절차의 주요 구성 요소다.

 

버전 관리 시스템

· CI를 구성하는 데 가장 기본이자 중요한 요소다.

· 리비전 관리 시스템(Revision Control System)으로 불리기 도하고, 코드의 이력을 관리하는 도구로 비분산형과 분산형이 있다.

- 대표적인 비분산형은 SVN과 IBM Rational ClearCase가 있고, 분산형은 GIT과 머큐리얼이 있다.

 

브랜칭 전량

· 버전 관리 시스템을 사용할 때는 브랜치를 최소화하는 것이 좋다.

· 몇몇 회사는 오직 하나의 브랜치만 유지하며 모든 개발이 이 브랜치 위에서 일어난다.

· 대부분의 회사는 여러 브랜치를 사용하는 전략을 유지한다. 

- 이런 전략을 택하는 이유는 팀의 일부는 릴리스 브랜치에서 작업할 때 다른 팀원은 또 다른 릴리스 브랜치에서 작업해야 하는 경우 또는 오래된 릴리스 버전에서 작업해야 하는 경우가 생길 수 있기 떄문이다. 

 

GitFLow 브랜칭 모델

· GitFlow는 여러 브랜치를 이용해 코드를 관리하는 방식이다. 

· 이 방법에서 마스터와 프로덕션 브랜치에는 언제나 릴리스 가능한 깨끗한 코드만 있다. 다른 개발 패치는 기능 브랜치와 기능을 통합할 통합 브랜치에 반영된다.

일반적인 버전의 GitFlow

 

· 다음은 가장 확장된 방식의 GitFlow다.

- 마스터와 프로덕션 브랜치에는 언제든 최종 배포가 가능한 코드만 있다.

- 기능 브랜치에는 모든 개발 내용이 들어간다.

- 통합 브랜치는에서 모든 코드를 통합하고 품질을 위해 테스트를 한다.

- 이전 방식과 달리 릴리스 브랜치가 더 있다. 통합 브랜치에서 안정적인 릴리스 버전이 생길 때 이버전에 기반해 릴리스 브랜치를 생성한다.

- 릴리스된 코드의 버그 픽스는 릴리스 브랜치에 통합된다.

- 마스터나 프로덕션 브랜치에 핫픽스가 필요한 경우 각각의 브랜치를 기반으로 핫픽스 브랜치가 생성된다.

확장된 방식의 GitFlow

 

CI 도구

· CI 도구는 지휘자 역할을 한다. CI 시스템의 중심에 위치해 1. 버전 관리 시스템, 2. 빌드 도구, 3. 바이너리 관리 도구, 4. 테스트 및 프로덕션 환경, 5.소스코드 분석 도구 및 자동화 테스트 도구 등을 연결한다.  

 

· CI 도구의 예: 빌드 포지, 뱀부, 팀시티, 젠킨스

 

· CI 도구는 파피프라인을 생성하는 방법을 제공한다. 

- 각 파이프라인에는 고유한 목적이 있다. ex) CI 관리, 소작업 관리, 배포 관장

- 파리프라인은 연속된 작업의 흐름으로, 각 작업은 연속해서 수행되는 소 작업의 모음이다.

- CI 도구의 핵심은 스크립트 언어를 이용해 다양한 소작업을 수행하는 것이다.

- 소작업은 폴더나 파일을 복사하는 등 간단한 것부터, 파일 수정을 담당하는 서버를 모니터링하는 것처럼 복잡한 펄 스크립트일 수도 있다.

 

· 젠킨스의 플러그인이 이 스크립트를 대체하고 있다.

- 더 이상 자바 코드를 빌드하는 스크립트를 짤 필요 없이 플러그인을 설치한 후 설정한 다음 원하는 작업을 실행시키면 된다.

 

자동으로 시작되는 빌드

· 빌드 자동화는 코드를 컴파일하고 실행 파일을 만들어내는 여러 단계를 자동화하는 것이다. 

· 빌드 도구: 앤트, 메이븐 등

 

· 자동으로 시작되는 빌드는 CI 시스템에서 가장 중요한 부분으로 두 가지 조건이 충족돼야 한다.

1. 빠른 속도

2. 코드나 통합 이슈를 최대한 빨리 잡아내는 것

 

· 빌드를 자동화하면 많은 시간을 절약할 수 있다. 코드가 변화하면 자동으로 빌드가 시작되게 하는 시스템은 더욱 많은 시간을 절약시켜 준다.

 

· 빌드가 자주 발생하고 빠르게 수행되면 SDLC 프레임워크에서 에러(빌드 에러, 컴파일 에러, 통합 에어)를 발견할 활률이 높아지고 발견되는 시점도 빨라진다.

 

코드 커버리지

· 테스트 케이스가 커버하는 코드의 양을 백분율로 나타낸 값을 의미한다.

커버리지 종류	설명
함수(Function)	작성된 모든 함수 중 테스트가 수행된 함수의 수
명령문(Statement)	전체 명령문 개수 중 실제로 수행된 명령문의 수
브랜치(Branches)	수행된 브랜치의 수
조건(Condition)	true와 false 값이 모두 테스트된 조건문의 수
라인(Line)	전체 코드 라인 중 테스트된 라인의 수

 

· 코드 커버리지 도구:

언어	도구
자바	Atlassian Clover, Cobertura, JaCoCo
C#/닷넷	OpenCover, dotCover
C++	OpenCppCoverage, gcov
파이썬	Coverage.py
루비(Ruby)	Simplecov

 

코드 정적 분석

· 화이트 박스 테스트라고 불리며, 코드의 구조적인 품질을 측정하는 소프트웨어로 코드가 얼마나 견고하고 지속 가능한지 알려준다.

· 실제로 프로그램을 수행하지 않고 실행되며, 기능을 테스트하는 동적 테스트와 달리 소프트웨어의 기능적인 부분을 분석하지 않는다.

· 소프트웨어의 내부적인 구조를 평가한다. 사용자 정의된 메트릭을 통해 분석 결과가 생성돼 유지 보수성에 대한 코드 품질을 알려준다.

ex) 반복적으로 사용되는 코드나 주석 처리된 라인 수, 코드의 복잡성 등을 측정

 

· 일반적으로 CI의 일부로써 빌드할 때마다 같이 수행된다.

· 개발자가 개발한 코드를 올리기 전에 수행되게 설정할 수 있으므로, 낮은 품질의 코드가 머지되는 것을 미리 예방할 수 있다.

· 코드 정적 분선 도구 예시: 소나큐브(대시보드가 함께 제공되며, 이를 통해 다양한 메트릭과 각 분석 결과를 통계로 보여준다)

 

자동화된 테스트

· 소프트웨어 품질을 유지하려면 다양한 테스트 시나리오를 통해 소스를 테스트해야 한다.

· 테스트는 수작업이고, 오랜 시간이 소요되고, 반복적인 일이므로 테스트 과정을 자동화하면 소프트웨어 배포에 걸리는 시간을 대폭 단축시킬 수 있다.

 

· 테스트를 자동화할 때 고려해야하는 상황:
1. 중요하고 구현하기 쉬운 테스트 케이스 먼저 자동화 한다. ex) 모든 테스트 절차가 동일하지만 다양한 데이터를 통해 테스트되는 케이스

2. 소프트웨어의 기능 중 여러 플랫폼에서 테스트되는 케이스를 자동화 한다.

3. 다양한 설정이 적용돼 실행되는 소프트웨어의 테스트를 자동화한다.

 

· 코드가 빌드, 패키징, 배포를 거친 후, 소프트웨어를 검증하려면 반드시 테스트를 거쳐야 한다.

첫 단계로 릴리스된 코드는 SIT(System Integration Test)를 거쳐 통합된 코드가 기능적으로 잘 동작하는지 검증 한다.

통합 테스트를 통과한 후, 코드는 다음 단계인 UAT(User Acceptance Test)

마지막으로 PT(Performace Test)를 거쳐 성능을 확인한다.  

 

바이너리 관리 도구

· 바이너리 파일의 버전 관리 시스템을 말한다. 

- SDLC의 일부로 소스코드는 CI를 통해 주기적으로 빌드돼 바이너리 파일로 만들어진다.

- 버전 관리 시스템이 소스코드의 버전 관리를 담당한다면, 바이너리 관리 시스템은 .rar, .war, .exe, .msi 등의 파일을 관리한다.

- 빌드된 바이너리 뿐만이 아니라 빌드에 필요한 서드파티 바이너리 파일도 관리한다.

ex) 메이븐은 소스코드를 빌드할 때 필요한 플러그인을 항상 인터넷에서 다운로드해 내 폴더에 복사한다. 플러그인을 매번 다운로드하는 대신 저장소 관련 도구를 이용할 수도 있다.

 

· 빌드가 수행되고 필요한 검증이 진행된 후, 빌드된 바이너리 파일들이 바이너리 관리 도구로 복사된다. 이를 통해 개발자가 테스터가 수동으로 필요한 바이너리를 골라 배포하고 테스트할 수 있다.

· 자동화된 테스트가 구성돼 있다면 빌드된 바이너리 파일은 자동으로 적합한 테스트 환경에 배포된다. 

 

· 바이너리 관리 도구의 역할:

1. 빌드된 바이너리가 생성될 때마다 바이너리 관리 도구에 저장된다.

- 빌드 결과물을 저장함으로써 결과물이 중앙서버에 저장돼 필요할 때마다 쉽게 접근 가능해진다.

2. 빌드 시 필요한 서드파티의 바이너리 플러그인이나 모듈을 저장한다. 

- 빌드 도구가 빌드 시 플러그인을 다운로드할 필요가 없어진다. 바이너리 관리 도구가 온라인에 연결돼 플러그인들을 항상 최신 버전으로 유지하는 역할을 한다.

3. 누가, 언제, 어떤 바이너리를 만들었는지 기록한다.

4. 릴리스를 더 쉽게 관리할 수 있게 스테이징 환경을 제공하고, CI 절차의 속도 향상에 도움을 준다.

5. 빌드의 주기가 빠른 CI 환경에서는 매 빌드 시 패키지가 만들어진다. 

- 이렇게 만들어진 모든 패키지가 한 장소에 존재하기에 개발자가 다음 단계에 적용시킬 바이너리를 쉽게 고를 수 있다.

 

패키징 자동화

· 빌드가 여러 종류의 결과물을 가지게 되는 경우가 있다. 예를 들어 .rar 파일, 유닉스 설정 파일, 릴리스 노트, 실행 파일, 데이터베이스 수정 쿼리를 결과물로 생성할 수 있다. 이 모든 결과물을 하나로 묶는 작업을 패키징이라고 부른다.

· 패키징 과정도 CI 도구를 이용해 자동화하면 많은 시간을 단축시킬 수 있다.

 

CI 사용의 장점

---

복잡하고 어려운 통합으로부터 해방

· 기능 브랜치에 올려진 모든 모든 커밋을 통합 브랜치에 통합하고 테스트하면, CI 도구가 통합 이슈를 즉시 알려준다.

· 폭포수 모델처럼 통합을 자주 하지 않으면 머지 지옥(머지 과정에서 나온 이슈를 해결해야하는 문제)에 빠질 수 있다. 

 

메트릭

· 젠킨스, 소나큐브, 아티팩토리, 깃허브 같은 도구는 작업 기간 동안 추세를 기록하고 보여준다. 이 추세를 통해 프로젝트 관리자와 팀원들은 프로젝트의 진행 방향 및 속도를 확인할 수 있다.

 

이슈의 조기 발견

· 모든 머지 이슈나 통합 이슈가 바로 발견되고, CI 시스템이 빌드 즉시 알람을 통해 이를 알려준다. 

 

빠른 개발, 기능 추가에 집중

· CI를 사용하는 프로젝트는 빌드, 테스트, 소스코드 통합을 자동으로 하는 환경이 되고, 이것은 빠른 개발로 이어진다. 개발 팀이 오직 개발에만 집중해 시간을 사용할 수 있기 때문이다.