지속적 전달·통합은 구름과 찰떡궁합··· 클라우드 CI/CD 플랫폼 안내서

소프트웨어 개발 및 생산 프로세스를 빠르게 하고자 한다면, 최소한 테스트 및 전달 프로세스의 일부를 자동화해야 한다. 이를 위해서는 CI/CD 파이프라인을 도입해야 할 가능성이 높다. 오류를 잡아내기 위한 테스트 스위트도 필요할 수 있다. 

지속적 통합(Continuous integration)의 약자인 CI는 소프트웨어 개발, 패키지화, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 팀에 소스 코드 버전 관리 시 확인하는 변경사항이 빌드를 망가뜨리거나 소프트웨어에 버그를 유입시키지 않을 것이라는 자신감을 갖는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 저장소의 메인 브랜치(Main Branch)에 대해 완료된 체크인(Check-in)이다.

지속적 전달(Continuous delivery )의 약자인 CD는 인프라 환경에 대한 테스트된 소프트웨어의 전달을 자동화한다. 일반적으로 고객이 평가를 확인하기 위해 생산에 직접 투입하는 것을 의미하지는 않는다. 일반적으로 조직은 빌드를 개발 환경에 넣으면서 CD를 시작한다. 개발자가 새로운 빌드를 완성하고 공개한 후, 일반적으로 테스트 환경으로 가서 더욱 광범위한 사용자(때로는 점당 내부 테스터, 베타 테스트에 자원한 더 큰 사용자 그룹, ‘도그 푸딩(Dog-fooding)’)들이 사용하면서 긴밀하게 모니터링한다. 마지막으로, 모든 것이 잘 되면 테스터가 승인하고 새 버전을 생산 환경에 투입한다.

각 CD 단계에는 구빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결할 수 있도록 버그 보고 티켓을 생성하는 옵션이 있다. 목표는 많은 빌드를 생산에 투입하는 것이 아니라 퇴보를 유발하지 않으면서 소프트웨어를 지속적으로 개선하는 것이다. 이 활동을 흔히 ‘데브옵스(DevOps)’라고도 부른다.

CI/CD를 클라우드에서 호스팅하는 이유
CI/CD 플랫폼을 자체 데이터센터에서 호스팅할 수도 있다. 애플리케이션과 데이터를 방화벽 안에서 호스팅하도록 의무화하는 기업들의 경우는 더욱 그렇다. 단점은 전담 팀이 인프라를 유지보수해야 한다는 점이다. 서버를 위한 일부 자본 지출 또한 발생한다.

클라우드에서 호스팅하는 옵션은 많은 기업에게 적절하다. 비용이 낮은 편이며, 지출 비용은 온보딩, 인프라 유지보수, 보안 유지보수, 지원, CI/CD 소프트웨어 개발 등의 제공되는 서비스로 상쇄된다. 또 CI/CD 소프트웨어를 클라우드에서 호스팅하면 파이프라인이 클라우드에 있는 경우 소스 코드 저장소와 더 쉽고 빠르게 상호작용할 수 있는 경우가 많다. 개발자와 테스터가 지리적으로 분산되어 있는 경우, 클라우드에서 저장소를 호스팅하면 방화벽 뒤의 원격 서버에서 호스팅하는 것보다 개발자에게 더 나은 경험을 제공하게 된다.

또한 CI/CD를 온프레미스와 클라우드 서버를 가로지를 하이브리드 인프라에 배치할 수 있다. 최근 여러 CI/CD 옵션이 온프레미스 및 클라우드로 구동 가능한 쿠버네티스(Kubernetes) 클러스터에서 컨테이너로 구동된다. 하이브리드 개발 시나리오에서는 개발 인프라에서 개발자의 위치와 다른 서버의 네트워크 위치를 고려하여 적절한 곳에 각 구성요소를 배치할 수 있다.

CI/CD는 저장소와 통합되어야 한다
“CI의 종점은 일반적으로 소프트웨어 저장소의 메인 브랜치(Main Branch)에 대해 완료된 체크인(Check-in)이다”라는 말을 들었을 때 알아차렸을 수 있지만 저장소는 CI 및 CD와 불가분의 관계를 가진다. 체크인 및 테스트 프로세스의 종점을 넘어 소프트웨어 저장소는 CI&CD 스크립트와 구성 파일을 저장할 때 선호하는 위치이다. 그렇다. 많은 CI/CD 플랫폼이 스크립트와 기타 파일을 내부에 저장할 수 있지만 일반적으로 도구 외부의 버전 컨트롤이 좀 더 나은 저장 위치다.

거의 모든 CI/CD 도구가 깃(Git)과 상호작용할 수 있다. 일부는 깃허브(GitHub), 깃허브 엔터프라이즈(GitHub Enterprise), 깃랩(GitLab), 비트버켓(Bitbucket) 등과 직접 통합된다. 서브버전(Subversion) 또는 머큐리얼(Mercurial)을 지원하는 것들도 있다.

CI/CD 도구 차원에서 프로그래밍 언어와 도구를 지원해야 한다
각 프로그래밍 언어 또는 언어 그룹(JVM 언어, LLVM 컴파일 언어, .NET 언어 등)에는 자체적인 빌드 도구와 테스트 도구가 있는 경향이 있다. CI/CD 도구가 유용하려면 특정 프로젝트에 포함된 모든 언어를 지원해야 한다. 그렇지 않으면 해당 도구를 위해 1개 이상의 플러그인을 작성해야 할 수도 있다.

오늘날 도커(Docker) 이미지가 분산된 모듈식 마이크로서비스 소프트웨어 배치에 점차 중요해지고 있다. CI/CD 도구가 소스 코드, 바이너리(Binary), 전제 조건으로부터 이미지 생성하기 및 특정 환경에 이미지 배치하기 등 도커 이미지를 처리하는 방법과 친숙한 경우 많은 도움이 된다. 

다시 한번 말하지만, 이것이 없다면 필요한 도커 기능을 구현하기 위해 플러그인 또는 스크립트를 작성해야 할 수도 있다. 마찬가지로, CI/CD 도구는 쿠버네티스 및 환경에서 사용하는 기타 컨테이너 오케스트레이션(Orchestration) 시스템을 지원해야 한다.

CI/CD 및 도구에 대한 이해
CI 및 CD의 원칙은 명확해 보일 수 있지만 세부사항은 그렇지 않다. CI/CD 도구마다 지원 및 문서화 수준이 다르다. 일례로 젠킨스(Jenkins)의 경우 다양한 참고 서적이 존재한다. 다른 제품의 경우, 도구 선택 시 상당한 주의의 일환으로 문서화 지원 포럼 및 유료 지원 옵션을 조사해야 할 수 있다.

CI에 관한 일반적인 배경지식은 듀밸(Duvall at al)이 저술한 애디슨 웨슬리(Addison-Wesley) 서적 ‘지속적 통합(Continuous Integration)’을 고려할 만하다. 마찬가지로, CD에 대한 일반적인 배경지식은 험블(Humble)과 팔리(Farley)가 저술한 ‘지속적 전달(Continuous Delivery)’에서 확인할 수 있다. 두 서적은 출판 당시 졸트상(Jolt Award)을 수상했다.

프로젝트마다 다른 CI/CD 도구를 선택할 수 있다
본 가이드의 핵심은 CI/CD 플랫폼 선택이지만 하나의 플랫폼이 모든 소프트웨어 개발 프로젝트에 최적이라고 가정해서는 안 된다. 대부분은 다수의 프로그래밍 언어와 환경을 사용하며, 모든 CI/CD 플랫폼이 그 모두를 지원하지는 않는다.

하나의 타협한 플랫폼을 찾는 대신에 각 프로젝트에 가장 적합한 CI/CD 플랫폼을 자유롭게 선택할 수도 있다. CI와 CD의 일반적인 원칙은 플랫폼마다 비슷하지만 자신이 작성한 스크립트를 항상 적용하지 못할 수 있다. 각 새로운 플랫폼의 추가적인 온보딩 시간 때문에 데브옵스 팀이 시간을 소요할 수 있지만 CI/CD 도구를 광범위하게 사용자 정의하는 것보다 비용이 낮을 가능성이 높다.

미래의 CI/CD 마이그레이션을 위한 계획을 수립
같은 방식으로, 특정 CI/CD 플랫폼이 프로젝트의 요구를 영원히 충족할 것이라고 가정해서는 안 된다. CI/CD 도구 내부가 아니라 저장소에 스크립트에 저장하는 등의 방법을 통해 항상 대비할 필요가 있다.

적절한 경우라면 서버리스(Serverless) CI/CD를 선택하라
일반적으로 클라우드 컨테이너 배치는 클라우드 서버 인스턴스 배치보다 비용이 낮으며, 서버리스 클라우드 배치는 컨테이너 배치보다 비용이 낮다. 안타깝게도, 현재 서버리스로 구동할 수 있는 CI/CD 플랫폼은 거의 없다.

서버리스란 해당 프로세스를 구동하는 컨테이너가 일반적으로 필요에 따라 (이벤트에 대응하여) 인스턴스화 되는 것을 의미한다. CI/CD의 경우, 트리거 이벤트는 특정 저장소 브랜치에 대한 코드 체크인이다. 그리고 저장소 웹훅(Webhook)이 서버리스 프로세스를 실행한다. 프로세스가 완료되면 리소스가 해제된다.

서버리스로 구동할 수 있는 몇 안 되는 CI/CD 플랫폼 중 하나가 서버리스 CI/CD(Serverless CI/CD)이며, 서버리스 프레임워크 프로(Serverless Framework Pro)에 포함되어 있다. 이는 오픈소스 서버리스 프레임워크(Serverless Framework)의 개선된 버전이다. 서버리스 CI/CD는 서버리스 앱 배치에 최적화되어 있으며 현재 AWS에서만 구동한다. 

기존의 클라우드 자산은 어디에 있는가?
클라우드 기반 CI/CD 구성(또는 기타 클라우드 애플리케이션)을 최적화하기 위해 모든 자산이 서로 ‘가까이’ 있다면 도움이 된다. 여기서 ‘가까이’는 지리적 위치와 네트워크 위치 모두를 의미한다.

예를 들어, 데이터베이스가 호주에 있고 애플리케이션이 북미에 있는 경우 애플리케이션이 데이터를 읽거나 써야 할 때마다 큰 랙이 발생할 것이다. 작은 규모에서 애플리케이션과 데이터베이스가 같은 가용성 구역(AZ)에 있는 경우 둘 사이의 지연 속도가 최소화될 것이다. 같은 지역의 다른 시간대에 있는 경우 지연 속도가 높아지겠지만 다른 지역에 있는 것만큼 높지는 않을 것이다.

마찬가지로, 데이터베이스가 버지니아의 구글 클라우드 플랫폼(Google Cloud Platform)에 있고 애플리케이션이 버지니아의 마이크로소프트 애저(Microsoft Azure)에 있는 경우 지연 속도는 둘 다 같은 AZ의 같은 클라우드 제공자에 있는 것보다 높을 것이다. 

이 모든 것들이 저장소(기본적으로 데이터베이스), CI/CD 소프트웨어, 실제 애플리케이션, 개발자와 테스터에도 적용된다. 모두가 ‘가까이’ 있는 경우 도움이 되지만 랙의 영향이 실시간 양방향 게임에서만큼 노골적이지 않다.

개발자가 신뢰할 수 있는 방식으로 눈에 띄는 대기 시간 없이 코드 커밋(Code Commit)을 마스터 저장소로 푸시할 수 있는 경우 만족할 것이다. 마찬가지로, 사용자와 테스터도 애플리케이션과 충분히 ‘가까이’ 있어 1초 미만의 응답시간이 확보되는 경우 만족할 것이다. CI/CD 소프트웨어의 경우 핵심은 배치 지점에 대한 신뢰할 수 있는 연결이다. 시간 초과 또는 패킷 드롭(Drop)을 유발하지 않는 한 약간의 랙은 용인될 수 있다.

클라우드 CI/CD 제품
놀랍도록 많은 수의 클라우드 기반 CI/CD 서비스가 이미 있다. 필자는 여기에서 14개의 클라우드 CI/CD 제품 제공업체를 예로 들었다. 이 목록에 포함되어 있다고 해서 추천하는 것이 아니며 포함되어 있지 않다고 해서 비난하는 것도 아니다.

AWS 코드파이프라인(CodePipeline)
AWS 코드파이프라인은 완전 관리형 지속적 전달 서비스이며, 빠르고 신뢰할 수 있는 애플리케이션 및 인프라 업데이트를 위해 릴리즈 파이프라인을 자동화하는 데 도움이 된다. 코드파이프라인은 정의한 릴리즈 모델에 따라 코드 변경이 있을 때마다 릴리즈 프로세스의 빌드, 테스트, 배치 단계를 자동화한다. 이를 통해 기능과 업데이트를 신속하고 신뢰할 수 있는 방식으로 제공할 수 있다. AWS 코드파이프라인과 깃허브 등의 제3자 서비스 또는 자신만의 사용자 정의 플러그인을 손쉽게 통합할 수 있다.

애저 데브옵스(Azure DevOps)
애저 데브옵스는 팀이 작업을 계획하고 코드 개발을 위해 협업하며 애플리케이션을 개발 및 배치하는 데 도움이 되는 개발자 서비스를 제공한다. ADOS(Azure DevOps Services)를 사용하여 클라우드로 또는 ADOS(Azure DevOps Server)를 사용하여 온프레미스로 작업할 수 있다. 

애저 데브옵스는 웹 브라우저 또는 IDE 클라이언트를 통해 액세스할 수 있는 통합된 기능을 제공한다. 애저 파이프라인은 지속적 통합과 전달을 지원하는 빌드 및 릴리즈 서비스를 제공한다. 기타 단독형 서비스로는 애저 레포스(Azure Repos, 깃 및 팀 파운데이션(Team Foundation) 소스 관리), 애자일 보드(Agile Boards, 애자일 도구 스위트), 애저 테스트 플랜스(Azure Test Plans, 수동/탐구 테스트 및 연속 테스트용 도구), 애저 아티팩트(Azure Artifacts, 팀이 공개 및 비공개 레지스트리의 패키지를 공유할 수 있음) 등이 있다.

비트버킷 클라우드(Bitbucket Cloud)
아틀라시안(Atlassian)의 비트버킷 클라우드는 깃 코드 호스팅과 호스 관리 및 내장된 CI/CD 솔루션을 비트버켓 파이프라인(Bitbucket Pipelines)으로 결합한다. 또한, 아틀라시안의 지라(Jira, 기능 및 이슈 추적) 및 트렐로(Trello, 칸반(Kanban) 스타일 프로젝트 관리)와의 통합을 제공하여 개발 팀이 한 곳에서 프로젝트를 계획하고 코드를 위해 협업하며 테스트하고 배치할 수 있다.

비트라이즈(Bitrise)
비트라이즈는 모바일 애플리케이션 개발자를 위한 데브옵스 겸 CI/CD 플랫폼이다. 스위프트(Swift), 오브젝티브 C(Objective-C), 자바(Java), 코틀린(Kotlin), 코도바(Cordova), 아이오닉(Ionic), 리액트 네이티브(React Native), 플러터(Flutter) 등 광범위한 모바일 기술을 지원한다. 비트라이즈와 깃허브, 깃랩, 비트버켓, 기타 깃 소스 컨트롤 서비스를 클라우드와 온프레미스로 통합할 수 있다. 

비트라이즈는 ‘하드웨어 없이 모든 플랫폼을 위한 클라우드에 있는 완전한 기능을 갖춘 모바일 CI/CD’로 홍보되고 있다. 즉, 빌드가 리눅스 기기에서 구동하는 것 외에 무료 사용자 및 오픈 소스 프로젝트를 위한 것들을 포함하여 맥OS 빌드도 모든 요금제에 완벽하게 포함되어 있음을 의미한다.

써클CI(CircleCI)
써클CI는 클라우드 기반 및 온프레미스의 여러 환경에서 빌드를 자동화할 수 있으며, 깃랩, 깃허브, 비트버켓과 통합하며 AWS, 애저, 구글 클라우드부터 아티팩토리(Artifactory)와 npm까지 광범위한 대상에 배치된다. 수천 개의 기존 통합 중에서 선택하거나 자신만의 것을 생성하고 빠른 속도를 위해 빌드를 최적화하며 작업을 병렬로 실행할 수 있고 프로젝트가 안전하게 개발, 배치, 유지관리 되도록 할 수 있다. 빌드 환경으로는 도커, 리눅스(안드로이드 에뮬레이터 포함), 맥OS, 윈도우, GPU, 암(Arm)이 있다.

클라우드비스(CloudBees)
클라우드비스는 소프트웨어 개발 팀에 젠킨스 기반 CI/CD, 릴리즈 오케스트레이션, 기능 관리, 가치 흐름 관리 기능을 제공한다. 위험 완화, 준법감시, 거버넌스 기능을 통한 관리를 제공하는 대형 준법감시 우선 조직을 위한 소프트웨어 제공 자동화 솔루션이다. 클라우드비스 플랫폼은 조직이 셀프 서비스 고속 보안 워크플로를 생성하고 소프트웨어 제공을 비즈니스 결과에 연계할 수 있는 도구를 제공한다.

코드프레시(Codefresh)
코드프레시는 아르고(Argo) 기반의 쿠버네티스용 소프트웨어 제공 플랫폼이며, 코드형 인프라가 저장소에 버전화 되어 있는 깃옵스(GitOps) 모델을 사용한다. 코드프레시는 아르고 CD(Argo CD), 아르고 워크플로(Argo Workflows), 아르고 이벤트(Argo Events), 아르고 롤아웃(Argo Rollouts)을 사용하며, 기업 배치를 위한 필수 기능으로 확장된다. 코드프레시는 개발자, 운영자, 제품 소유자, 프로젝트 관리자 등 모든 이해관계자를 위한 보안, 유지관리성, 추적성, 단일 관리창을 제공한다. 코드프레시는 깃허브, 깃랩, 비트버켓을 지원한다.

깃허브 액션(GitHub Actions)
깃허브 액션은 깃허브 호스팅 연속 통합 및 지속적 전달 플랫폼이며, 빌드, 테스트, 배치 파이프라인을 자동화할 수 있다. 저장소에 대한 모든 풀(Pull) 요청을 빌드 및 테스트하는 워크플로를 생성하거나 생산을 위한 병합된 풀 요청을 배치할 수 있다. 

깃허브 액션을 통해 저장소에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있다(예를 들어, 워크플로를 실행하여 누군가 저장소에서 새 이슈를 생성할 때마다 적절한 라벨을 자동으로 추가할 수 있다). 깃허브는 워크플로를 실행할 리눅스, 윈도우, 맥OS 가상 머신을 제공하며, 셀프 호스팅 러너(Runner)를 사용하여 클라우드 또는 온프레미스로 자신만의 VM을 구동할 수 있다. 깃허브 액션은 Node.js, 파이썬(Python), 자바, 루비(Ruby), PHP, 고(Go), 러스트(Rust), .NET, 스위프트(Swift)를 지원한다.

깃랩 CI/CD(GitLab CI/CD)
깃랩 CI/CD는 모든 지속적 기법(지속적 통합, 지속적 전달, 지속적 배치)에 사용할 수 있는 깃랩의 일부분이다. 깃랩 CI/CD를 통해 제3자 애플리케이션 또는 통합없이 애플리케이션을 개발, 테스트, 배치, 모니터링할 수 있다. 

깃랩은 애플리케이션을 개발하고 테스트하기 위해 자동으로 프로그래밍 언어를 감지하고 CI/CD 템플릿을 사용하여 기본 파이프라인을 생성 및 구동한다. 그리고 앱을 스테이징(Staging) 및 생산에 배치하기 위해 배치를 구성할 수 있으며, 리뷰 앱(Review Apps)을 구성하여 브랜치당 변경사항을 미리보기 할 수 있다. 따라서 깃랩 CI/CD는 개발 사이클 초기 단계에 버그와 오류를 잡고 생산에 배치된 모든 코드가 앱을 위해 수립한 코드 표준을 준수하도록 하는 데 도움이 된다.

구글 클라우드 빌드(Google Cloud Build)
구글 클라우드 빌드는 클라우드 호스팅 완전 관리형 CI/CD 플랫폼이다. 구글 클라우드, 기타 퍼블릭 클라우드, 온프레미스 시스템에서 또는 엄격하게 자체 사설 네트워크 내부에서 빌드를 구동할 수 있다. 배치를 자동화하기 위해 빌드 단계의 일환으로써 파이프라인을 생성하고 내장된 통합 기능을 사용하여 구글 쿠버네티스 엔진(Google Kubernetes Engine), 구글 앱 엔진(Google App Engine), 구글 클라우드 펑션(Google Cloud Function), 구글 파이어베이스(Google Firebase)를 사용하여 배치할 수 있다. 트리거를 구성하여 깃허브, 구글 클라우드 소스 리포지토리(Google Cloud Source Repositories), 비트버켓 저장소로 변경사항을 푸시 할 때 소스 코드를 자동으로 빌드, 테스트, 배치할 수 있다. 복잡한 파이프라인 생성 및 실행을 위해 클라우드 빌드와 스핀네이커(Spinnaker)를 함께 사용할 수 있다.

IBM CCD(IBM Cloud Continuous Delivery)
IBM CCD는 소프트웨어 제공을 위한 툴체인(Toolchain), 파이프라인, 도구 통합을 제공한다. 개발과 운영을 반복 가능하고 더 쉽게 관리할 수 있는 IBM 서비스, 오픈 소스 도구, 제3자 도구가 포함된 툴체인을 생성할 수 있다. 테크톤(Tekton) 기반 제공 파이프라인을 활용함으로써 최소한의 인간 개입으로 반복 가능한 방식으로 빌드, 테스트, 배치할 수 있다. 깃 저장소를 사용하여 소스 코드를 관리하고 작업을 추적하며 IBM이 호스팅하며 깃랩 커뮤니티 에디션(GitLab Community Edition)을 기반으로 개발된 이슈 추적을 관리할 수 있다. 

그리고 IBM, 오픈소스, 제3자 도구가 포함된 공유 가능하고 사용자 정의 가능한 템플릿을 사용하여 데브섹옵스(DevSecOps)를 위한 툴체인 및 쿠버네티스, 클라우드 파운드리(Cloud Foundry), VM 등에 대한 배치를 신속하게 제공할 수 있다.

스핀네이커(Spinnaker)
스핀네이커는 높은 속도와 신뢰감으로 소프트웨어 변경사항을 제공하는 데 도움이 되도록 고안된 오픈소스 멀티 클라우드 지속적 전달 플랫폼이다. 스핀네이커는 클라우드 리소스를 확인 및 관리할 수 있는 애플리케이션 관리 기능과 지속적 전달 워크플로를 구성 및 관리할 수 있는 애플리케이션 배치 기능을 결합한다. 성숙하고 널리 생산 준비된 지속적 전달 플랫폼인 스핀네이커는 넷플릭스(Netflix), 구글, 마이크로소프트, 아마존의 전문 지식을 소프트웨어 개발 라이프 사이클에 적용할 수 있다.

팀시티(TeamCity)
팀시티는 온갖 종류의 워크플로와 개발 활동을 위한 유연성을 가능하게 하는 제트브레인스(JetBrains)의 범용 CI/CD 솔루션이다. 

팀시티를 통해 코틀린(Kotlin)을 사용하여 CI/CD 구성을 작성할 수 있으며, 완전한 기능을 갖춘 프로그래밍 언어와 툴셋을 활용할 수 있다. 팀시티는 깃뿐 아니라 모든 버전 관리 시스템과 통합되어 있다. 자바, .NET, 파이썬, 루비, X코드(Xcode), 기타 언어를 플러그인을 통해 네이티브로 지원한다. 또한 팀시티는 도커, 유트랙(YouTrack), 지라, 버그질라(Bugzilla), 메이븐(Maven), VSTS(Visual Studio Team Services), 너겟(NuGet)과 통합되어 있다.

트래비스 CI(Travis CI)
트래비스 CI는 연속 통합 및 배치 도구이며 빌드, 테스트, 배치를 위한 유연한 자동화를 제공한다. 코드 변경사항을 자동으로 빌드 및 테스트하는 것 외에 트래비스 CI는 배치 및 알림을 관리하여 개발 프로세스의 다른 부분을 자동화할 수 있다. 

즉, 빌드 스테이지(Build Stages)를 사용하여 작업들이 서로 의존하도록 하고 알림을 구성하며 빌드 후 배치를 준비하고 다른 많은 작업을 수행할 수 있다. 트래비스 CI는 오픈 소스 프로젝트에 무료로 서비스를 제공하는 최초의 CI 서비스였으며 계속 그렇게 하고 있다. 트래비스 CI는 어셈블라(Assembla), 비트버켓, 깃허브, 깃랩, 30개 이상의 프로그래밍 언어를 지원한다.

실행 전 개념 증명을 수행하라
CI/CD를 완전히 구현하면 인프라의 중요한 부분이 될 것이다. 속도를 향상되는 과정에서 이 점을 기억할 필요가 있다.

CI/CD 파이프라인을 롤아웃하기 시작하기 전에 엄격한 개념 증명을 수행하는 것이 중요하다. CD 단계를 시작하기 전에 CI 부분을 확실하게 한다. CI/CD 파이프라인을 생산 인스턴스에 연결하기 전에 테스트 스위트와 롤백 기능을 활용하고, 자동화가 확실히 안정화되었다는 확신이 들 때까지 인간의 개입을 유지하도록 한다.

* 인포월드 기고 편집자이자 리뷰어인 Martin Heller는 웹 및 윈도우 프로그래밍 컨설턴트 경력을 보유자다. 1986년부터 2010년까지는 데이터베이스, 소프트웨어, 웹사이트 개발자로 일했으며 그 이후에는 알파 소프트웨어의 기술 및 교육 부사장, 튜브파이의 의장이자 CEO를 역임했다. dl-ciokorea@foundryco.com