Continuous Delivery vs Continuous Deployment by Hubert Shin

원문보기

지속적인 디플로이(Continuous Deploy)라는 개념이 Timothy Fitz 의 블로그를 통해 세상에 등장했다. 이 때가 Dave와 내가 함께 집필한 지속적인 딜리버리(Continuous Delivery)라는 이름의 책보다 일년 먼저였다. 우리는 굳이 지속적인 디플로이와 다른 명칭인 지속적인 딜리머리라는 명칭을 선택했다. 왜 그랬는지 궁금하지 않은가? 실제로는 어떤 차이가 있을까? 아니면 혹시나 그냥 같은 이름을 쓰지 않기 위해서 였을까?

우리의 책을 지속적인 딜리버리라고 이름 짓게 된 몇 가지 이유들이 있다. 무엇보다, 우리 생각에는 디플로이가 무조건적인 릴리즈를 의미하지 않는다는 것이 첫 번째 이유이다. 우리가 책에서 기술한 것처럼, UAT(User Acceptance Testing)를 하는 단계 직전까지도 지속적인 디플로이는 할 수 있다. 이것은 큰 문제는 아니다. 지속적인 디플로이가 특별한 이유는 어떤 변경이 있더라도, 자동화된 테스트(또는 짧은 QA의 검증)를 거쳐 제품화(Production)로 디플로이 될 수 있다는 것이다. 지속적인 디플로이는 훌륭한 품질의 빌드가 완료된 코드를 사용자에게 릴리즈하는 좋은 프랙티스이다. 때문에, 이를 위한 더 정확한 표현을 찾는다면 "지속적인 릴리즈" 가 될 것이다.

지속적인 딜리버리는 지속적인 디플로이를 포함 할 수 있으나, 반대로는 될 수 없다. 즉, 지속적인 딜리버리가 더 큰 개념이다. 지속적인 딜리버리는 릴리즈 스케쥴을 IT 관점이 아닌 비즈니스 관점에서 다루는 것을 말한다. 지속적인 딜리버리를 수행한다는 것은 당신의 소프트웨어가 전체 프로젝트 라이프사이클을 거쳐 상품화될 준비가 되어있다는 것을 의미한다. 이것은 어떤 빌드도 잠재적으로 몇 초 안에, 몇 분안에 자동화된 프로세스를 거쳐 사용자가 사용할 수 있게 릴리즈 될 수 있음을 의미한다.

다르게 말하면 딜리버리에 관련된 모든이들 즉, 개발자, 테스터, DBA, 시스템 어드민, 사용자 그리고 비지니스 담당자들 사이에 자동화된 빌드, 테스트, 디플로이 프로세스와 훌륭한 협업을 수행하도록 하는 것을 의미한다.

지속적인 딜리버리를 하는 곳에서는, 개발자들이 코드를 만들고 테스터에게 넘기는 시점이나 기능이 "QA 완료"가 되는 시점에 "완료"라고 이야기하지 않는다. 운영서버에서 정상적으로 동작할 때, 비로소 "완료"라고 할 수 있다. 즉, 스프린트 (당신이 스크럼을 쓴다면)안에서 마무리되었다고 하는 일이 더 이상의 추가적인 테스트가 있어야 하거나 또 다른 디플로이 단계가 있을 필요가 없다는 것을 의미한다. 만약 당신이 칸반을 쓰면서 지속적인 딜리버리를 하고 싶다면, 사용자에게 릴리즈 되기 전에 또 다른 스토리를 가지고 일할 수 없다는 것을 의미한다.

그러나, 항상 좋은 빌드로 사용자에게 릴리즈해야 한다는 말은 현실적이지 않을 수도 있다. 특히나, 임베디드 소프트웨어 같이 소프트웨어의 변경과 하드웨어의 변경을 함께 고려해야 하는 개발환경에서는 보통 불가능한 일이다. 또한 COTS의 관점에서 마케팅적인 이유로, 주어진 시간에 아주 적은 양의 릴리즈된 버젼만 필요할 때도 있다. 이와 같은 맥락의 또 다른 많은 이유들이 있을 수 있다. 그러나 중요한 점은 그 이유들이 반드시 비즈니스적인 이유여야 한다는 것이다.

만약 당신이 지속적인 딜리버리를 하고 있다는 의미에 대해 직접적인 설명이 필요하다면, 난 다음과 같이 정의하고 싶다. 지속적인 딜리버리란 당신이 고객에게 가치를 전달하는 가장 좋은 방법을 의사결정하여, 지속적인 디플로이가 가능하게 만든 것이다. 특히, 만약 당신이 사용자에게 항상 빌드가 완료된 코드를 릴리즈 할 수 없다면, 스토리의 완료의 의미는 과연 무엇인가? 내 생각에는 적어도 아래와 같은 조건들이 적용되어야 한다.
  • 스토리가 담긴 빌드에 해당하는 전체 테스트 스위트를 실행한다. 이것은 스토리가 기대할만한 비지니스적 가치가 있는지 검증한다. 또한 개발 프로세스를 수행하며, 문제가 될만한 내용은 없는지 확인한다. 더 효율적이기 위해 이것은 잘 짜여진 다음 세 가지의 자동화된 테스트가 존재함을 의미한다. 그 세가지는 단위 테스트, 콤포넌트, 인수 레벨 테스트이다.
  • 이 스토리는 고객에게 실제 운영환경과 비슷한 환경에서 데모를 수행해야 한다. 실제 운영환경과 비슷한 곳이란, 약간의 제약은 있겠지만 실제 환경과 거의 같은 환경을 말한다. 만약 실제운영환경과 비슷한 환경이 아닌, 실제 운영환경에 방대한 덩어리를 디플로이 하더라도, Blue-green 디플로이 같은 테크닉을 이용하여 딜리버리 할 수 있다. Blue-green 디플로이는 다른 버젼의 어플리케이션을 사용자에게 영향 없이 병행하여 실 운영환경에 디플로이 하는 방법이다.
  • 운영에 디플로이 하는데 장벽이 없어야 한다. 다른 말로 풀이하자면, 만약 디플로이 하기로 결정하게 되면 버튼 한번 누르는 것으로 전체적으로 자동화된 공정을 지나 사용자에게 빌드된 소스가 디플로이 될 수 있어야 한다. 특히 이것은 용량, 가용성, 보안같은 비기능적 특성들도 함께 고려된 테스트여야 한다. 만약 당신이 SOA를 쓰거나 당신의 어플리케이션과 다른 시스템 사이의 의존관계가 있는 경우에도, 통합하는데 문제가 없는 경우라야 한다.

핑백

덧글

댓글 입력 영역