메뉴 건너뛰기

이 문서는 Xebia(http://xebia.com/)의 Whitepaper인 "Introducing Continous Delivery in the Enterprise"를 참고하여 작성되었습니다. 

이번 문서는 1부에 이어 지속적인 딜리버리를 해야하는 이유를 지속적인 딜리버리가 적용되지 않았던, 전통적인 개발 방법과 비교하여 설명한다.

continuousDelivery2.jpg

왜 우리는 지속적인 딜리버리(Continous Delivery)를 해야하는가?

비용을 절감한다(It lowers your cost)
  • 전통적인 개발 방법 : 전통적인 개발 방법에서 배포는 수동적으로 진행되었다. 개발과는 다른 전문적인 빌드 스크립트를 작성해야하고, 항상 다양한 문제를 동반하며 이를 해결하기 위한 시간과 비용이 소비된다. 결국 배포를 진행이 될 수록, 그 비용은 계속적으로 증가하게된다. 
  • 지속적인 딜리버리 : 지속적인 딜리버리에서 배포는 전체 비용에 거의 영향을 주지 않는다. 배포 파이프라인이 구성되면, 배포는 자동으로 이루어지거나, 적어도 버튼 한번의 클릭으로 실행된다. 이는 몇일 걸리는 배포의 업무를 몇 분 단위로 누구나 할 수 있게 해준다. 
타임-투-마켓 시간이 짧아진다(It shortens your time to market)
  • 전통적인 개발 방법 : 전통적인 개발 방법에서 한번의 릴리즈는 수 많은 변경사항들이 일어난다. 릴리즈 시간은 길어지고, 배포를 위해 많은 노력이 요구된다. 많은 변경사항을 가진 거대한 릴리즈는 한번의 많은 양의 변경을 처리할 수 없기 때문에, 불가피하게 지연된다. 더구나 이 릴리즈 프로세스는 효율적이 못하기 때문에, 처음 100개의 변경사항 중에 3개의 변경사항이 테스트에 실패한다면, 97개의 변경은 3개의 Defect이 수정되기를 기다려야할 것이다. 
  • 지속적인 딜리버리 : 지속적인 딜리버리에서 변경들은 연속적으로 제품에 반영되고 가시화된다. 이 변경사항들은 고객이 즉각 사용할 수 있게되어 비즈니스 가치를 바로 반영할 수 있다. 이 기능을 사용한 고객들로부터 즉각적인 피드백을 수집할 수 있게되 마켓에서 경쟁령은 더욱 좋아질 것이다. 
리스크를 완화한다(It mitigates your risk) 
  • 전통적인 개발 방법 : 많은 양의 변경이 환경에 추가되면, 당연히 리스크는 발생된다. 긴 릴리즈의 기간 동안에는 환경이 변경될 수 도 있고 환경을 변경할 수 있는 기회를 잃을 수 있다. 이러한 환경적인 요소로인해, 매번 배포를 하는 것은 빅뱅이될 수 있다. 테스트를 해보지 못한 조합이 발생할 수도 있다. 매 릴리즈마다 배포는 새로워보이며, 이전 배포의 경험은 무용지물이 될 수 있다. 
  • 지속적인 딜리버리 : 지속적인 딜리버리는 문제가 생기면, 더 자주 하라! 라고 말한다. 자동화된 배포를 통해 문제는 빠르게 식별되며, 빠르게 고쳐지며 우리가 잘하고 있다는 것을 입증할 것이다. 이는 전통적인 방법에 비해 리스크를 낮출 수 있으며, 릴리즈 프로세스는 훨씬 더 안정적이게 될 것이다.  
IT 조직의 신뢰를 구축한다(It (re)builds trust within your IT organization)
  • 전통적인 개발 방법 : 계속적으로 빌드가 실패하게되면, 사람들은 회의는 커지고 무기력하게 된다. 한번 의심하기 시작하면, 사람들은 책임때문에 그 액티비트를 회피하는 방법을 강구하고 업무에 대한 자신감은 더욱 상실하게 된다. 이는 조직 내에서도 동일한 여파를 가져오게 될 것이다. 운영 조직은 변경을 원하지 않을 것이고, 이는 보수적인 접근을 수행하게 만든다. 불필요한 엄격한 절차를 수행하거나 일정을 더 길게 잡아 많은 비용을 지출하게 될 것이다.
  • 지속적인 딜리버리 : 매일 배포는 완전히 자동으로 실행된다. 결국 배포는 입증되고, 사람들의 자신감은 증대되며 신뢰성은 높아진다. 배포 프로세스가 자리를 잡고, 정확히 실행되면, 신뢰감이 생성되고, 개발과 운영 조직 사이의 불화의 이유는 없어질 것이다.
고객을 이해하는 것을 돕는다(It helps you to understand your customer)
  • 전통적인 개발 방법 : 전통적인 개발 방법은 아이디어가 구현되기 전에 아이디어는 전체적으로 설계되어야 하고, 범위를 설정해야 한다. 모든 투자가 이루어진 후에야 자신이 생각한 아이디어의 결과가 성공했는지 확인할 수 있다. 프로젝트가 시작되기 앞서, 전체 예산을 지불해야하며, 아이디어에 대한 투자가 가치 있음음 확신할 수 있어야 한다. 프로젝트가 진행되는 동안에도, 고객은 진행사항 및 기능에 대한 검증을 할 수 있는 방법이 없다.
  • 지속적인 딜리버리 : 아이디어를 구성하고, 작은 단위로 디자인하고, 구현한다. 기능이 이용가능하게되면, 투자는 자본화된다. 딜리버리 프로세스는 범위와 요구사항을 조절하는 가능성을 제공한다. 그리고 앤드유저에 의해 사용되지 않는 실제적인 기능에 대한 투자를 멈출지 결정을 할 수 있게 해준다. 제품이 완성되어 갈 수 록 고객의 행동을 측정할 수 있게 때문에, 프로젝트는 전통적인 개발 방법보다 더욱 고객의 요구사항을 반영한다. 
어플리케이션의 전체 품질이 향상된다(It raises the overall quality of your application) 
  • 전통적인 개발 방법 : 코드는 필요한 시점에 수동으로 컴파일되고 패키지 된다. 코드의 마지막 단계에서 수동 테스트가 실행된다. 테스트 결과는 프로젝트의 마지막에 가시화된다. 테스트가 실패할 때, 무엇이 변경되었고 어떤것을 수정해야할 필요가 있는지 솔루션을 찾는 것은 어렵다. 많은 비용과 시간이 소비되고 프로젝트는 계속 진행되어야 하기 때문에, 모든 문제가 해결되지 않았을지라도 코드는 제품에 삽입된다.
  • 지속적인 딜리버리 : 완벽히 자동화된 조립, 컴파일, 테스팅 프로세스는 딜리버리 프로세스의 중요한 부분으로 형성되어 빠르고 쉽게 진행된다. 코딩 이슈는 즉각적으로 가시화되고 잉크가 마르기 전에 수정될 것이다. 코드가 준비상태라고 말하면, 이 코드는 실제로 준비된 것이다. 

Who's PSEG

profile

PSEG는 Practical Software Engineering Group의 약자입니다. 

이론을 넘어 실용적으로 활용할 수 있는 소프트웨어 공학을 공유하는게 그룹의 목적입니다.

Atachment
첨부 '1'
?

 


  1. Martin Fowler가 말하는 지속적인 통합(Continuous Integration)

    조금 오래된 자료이긴 하나, 카페 자료를 옮기면서 유용하고 기억해두면 좋을 것 같아 남깁니다. 다양한 애자일 베스트 프랙티스 중 하나인 지속적인 통합 즉, CI(Continuous Integration)는 하나의 트랜드를 넘어서, 프로젝트에서는 필수 요소로 자리 잡았...
    Date2014.05.07 ByPSEG Reply0 Views5637
    Read More
  2. 지속적인 딜리버리(Continuous Delivery)의 소개 - 2부

    이 문서는 Xebia(http://xebia.com/)의 Whitepaper인 "Introducing Continous Delivery in the Enterprise"를 참고하여 작성되었습니다. 이번 문서는 1부에 이어 지속적인 딜리버리를 해야하는 이유를 지속적인 딜리버리가 적용되지 않았던, 전통적인 개발 방...
    Date2014.04.30 ByPSEG Reply0 Views4758
    Read More
  3. 지속적인 딜리버리(Continuous Delivery) 소개 - 1부

    이 문서는 http://xebia.com/의 Whitepaper인 "Introducing Continous Delivery in the Enterprise"를 참고하여 작성되었습니다. 오늘날 현실 불과 몇년전까지만 하더라도, 사람들은 인터넷의 서비스를 즐기기 위해 컴퓨터를 이용해야 했다. 오늘날 사람들은 ...
    Date2014.04.30 ByPSEG Reply0 Views5352
    Read More
  4. INCOSE 요구사항 관리 도구 비교 조사

    INCOSE는 국제 시스템 엔지니어링 협회이다. 시스템 엔지니어링을 위한 핸드북, CASE 도구 조사, 교육, 시스템 엔지니어링 전문 자격 검증 등의 다양한 역할을 수행하고 있는 협회이다. 이번 포스트에서는 시스템 엔지니어링 협회의 도구 데이터베이스에서 요...
    Date2014.04.30 ByPSEG Reply0 Views6680
    Read More
Board Pagination Prev 1 2 3 4 Next
/ 4