지속적인 업데이트 배포 모델
- 4분
소프트웨어 배달 모델로서 "대규모 배포"의 많은 단점에 대해 배웠지만 잘 작동하지 않는 것을 아는 것은 해결의 절반에 불과합니다. 이 단원에서는 모놀리식 메서드의 대안과 향상된 안정성 목표를 달성하는 방법에 대해 알아봅니다.
또한 때때로 서로 교환적으로 사용되는 두 개의 관련 용어를 구별할 가치가 있습니다.
- 지속적인 업데이트: 자동화된 테스트를 통과하는 모든 변경 내용은 프로덕션에 배포할 준비가 되었지만 프로덕션에 대한 실제 릴리스는 수동 승인에 의해 제어됩니다.
- 지속적인 배포: 자동화된 테스트를 통과하는 모든 변경 내용은 수동 게이트 없이 프로덕션으로 자동으로 릴리스됩니다.
둘 다 동일한 기반(빈번한 통합, 자동화된 테스트, 반복 가능한 파이프라인)에 따라 달라집니다. 이 모듈에서는 이러한 공유 기반에 중점을 둡니다.
지속적인 업데이트란?
지속적인 업데이트 는 코드베이스에 대한 모든 변경 내용을 더 빠르고 스트레스가 적고 위험도가 낮으며 재현 가능한 방식으로 릴리스할 수 있는 방법입니다. 지속적인 업데이트는 각 소프트웨어 배포를 수행하거나 대규모 이벤트를 업데이트하는 대신, 요청 시 발생하는 빠르고 일상적인 예측 가능한 환경으로 바뀝니다.
배포 빈도: 지속적인 업데이트 모델을 사용하면 배포가 자주 발생합니다. 주기는 매월, 매주, 매일 또는 매시간일 수 있습니다. 핵심은 더 작고 집중적인 변경 내용을 더 자주 배포한다는 것입니다.
코드 커밋에 의해 트리거됨: 미리 예약된 릴리스 창을 기다리는 대신 코드가 커밋될 때 배달 파이프라인이 시작됩니다. 이 코드는 소프트웨어나 인프라이거나, 소프트웨어 구성과 같은 것일 수 있습니다. 그런 다음 각 변경 내용이 빌드, 테스트 및 릴리스 준비 상태로 유지됩니다. 조직의 제어에 따라 승인 후에도 나중에 프로덕션으로 승격할 수 있습니다.
자동화된 테스트: 통합 자동화된 테스트를 사용하여 코드를 테스트할 뿐만 아니라 해당 테스트 결과에 대한 빠른 피드백을 제공할 수 있습니다. 실패한 테스트를 신속하게 반복하고 복구할 수 있는 빠른 피드백입니다.
코드를 테스트한 후에는 테스트, QA 등과 같은 일련의 준비된 환경에서 종단 간에 배포를 테스트할 수 있습니다. 환경을 통해 배포를 롤링하면 배포 환경에 통합된 한 부분이 됩니다.
기록 레코드: 배포 활동의 기록 레코드를 원할 뿐만 아니라 언제든지 프로덕션 환경을 조정할 수 있기를 원합니다. 현재 프로덕션 환경을 만든 배포를 파악하려고 합니다. 이 정보를 사용하여 구성, 테스트 결과 및 코드 자체를 추적하여 배포를 트리거한 개별 끌어오기 요청으로 되돌릴 수 있습니다.
배포 목표
지속적인 업데이트의 작동 방식을 파악했으므로 소프트웨어 솔루션을 배포할 때 달성에 도움이 되는 지속적인 업데이트 목표 및 기타 DevOps 사례를 고려합니다.
목표 1: 서비스 배포와 관련된 스트레스를 줄이고 그러한 서비스의 안정성 높이기
소프트웨어 및 인프라 배포의 스트레스를 줄이면 이를 실행하는 엔지니어의 일상적인 환경이 향상됩니다. 결과적으로 안정성이 증가하여 중단 및 장애가 더 적어지면 최종 사용자에게도 혜택이 됩니다.
목표 2: 변경이 필요한 시점과 변경 내용이 프로덕션 환경에 배포되는 시점 사이의 시간 줄이기
예를 들어 수익에 영향을 미치는 코드 결함을 확인했으며 이를 해결하는 방법을 정확히 알고 있다고 가정해 보겠습니다. 완성도 높은 DevOps 사례를 사용하면 커밋에서 프로덕션으로의 경로가 짧고 예측 가능합니다. 변경 내용은 빌드되고, 관련 환경에서 자동으로 테스트되며, 몇 분 내에 릴리스할 수 있습니다. 필요한 승인이 이루어지면 향후 릴리스 기간까지 대기하지 않고 프로덕션으로 승격할 수 있습니다.
목표 3: 아이디어를 갖는 것과 사용 가능한 소프트웨어를 제공하는 것 사이의 시간 단축
이 목표는 이전 목표와 비슷하지만 수정보다는 혁신에 중점을 둡니다. 새로운 아이디어에 따라 행동하는 데 얼마나 걸리나요? 이 배포 모델을 사용하면 추가가 현재 시스템을 중단하거나 방해하지 않는다는 확신을 가지고 프로덕션 시스템에 새로운 개념을 통합할 수 있습니다. 이러한 신뢰도를 통해 새로운 기능을 신속하게 제공할 수 있습니다.
배포 결과
이 단원에서 설명하는 목표는 단지 이론적인 열망이 아니라 측정할 수 있습니다. 2014년부터 DevOps 연구 및 평가(DORA) 팀은 소프트웨어 배달 성능에 대한 연간 DevOps 연구를 발표했습니다. 최근 몇 년 동안 이 작업은 Accelerate State of DevOps 보고서로 발행되었습니다. 현재 DORA 모델은 5개의 배달 메트릭을 추적합니다.
- 배포 빈도
- 리드 타임 변경
- 변경 작업 실패율
- 실패한 배포 복구 시간
- 배포 재작업 비율
매년 이 연구에 따르면 실적이 높은 팀은 변경 내용을 더 자주 제공하고, 커밋에서 프로덕션으로 더 빠르게 이동하고, 실패한 배포에서 더 빨리 복구하고, 배포 관련 문제를 해결하는 데 더 적은 시간을 소비하는 것으로 나타났습니다. 최신 연구 및 메트릭 정의는 DORA의 소프트웨어 배달 메트릭을 참조하세요.
이러한 결과는 배포 관행이 중요하다는 생각의 유효성을 검사합니다.