지속적 통합 (Continuous Integration, CI)

지속적 통합 (CI)

: 일련의 테스트를 통과한 후 모든 개발자 변경 사항을 마스터 브랜치에 지속적으로 구축, 테스트 및 통합하는 프로세스

→ 그 결과 잠재적으로 배포 가능한 코드가 생성됨

 

지속적 전달 (CD)

: 모든 변경 사항을 프로덕션과 유사한 환경에 전달하여 코드를 프로덕션에 빠르고 안전하게 배포할 수 있도록 설계된 일련의 사례

프로덕션 환경에 배포할 필요가 없으며 실제로 많은 사람들이 프로덕션 환경에 지속적으로 배포할 때 지속적 배포(CD)라는 용어를 사용

지속적 전달을 위해서는 프로덕션 환경을 모방한 개발, 테스트, 스테이징 환경과 같은 곳에 배포하기만 하면 됨.

ex. 프로덕션 환경이 Kubernetes에서 실행되는 컨테이너인 경우 Kubernetes의 컨테이너에 있는 개발 환경에 배포해야 함

 

 

기존 개발 과정 : 수명이 긴 개발 브랜치

  이전 버전 제어 시스템에서는 브랜치를 만들 때마다 전체 코드 사본을 만들어 브랜치를 만드는 데 비용이 많이 들기 때문

  비용 때문에 사람들은 브랜치를 만드는 것을 거부하게 되고, 브랜치를 만들더라도 자주 삭제하지 않았음

  Git과 같은 최신 버전 제어 시스템에서는 더 이상 그렇지 않지만 일부 개발 팀은 기존 방식을 유지

 

이러한 개발 브랜치는 릴리스 브랜치와 분리되어 유지되고 주기적으로 릴리스 브랜치에 병합됨 

  오랜 기간 동안 변경된 양이 많기 때문에 브랜치가 병합 충돌에 취약함

  빌드는 릴리스 후보 브랜치에서 주기적으로, 때로는 야간에 실행함

 

 

지속적 통합(CI)

개발자가 코드를 공유 리포지토리에 자주, 가능하면 매일 통합해야 하는 개발 방식

- 개발자가 기능이 완성되면 마스터에 병합되는 수명이 짧은 기능 브랜치에서 작업하도록 함으로써 가능

  : 각 기능이 완성되는 대로 통합할 수 있음

- 그런 다음 자동화된 테스트와 자동화된 빌드를 통해 각 체크인을 검증하여 팀에서 문제를 조기에 자주 감지할 수 있음.

- 병합이 완료되면 브랜치가 삭제되고 새 피쳐에 대한 새 브랜치가 생성됨.

 

소량으로 작업하는 게 좋음

- 정기적으로 커밋 수행 → 병합 간에 걸리는 시간 감소 → 충돌하는 변경 사항의 수 감소

- (기존) 커밋과 커밋 간의 시간 증가 → 병합 충돌 위험 증가

  : 이러한 충돌은 해결하기 어렵고 시간이 많이 걸릴 수 있음.

- 풀 리퀘스트 → 팀원들의 의견 교환 : 코드 검토 → 문제 발생 가능성 감소

 

모든 변경 사항을 하루에 한 번 이상 또는 기능 빌드당 한 번 커밋

 

모든 풀 리퀘스트는 자동으로 빌드하고 테스트

: CI 도구가 버전 제어 시스템을 모니터링한 다음 빌드를 자동화하고 자동으로 실행 (자동화)

  ex. Travis CI, Circle CI, Jenkins, GitHub Actions

코드가 빌드되면 모든 테스트를 실행하여 코드가 개발자가 예상한 대로 작동하는지 확인 : 빌드를 자체 테스트

테스트 결과는 pull 요청에 피드백. (실패한 테스트가 있는 pull 요청을 병합해서는 안됨)

 

 

지속적 통합(CI)의 이점

: 테스트 자동화

- 변화에 대한 대응 시간을 단축하고 더 빠르게 움직일 수 있음

- 지금까지 수행한 모든 작업이 제대로 작동하는 것으로 확인됨

- 테스트에 시간을 낭비하지 않고 기능 구축에 시간 사용

작은 변경 사항도 통합

- 코드 통합의 위험을 줄여줌

- 변화가 적을수록 변경으로 인한 파손 위험이 줄어듦

pull 요청

- 팀원들의 코드 검토로 코드 품질 향상

마스터 브랜치는 항상 배포 가능

: 테스트되지 않은 코드는 작동하지 않는다고 가정. 테스트되지 않은 코드를 마스터 브랜치에 병합해서는 안됨