Traditional development team vs Continuous Delivery team by Hubert Shin

XebiaLabs 에서 출간한 The IT Manager's Guide to Continuous Delivery 를 보고 의미가 있을 것 같아 번역을 하게 되었습니다. 

전통적인 방식의 딜리버리 팀과 Continuous Delivery 팀의 차이가 어떤 것일까요?
아래 글을 읽고 한번 확인해 보시죠 


전통적인 방식의 딜리버리  
  • 요구정의: 우리는 모든 것을 알고 있어요(We know everything)
    • 기간: 몇 주에서 몇 달
    • 낭비: 상세화된 불필요한 기능들. 잘못 상세화된 기능들. 불필요하게 많이 상세화된 기능들. 고객 피드백 부재. 대규모 사전 설계. 개발자에게 실행가능성에 대한 피드백을 전달 받지 못함
    • 설명
      • 대규모의 일을 하거나, 자주 릴리즈를 못하는 상황에서 BA는 기능을 먼저 모두 정의하려고 한다. 모호함과 해석의 차이를 사전에 제거하기 위해, 상세한 문서화를 통해 그들이 상상할 수 있는 모든 유스케이스와 시나리오를 찾아내려고 한다. 이러한 방식은 고객이 실제로 무엇을 원하는지 뿐만이 아니라, 그 이상의 것을 상상하여 만들게 한다. 이렇게 요구정의를 하면 고객들의 기대에 맞지 않는 다른 기능까지 정의하게 된다. 
      • 이것은 비즈니스 가치를 전달하는 측면서 볼 때, 이미 만들어지기 전부터 시장에 늦은 타이밍에 전달하게 되는 것이다. 한 개의 기능 개발을 실제로 하기 전에 너무 많은 충분한 기능 리스트를 모아야 하기 때문이다.
  • 코딩: 지연된 문제들(Postponing problems)
    • 기간: 몇 주
    • 낭비: 중복된 노력, 개발자 간 커뮤니케이션 부재
    • 설명: 기능 요구사항의 상세화가 모두 끝나면, 한 개 또는 더 많은 개발팀에게 기능 요구사항들이 한 개씩 전달된다. 개발자들은 홀로 일하게 되고, 그들의 동료들과 중복된 일을 할 수도 있게 되는 상황에서 어플리케이션 코드의 변경을 수행한다. 몇 주 뒤, 특정한 기능에 관련한 일은 마무리 된다.
  • 통합: 머지 지옥(Merge hell) 
    • 기간: 며칠
    • 낭비: 머지 시 발생한 모든 팀들이 함께 해결해야할 문제들 
    • 설명
      • 홀로 작업한 코드들을에 대한 작업이 끝난 몇 주 후 이 새로운 코드들은 한 개의 코드 베이스로 통합되어야 한다. 머지 전, 더 길게 이 코드의 작업이 걸릴 수록, 더 많은 개발팀들이 관여할 수록, 더 많은 문제가 발생한다. 
      • 늦은, 자주하지 않는 통합은 납기를 준수하지 못하게 되는 중요한 리스크이다.
  • 설치: 에러가 나기 쉬운 수작업 디플로이(Error-prone manual deployment)
    • 기간: 1주
    • 낭비: 디플로이 수행을 위해 기다리는 시간, 잘못된 디플로이 설명을 수정하는 시간, 잘못된 디플로이를 수정하는 시간, 디플로이 해야 할 환경을 준비하는 시간, QA가 테스트 가능한 시점을 기다리는 시간, 여러 팀간의 핑퐁 게임 
    • 설명
      • 개발 환경에서 몇 주간 수작업으로 만들어져 어플리케이션이 동작하게 된 후, 개발 팀은 운영 환경에 디플로이 하게하기 위한 설치 매뉴얼을 준비하고, 테스트 환경 또한 준비한다. 이 설치 메뉴얼은 개발자들이 기억하는 모든 단계 단계들을 작성해 놓으나, 보통은 완전히 테스트된 시나리오에 대해 표현하지는 않는다.
      • 설치 메뉴얼과 어플리케이션 바이너리는 공유된 네트워크 드라이브를 통해 운영에 전달된다. 운영팀의 담당자가 시간이 날 떄 테스트 환경에서 테스트 될 수 있도록 운영을 위한 시스템 상의 티켓(이슈)을 만든다. 이 운영팀에 전달된 티켓은 만약 5일 내에 운영팀이 접수해야 한다면, 그 5일에 매우 근접한 시점에 운영팀으로부터 접수된다. 그리고 한 운영 담당자는 메뉴얼에 따라 디플로이를 실시한다. 몇개의 스텝을 진행한 후, 운영자는 에러를 발견하게 된다. 이 에러는 티켓에 작성한 코멘트와 함께 개발팀에 전달된다.
      • 다음 날 아침 QA팀은 테스트를 하려고 준비하고 있으나 어플리케이션은 심지어 동작하지 않는다. 선임 개발자는 코멘트가 작성된 티켓을 보고 작성된 설치 메뉴얼에 에러를 발견한다. 이를 수정하고 다시 네트워크 드라이브에 공유한다. 그리고 다시 그 티켓을 운영팀에 넘긴다.
      • 결과적으로 운영자는 그 일은 다시 수행하고 마침내 테스트 환경에 설치를 마친다. 
  • 테스팅: QA 수작업 테스트에 의한 품질 기준 낮추기(Lowering the bar after manual QA 
    • 기간: 3주
    • 낭비: 요구사항을 테스트로 만들지 못한 것, 수정 전 모든 테스트가 끝나길 기다린 것, 개발한 기능이 동작하지 않는 것, 당장 필요하지 않은 시나리오 까지 정의된 것, 멀쩡한 기능까지 3개의 결함 때문에 릴리즈 되지 못하고 대기 상태가 된 것, 요구사항 해석에 따라 달리 오해가 발생하는 것, 여러 팀들간의 전달 시간 
    • 설명
      • QA팀은 이제 인수 테스트를 시작할 수 있다. 개발 단계 동안 팀은 상세한 요구사항에 대해 이미 확장한 테스트 계획을 세워놓았다. 이 중 어떤 요구사항들은 테스트 자동화를 하면 좋은 것들이다. 하지만 상세화된 요구사항을 테스트 자동화 스크립트로 바꾸는 것은 쉬운 일이 아니다. 많은 요구사항이 잘못 쓰여졌거나 자동화 스크립트에 걸맞지 않는 경우가 많다.
      • 다양한 프로세스로 테스트 계획을 수핸한다. 이 모든 과정이 완료 되고, QA팀은 보고 할 때 15개의 실패한 테스트 시나리오를 발견한다. 이것은 릴리즈를 하지 못하는 수준이다. 15개의 실패한 테스트는 다수의 중요 기능들과 연관되어 있다. 이들을 지연시키게 되면 이는 시장에 제품을 내어 놓을 수 없을 수준이다. 
      • 이들은 결함 중 3개만 빨리 패치를 수행하도록 한다. 개발팀에 이 3개에 대한 패치에 대해 QA테스트를 완료하고 이들은 마지못해 Pass 사인을 준다.
      • 릴리즈 매니저는 이 패치된 버젼에 대한 티켓을 만들어 프로덕션 버젼을 만든다. 12개의 시나리오는 실패한 상태로 말이다. 이들은 유지보수 단계에 매우 빠르게 수정하기로 암묵적으로 합의한다.
  • 릴리즈 준비: 사전 프로덕션의 병목 (The Pre-production bottleneck) 
    • 기간: 4주
    • 낭비: 사전 프로덕션 환경이 준비되길 기다리는 대기, 납기 준수 실패, 프로세스 마지막에나 발견된 에러 
    • 설명
      • 새로운 버젼이 릴리즈되기 전 사전 프로덕션 환경에서 최종 테스트를 거쳐야만 한다. 이것은 실제 운영이 잘 돌아가는 상황을 만들기 위해 반드시 수행해야 하는 단계이다. 가장 큰 문제는 실제 운영과 이전 환경들이 매우 상이하다는 것이다. 
      • 이 바쁜 사전 프로덕션 환경을 위한 배타적인 슬롯을 얻는 것은 사전에 잘 계획되어야 한다. 왜냐하면 다음 슬롯은 2주 후에나 있기 때문이다. 
      • 한번 어플리케이션이 설치되면, QA는 제품 통합, 안정성, 회귀 테스트를 실시한다. 일주일 후, 이 팀은 두 개의 에러를 발견하고, 개발팀으로 부터 이틀 후 이 내용이 수정된 내용을 다시 전달 받는다. 실패한 테스트를 다시 수행 후  프로덕션을 위한 릴리즈를 승인한다. 
  • 운영(Go-Live): 분기마다 릴리즈되는 사이클(The Quarterly Release Cycle)
    • 기간: 3주
    • 낭비: 정기 릴리즈까지 대기하는 시간, 야근, 주말근무 
    • 설명
      • 새로운 어플리케이션 버젼은 정기 분기 릴리즈 기간에 맞출 수 있게 겨우 승인된다. 3주 후 릴리즈를 수행할 수 있다. 평소와 비슷하게 이것은 매우 바쁘고 스트레스를 주는 일이다. 토요일에서 일요일 사이에 릴리즈가 일어나고, 운영팀은 수작업을 통해 9개의 새로운 어플리케이션 버젼을 릴리즈 해야 한다. 다양한 메뉴얼에 작성되어 있는 다양한 스텝들을 4시간동안 모이 수행해본 뒤, QA 분서는 4.5 시간을 들여 이 릴리즈를 검토하고 승인한다. 
      • Go/No-Go 납기 직전에 QA는 테스트를 완료하고 드디어 어플리케이션은 동작하게 된다.


Continuous Delivery 를 하는 조직의 일하는 방식 
  • 협업: 기능의 처음부터 끝까지 함께 하는 팀 (End to End Feature Teams) 
    • 설명
      • 새로운 아이디어가 만들어지고 딜리버리 스트림에 포함되는 것을 준비하는 것은 모든 관련된 그룹이 포함된 팀에 의해 가능한한 빨리 일어난다. 분석자, 개발자, 테스터와 운영팀이 함께 결정한다. 이 접근은 아이디어에 대해 공유된 시간을 갖도록 하여 효과적으로 아이디어를 구현할 수 있도록 한다. 이러한 애자일 팀은 서비스 딜리버리의 모든 스펙트럼의 일들을 수행하고, 성공적인 작업을 수행 할 수 있게 한다.
  • 정의: 명세를 자동화 인수 테스팅으로 (Specifications Become Automated Accepting Tests) 
    • 기간: 0.5일
    • 설명
      • 아무리 애자일 팀이라도 변경에 대해서는 구현되기 전에 명세화가 되어야 한다. 물론 이것은 앞서 말한 팀의 명세와는 차이가 있다. 스펙들은 전체 딜리버리 팀에 의해 형태가 정해지고, 분석자나 QA가 비즈니스 적으로 확인할 수 있는 말들로 작성된 수행이 가능한 테스트를 쓴다. 
      • 이것은 효율을 증가시키고 오해의 가능성을 한방에 없앨 수 있다. 왜 종이 문서에 스펙을 쓰고 이후 코드에 이것을 옮겨야 하는가? 그것도 다른 누군가가 말이다. 한번에 실행가능한 테스트를 만들면 되는 것이 아닌가?
  • 코딩: 테스트 먼저, 코딩을 이후에 (Test first, Then code)
    • 기간: 0.5일 
    • 설명
      • 기능을 구현하기 전, 개발자는 코드를 짜기 전이기 때문에 실패하는 Unit 테스트를 작성해 놓는다. 이후 이 테스트를 성공시키는 코드를 짠다. 이러한 프랙티스틑 의도에 맞는 코드를 만들고, 이 프랙티스가 팀에 녹아들면 모든 코드가 의도한 대로 만들어 진다.
      • 새로운 코드가 만들어 져 버젼 컨트롤 레파지터리에 들어오기전 모든 테스트는 성공해야 한다. 이렇게 함으로 개발자들이 일하는 모든 코드의 베이스는 동일해진다. 업데이트 된 코드 또한 지속적인 통합을 통해 다시 제대로 돌아간다는 것을 확인하게 된다. 이는 다른 개발자들의 어떤 작업과도 문제가 발생하지 않는 다는 것을 확인시켜준다. 
      • 만약 빌드가 실패하면, 모든 팀이 이를 확인하게 되고, 빌드가 다시 성공할 때까지 모든 문제보다 우선적으로 이를 먼저 해결한다. 
  • Off It Goes: Continuous Delivery Pipeline 
    • 기간: 0.5일
    • 설명
      • 통합 빌드는 CD Pipeline의 첫번째 관문이다. 이것은 우리가 스펙으로 작성한 자동화 인수 테스트를 통과한 것 뿐만이 아니라, 보안, 성능, 가용성 부분의 테스트도 모두 통과한 것이다.
      • 이러한 테스트들은 자동화된 것으로 수행되어 “Hands Off” 환경으로 전달된다. 여기에는 사람의 손이 닿을 수 없다. 만들어진 기능은 테스트들이 잘 수행완료됨과 동시에 이들 환경으로 디플로이 된다.
      • 스피드와 자동 프로비저닝의 신뢰성 그리고 운영 환경과 같이 설정된 테스트 환경은 파이프라인에서 매우 중요한 요소이다. 
      • 이것은 다양한 형태의 테스트를 동시에 이루어지도록 할 수 있고, 높은 품질의 파이프라인은 팀 스스로 품질에 대한 자신감을 높일 수 있게 만든다.
  • Go-Live: 제품 책임자가 버튼을 누른다 (The Product Owner hits the button)
    • 기간: 1시간 
    • 설명
      • 만약 새로운 기능이 파이프라인을 지나가는 동안 어떠한 문제도 일으키지 않으면, 비즈니스 책임자는 새로운 버젼의 어플리케이션에 대한 승인을 요청할 수 있다. 
      • 이것은 이미 수천개의 지난 밤 내내 진행된 수천개의 인수 테스트를 통과한 뒤이다. 모든 테스트 결과는 요약 정리되어 품질 대쉬보드에 보이고, 만약 원한다면 상세내역 또한 확인할 수 있다.
      • 새로운 기능의 승인 후, 비즈니스 책임자는 완전히 자동화 된 프로덕션 디플로이 환경에 이 기능을 추가한다. 이 디플로이는 정해진 시간에 늘 돌아가는 환경으로 개발자나 운영자가 필요하지 않은 작업이다. 새로운 기능을 추가하는 것은 Contents management system에 새로운 컨텐츠를 추가하는 것만큼 쉽다. 
      • 비즈니스 담당자들은 파이브라인 내에서 진행되는 어떠한 테스트의 내용도 신뢰한다. 왜냐하면 작성하는데, 이미 함께 도움을 주었기 때문이다. 자동으로 돌아가더라도 특별한 차이는 없다. 
      • 이후 새로운 변경은 일부 사용자들에게 노출된다. 만약 심각한 문제가 발생했다면 이 “카나리아 부분집합”은 다시 자동으로 롤백된다. 

덧글

댓글 입력 영역