2021.06.14

클라우드 기반 CI/CD 플랫폼 선택법

Martin Heller | InfoWorld
빠른 소프트웨어 개발과 잦은 프로덕션 빌드 배포가 목표라면 테스트 및 제공 프로세스의 적어도 일부라도 자동화해야 한다. 이상적으로 이는 프로젝트를 위한 CI/CD 파이프라인, 고객이 소프트웨어를 접하기 전에 오류를 포착하기 위한 테스트 모음, 그리고 파이프라인의 각 단계를 구현하는 스크립트를 구현한다는 것을 의미한다. 
 
ⓒ Getty Images Bank

지속적 통합(CI)은 소프트웨어 빌드와 패키징, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 개발팀이 소스 코드 버전 제어에 체크인하는 변경 사항이 빌드의 작동을 중단시키거나 소프트웨어에 버그를 유입시키지 않는다는 어느 정도의 확신을 얻는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 체크인이다. 

지속적 제공(CD)은 테스트된 소프트웨어를 인프라 환경에 전달하는 과정을 자동화한다. 물론 프로덕션에 바로 던져 넣어 고객이 불평하는지 여부를 살피는 것을 의미하지는 않는다. 일반적으로 조직은 먼저 개발 환경으로 빌드를 푸시한다. 개발자 스스로 새 빌드를 살펴보고 릴리스하면 다음은 보통 테스트 환경으로 넘어간다. 테스트 환경에서는 더 폭넓은 사용자 그룹에 의해 사용되고(전담 내부 테스터들로 구성될 수도 있고, 베타 테스트나 내부 시험(dog-fooding)에 등록한 사용자 그룹인 경우도 있음) 면밀하게 모니터링된다. 아무 문제가 없으면 마지막으로 테스터들이 새 버전을 승인하고 프로덕션 환경으로 보낸다. 

CD의 각 단계에는 이전 빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결해야 할 버그 보고서 티켓을 생성하는 옵션이 있다. 목표는 프로덕션으로 많은 수의 빌드를 푸시하는 것이 아니라 퇴행 없이 지속적으로 소프트웨어를 개선 및 향상하는 것이다. 이 방식을 지칭하는 또 다른 용어가 “데브옵스”다.  
 

클라우드에 CI/CD를 호스팅하는 이유 

자체 데이터센터에 CI/CD 플랫폼을 호스팅하는 방법은 특히 방화벽 안에 애플리케이션과 데이터를 호스팅할 것을 의무화하는 기업에서 사용 가능한 옵션이다. 이 경우의 단점은 인프라를 유지보수할 전담팀이 필요하며 서버에 대한 어느 정도의 설비 투자가 발생한다는 점이다. 

클라우드에 호스팅할 수 있다면 일반적으로는 그 방법이 더 낫다. 클라우드에 호스팅하는 비용은 크지 않고, 운영비는 제공되는 서비스(온보딩, 인프라 유지보수, 보안 유지보수, 지원, CI/CD 소프트웨어 유지보수)로 상쇄된다. CI/CD 소프트웨어를 클라우드에 호스팅하고 소스 코드 리포지토리도 클라우드에 호스팅된다면, 파이프라인에서 소스 코드 리포지토리와의 상호작용이 더 쉽고 빨라진다. 개발자 및 테스터가 지리적으로 분산되어 있는 경우, 리포지토리를 클라우드에 호스팅하면 방화벽 뒤의 원격 서버에 호스팅하는 경우에 비해 개발자에게 더 원활한 환경을 제공할 수 있다. 

CI/CD를 온프레미스와 클라우드 서버의 하이브리드에 배포하는 것도 가능하다. 여러 최신 CI/CD가 쿠버네티스 클러스터의 컨테이너에서 실행되며, 온프레미스와 클라우드에서도 마찬가지로 원활하게 실행된다. 하이브리드 배포 시나리오에서는 개발자 자신의 물리적인 위치와 개발 인프라에 있는 다른 서버의 네트워크 위치 등 각 구성요소를 가장 적합한 곳에 배치할 수 있다. 
 

CI/CD와 리포지토리의 통합 

앞서 “CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 완성된 체크인”이라고 강조했듯이, 리포지토리는 CI와 CD에 필수적이다. 소프트웨어 리포지토리는 체크인과 테스트 프로세스의 종점이기도 하지만 CI 및 CD 스크립트와 구성 파일을 저장하는 용도로도 많이 사용된다. 물론 많은 CI/CD 플랫폼이 스크립트 및 기타 파일을 내부적으로 저장할 수 있지만 일반적으로는 툴 외부의 버전 제어에 두는 편이 더 낫다. 

거의 모든 CI/CD 툴이 깃(Git)과 상호적용이 가능하다. 일부는 깃허브(GitHub), 깃허브 엔터프라이즈, 깃랩(GitLab) 또는 비트버킷(Bitbucket)과 직접 통합된다. 서브버전(Subversion) 및 머큐리얼(Mercurial)를 지원하는 툴도 소수 있다. 
 

CI/CD 툴이 현재의 프로그래밍 언어와 툴을 지원해야 함 

각 프로그래밍 언어 또는 언어 그룹(JVM 언어, LLVM 컴파일 언어, 닷넷 언어 등)에는 보통 자체 빌드 툴과 테스트 툴이 있다. CI/CD 툴이 유용성을 가지려면 해당 프로젝트에 속하는 모든 언어를 지원해야 한다. 그렇지 않은 경우 툴을 위해 하나 또는 그 이상의 플러그인을 만들어야 할 수 있다. 

도커 이미지는 분산 모듈형 및 마이크로서비스 소프트웨어 배포에서 점점 더 중요해지고 있다. 소스 코드, 바이너리, 전제 조건으로부터 이미지를 생성하고 특정 환경에 이미지를 배포하는 등 도커 이미지를 어떻게 처리해야 하는지를 CI/CD 툴이 알면 도움이 된다. 마찬가지로 이 기능이 없으면 플러그인 또는 스크립트를 직접 작성해서 필요한 도커 기능을 구현해야 할 수 있다. CI/CD 툴이 쿠버네티스와 현재 환경에서 사용 중인 기타 컨테이너 오케스트레이션 시스템을 지원하는 편이 좋다. 
 

현재 고려 중인 CI/CD와 툴을 개발자가 이해하는가? 

CI 및 CD의 원칙은 명확하지만 세부 사항은 그렇지 않다. CI/CD 툴은 다양하고, 저마다 지원과 문서화 수준도 다르다. 젠킨스(Jenkins)에 관해서는 여러 권의 책이 있는데, 젠킨스가 가장 오래된 툴임을 감안하면 당연한 일이다. 다른 제품의 경우 선택 과정에서 문서와 지원 포럼, 유료 지원 옵션을 잘 살펴봐야 한다.  
 

프로젝트마다 다른 CI/CD 툴 선택 가능 

이 가이드의 주제는 CI/CD 플랫폼 선택이지만, 한 가지 플랫폼이 모든 소프트웨어 개발 프로젝트에 최적일 것이라고 기대해서는 안 된다. 대부분 기업은 여러 프로그래밍 언어와 환경을 사용하는데, 모든 CI/CD 플랫폼이 사용 중인 모든 언어와 환경을 지원하지는 않는다. 




2021.06.14

클라우드 기반 CI/CD 플랫폼 선택법

Martin Heller | InfoWorld
빠른 소프트웨어 개발과 잦은 프로덕션 빌드 배포가 목표라면 테스트 및 제공 프로세스의 적어도 일부라도 자동화해야 한다. 이상적으로 이는 프로젝트를 위한 CI/CD 파이프라인, 고객이 소프트웨어를 접하기 전에 오류를 포착하기 위한 테스트 모음, 그리고 파이프라인의 각 단계를 구현하는 스크립트를 구현한다는 것을 의미한다. 
 
ⓒ Getty Images Bank

지속적 통합(CI)은 소프트웨어 빌드와 패키징, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 개발팀이 소스 코드 버전 제어에 체크인하는 변경 사항이 빌드의 작동을 중단시키거나 소프트웨어에 버그를 유입시키지 않는다는 어느 정도의 확신을 얻는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 체크인이다. 

지속적 제공(CD)은 테스트된 소프트웨어를 인프라 환경에 전달하는 과정을 자동화한다. 물론 프로덕션에 바로 던져 넣어 고객이 불평하는지 여부를 살피는 것을 의미하지는 않는다. 일반적으로 조직은 먼저 개발 환경으로 빌드를 푸시한다. 개발자 스스로 새 빌드를 살펴보고 릴리스하면 다음은 보통 테스트 환경으로 넘어간다. 테스트 환경에서는 더 폭넓은 사용자 그룹에 의해 사용되고(전담 내부 테스터들로 구성될 수도 있고, 베타 테스트나 내부 시험(dog-fooding)에 등록한 사용자 그룹인 경우도 있음) 면밀하게 모니터링된다. 아무 문제가 없으면 마지막으로 테스터들이 새 버전을 승인하고 프로덕션 환경으로 보낸다. 

CD의 각 단계에는 이전 빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결해야 할 버그 보고서 티켓을 생성하는 옵션이 있다. 목표는 프로덕션으로 많은 수의 빌드를 푸시하는 것이 아니라 퇴행 없이 지속적으로 소프트웨어를 개선 및 향상하는 것이다. 이 방식을 지칭하는 또 다른 용어가 “데브옵스”다.  
 

클라우드에 CI/CD를 호스팅하는 이유 

자체 데이터센터에 CI/CD 플랫폼을 호스팅하는 방법은 특히 방화벽 안에 애플리케이션과 데이터를 호스팅할 것을 의무화하는 기업에서 사용 가능한 옵션이다. 이 경우의 단점은 인프라를 유지보수할 전담팀이 필요하며 서버에 대한 어느 정도의 설비 투자가 발생한다는 점이다. 

클라우드에 호스팅할 수 있다면 일반적으로는 그 방법이 더 낫다. 클라우드에 호스팅하는 비용은 크지 않고, 운영비는 제공되는 서비스(온보딩, 인프라 유지보수, 보안 유지보수, 지원, CI/CD 소프트웨어 유지보수)로 상쇄된다. CI/CD 소프트웨어를 클라우드에 호스팅하고 소스 코드 리포지토리도 클라우드에 호스팅된다면, 파이프라인에서 소스 코드 리포지토리와의 상호작용이 더 쉽고 빨라진다. 개발자 및 테스터가 지리적으로 분산되어 있는 경우, 리포지토리를 클라우드에 호스팅하면 방화벽 뒤의 원격 서버에 호스팅하는 경우에 비해 개발자에게 더 원활한 환경을 제공할 수 있다. 

CI/CD를 온프레미스와 클라우드 서버의 하이브리드에 배포하는 것도 가능하다. 여러 최신 CI/CD가 쿠버네티스 클러스터의 컨테이너에서 실행되며, 온프레미스와 클라우드에서도 마찬가지로 원활하게 실행된다. 하이브리드 배포 시나리오에서는 개발자 자신의 물리적인 위치와 개발 인프라에 있는 다른 서버의 네트워크 위치 등 각 구성요소를 가장 적합한 곳에 배치할 수 있다. 
 

CI/CD와 리포지토리의 통합 

앞서 “CI의 종점은 일반적으로 소프트웨어 리포지토리의 주 분기에 대한 완성된 체크인”이라고 강조했듯이, 리포지토리는 CI와 CD에 필수적이다. 소프트웨어 리포지토리는 체크인과 테스트 프로세스의 종점이기도 하지만 CI 및 CD 스크립트와 구성 파일을 저장하는 용도로도 많이 사용된다. 물론 많은 CI/CD 플랫폼이 스크립트 및 기타 파일을 내부적으로 저장할 수 있지만 일반적으로는 툴 외부의 버전 제어에 두는 편이 더 낫다. 

거의 모든 CI/CD 툴이 깃(Git)과 상호적용이 가능하다. 일부는 깃허브(GitHub), 깃허브 엔터프라이즈, 깃랩(GitLab) 또는 비트버킷(Bitbucket)과 직접 통합된다. 서브버전(Subversion) 및 머큐리얼(Mercurial)를 지원하는 툴도 소수 있다. 
 

CI/CD 툴이 현재의 프로그래밍 언어와 툴을 지원해야 함 

각 프로그래밍 언어 또는 언어 그룹(JVM 언어, LLVM 컴파일 언어, 닷넷 언어 등)에는 보통 자체 빌드 툴과 테스트 툴이 있다. CI/CD 툴이 유용성을 가지려면 해당 프로젝트에 속하는 모든 언어를 지원해야 한다. 그렇지 않은 경우 툴을 위해 하나 또는 그 이상의 플러그인을 만들어야 할 수 있다. 

도커 이미지는 분산 모듈형 및 마이크로서비스 소프트웨어 배포에서 점점 더 중요해지고 있다. 소스 코드, 바이너리, 전제 조건으로부터 이미지를 생성하고 특정 환경에 이미지를 배포하는 등 도커 이미지를 어떻게 처리해야 하는지를 CI/CD 툴이 알면 도움이 된다. 마찬가지로 이 기능이 없으면 플러그인 또는 스크립트를 직접 작성해서 필요한 도커 기능을 구현해야 할 수 있다. CI/CD 툴이 쿠버네티스와 현재 환경에서 사용 중인 기타 컨테이너 오케스트레이션 시스템을 지원하는 편이 좋다. 
 

현재 고려 중인 CI/CD와 툴을 개발자가 이해하는가? 

CI 및 CD의 원칙은 명확하지만 세부 사항은 그렇지 않다. CI/CD 툴은 다양하고, 저마다 지원과 문서화 수준도 다르다. 젠킨스(Jenkins)에 관해서는 여러 권의 책이 있는데, 젠킨스가 가장 오래된 툴임을 감안하면 당연한 일이다. 다른 제품의 경우 선택 과정에서 문서와 지원 포럼, 유료 지원 옵션을 잘 살펴봐야 한다.  
 

프로젝트마다 다른 CI/CD 툴 선택 가능 

이 가이드의 주제는 CI/CD 플랫폼 선택이지만, 한 가지 플랫폼이 모든 소프트웨어 개발 프로젝트에 최적일 것이라고 기대해서는 안 된다. 대부분 기업은 여러 프로그래밍 언어와 환경을 사용하는데, 모든 CI/CD 플랫폼이 사용 중인 모든 언어와 환경을 지원하지는 않는다. 


X