릴리스 관리란?

릴리스 관리의 가장 첫 번째 단계는 이미 구축된 기능 또는 서비스에 새로운 제품 기능 또는 변화를 적용할 필요가 있는지 파악하는 것입니다. 변경 요청을 하게 되면 미리 지정된 채널을 통해 검토되어 필요성, 타당성, 비용 및 다른 기준을 기반으로 평가됩니다. 모든 변경 요청이 승인되는 것은 아니며, 승인되는 요청만 계획 단계로 넘어가게 됩니다.

계획 단계에서는 릴리스 관리 시스템을 만들고 설정하게 됩니다. 일반적으로 이 단계에서 더 많은 시간을 투자하는 것이 필수적입니다.

이 단계에서 비즈니스는 릴리스에 적용할 구조를 정의합니다. 구조를 정교하게 정의하면 앞으로의 로드맵을 팀에 제공하여 팀원들이 일련의 단계를 따라가고 릴리스가 배포 및 그 이후 단계를 거치도록 합니다. 릴리스 계획을 간단한 검사 목록으로 만들어 시간 순으로 진행할 세부 조치 및 작업을 설명하고 각 작업을 담당할 팀 또는 개인을 할당할 수 있습니다. 많은 비즈니스의 경우에서 디지털 워크플로우가 세부적일수록 더욱 명확한 방향성이 제시되어 모든 팀원이 공동의 목표를 위해 일하고 필수 요구 사항이 충족되는 경향이 나타났습니다.

효과적인 릴리스 계획에는 일반적으로 마일스톤, 책임, 예상 타임라인, 기한, 프로젝트에 대한 명확하고 종합적인 관점이 전체적으로 고려됩니다. 릴리스 계획은 전체 프로세스에 걸쳐 이전 단계로 다시 돌아갈 수 있는 시스템입니다. 여러 릴리스에 대해 반복해 사용할 수 있는 릴리스 관리 시스템을 구축하면 향후 프로세스에서 시간을 단축하고 보다 효과적으로 작업에 드는 노력을 전사 차원에서 조정할 수 있습니다.

승인, 아이디어 수집, 계획 단계를 거치면 실제 개발 단계에 착수하게 됩니다. 제품, 구성요소 또는 기능을 설계하고 구축할 때는 발생할 수 있는 문제를 해결하고 프로젝트의 확실한 요구 사항을 소프트웨어로 녹여내야 합니다. 이 단계는 다음 단계와 어느 정도 중복되는 부분이 있습니다.

설계 및 구축 단계를 거치면서 진행 중인 제품은 실제 테스트 환경으로 보내지게 됩니다. 기능적 및 비기능적인 다양한 테스트를 통해 소프트웨어의 문제 및 버그가 검출되면 해당 릴리스는 다시 수정 단계를 거칩니다. 대부분의 릴리스는 반복 프로세스에서 앞과 뒤를 오가며 최종 검토 단계에서 인증을 받기 전까지 여러 번의 반복 단계를 거치게 됩니다.

배포 전에 릴리스는 최종 검토 단계를 거치며 이때 테스트 중 얻은 새로운 정보 또는 통찰력이 반영됩니다. QA 팀이 최종 제품을 분석 및 검사하여 해당 제품이 계획 단계에서 구축된 표준 및 요구 사항을 충족하는지 검토합니다. 배포했을 때 어떤 버그가 검출된다 하더라도 최종 검토를 통해 제품 출시 또는 출시 이후에 발생할 수 있는 문제를 처리할 수 있는 정보를 충분히 제공받을 수 있습니다.

프로젝트 소유자로부터 최종 승인을 받은 제품은 프로덕션으로 보내져 최종 사용자에게 릴리스될 수 있습니다. 변경 알림, 운영 가이드 및 필수 교육 리소스 등의 보충 교육 자료 또한 함께 릴리스되어야 합니다. 이러한 리소스는 최종 사용자뿐 아니라 사용자 질문을 처리하거나 문제 해결에 도움을 주어야 하는 회사의 지원 팀에게도 적합하도록 조정해야 합니다.

배포 단계는 릴리스 관리 프로세스의 정점에 있지만 출시와 동시에 프로세스가 끝나는 것은 아닙니다. 팀은 릴리스를 관리하기 위해 후속 조치를 취해 문제 또는 장애물을 파악하고 프로세스를 개선함으로써 향후 제품 출시에 대비해야 합니다.

규모에 상관없이 모든 비즈니스가 굉장히 유사한 엔드 투 엔드 프로세스를 거칠 가능성이 높습니다. 하지만 프로젝트 수가 적은 작은 규모의 조직은 릴리스 관리 프로세스 버전이 규모가 큰 비즈니스에 비해 훨씬 간단할 것입니다. 회사가 성장세에 맞춰 릴리스의 규모를 조정하고 팀과 부서가 더 많은 사람들을 고용할수록 릴리스 관리 또한 규모가 커져 보다 향상된 기능의 지원 도구를 필요로 합니다.