지속적 통합(CI)은 팀원들이 작업 결과를 자주 통합하는 소프트웨어 개발 방식이다. 통합할 때마다 자동 빌드하여 통합 오류를 빠르게 찾아낸다.
간단히 말해 CI의 기본 목적은 문제를 일으키는 변경을 가능한 한 조기에 자동으로 발견해내는 것이다.
현실을 반영하고 특히 대규모 개발을 고려해 CI를 다시 정의해보면 지속적 통합은 빠르게 진화하는 복잡한 생태계 전체를 지속적으로 조립하고 테스트하는 개발 방식이다.
23.1 지속적 통합이란?
23.1.1 빠른 피드백 루프
버그는 발견하는 시점이 늦을수록 처리 비용이 기하급수적으로 증가한다.
CI는 우리가 빠른 피드백 루프를 이용하도록 유도하여 버그 비용을 최소로 줄여준다.
카나리 배포를 활용하면 프로덕션에서 일어나는 문제가 확실하게 줄어든다. 프로덕션 전체에 배포하기 전에 일부에만 먼저 배포하여 초기 피드백 루프를 만들 수 있기 때문이다. 하지만 여러 가지 버전이 동시에 배포되어 있으면 호환성 문제가 생길 수 있으니 카나리 배포 자체로 문제를 일으킬 여지도 있다.
버전 왜곡이라는 이 문제는 분산 시스템에서 호환되지 않는 여러 코드, 데이터, 설정 정보가 공존하는 상태를 말한다.
실험과 기능 플래그도 매우 강력한 피드백 루프이다. 변경을 컴포넌트 단위로 격리한 후 프로덕션 환경에서 동적으로 켜고 끌 수 있게 하여 배포 위험을 줄여주는 기법들이다.
볼 수 있고 조치할 수 있는 피드백
CI가 제공하는 피드백을 많은 사람이 볼 수 있어야 한다.
테스트 이력을 볼 수 있게 한 덕분에 엔지니어들은 피드백을 공유하고 협업할 수 있다. 마지막으로 CI 테스트가 제공하는 피드백은 모두 조치가 가능해야 한다. 즉 문제를 찾고 고치기가 쉬워야 한다.
23.1.2 자동화
개발 관련 활동들을 자동화하면 장기적으로 엔지니어링 자원을 아낄 수 있다는 건 잘 알려진 사실이다. 구글에서 변경이 체크인되는 즉시 동료 리뷰를 진행하여 오류가 스며들 가능성을 낮춘것 역시 프로세스를 코드로 정의해 자동화했기 때문이다.
여러 개발 활동 중 CI는 특별히 빌드와 릴리스 프로세를 자동화한다.
지속적 빌드
지속적 빌드는 가장 최근의 코드 변경을 헤드에 통합한 다음 자동으로 빌드와 테스트를 수행한다. 지속적 빌드도 컴파일을 통과하더라도 테스트에 실패하면 빌드 실패로 간주한다.
지속적 배포
지속적 배포의 첫 번째 단계는 릴리스 자동화이다. 헤드로부터 지속해서 최신 코드와 설정 정보를 가져와서 릴리스 후보를 만들어내는 작업구조이다.
릴리스 후보 : 자동화된 프로세스가 만든 서로 밀접하게 관련된 요소들로 구성된 배포 가능한 단위, 지속적 빌드를 통과한 코드, 설정정보, 기타 의존성들을 조합해 만든다.
지속적 배포 : 지속해서 릴리스 후보를 조립한 다음 다양한 환경에 차례로 승격시켜 테스트하는 활동, 프로덕션까지 승격시키는 경우도 있고 그렇지 않은 경우도 있다.
614~~