연속 전달

Continuous delivery
Continuous Deployment와 혼동하지 마십시오.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

CD(Continuous Delivery)는 팀이 짧은 사이클로 소프트웨어를 제작하는 소프트웨어 엔지니어링 접근방식입니다.소프트웨어를 출시할 때 소프트웨어를 수동으로 [1][2]출시하지 않고 언제든지 안정적으로 출시할 수 있습니다.보다 빠른 속도와 빈도로 소프트웨어를 구축, 테스트 및 출시하는 것을 목표로 하고 있습니다.이 접근방식은 운영 중인 애플리케이션에 대한 추가 업데이트를 허용함으로써 변경사항 제공에 따른 비용, 시간 및 위험을 줄이는 데 도움이 됩니다.지속적인 제공을 위해서는 간단하고 반복 가능한 도입 프로세스가 중요합니다.

지속적인 배포는 지속적인 배포(CD라고도 함)와 대조됩니다.이 접근방식은 소프트웨어도 단기간에 제작되지만 수동 배포가 아닌 자동 배포를 통해 제작됩니다.따라서 지속적인 도입은 지속적인 제공보다 더 완전한 자동화 형태로 [citation needed]볼 수 있습니다.

DevOps와의 관계

Continuous delivery와 DevOps는 그 의미가 비슷하고 종종 결합되지만 [3]두 개념은 서로 다릅니다.DevOps는 폭넓은 [4]범위를 가지고 있으며, 특히 소프트웨어 [4]전송 프로세스 자동화뿐만 아니라 소프트웨어 전송과 관련된 다양한 팀(개발자, 운영, 품질보증, 관리 등)의 협업을 중심으로 하고 있습니다.한편, 계속적인 제공은 제공 측면을 자동화하기 위한 접근 방식이며, 다양한 프로세스를 통합하여 보다 빠르고 [5]빈번하게 실행하는 데 초점을 맞추고 있습니다.따라서 DevOps는 연속 전달의 산물이 될 수 있으며 CD는 DevOps로 직접 흐릅니다.

지속적인 도입과의 관계

주요 기사:지속적인 도입

지속적인 제공이란 수동 릴리스를 통해 언제든지 도입할 수 있는 소프트웨어를 제공하는 기능입니다.이는 자동 [6]도입을 사용하는 지속적인 도입과는 대조적입니다.Martin Fowler에 의하면, 계속적인 도입에는,[7] 계속적인 제공이 필요합니다.학술지에서는 도입 방법에 따라 수동과 [2][8]자동화라는 두 가지 접근방식을 구별하고 있습니다.

원칙

Continuous Delivery process diagram.svg

지속적인 전송은 배포[9] 파이프라인이라는 일반적인 개념을 린 포카 요크([10]소프트웨어가 릴리스하는 과정에서 통과해야 하는 일련의 검증)로 간주합니다.코드는 필요에 따라 컴파일되어 소스 제어 저장소에 변경이 커밋될 때마다 빌드 서버에 의해 패키징되며, 릴리스 가능한 것으로 표시되기 전에 여러 가지 다른 기술(수동 테스트 포함)로 테스트됩니다.

긴 사이클 시간에 익숙한 개발자는 CD 환경에서 작업할 때 사고방식을 바꿔야 할 수 있습니다.코드 커밋은 언제든지 고객에게 공개될 수 있음을 이해하는 것이 중요합니다.기능 토글 등의 패턴은 최종 사용자가 아직 사용할 준비가 되지 않은 코드를 조기에 커밋하는 데 매우 유용합니다.NoSQL을 사용하면 데이터 마이그레이션 및 스키마 변경 단계(종종 지속적인 전달 [11]워크플로우에 대한 수동 단계 또는 예외)를 제거할 수 있습니다.코드 분기 등 코드를 분리하여 개발하기 위한 기타 유용한 기술은 CD 세계에서는 사용되지 않지만 CD의 원리에 맞게 조정해야 합니다.예를 들어, CD 프로세스 초기에 하나의 코드 분기에서 해방 가능한 아티팩트를 구축해야 하기 때문에 장기간의 코드 분기를 여러 개 실행하는 것은 비현실적인 것으로 판명될 수 있습니다.파이프라인의 [clarification needed]모든 단계

도입 파이프라인

배포 파이프라인을 통해 연속 전달을 사용할 수 있습니다.도입 파이프라인의 목적은 가시성, 피드백 및 지속적인 [12]도입의 3가지 컴포넌트로 구성됩니다.

  • 가시성 – 구축, 도입, 테스트, 릴리즈 등 딜리버리 시스템의 모든 측면을 팀원 모두가 볼 수 있으므로 협업을 촉진할 수 있습니다.
  • 피드백 – 팀원은 문제가 발생했을 때 가능한 한 빨리 문제를 파악하여 문제를 가능한 한 빨리 해결할 수 있습니다.
  • 지속적인 도입 – 완전 자동화 프로세스를 통해 모든 버전의 소프트웨어를 모든 환경에 도입 및 출시할 수 있습니다.

공구/공구 종류

지속적인 제공은 소스 제어에서 프로덕션까지 모든 과정을 자동화합니다.이 프로세스의 [13]전부 또는 일부를 달성하는 데 도움이 되는 다양한 도구가 있습니다.이러한 툴은 도입 파이프라인의 일부이며 지속적인 제공이 포함됩니다.프로세스의 다양한 부분을 실행하는 툴의 종류에는 지속적인 통합, 애플리케이션 릴리스 자동화, 빌드 자동화, 애플리케이션 라이프 사이클 [14]관리 등이 있습니다.

지속적인 제공을 위한 설계

연속 전달을 효과적으로 실시하려면 소프트웨어 애플리케이션은 도입 가능성, 변경 가능성 및 테스트 [15]가능성 등의 일련의 아키텍처상 중요한 요건(ASR)을 충족해야 합니다.이러한 ASR은 높은 priority를 필요로 하기 때문에 가볍게 교환할 수 없습니다.

마이크로 서비스는 연속 [16]전달을 위해 설계할 때 자주 사용됩니다.마이크로 서비스를 사용하면 소프트웨어 시스템의 도입 가능성과 변경 가능성을 높일 수 있습니다.도입에 의존하지 않는 도입시간 단축, 도입절차 간소화, 다운타임 없는 도입 등 도입기능이 개선되었습니다.관찰된 변경 가능성 개선사항에는 작은 증분 기능 변경에 대한 주기 시간 단축, 기술 선택 변경, 증분 품질 속성 변경, 언어 및 라이브러리 업그레이드 [16]등이 포함됩니다.

구현 및 사용방법

Jez Humble과 David Farley(2010)가 쓴 CD북은 이 용어를 대중화시켰지만, 이 용어가 만들어진 이후 그 정의는 계속 발전하여 현재는 더욱 발전된 의미를 가지고 있다.오늘날 기업들은 이러한 지속적인 제공 원칙과 모범 사례를 구현하고 있습니다.예를 들어 의료와 웹의 영역 차이는 여전히 유의하며 구현과 [17]사용에 영향을 미친다.이러한 접근방식을 가진 유명한 기업으로는 야후,[18] 아마존,[19] 페이스북,[20] 구글,[21] 패디[1] 파워, 웰스 파고 [22]등이 있다.

장점과 장애

연속 배송의 몇 가지 이점이 보고되었다.[1][17]

  • 시장 투입 시간 단축: CD를 통해 조직은 새로운 소프트웨어 릴리스에 내재된 비즈니스 가치를 고객에게 보다 신속하게 제공할 수 있습니다.이 기능을 통해 회사는 경쟁에서 한 발 앞서 나갈 수 있습니다.
  • 적절한 제품 구축: 빈번한 릴리즈를 통해 애플리케이션 개발 팀은 사용자 피드백을 보다 신속하게 얻을 수 있습니다.따라서 유용한 기능만 사용할 수 있습니다.기능이 유용하지 않다는 것을 알게 되면, 고객은 그 기능에 더 이상의 노력을 기울이지 않습니다.이를 통해 적절한 제품을 만들 수 있습니다.
  • 생산성 및 효율성 향상: 자동화를 통해 개발자, 테스터, 운영 엔지니어 등의 시간을 대폭 절감합니다.
  • 신뢰성 높은 릴리스:릴리스와 관련된 리스크가 대폭 감소하여 릴리스 프로세스의 신뢰성이 향상되었습니다.CD에서는 도입 프로세스와 스크립트를 반복 테스트한 후 도입에서 실제 가동으로 이행합니다.따라서 전개 프로세스 및 스크립트의 오류는 대부분 이미 검출되었습니다.릴리스가 빈번해지면, 각 릴리스의 코드 변경의 수는 감소합니다.이렇게 하면 발생한 문제를 쉽게 찾아 해결할 수 있어 영향을 미치는 시간을 단축할 수 있습니다.
  • 제품 품질 향상:미해결 버그와 실가동 사고의 수가 큰폭으로 감소했습니다.
  • 고객 만족도 향상:보다 높은 수준의 고객 만족도를 달성할 수 있습니다.

장애물도 [17]조사되고 있다.

  • 고객 선호도:시스템에 대한 지속적인 업데이트를 원하지 않는 고객도 있습니다.이는 특히 업무의 중요한 단계에서 해당됩니다.
  • 도메인 제한:통신 및 의료 등 일부 영역에서는 새로운 버전이 운영 단계에 진입하기 전에 광범위한 테스트를 거쳐야 합니다.
  • 테스트 자동화 부족:테스트 자동화가 부족하면 개발자의 신뢰성이 떨어지고 지속적인 제공이 방해될 수 있습니다.
  • 환경의 차이: 개발, 테스트 및 실가동 환경에서 사용되는 환경이 다르면 검출되지 않은 문제가 실가동 환경으로 유출될 수 있습니다.
  • 인간의 오라클이 필요한 테스트:모든 품질 속성을 자동화로 확인할 수 있는 것은 아닙니다.이러한 속성으로 인해 공급 파이프라인의 속도가 느려지고 루프에 사람이 참여해야 합니다.

Chen은 [6]8가지 채택 과제를 추가로 제기하고 자세히 설명했습니다.이러한 과제는 조직 구조, 프로세스, 도구, 인프라, 레거시 시스템, CD용 아키텍처, 비기능적 요건 연속 테스트 및 테스트 실행 최적화 분야에서 발생합니다.

채택 과제를 극복하기 위한 전략

계속적인 딜리버리 도입의 과제를 극복하기 위한 몇 [6]가지 전략이 보고되고 있습니다.

CD 도입의 과제를 극복하기 위한 전략
전략. 묘사
CD를 진통제로 판매하다 CD가 해결할 수 있는 각 이해관계자의 과제를 특정하고, 그 이해관계자에게 진통제로 CD를 판매합니다.이 전략은 CD 구현에 필요한 다양한 이해관계자의 지지를 얻는 데 도움이 됩니다.
다학제 멤버로 구성된 전담 팀 전담 팀이 없으면 직원들이 다른 가치의 흐름을 담당하도록 배치되는 경우가 많기 때문에 진행하기가 어려울 수 있습니다.복수분야의 팀이 CD의 실장에 필요한 폭넓은 스킬을 제공할 뿐만 아니라, 관련 팀과의 커뮤니케이션을 원활히 합니다.
연속 전달의 지속적 제공 CD의 실장은 가능한 한 빨리 회사에 가치를 제공하는 방식으로 조직하고, 점차적으로 더 많은 프로젝트를 도입하고, 최종적으로 조직 전체에 CD를 전개합니다.이 전략은 구체적인 이점을 가시화함으로써 필요한 투자를 정당화하는 데 도움이 됩니다.그 결과, CD로의 길고 힘든 여정에서 살아남기 위해 필요한 지속적인 기업 지원과 투자를 달성하는 데 도움이 됩니다.
간단하지만 중요한 응용 프로그램부터 시작 CD로 이행하는 최초의 몇 개의 애플리케이션을 선택할 때는 이행이 용이하지만 비즈니스에 중요한 애플리케이션을 선택합니다.이행이 용이해지면 CD의 이점을 신속하게 실증할 수 있기 때문에 구현 이니셔티브가 중단되는 것을 방지할 수 있습니다.비즈니스에 있어서 중요한 것은, 필요한 자원의 확보에 도움이 되어, 명확하고 논쟁의 여지가 없는 가치를 나타내, 조직내에서 CD의 인지도를 높이는 것입니다.
Visual CD 파이프라인 골격 팀에게 전체 CD 파이프라인 뷰를 제공하지만 아직 구현할 수 없는 단계는 빈 CD 파이프라인 골격을 제공합니다.이것에 의해, CD에 대한 사고방식을 확립해, CD의 도입의 모멘텀을 유지할 수 있습니다.파이프라인의 골격은 팀이 CD로 이행하기 위해 오랜 기간 동안 많은 노력과 사고방식을 변경해야 할 때 특히 유용합니다.
엑스퍼트 드롭 개발팀의 시니어 멤버로서 어려운 프로젝트에 참가할 CD 전문가를 지정합니다.팀의 전문가가 있으면 팀 내부에서 CD로 이동하는 동기 부여와 추진력을 얻을 수 있습니다.또한 이행에 많은 시간과 노력이 필요한 경우에도 모멘텀을 유지할 수 있습니다.

「 」를 참조해 주세요.

추가 정보

  • Humble, Jez; Farley, David (2010). Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation. Addison-Wesley. ISBN 978-0-321-60191-9.
  • Wolff, Eberhard (2017). A Practical Guide to Continuous Delivery. Addison-Wesley. ISBN 978-0-134-69147-3.

레퍼런스

  1. ^ a b c Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. doi:10.1109/MS.2015.27. S2CID 1241241.
  2. ^ a b Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices". IEEE Access. 5: 3909–3943. arXiv:1703.07019. Bibcode:2017arXiv170307019S. doi:10.1109/ACCESS.2017.2685629. S2CID 11638909.
  3. ^ Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester.
  4. ^ a b Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN 978-0-321-60191-9.
  5. ^ Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
  6. ^ a b c Chen, Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. 128: 72–86. doi:10.1016/j.jss.2017.02.013.
  7. ^ "bliki: ContinuousDelivery". martinfowler.com. Retrieved 2015-10-29.
  8. ^ Shahin, Mojtaba; Babar, Muhammad Ali; Zahedi, Mansooreh; Zhu, Liming (2017). "Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges". 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). pp. 111–120. doi:10.1109/ESEM.2017.18. ISBN 978-1-5090-4039-1. S2CID 3479812.
  9. ^ Humble, J.; Read, C.; North, D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). pp. 113–118. doi:10.1109/AGILE.2006.53. ISBN 0-7695-2562-8. S2CID 16572138.
  10. ^ Fitzgerald, Brian (2014-06-03). Continuous Software Engineering and Beyond: Trends and Challenges (PDF). 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. pp. 1–9. doi:10.1145/2593812.2593813. hdl:10344/3896. ISBN 978-1-4503-2856-2. Archived from the original (PDF) on 2014-10-25. Retrieved 2014-10-24.
  11. ^ Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. Retrieved 3 January 2014.
  12. ^ Duvall, Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" (PDF). Refcardz. Retrieved October 9, 2015.
  13. ^ Phillips, Andrew (29 July 2014). "The Continuous Delivery Pipeline – What it is and Why it's so important in Developing Software". DevOps.com. Archived from the original on 28 September 2015. Retrieved October 9, 2015.
  14. ^ Binstock, Andrew (16 September 2014). "Continuous Delivery: The Agile SUccessor". Dr. Dobb's the World of Software Development. San Francisco: UBM.
  15. ^ Chen, Lianping (2015). Towards Architecting for Continuous Delivery. The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015). Montréal, Canada: IEEE. doi:10.1109/WICSA.2015.23.
  16. ^ a b Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  17. ^ a b c Leppänen, M.; Mäkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mäntylä, M. V.; Männistö, T. (2015-03-01). "The Highways and Country Roads to Continuous Deployment". IEEE Software. 32 (2): 64–72. doi:10.1109/MS.2015.50. ISSN 0740-7459. S2CID 18719684.
  18. ^ "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 October 2013.
  19. ^ "Velocity 2011: Jon Jenkins, "Velocity Culture"". youtube.com. 20 June 2011.
  20. ^ "Rapid Release At Massive Scale". 2017-08-31.
  21. ^ Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. Retrieved 16 July 2014.
  22. ^ jFrog (December 2014). "2014-year-continuous-integration-revolution".