CI / CD 란 무엇입니까? 지속적 통합 및 지속적 전달 설명

CI (지속적 통합) 및 CD (지속적 배포)는 애플리케이션 개발 팀이 코드 변경을 더 자주, 안정적으로 제공 할 수 있도록하는 문화, 일련의 운영 원칙 및 관행 모음을 구현합니다. 구현은 CI / CD 파이프 라인 이라고도합니다 . 

CI / CD는 devops 팀이 구현할 모범 사례 중 하나입니다. 또한 배포 단계가 자동화되어 있기 때문에 소프트웨어 개발 팀이 비즈니스 요구 사항, 코드 품질 및 보안을 충족하는 데 집중할 수 있으므로 민첩한 방법론 모범 사례입니다.

CI / CD 정의

지속적인 통합  은 개발 팀이 작은 변경 사항을 구현하고 코드를 버전 제어 저장소에 자주 체크인하도록 유도하는 코딩 철학이자 일련의 관행입니다. 대부분의 최신 응용 프로그램은 서로 다른 플랫폼과 도구에서 코드를 개발해야하므로 팀은 변경 사항을 통합하고 검증 할 메커니즘이 필요합니다.

CI의 기술적 목표는 애플리케이션을 빌드, 패키징 및 테스트하는 일관되고 자동화 된 방법을 설정하는 것입니다. 통합 프로세스의 일관성이 유지되면 팀은 코드 변경을 더 자주 수행 할 가능성이 높아 공동 작업과 소프트웨어 품질이 향상됩니다.

지속적 전달  은 지속적 통합이 끝나는 곳을 선택합니다. CD는 선택한 인프라 환경에 애플리케이션 제공을 자동화합니다. 대부분의 팀은 개발 및 테스트 환경과 같은 프로덕션 이외의 여러 환경에서 작업하며 CD는 코드 변경 사항을 자동으로 푸시 할 수 있도록합니다.

CI / CD 도구는 각 제공과 함께 패키지화해야하는 환경 별 매개 변수를 저장하는 데 도움이됩니다. 그런 다음 CI / CD 자동화는 웹 서버, 데이터베이스 및 애플리케이션을 배포 할 때 다시 시작하거나 다른 절차를 따라야 할 수있는 기타 서비스에 필요한 모든 서비스 호출을 수행합니다.

지속적 통합 및 지속적 전달은 사용자에게 양질의 애플리케이션과 코드를 제공하는 것이 목표이므로 지속적 테스트가  필요  합니다. 지속적인 테스트는 종종 CI / CD 파이프 라인에서 실행되는 일련의 자동화 된 회귀, 성능 및 기타 테스트로 구현됩니다.

성숙한 CI / CD devops 사례에는 CI / CD 파이프 라인을 통해 애플리케이션 변경이 실행되고 빌드가 프로덕션 환경에 직접 배포되는 지속적인 배포를 구현하는 옵션이 있습니다. 지속적 배포를 실행하는 팀은 매일 또는 매시간 일정에 따라 프로덕션에 배포하도록 선택하지만, 모든 비즈니스 응용 프로그램에 항상 최적 인 것은 아닙니다.  

관련 비디오 : CI / CD로 코드를 더 빠르게 제공하는 방법

지속적인 통합이 협업과 품질을 향상시키는 방법

지속적인 통합은 프로세스 메커니즘과 일부 자동화로 뒷받침되는 개발 철학입니다. CI를 연습 할 때 개발자는 코드를 버전 관리 저장소에 자주 커밋하고 대부분의 팀은 최소한 매일 코드 커밋에 대한 최소한의 표준을 가지고 있습니다. 이것의 근거는 광범위한 기간에 걸쳐 개발 된 큰 차이보다 작은 코드 차이에서 결함 및 기타 소프트웨어 품질 문제를 식별하는 것이 더 쉽다는 것입니다. 또한 개발자가 더 짧은 커밋 주기로 작업 할 때 여러 개발자가 동일한 코드를 편집하고 커밋 할 때 병합을 요구할 가능성이 적습니다.

지속적인 통합을 구현하는 팀은 종종 버전 제어 구성 및 실행 정의로 시작합니다. 코드 체크인은 자주 수행되지만 기능과 수정 사항은 짧은 시간과 긴 시간 모두에서 구현됩니다. 지속적 통합을 실행하는 개발 팀은 다양한 기술을 사용하여 프로덕션에 준비된 기능과 코드를 제어합니다.

많은 팀이 런타임에 기능 및 코드를 켜거나 끄는 구성 메커니즘 인 기능 플래그를 사용 합니다 . 아직 개발중인 기능은 코드에서 기능 플래그로 래핑되고 프로덕션에 마스터 분기와 함께 배포되며 사용할 준비가 될 때까지 꺼집니다. 최근 설문 조사에 따르면 기능 플래그를 사용하는 팀의 63 %가 더 나은 테스트와 더 높은 품질의 소프트웨어를보고합니다. CloudBees Rollout, Optimizely Rollouts 및 LaunchDarkly와 같은 기능 플래그 지정 도구는 CI / CD 도구와 통합되고 기능 수준 구성을 활성화합니다.

기능을 관리하는 또 다른 기술은  버전 제어 분기 입니다. Gitflow와 같은 분기 전략은 개발, 테스트 및 프로덕션을 위해 새 코드가 표준 분기에 병합되는 방법에 대한 프로토콜을 정의하기 위해 선택됩니다. 개발주기가 더 오래 걸리는 기능을 위해 추가 기능 분기가 생성됩니다. 기능이 완료되면 개발자는 기능 분기의 변경 사항을 기본 개발 분기로 병합 할 수 있습니다. 이 접근 방식은 잘 작동하지만 동시에 개발중인 기능이 많은 경우 관리가 어려울 수 있습니다.

그런 다음 모든 소프트웨어, 데이터베이스 및 기타 구성 요소를 패키징하여 빌드 프로세스 자체를 자동화합니다. 예를 들어 Java 응용 프로그램을 개발하는 경우 CI는 HTML, CSS 및 JavaScript와 같은 모든 정적 웹 서버 파일을 Java 응용 프로그램 및 데이터베이스 스크립트와 함께 패키징합니다.

CI는 모든 소프트웨어 및 데이터베이스 구성 요소를 패키징 할뿐만 아니라 자동화는 단위 테스트 및 기타 테스트도 실행합니다. 이 테스트는 개발자에게 코드 변경으로 인해 기존 단위 테스트가 중단되지 않았다는 피드백을 제공합니다.

대부분의 CI / CD 도구를 사용하면 개발자가 버전 제어 저장소의 코드 커밋에 의해 트리거되거나 정의 된 일정에 따라 요청시 빌드를 시작할 수 있습니다. 팀은 팀 규모, 예상되는 일일 커밋 수 및 기타 애플리케이션 고려 사항에 가장 적합한 빌드 일정에 대해 논의해야합니다. 커밋 및 빌드가 빠르도록하는 모범 사례입니다. 그렇지 않으면 빠르게 코딩하고 자주 커밋하려는 팀의 진행을 방해 할 수 있습니다.

지속적인 테스트는 테스트 자동화를 뛰어 넘습니다.

자동화 된 테스트 프레임 워크는 품질 보증 엔지니어가 소프트웨어 빌드의 통과 또는 실패 여부를 파악하는 데 도움이되는 다양한 유형의 테스트를 정의, 실행 및 자동화하는 데 도움이됩니다. 여기에는 모든 스프린트가 끝날 때 개발되고 전체 애플리케이션에 대한 회귀 테스트 로 집계되는 기능 테스트가 포함 됩니다. 그런 다음 이러한 회귀 테스트는 코드 변경이 테스트 범위가있는 애플리케이션의 모든 기능 영역에서 개발 된 테스트 중 하나 이상에 실패했는지 여부를 팀에 알립니다.

모범 사례는 개발자가 로컬 환경에서 회귀 테스트의 전부 또는 일부를 실행하도록 설정하고 요구하는 것입니다. 이 단계에서는 개발자가 회귀 테스트가 코드 변경을 통과 한 후에 만 ​​코드를 버전 제어에 커밋하도록합니다.

회귀 테스트는 시작에 불과합니다. 성능 테스트, API 테스트, 정적 코드 분석, 보안 테스트 및 기타 테스트 양식도 자동화 할 수 있습니다. 핵심은 명령 줄, 웹훅 또는 웹 서비스를 통해 이러한 테스트를 트리거 할 수 있고 성공 또는 실패 상태 코드로 응답하는 것입니다.

테스트가 자동화되면 지속적인 테스트는 자동화가 CI / CD 파이프 라인에 통합됨을 의미합니다. 일부 단위 및 기능 테스트는 통합 프로세스 전이나 도중에 문제를 표시하는 CI에 통합 될 수 있습니다. 성능 및 보안 테스트와 같은 전체 제공 환경이 필요한 테스트는 종종 CD에 통합되고 빌드가 대상 환경에 전달 된 후에 수행됩니다.

CD 파이프 라인은 여러 환경에 대한 변경을 자동화합니다.

지속적 전달은 애플리케이션을 전달 환경으로 푸시하는 자동화입니다. 대부분의 개발 팀에는 일반적으로 테스트 및 검토를 위해 응용 프로그램 변경 사항이 준비되는 하나 이상의 개발 및 테스트 환경이 있습니다. Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo 또는 Travis CI와 같은 CI / CD 도구는 단계를 자동화하고보고를 제공하는 데 사용됩니다.

일반적인 CD 파이프 라인에는 빌드, 테스트 및 배포 단계가 있습니다. 보다 정교한 파이프 라인에는 다음 단계가 포함됩니다.

  • 버전 제어에서 코드를 가져오고 빌드를 실행합니다.
  • 클라우드 인프라를 구축하거나 해체하기 위해 코드로 자동화 된 필수 인프라 단계를 실행합니다.
  • 대상 컴퓨팅 환경으로 코드 이동.
  • 환경 변수를 관리하고 대상 환경에 맞게 구성합니다.
  • 웹 서버, API 서비스 및 데이터베이스 서비스와 같은 적절한 서비스에 응용 프로그램 구성 요소를 푸시합니다.
  • 서비스를 다시 시작하거나 새 코드 푸시에 필요한 서비스 끝점을 호출하는 데 필요한 단계를 실행합니다.
  • 테스트가 실패 할 경우 연속 테스트 및 롤백 환경을 실행합니다.
  • 배달 상태에 대한 로그 데이터 및 경고를 제공합니다.

예를 들어 Jenkins 사용자는 빌드, 테스트 및 배포와 같은 다양한 단계를 설명하는 Jenkinsfile에서 파이프 라인을 정의합니다. 환경 변수, 옵션, 비밀 키, 인증 및 기타 매개 변수는 파일에서 선언 된 다음 단계적으로 참조됩니다. 게시 섹션은 오류 조건 및 알림을 처리합니다.  

보다 정교한 CD에는 데이터 동기화 수행, 정보 자원 보관 또는 응용 프로그램 및 라이브러리 패치 수행과 같은 다른 단계가있을 수 있습니다. CI / CD 도구는 일반적으로 플러그인 시장을 지원합니다. 예를 들어 Jenkins는 타사 플랫폼, 사용자 인터페이스, 관리, 소스 코드 관리 및 빌드 관리와의 통합을 지원하는 1,500 개 이상의 플러그인을 나열합니다.

CI / CD 도구가 선택되면 개발 팀은 모든 환경 변수가 애플리케이션 외부에 구성되어 있는지 확인해야합니다. CI / CD 도구를 사용하면 이러한 변수를 설정하고, 암호 및 계정 키와 같은 변수를 마스킹하고, 배포시 대상 환경에 맞게 구성 할 수 있습니다.

CD 도구는 대시 보드 및보고 기능도 제공합니다. 빌드 또는 전달이 실패하면 개발자에게 실패에 대한 정보를 알립니다. 버전 제어 및 애자일 도구와 통합되므로 빌드를 구성한 코드 변경 및 사용자 스토리를 찾는 데 사용할 수 있습니다.

Kubernetes 및 서버리스 아키텍처로 CI / CD 파이프 라인 구현 

클라우드 환경에서 CI / CD 파이프 라인을 운영하는 많은 팀은 Docker와 같은 컨테이너와 Kubernetes와 같은 오케스트레이션 시스템도 사용합니다. 컨테이너를 사용하면 표준 휴대용 방식으로 애플리케이션을 포장하고 배송 할 수 있습니다. 컨테이너를 사용하면 다양한 워크로드가있는 환경을 쉽게 확장하거나 해체 할 수 있습니다.

컨테이너, 인프라를 코드로, CI / CD 파이프 라인을 함께 사용하는 방법에는 여러 가지가 있습니다. Jenkins를 사용하는 Kubernetes 또는 Azure DevOps를 사용하는 Kubernetes와 같은 자습서를 통해 옵션을 탐색 할 수 있습니다.

서버리스 컴퓨팅 아키텍처는 애플리케이션을 배포하고 확장하는 또 다른 방법을 제시합니다. 서버리스 환경에서 인프라는 클라우드 서비스 공급자가 완전히 관리하며 애플리케이션은 구성에 따라 필요에 따라 리소스를 소비합니다. 예를 들어 AWS에서 서버리스 애플리케이션은 Lambda 함수로 실행되고 배포는 플러그인을 사용하여 Jenkins CI / CD 파이프 라인에 통합 될 수 있습니다. 

CI / CD로 더 빈번한 코드 배포 가능

요약하자면 CI 패키지 및 테스트 소프트웨어는 변경 사항이 단위 테스트에 실패한 경우 개발자에게 빌드하고 경고합니다. CD는 인프라에 변경 사항을 전달하고 추가 테스트를 실행하는 자동화입니다. 

CI / CD 파이프 라인은 애플리케이션을 자주 개선하고 안정적인 제공 프로세스가 필요한 비즈니스를 위해 설계되었습니다. 빌드 표준화, 테스트 개발 및 배포 자동화를위한 추가 노력은 코드 변경 사항 배포를위한 제조 프로세스입니다. 일단 배치되면 팀은 응용 프로그램을 향상시키는 프로세스에 집중하고 컴퓨팅 환경에 제공하는 시스템 세부 사항에 집중할 수 있습니다.

CI / CD는 변경 사항을 자주 푸시하려는 개발자와 안정적인 애플리케이션을 원하는 작업 간의 불일치를 해결하기 때문에 devops 모범 사례입니다. 자동화를 통해 개발자는 변경 사항을 더 자주 푸시 할 수 있습니다. 운영팀은 환경에 표준 구성이 있고, 제공 프로세스에서 지속적인 테스트가 있으며, 환경 변수가 애플리케이션에서 분리되고, 롤백 절차가 자동화되기 때문에 더 큰 안정성을 보게됩니다.

CI / CD 파이프 라인 구현의 영향은 devops 핵심 성과 지표 (KPI)로 측정 할 수 있습니다. 지속적 테스트가 포함 된 CI / CD를 구현하면 배포 빈도, 변경 리드 타임 및 사고로부터 MTTR (평균 복구 시간)과 같은 KPI가 개선되는 경우가 많습니다. 그러나 CI / CD는 이러한 개선을 추진할 수있는 하나의 프로세스 일 뿐이며 배포 빈도를 개선하기위한 다른 전제 조건이 있습니다.

CI / CD를 시작하려면 개발 팀과 운영 팀이 기술, 관행 및 우선 순위에 대해 협력해야합니다. 팀은 비즈니스 및 기술에 대한 올바른 접근 방식에 대한 합의를 개발하여 CI / CD가 마련되면 팀이 지속적으로 다음 관행을 따르도록해야합니다.