연속 통합 분석

  • 4분

연속 통합은 DevOps 분류의 8가지 기능 중 하나입니다.

연속 통합이 필요한 이유 알아보기

1999년 9월 23일, 화성 기후 탐사 위성은 화성 상층 대기로 잠시 진입하면서 보호를 위해 태양 전지 판을 접었습니다.

성공적으로 궤도에 진입한 후 위성은 몇 년 동안 화성의 사진을 지구로 보내야 했습니다. 하지만 안타깝게도 위성은 화성의 대기에서 불에 타버렸습니다.

타사에서 제공하는 지상 제어 소프트웨어가 파운드 초 수치를 야드파운드 단위로 계산했습니다. NASA에서 제작한 소프트웨어는 값이 미터법 단위인 뉴턴-초일 것으로 예상했습니다. 값이 올바르게 변환되지 않았기 때문에 우주선의 위치를 나타내는 수치의 사소한 차이가 수백만 마일에 걸쳐 심각해졌습니다.

당시 NASA가 코딩 표준에서 미터법 사용을 의무화했음에도 불구하고 품질 보증 부서에서는 외부 소프트웨어가 야드파운드법을 사용하는 것을 알아채지 못했습니다. 파일 형식 오류를 비롯한 여러 버그로 인해 제공된 소프트웨어가 사용되지 않고 계산이 수동으로 이루어졌습니다. 이는 연속 통합이 필요한 예입니다.

연속 통합 살펴보기

연속 통합은 마음가짐이자 팀 전략입니다. 또한 저자이자 강사인 Martin Fowler는 연속 통합을 팀 구성원이 작업을 자주 통합하는, 즉 일반적으로 각 구성원이 최소한 하루에 한 번씩 통합해 하루에 여러 번 통합이 이루어지는 소프트웨어 개발 방식이라고 정의합니다.

각 통합은 자동화된 빌드(테스트 포함)에 의해 확인되어 최대한 빠르게 통합 오류를 검색합니다.

해당 방식을 올바르게 사용하면 프로세스 초기에 문제를 포착하여 통합 문제를 줄일 수 있습니다.

다이어그램은 지속적인 업데이트와 지속적인 배포의 차이점을 제시합니다. 두 경우 모두 단계는 동일합니다. 코드 완성, 단위 테스트, 통합, 승인 테스트, 제품에 배포 순으로 진행됩니다. 지속적인 업데이트의 경우 제품에 배포하는 작업이 수동으로 진행됩니다. 지속적인 배포의 경우 자동으로 진행됩니다. 연속 통합은 지속적인 업데이트와 지속적인 배포를 위한 첫 세 단계를 포괄합니다.

연속 통합의 목표는 다음과 같습니다.

참고

연속 통합의 목표는 지속적인 협업, 지속적인 업데이트 및 지속적인 품질을 포함합니다.

하지만 연속 통합이 없다면 어떤 일이 일어날까요? 연속 통합 노력이 부족하면 다음과 같은 결과가 발생할 수 있습니다.

  • 긴 개발 주기
    • 컴파일되지 않은 코드
    • 언제든지 작동하지 않을 수도 있는 소스 코드
    • 코드 동결
  • 많은 양의 빌드 실패/버그
    • 며칠에 걸쳐 병합해야 하는 오래된 분기
    • 소스 제어에서 누락된 코드
    • 개발 주기 후반에 발견되는 보안 문제
    • 많은 양의 기술적인 문제
    • 코드 검사 번호가 없거나 낮음
    • 전반적인 품질 저하
  • 제한된 커뮤니케이션 및 협업
    • 코딩 표준을 따르지 않는 코드
    • 코드 검토가 거의 또는 전혀 되지 않음
    • 개발 주기 후반에 수행되는 테스트
    • 대부분의 경우 수동 작업 필요

통합 지점은 시스템을 개선하는 데 사용되는 빠른 피드백 루프입니다. 통합 지점의 타이밍이 어긋나면 프로젝트에 문제가 있는 것입니다. 다음은 Dantar Oosterwal이 The Lean Machine이라는 책에서 언급한 내용입니다.

통합 지점의 출현은 제품 개발을 제어한다는 의미입니다. 통합 지점은 시스템을 개선하기 위한 활용 지점입니다. 통합 지점의 타이밍이 어긋나면 프로젝트에 문제가 있는 것입니다.

Dantar Oosterwal, The Lean Machine

© Scaled Agile, Inc.

팀이 실제로 연속 통합을 수행하고 있는지 궁금하다면 다음 질문을 통해 답을 확인할 수 있습니다.

  • 모든 개발자가 트렁크 기반으로 개발 중인가요?
  • 트렁크의 모든 변경 내용이 빌드 프로세스를 시작하나요?
  • 빌드 및 테스트가 실패할 경우 팀이 몇 분 이내에 빌드를 수정하나요?

성과 또한 연속 통합의 유무에 따라 영향을 받습니다. Nicole Forsgren, Jez Humble, Gene Kim이 저술한 The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations를 위해 수집 및 분석된 데이터에 따르면 성과가 낮은 기업의 시장 출시 속도가 빨라지면 품질이 떨어집니다.

하지만 성과가 높은 기업은 시장 출시 속도를 높여도 품질을 유지할 수 있습니다. 성과가 높은 기업은 배포 주기가 더 짧고 덜 복잡하며 연속 통합을 사용하여 이슈를 즉시 해결하고 흐름 및 효율성을 높입니다.

2017 높은 성과를 내는 기업 보통 성과를 내는 기업 낮은 성과를 내는 기업
배포 빈도 하루에 여러 번 1주~1개월 1주~1개월
변경에 대한 리드 타임 1시간 미만 1주~1개월 1주~1개월
MTTR 1시간 미만 < 1일 1일~1주
실패율 변경 0~15% 0~15% 31~45%