2019.03.22

서비스로서의 CI/CD : 클라우드의 지속적 통합과 제공을 위한 10가지 툴

Peter Wayner | InfoWorld

클라우드와 지속적 통합(Continuous Integration, CI)은 잘 맞는 한 쌍이다. 클라우드는 물리 서버를 설치하고 유지보수하는 고통을 없애고, CI는 코드를 빌드, 테스트, 배포하는 데 따르는 힘든 작업의 대부분을 자동화한다. 두 가지 기술 모두 개발 팀이 짊어지는 부담을 덜어주는 데 목표를 두니, 둘을 결합해서 더 많은 단순 작업을 없앨 수 있다면 금상첨화일 것이다.

CI 서비스는 숫자도 많고 적어도 추상적 관점에서는 기능도 대부분 동일하다. CI 서비스에서 가장 먼저 하는 일은 사용자가 개발한 새로운 소프트웨어의 뛰어남을 온 세상에 알리기 전에 해야 할 일, 즉 컴파일, 테스트와 같은 작업을 목록화하는 것이다. 코드를 작성해서 커밋하면 툴이 체크리스트에 따라 장애물이 있는지 여부를 살핀다. 장애물이 없다면 최상이다.
 

ⓒGettyImagesBank



누구나 소프트웨어 개발 프로젝트에서 CI를 사용할 수 있지만, 가장 큰 이득을 얻는 쪽은 팀, 주로 상호 연계되는 코드 블록으로 작업하는 대규모 팀이다. 철저한 CI 구현은 빌드와 테스트를 계속 반복하면서 여러 팀원이 각자의 코드를 체크인하는 과정에서 발생했을지도 모를 새로운 오류와 비호환성을 찾는다. 지속적 통합 서버는 모든 프로그래머의 작업을 동기화하고 문제를 발견하도록 돕는다.

테스트를 CI 서버 작업 목록의 마지막 요소로 보는 시각도 있지만, 최근에는 신규 코드 배포, 즉 “지속적 배포(Continuous Deployment)” 프로세스를 포함하도록 작업 목록을 확장하는 팀이 늘고 있다. 완전히 자동화된 배포에 안심하지 못하는 사람들은 프로세스에 몇 가지 수작업을 추가하는 경우가 많다. 책임 소재와 사람의 확인이 있어야만 안심이 되기 때문이다. 이러한 혼합적 접근 방식을 “지속적 제공(Continuous Delivery, CD)”이라고 지칭한다. 코드는 스테이징 또는 테스팅 클러스터로 전달된 후 거기서 사람이 프로덕션으로 푸시하는 최종 단계를 기다리게 된다.

서버룸에서 CI가 효과적이라면 더 빠른 제공 속도와 더 높은 효율성의 기회가 풍부한 클라우드에서는 당연히 더 유익할 것이다. 가장 좋은 점은 클라우드는 이 작업을 분할해서 병렬로 실행할 수 있다는 것이다. 서비스는 대규모 하드웨어 풀로 시작한 다음 이를 다수의 팀 사이에 공유한다. 모든 사용자가 각자의 코드를 동시에 푸시하지 않는 한 빌드와 테스트는 훨씬 더 빠른 속도로 실행된다. 개발자가 모든 테스트를 실행하는 짧은 순간을 위해 대형 하드웨어 랙을 구매하는 것은 비현실적이지만, 팀이 랙을 공유한다면 모두가 빨라진 속도를 즐길 수 있다.

다만 위험과 우려도 있으며 그 중 가장 큰 우려는 통제력 상실이다. 모든 클라우드 서비스에는 코드를 제 3자의 손에 맡긴다는 전제 조건이 있다. 이를 홀가분하게 받아들이는 사람도 있지만 두렵게 생각하는 사람도 있다. 모든 클라우드 서비스는 보안을 강조하지만, 코드가 자신의 통제 범위를 벗어날 때의 찜찜한 기분을 떨치기는 어렵다.

클라우드 서비스는 모든 주요 언어에 대한 폭넓은 지원 외에, 다양한 틈새 언어는 물론 희귀하다고 할 수 있는 언어까지 지원한다. 이는 개발자들의 노력보다는 처음 시작할 때 아키텍처와 관련하여 내린 현명한 의사 결정에 따른 결과라고 볼 수 있다. 작업 목록은 거의 항상 셸 또는 명령줄을 위한 명령으로 인코딩되므로 지속적 통합 툴은 작업 목록을 완료하거나 극복할 수 없는 장애물이 나타나기 전까지 계속 명령을 내린다. 자바와 같은 일부 언어는 더 정교한 옵션을 제공하지만 대부분의 경우 명령줄로 할 수 있는 일이라면 어느 것이든 이 툴로도 할 수 있다.

클라우드에서의 CI/CD를 구현하기 위한 10가지 선택안을 소개한다.
 

클라우드비즈(CloudBees)

클라우드비즈 코어(CloudBees Core)는 지속적 통합 분야에서 유명한 오픈소스 프로젝트인 젠킨스로 시작했으며, 이후 테스트, 지원과 코드 실행을 보장하는 몇 가지 확인 요소를 추가했다. 이 업체는 실험적인 플러그인은 모두 걸러내고 자체 플러그인 몇 가지를 더한 다음 완성도 높게 다듬어서 신뢰성을 확보했다.

클라우드비즈는 여전히 젠킨스 개발 팀의 80%를 보유하고 있으며, 이들이 오픈소스 프로젝트에 활발하게 코드를 기여하는 만큼 젠킨스에 대한 이해도가 높다고 볼 수 있다. 클라우드비즈는 속도를 높이기 위한 폭넓은 병렬화와 개발 프로세스를 추적하기 위한 계측 기능도 추가했다.

클라우드비즈는 무료 등급부터 1년 서비스가 포함된 “스타터 키트”까지 다양한 가격 옵션을 제공한다. 또한 툴 관련 도움은 필요하지만 클라우드 컴퓨팅을 원하지는 않는 사람들을 위해 젠킨스 지원도 따로 분리해 제공한다.

AWS 코드파이프라인(AWS CodePipeline)

아마존의 지속적 통합 및 배포 툴인 AWS 코드파이프라인은 코드 및 데이터의 방향에 대한 개방성을 유지하면서 AWS 서버에 코드를 제공하는 데 최적화됐다. 기본 툴은 주요 언어(자바, 파이썬, Node.js, 루비, 고, 안드로이드, 리눅스용 닷넷 코어)를 위한 사전 구성된 빌드 환경을 제공하며, 결과를 서버로 보내 실행하기 전에 S3 버킷에 집어넣는다.

이름이 조금씩 다른 계층이 상당히 많다. 코드빌드(CodeBuild)는 코드파이프라인으로 트리거될 때 코드커밋(CodeCommit)에서 최신 요소를 가져온 다음 그 결과를 코드디플로이(CodeDeploy)로 전달한다. 다뤄야 할 코드가 너무 많다고 느껴진다면 또다른 자동화 계층을 제공하는 코드스타(CodeStar)를 사용하면 된다. 모든 실수를 저절로 없애 주는 코드버그이레이저스타(CodeBugEraserStar)라는 이름의 계층도 있었으면 좋겠다는 생각이 든다. 주목할 점은 이러한 코드 계층에 대해서는 아무런 비용도 지불하지 않는다는 것이다. 아마존은 이 과정에서 사용된 컴퓨팅 및 스토리지 리소스에 대한 비용만 청구한다. 무료처럼 느껴지기만 할 뿐 엄밀히 말해 무료는 아니다.
 




2019.03.22

서비스로서의 CI/CD : 클라우드의 지속적 통합과 제공을 위한 10가지 툴

Peter Wayner | InfoWorld

클라우드와 지속적 통합(Continuous Integration, CI)은 잘 맞는 한 쌍이다. 클라우드는 물리 서버를 설치하고 유지보수하는 고통을 없애고, CI는 코드를 빌드, 테스트, 배포하는 데 따르는 힘든 작업의 대부분을 자동화한다. 두 가지 기술 모두 개발 팀이 짊어지는 부담을 덜어주는 데 목표를 두니, 둘을 결합해서 더 많은 단순 작업을 없앨 수 있다면 금상첨화일 것이다.

CI 서비스는 숫자도 많고 적어도 추상적 관점에서는 기능도 대부분 동일하다. CI 서비스에서 가장 먼저 하는 일은 사용자가 개발한 새로운 소프트웨어의 뛰어남을 온 세상에 알리기 전에 해야 할 일, 즉 컴파일, 테스트와 같은 작업을 목록화하는 것이다. 코드를 작성해서 커밋하면 툴이 체크리스트에 따라 장애물이 있는지 여부를 살핀다. 장애물이 없다면 최상이다.
 

ⓒGettyImagesBank



누구나 소프트웨어 개발 프로젝트에서 CI를 사용할 수 있지만, 가장 큰 이득을 얻는 쪽은 팀, 주로 상호 연계되는 코드 블록으로 작업하는 대규모 팀이다. 철저한 CI 구현은 빌드와 테스트를 계속 반복하면서 여러 팀원이 각자의 코드를 체크인하는 과정에서 발생했을지도 모를 새로운 오류와 비호환성을 찾는다. 지속적 통합 서버는 모든 프로그래머의 작업을 동기화하고 문제를 발견하도록 돕는다.

테스트를 CI 서버 작업 목록의 마지막 요소로 보는 시각도 있지만, 최근에는 신규 코드 배포, 즉 “지속적 배포(Continuous Deployment)” 프로세스를 포함하도록 작업 목록을 확장하는 팀이 늘고 있다. 완전히 자동화된 배포에 안심하지 못하는 사람들은 프로세스에 몇 가지 수작업을 추가하는 경우가 많다. 책임 소재와 사람의 확인이 있어야만 안심이 되기 때문이다. 이러한 혼합적 접근 방식을 “지속적 제공(Continuous Delivery, CD)”이라고 지칭한다. 코드는 스테이징 또는 테스팅 클러스터로 전달된 후 거기서 사람이 프로덕션으로 푸시하는 최종 단계를 기다리게 된다.

서버룸에서 CI가 효과적이라면 더 빠른 제공 속도와 더 높은 효율성의 기회가 풍부한 클라우드에서는 당연히 더 유익할 것이다. 가장 좋은 점은 클라우드는 이 작업을 분할해서 병렬로 실행할 수 있다는 것이다. 서비스는 대규모 하드웨어 풀로 시작한 다음 이를 다수의 팀 사이에 공유한다. 모든 사용자가 각자의 코드를 동시에 푸시하지 않는 한 빌드와 테스트는 훨씬 더 빠른 속도로 실행된다. 개발자가 모든 테스트를 실행하는 짧은 순간을 위해 대형 하드웨어 랙을 구매하는 것은 비현실적이지만, 팀이 랙을 공유한다면 모두가 빨라진 속도를 즐길 수 있다.

다만 위험과 우려도 있으며 그 중 가장 큰 우려는 통제력 상실이다. 모든 클라우드 서비스에는 코드를 제 3자의 손에 맡긴다는 전제 조건이 있다. 이를 홀가분하게 받아들이는 사람도 있지만 두렵게 생각하는 사람도 있다. 모든 클라우드 서비스는 보안을 강조하지만, 코드가 자신의 통제 범위를 벗어날 때의 찜찜한 기분을 떨치기는 어렵다.

클라우드 서비스는 모든 주요 언어에 대한 폭넓은 지원 외에, 다양한 틈새 언어는 물론 희귀하다고 할 수 있는 언어까지 지원한다. 이는 개발자들의 노력보다는 처음 시작할 때 아키텍처와 관련하여 내린 현명한 의사 결정에 따른 결과라고 볼 수 있다. 작업 목록은 거의 항상 셸 또는 명령줄을 위한 명령으로 인코딩되므로 지속적 통합 툴은 작업 목록을 완료하거나 극복할 수 없는 장애물이 나타나기 전까지 계속 명령을 내린다. 자바와 같은 일부 언어는 더 정교한 옵션을 제공하지만 대부분의 경우 명령줄로 할 수 있는 일이라면 어느 것이든 이 툴로도 할 수 있다.

클라우드에서의 CI/CD를 구현하기 위한 10가지 선택안을 소개한다.
 

클라우드비즈(CloudBees)

클라우드비즈 코어(CloudBees Core)는 지속적 통합 분야에서 유명한 오픈소스 프로젝트인 젠킨스로 시작했으며, 이후 테스트, 지원과 코드 실행을 보장하는 몇 가지 확인 요소를 추가했다. 이 업체는 실험적인 플러그인은 모두 걸러내고 자체 플러그인 몇 가지를 더한 다음 완성도 높게 다듬어서 신뢰성을 확보했다.

클라우드비즈는 여전히 젠킨스 개발 팀의 80%를 보유하고 있으며, 이들이 오픈소스 프로젝트에 활발하게 코드를 기여하는 만큼 젠킨스에 대한 이해도가 높다고 볼 수 있다. 클라우드비즈는 속도를 높이기 위한 폭넓은 병렬화와 개발 프로세스를 추적하기 위한 계측 기능도 추가했다.

클라우드비즈는 무료 등급부터 1년 서비스가 포함된 “스타터 키트”까지 다양한 가격 옵션을 제공한다. 또한 툴 관련 도움은 필요하지만 클라우드 컴퓨팅을 원하지는 않는 사람들을 위해 젠킨스 지원도 따로 분리해 제공한다.

AWS 코드파이프라인(AWS CodePipeline)

아마존의 지속적 통합 및 배포 툴인 AWS 코드파이프라인은 코드 및 데이터의 방향에 대한 개방성을 유지하면서 AWS 서버에 코드를 제공하는 데 최적화됐다. 기본 툴은 주요 언어(자바, 파이썬, Node.js, 루비, 고, 안드로이드, 리눅스용 닷넷 코어)를 위한 사전 구성된 빌드 환경을 제공하며, 결과를 서버로 보내 실행하기 전에 S3 버킷에 집어넣는다.

이름이 조금씩 다른 계층이 상당히 많다. 코드빌드(CodeBuild)는 코드파이프라인으로 트리거될 때 코드커밋(CodeCommit)에서 최신 요소를 가져온 다음 그 결과를 코드디플로이(CodeDeploy)로 전달한다. 다뤄야 할 코드가 너무 많다고 느껴진다면 또다른 자동화 계층을 제공하는 코드스타(CodeStar)를 사용하면 된다. 모든 실수를 저절로 없애 주는 코드버그이레이저스타(CodeBugEraserStar)라는 이름의 계층도 있었으면 좋겠다는 생각이 든다. 주목할 점은 이러한 코드 계층에 대해서는 아무런 비용도 지불하지 않는다는 것이다. 아마존은 이 과정에서 사용된 컴퓨팅 및 스토리지 리소스에 대한 비용만 청구한다. 무료처럼 느껴지기만 할 뿐 엄밀히 말해 무료는 아니다.
 


X