지속적 통합이란 무엇인가요? 

코드가 제출되면 CI 툴은 통합 오류를 보다 신속하게 감지하고 해결하기 위해 빌드의 반복을 생성하고 자동화된 테스트를 실행하여 각 통합을 확인합니다.

CI는 기존 소프트웨어 개발의 과제, 즉 통합 및 배포와 관련된 프로세스에 대한 대응책으로 만들어졌습니다. 기존 개발에서는 각 개발자가 새 코드를 앱이나 서비스의 새로운 반복에 수동으로 통합해야 했기 때문에 특히 대규모 개발 팀의 경우 통합이 느리고 오류가 발생하기 쉬운 프로세스였습니다.

서로 다른 코드 조각이 항상 잘 연동되는 것은 아니었고 개발자들은 서로 다른 타임라인에서, 때로는 마지막 순간에 변경 사항을 통합했기 때문에 통합 문제에 대한 피드백이 지연되는 경우가 많았습니다. 일관되지 않은 통합으로 인한 지연으로 인해 팀은 어떤 변경 사항으로 인해 버그가 발생했는지 파악하기가 더 어려워졌고, 디버깅 프로세스도 쉽지 않았습니다.

또한 소프트웨어 테스트가 드물고 대규모 일괄 업데이트가 한꺼번에 이루어졌기 때문에 버그가 틈새로 빠져나가 코드 베이스에 축적되어 최종 사용자에게 오류와 결함을 초래할 수 있었습니다. (그리고 개발자에게는 문제 해결이 더 어려워집니다.)

최신 DevOps 사례, 지속적 통합/지속적 배포(CI/CD) 파이프라인, 마이크로서비스 아키텍처의 기반이 되는 CI 툴은 통합 성능에 대한 신속한 피드백을 제공하여 빌드 프로세스를 간소화하는 데 도움이 됩니다.

CI 시스템을 사용하면 새 코드가 중앙 저장소에 추가되고(일반적으로 하루에 여러 번) 빌드 및 테스트를 위해 남아 있습니다. 시스템이 오류를 감지하면 알림을 보내고, 코드를 수정하고, 업데이트된 코드가 올바른지 확인한 후 코드 베이스와 완전히 병합합니다.

결과적으로 CI 접근 방식을 사용하면 소프트웨어 개발팀은 소프트웨어 성능에 영향을 미치기 전에 오류를 발견하고 수정할 수 있으므로 소프트웨어 품질이 향상되고 배포 일정이 더욱 예측 가능해집니다.

지속적 통합 시스템의 정확한 구성은 팀마다, 비즈니스마다 다르지만 모든 CI 시스템은 특정 구성 요소와 프로세스를 사용하여 통합 작업을 최적화합니다.

CI는 모든 개발자가 코드를 커밋하는 중앙 리포지토리에서 시작됩니다. 중앙 리포지토리는 CI 관행의 초석 역할을 하며 종종 Git 및 Bitbucket과 같은 버전 제어 시스템(VCS)으로 관리됩니다. 개발자가 변경 사항을 제출하면 중앙 리포지토리가 이를 추적하여 개발팀이 보다 효율적으로 협업하는 데 사용할 수 있는 완전한 코드 변경 이력을 생성합니다.

또한 리포지토리는 트렁크 기반 개발 또는 GitFlow와 같은 분기 전략을 사용하여 병렬 개발을 용이하게 합니다. 분기를 통해 개발자는 기능 분기와 수명이 짧은 분기를 만들어 작업을 기본 코드 분기에 다시 병합하기 전에 격리할 수 있습니다.

다양한 플랫폼을 위한 다양한 프로젝트를 구축하도록 구성할 수 있는 CI 서버는 모든 CI 작업을 중앙 집중화하고 소프트웨어 개발을 위한 안정적이고 신뢰할 수 있는 플랫폼을 제공합니다. 이는 지속적 제공을 위해 워크플로를 모델링 및 시각화하고 지속적 제공(CD) 파이프라인을 구축하기 위한 직관적인 인터페이스를 제공합니다.

또한 CI 서버는 자동화된 빌드, 테스트 및 릴리스를 실행하고, 버전 제어 프로토콜을 조정하고, 코드 리포지토리를 모니터링하고, 상태 보고를 처리하고, 시스템 기능을 향상시킬 수 있는 플러그인을 지원합니다.

CI 시스템은 개발자가 매일 여러 번 코드 변경 사항을 제출하도록 권장하며, 특정 작업이나 기능에 대한 작고 집중적인 변경 사항을 우선시합니다. 팀은 풀 요청(설명) 및 병합 요청과 같은 도구를 사용하여 새 코드를 병합하기 전에 코드 검토를 시작하고 문제를 논의하므로, 오류를 조기에 발견할 수 있습니다.

지속적 통합 서버 및 툴(Jenkins, CircleCI, GitHub, AWS CodePipeline 및 GitLab CI와 같은 인기 있는 오픈 소스 CI 툴 포함)는 중앙 리포지토리에서 코드 변경을 모니터링합니다. 새로운 변경 사항을 감지하면 빌드 서버는 빌드 프로세스를 트리거하고 사전 정의된 워크플로와 빌드 스크립트를 실행하여 테스트 및 최종적인 배포를 준비하기 위해 코드를 컴파일 및 패키징합니다.

CI 도구는 코드 베이스와 병합하기 전에 코드의 유효성을 검사하기 위해 다양한 테스트를 실행합니다. 단위 테스트는 개별 구성 요소 또는 기능의 유효성을 검사하여 코드 동작에 대한 즉각적인 피드백을 제공합니다. 통합 테스트는 소프트웨어 구성 요소와 모듈 간의 상호 작용을 평가하여 함께 올바르게 작동하는지 확인하고 단위 테스트에서 놓칠 수 있는 문제를 파악합니다.

일부 CI 워크플로에서 엔드투엔드 테스트는 사용자 상호 작용을 시뮬레이션하여 소프트웨어가 사용자의 관점에서 올바르게 작동하는지 확인하여 소프트웨어를 검증합니다. 또한 팀은 코드 품질 테스트와 정적 분석을 실행하여 부하 시 애플리케이션의 응답성과 안정성을 확인하고 코딩 표준 위반 및 보안 취약점을 식별할 수 있습니다.

CI 서버는 빌드 또는 테스트가 실패할 경우 개발자에게 이를 즉시 알립니다. 오류가 발생할 경우 개발자는 기본 분기가 배포 가능한 상태로 유지되도록 코드를 복구하는 데 우선순위를 둡니다.

빌드가 성공하면 서버는 향후 테스트 및 배포를 위해 아티팩트 리포지토리에 버전이 지정되고 저장되는 아티팩트(컴파일된 바이너리, Docker 이미지 및 설치 프로그램 등)를 생성합니다. 결과에 관계없이, 주요 CI 시스템은 팀원이 항상 포괄적인 버전 문서에 액세스할 수 있도록 통합 시도, 성공률 및 기타 메트릭을 기록합니다.

테스트는 지속적 통합 프로세스의 중요한 구성 요소입니다. 테스트는 최소한 CI 활동의 약 1/3을 차지하지만, 이는 팀이 단일 테스트 단계를 실행하는 경우에만 해당됩니다. 실제로 테스트 활동은 CI 툴의 워크로드의 대부분을 차지할 수 있습니다. 

CI 환경에서의 지속적인 테스트는 개발자가 빌드와 패키지(설치 가능한 엔터티 또는 패키지된 엔터티라고도 함)를 생성할 때 시작되고 패키지가 프로덕션에 투입될 때 끝납니다. 처음부터 끝까지의 모든 단계가 테스트 모음으로 구성됩니다.

CI의 자동화된 테스트 프로세스의 일부로, 테스트 주도 개발은 반복적으로 코드를 빌드하고 한 번에 하나의 사용 사례로 테스트합니다. 그런 다음 애플리케이션의 기능 영역에서 코드가 어떻게 수행되었는지 팀에 알립니다.

그러나 개발자는 로컬 환경에서 모든 테스트와 테스트의 하위 집합을 실행하여 새 코드 변경 사항이 테스트를 통과한 후에만 소스 코드를 버전 제어에 커밋하도록 하는 것이 중요합니다. 이 접근 방식은 테스트 커버리지를 극대화하고 코드 회귀를 방지하며 지속적인 제공을 위한 토대를 마련합니다.

DevOps 프레임워크에서 지속적 통합은 소프트웨어 개발 프로세스의 시작 부분에 있습니다. DevOps 파이프라인은 기존에 각자의 사일로에 존재하던 개발팀과 IT 운영팀의 노력을 자동화하고 결합하여 고품질 소프트웨어의 제공을 가속화합니다.

최고의 DevOps 프로세스와 문화는 개발 및 운영을 넘어 플랫폼 및 인프라 엔지니어링, 보안, 규정 준수, 거버넌스, 위험 관리, LOB(Line of Business), 최종 사용자 및 고객을 포함하도록 확장됩니다. 즉, 우수한 DevOps는 모든 애플리케이션 이해관계자의 의견을 소프트웨어 개발 라이프사이클에 통합해야 합니다.

CI는 DevOps의 일부로, 개발자가 코드를 최소한 하루에 한 번 이상 확인하여 로컬 사본이 코드 빌드의 메인 분기에서 너무 멀리 떨어지지 않도록 할 수 있습니다. 이러한 접근 방식은 팀이 제공 및 배포 단계에서 빌드를 "손상"시킬 수 있는 치명적인 병합 충돌을 피하는 데 도움이 됩니다.

지속적 통합은 CI/CD 파이프라인의 첫 번째 단계이며 일반적으로 지속적 제공 및 지속적 배포 프로세스가 뒤따릅니다.

지속적 전달(CD) 은 지속적 통합이 중단되는 부분을 찾아 개발, 테스트, 궁극적으로 최종 사용자에게 전달하기 위해 필요한 모든 환경에 애플리케이션 및 검증된 코드 기반 변경 사항(업데이트, 버그 수정 및 새로운 기능)을 자동으로 전달합니다. CD 프로세스는 빌드 단계를 '녹색'으로 유지하므로 아티팩트는 언제든지 배포할 수 있습니다.

지속적 배포(DevOps의 마지막 단계)를 사용하면 코드 변경 사항이 프로덕션 환경으로 자동으로 릴리스되고 최종 사용자에게 배포됩니다. 이 시점에서 코드 수정은 모든 테스트 프로토콜을 통과했으므로 안전하고 공개적으로 사용할 수 있습니다. 그런 다음 CI 스크립트 또는 툴이 소프트웨어 아티팩트를 공용 서버 또는 배포 플랫폼(예: 애플리케이션 스토어)으로 이동하고 업데이트를 최종 사용자에게 푸시합니다.

지속적 통합과 민첩한 개발은 테스트 자동화를 포함하여 많은 기능이 동일하므로 이 두 가지가 어떻게 상호 작용하는지 논의하는 것이 유용할 수 있습니다.

애자일(Agile)은 개발 프로세스를 더 작은 작업 그룹 또는 '스프린트(sprint)'로 구성하여 장벽을 최소화하고 개발자 협업을 가능하게 하며 소프트웨어 제공을 가속화하는 관행입니다. 애자일 방법론은 소프트웨어 개발 관행과 고객 요구가 동적이고, 이로 인해 시간이 지남에 따라 변경될 가능성이 높다는 점을 인정합니다.

이처럼 애자일은 팀과 비즈니스가 변화에 더 쉽게 적응하고 시간이 지남에 따라 소프트웨어 솔루션을 확장 및 발전시킬 수 있도록 반복적인 개발 접근 방식을 제공합니다. 또한 CI는 빈번한 업데이트와 코드 유효성 검사를 장려하므로 애자일 팀이 고품질 제품을 더욱 빠르게 출시할 수 있어 본질적으로 애자일 관행이 될 수 있도록 합니다.

지속적 통합을 통해 DevOps 팀은 소프트웨어 코딩, 테스트, 배포 및 지원을 위해 공유 리포지토리를 사용할 수 있지만, 기업이 프로세스를 최적화하기 위해 수행할 수 있는 몇 가지 추가 단계가 있습니다. 일반적으로 구현되는 CI 모범 사례는 다음과 같습니다.

특히 DevOps 및 민첩한 개발의 일환으로 강력한 CI 파이프라인을 설정하려면 올바른 툴 선택, 빌드 및 테스트 워크플로 정의, 인프라 구성 등 신중한 계획과 구성이 필요합니다. 또한 CI 파이프라인은 코드 베이스, 종속성(예: API) 및 인프라의 변경 사항을 수용하기 위해 정기적인 유지 관리가 필요합니다.

그러나 CI를 구현하면 소프트웨어 개발 팀에 다음과 같은 다양한 이점을 제공할 수 있습니다.

CI 프로세스를 통해 팀은 조기에 오류를 해결할 수 있으며, 때로는 체크인 후 몇 분 이내에 오류를 해결할 수 있습니다.

팀원 모두가 코드를 변경하고, 코드 변경 사항을 통합하고, 코드 비호환성 및 통합 오류를 식별하여 지식 공유를 간소화하고 동료 피드백을 통해 코드 및 소프트웨어 품질을 개선할 수 있습니다.

새로운 코드가 지속적으로 통합되기 때문에 팀은 대규모 코드 배치를 통합하고 테스트하는 데 소요되는 시간을 줄일 수 있습니다. 또한 CI 도구가 제공하는 가속화된 피드백 루프를 통해 개발자는 소프트웨어 업데이트와 신제품을 반복하여 최종 사용자에게 더 빠르게 제공할 수 있습니다.

코드 커밋이 잦다는 것은 이해하고, 검토하고, 테스트하기 쉬운 소규모의 점진적인 변경이 많다는 것을 의미합니다. 이렇게 하면 개발을 진행하면서 코드 베이스에 중대한 문제가 발생할 위험이 줄어듭니다.