CI(Continuous Integretion)

CI의 배경

 

소프트웨어 개발 주기

 

1. 요구사항 분석

• 비즈니스 조직은 해당 프로젝트에서 달성해야 하는 요구 사항을 분석함.
• 이 과정에서 프로젝트의 비용과 프로젝트로 얻을 수 있는 결과가 계산되고 프로젝트의 목표를 설정함.

2. 설계

• 정교하게 구현해야 할 기능들을 정리하고 프로젝트 전체 계획을 만듦.
• 프로세스 그림이나 전체적인 인터페이스, 레이아웃, 디자인 등 여러 종류의 문서가 만들어짐.

3. 구현

• 구현 단계에서 프로젝트 매니저는 어떤 일을 할지 결정해서 개발자에게 분배함.
• 개발자들은 설계 단계에서 정의된 과제와 목표에 따라 개발을 진행한다.

4. 테스트

• 모든 기능이 구현된 후 테스트 팀이 이 역할을 맡음.
• 소프트웨어의 모든 모듈을 테스트하고, 이 과정에서 버그가 발견될 경우 이슈로 기록함.
• 테스트에 실패한 내용은 개발 팀에서 빠르게 수정하고 테스트가 완료된 코드는 프로덕션 환경에 배포됨.

5. 유지보수

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

 

---

 

 

소프트웨어 개발에서의 폭포수 모델

 

• 소프트웨어 개발 방법론 중에서 가장 널리 사용되는 폭포수 모델.
• 한 방향으로 쭉 흘러가는 제조업에서의 개발 방식.
• 단계가 종료된 후에는 수정이 어려움.
• 수십 년 동안 훌륭히 작동했으나 최근 몇 년 간 소프트웨어 기술이 급속하게 발전함에 따라 요구사항을 충족시키기에 적합하지 않은 모델로 평가되고 있음.

폭포수 모델의 단점

• 불확실성이 큼.
• 새로운 요구사항이 자주 발생하는 전자상거래 영역의 경우 적합하지 않음.
• 전체 개발이 끝난 후에야 통합이 진행되기 때문에 수많은 통합 이슈가 가장 마지막 단계에서 발견됨.
• 각 단계에서 진행 현황을 알기 힘듦.

폭포수 모델의 장점

• 요구 사항이 문서로 잘 정리되고 변하지 않음.
• 관리자, 테스트 팀, 개발 팀, 빌드, 릴리즈 팀과 배포 팀을 유지할 자원이 충분히 주어짐.
• 기술이 고정돼 잘 변하지 않음.
• 모호한 요구사항이 존재하지 않음.
• 요구사항이 요구사항 분석 단계 이후에 새로 발생하지 않음.

 

---

 

 

애자일 방법론의 대두

 

출처: https://m.post.naver.com/viewer/postView.naver?volumeNo=27695616&memberNo=45977335

 

• 애자일(Agile): 빠르고 쉬움
• 빠르고 유연하며 조금씩 발전되는 소프트웨어 개발을 통해 목표를 계속 수정해나가는 것.
• 폭포수 방법론의 대안

 

 

애자일 원칙

 

프로세스, 도구보다는 사람과 상호작용을,

광범위한 문서보다는 실제 작동하는 제품을,

계약 협상 보다는 고객 협력을,

계획을 따르기보다는 변화 대응을

 

 

Principles behind the Agile Manifesto

 

애자일 방법론의 동작 방식

• 애자일 방법론에서는 소프트웨어 애플리케이션이 여러 가지의 기능과 모듈로 분류되며 이런 기능이 이터레이션을 반복하며 배포된다.
• 각각의 이터레이션은 3주 동안 진행되며 계획 세우기, 요구 사항 분석, 설계, 코딩, 단위 테스트, 사용자 인수 테스트를 동시에 진행하는 복합 기능 팀이 이를 수행함.
• 목표는 하나의 이터레이션에서 기능의 개발, 테스트, 릴리스를 완료하는 것. 

 

애자일 방법론의 장점

• 기능의 빠른 구현과 데모
• 적은 리소스 소요
• 팀워크 향상과 상호 교육
• 요구 사항이 자주 변경되는 프로젝트에 ㅈ거합
• 최소한의 문서
• 계획이 없거나 최소한의 계획
• 동시 개발

 

---

 

 

스크럼 프레임워크

 

 

• 스크럼(scrum): 복잡한 소프트웨어를 개발하고 유지하는 애자일 방법론에 기반을 둔 프레임워크
• 단순한 절차가 아닌, 정해진 역할과 임무, 팀으로 이뤄진 프레임워크로 켄 슈와버와 제프 서덜랜드가 스크럼 지침서를 작성해 탄생시킴.
• 개발 팀이 어떻게 개발할지를 결정함.

 

 

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

 

스프린트

• 릴리즈 가능한 결과를 생산하는 데 할당된 기간
• 이전 스프린트가 종료되면 바로 새 스프린트가 시작됨.
• 하나의 스프린트는 스크럼의 지식에 따라 2주부터 한 달까지 변동 가능함

프로덕트 백로그

• 개발할 소프트웨어에 필요한 모든 기능의 집합
• 끊임없이 변동 가능함.

스프린트 백로그

• 스프린트에서 진행하기로 결정된 기능의 집합

인크리먼트

• 전체 프로덕트 백로그 중 이번 스프린트에서 완료된 기능과 이전 모든 스프린트에서 완료된 기능 의미

개발팀

• 스프린트 마지막에 릴리즈 가능한 인크리먼트를 개발하는 역할

프로덕트 오너

• 제품 백로그를 관리, 통제할 수 있는 권한을 가진 사람으로 제품 책임자는 단 한 명이어야 함.
• 고객 및 조직 가치에 기반하여 제품 백로그 항목들의 우선순위를 결정하고, 매 스프린트의 결과를 검토하여 우선순위를 지속적으로 조정, 관리함

스크럼 마스터

• 스크럼을 이해시키고 진행하는 역할
• 조력자 역할

 

 

 

 

스크럼의 동작 방식(절차)

출처: https://dongchans.github.io/2019/87/

 

 

1. 스프린트 계획

• 스프린트 주기에 포함시킬 기능을 결정
• 개발자들이 주도

2. 스프린트 주기

• 스프린트 주기동안 개발자는 이번 스프린트에 작업하기로 결정된 기능을 구현함.
• 기간은 작업량에 따라 1주에서 한 달 단위로 정해짐

3. 일간 스크럼 회의

• 매일 진행
• 회의 시에는 개발 팀이 어제 달성한 작업을 논의하고 오늘 작업할 내용, 이슈 등을 논의함.

4. 스프린트 진척 관리

• 일간 스크럼에서 스프린트의 진척을 관리함.
• 스크럼 팀은 남은 작업량을 추적해 스프린트 목표 달성 가능성을 예측할 수 있음.

5. 스프린트 리뷰

• 개발 팀이 작업을 끝낸 기능의 데모를 진행함.
• 프로덕트 오너는 프로덕트 백로그를 최신으로 변경함.

6. 스프린트 회고

• 잘된 점과 개선이 필요한 점을 논의해 다음 스프린트에서 개선할 점을 결정.
• 주로 스프린트 리뷰와 스프린트 계획 사이에 함.

 

 

 

---

 

 

 

CI의 개념

 

• 지속적 통합(Continuous Integretion): 개발자들이 빠른 주기로 작업한 내용을 통합 브랜치에 통합하고 빌드하는 개발 방식
• 통합(Integretion): 개인이 작업한 코드를 공용 작업 환경에 올리는 것으로 개인 브랜치를 중앙 브랜치에 병합하는 과정으로 이루어짐.
• CI는 통합 과정에서 발생하는 이슈를 가능한 빨리 발견하기 위해 필요함.
  • 코드가 잘못 반영되거나 개발자가 수동으로 빌드할 때 실수를 하면 빌드가 실패함.
  • 개발자가 개인 개발 환경을 통합 환경에 맞게 주기적으로 리베이스 하지 않으면 통합 이슈가 발생함.
  • 코드가 단위 테스트케이스나 통합 테스트케이스를 통과하지 못하면 테스트 이슈가 발생함.

 

CI를 이용한 애자일

 

 

 

 

• CI는 애자일에서 빠른 배포에 필요한 속도를 얻는데 도움을 줌.
• 기능 개발 시 코드를 여러 번 수정하게 됨. 이 과정에서 코드를 반영하고, 버전 관리 시스템에서 변경 사항을 가져오고, 소스코드를 빌드하고, 단위 테스트를 진행하고, 통합하고, 통합된 코드를 빌드하고, 이를 묶어 배포하는 등 여러 과정을 수행함.
• CI 환경에서는 젠킨스같은 도구를 이용해 모든 과정을 빠르게 에러 없이 진행할 수 있음.
• 알림을 통해 더 빠르게 대응 가능함.

 

---

 

 

CI의 구성 요소

 

버전 관리 시스템

• CI를 구성하는데 가장 기본이자 중요한 요소
• 버전 관리 시스템은 때때로 리비전 관리 시스템으로 불리기도 하는데, 코드의 이력을 관리하는 도구로 비분산형과 분산형이 있으며 비분산형은 SVN, 분산형은 GIT이 유명하다.

브랜칭 전략

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

 

GitFlow 브랜칭 모델

 

 

• 여러 브랜치를 이용해 코드를 관리하는 방식으로 이 방법에서 프로덕션(마스터) 브랜치에는 항상 릴리즈 가능한 깨끗한 코드만 있음.
• 기능 브랜치에는 모든 개발 내용이 들어감.
• 통합 브랜치에서 모든 코드를 통합하고 품질을 위해 테스트를 함.
• 통합 브랜치에서 안정적인 릴리즈 버전이 생길 때 이 버전에 기반해 릴리즈 브랜치를 생성함.
• 프로덕션 브랜치에 핫픽스가 필요한 경우에도 각각의 브랜치를 기반으로 핫픽스 브랜치가 생성됨.

CI 도구

• CI 도구는 지휘자 역할로 CI 시스템의 중심에 위치해 버전 관리 시스템, 빌드 도구, 바이너리 관리도구 등을 연결함.
• CI 도구는 파이프라인을 생성하는 방법을 제공함. 
  • 각 파이프라인에는 고유한 목적이 있는데 CI를 관리하거나, 소작업을 관리하거나, 배포를 관장함.
  • 기술적으로 파이프라인은 연속된 작업의 흐름이며 각 작업은 연속해서 수행되는 소작업의 모음임.
  • 소작업은 폴더나 파일을 복사하는 등의 간단한 것부터 파일 수정을 담당하는 서버를 모니터링하는 것처럼 복잡한 펄 스크립트일 수도 있으며 점점 젠킨스의 플러그인이 스크립트를 대체하고 있음.
  • 자바 코드를 빌드하는 스크립트를 짤 필요 없이 플러그인을 설치한 후 설정한 다음 원하는 작업을 실행시키면 됨.
  • 기술적으로, 플러그인은 자바로 쓰여진 작은 모듈임.
  • 하지만 이런 플러그인을 통해 개발자가 스크립트를 짜는 부담으로부터 자유로워질 수 있음.

자동으로 시작되는 빌드

• 빌드 자동화는 코드를 컴파일하고 실행 파일을 만들어내는 여러 단계를 자동화하는 것.
• 자동으로 시작되는 빌드는 CI에서 가장 중요한 부분으로 다음 두 가지 조건이 충족돼야 함.
  • 빠른 속도
  • 코드나 통합 이슈를 최대한 빨리 잡아내는 것.

코드 커버리지

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

코드 정적 분석

• 화이트 박스 테슷트라고도 부름
• 코드의 구조적인 품질을 측정하는 소프트웨어로 코드가 얼마나 견고하고 지속 가능하지를 알려줌.

자동화된 테스트

• 테스트를 자동화하는 것은 어려움. 따라서 쉬운 부분부터 가능한 많은 부분들을 자동화하는 것이 좋음.

바이너리 관리 도구

• 바이너리 파일의 버전 관리 시스템.
• .rar, .exe, .msi 등의 파일을 관리.
• 빌드된 바이너리를 한 곳에 저장해 필요할 때마다 쉽게 접근 및 관리 가능함.

패키징 자동화

• 빌드가 여러 종류의 결과물을 가지게 되는 경우(.rar 파일, 유닉스 설정 파일, 릴리스 노트, 실행 파일, 데이터베이스 수정 쿼리 등)에 이 결과물을 하나로 묶는 작업을 패키징이라고 함. 이 과정을 자동화함.

 

 

 

 

CI 사용의 장점

 

• 복잡하고 어려운 통합으로부터 해방
• 메트릭: 작업기간 동안의 추세를 보고 프로젝트의 진행 방향 및 속도 확인 가능
• 이슈의 조기 발견
• 빠른 개발
• 기능 추가에 집중: 시간 확보

 

 

 

 

참고: 초보를 위한 젠킨스 2 활용 가이드