릴리즈 단계 정리 (alpha, RC, RTM)

 작년에 개발팀과 검증팀이 협업을 한지 1년 남짓된 상태라 급한대로 RC, RTM 버전만 분리하여 운영하였는데, 제품의 버전이 올라감에 따라 복잡도도 올라가고, 파트너가 많아지다 보니 RC 버전 검증 기간에 신규 개발건들이 반영되는 등.. side-effect를 일으킬 수 있는 요소들이 점차 증가하게 되었다. 실제로 작년말 릴리즈 된 버전에 검증 중에 변경된 feature로 인해 side-effect가 발생하였고, 추가 bugfix 버전을 릴리즈 하는 일이 벌어지기도 하였다.

 이렇게 버전 컨트롤이 점점 쉽지 않은 상황에 제품의 완성도를 높이기 위해서는 RC 버전에 대한 코드 프리징이 우선되어야 겠다는 판단이 들었고, 소프트웨어 배포 생명주기(Link)를 참고하여 현 회사에서 현실적으로 도입 효과가 가장 커 보이는 Alpha 버전 릴리즈 단계를 추가하게 되었다.

 그래서 올해초 개발팀, PM팀 등 유관부서에 Alpha 릴리즈 단계를 도입해보고자 설명하는 세션을 마련하였고, 그 때 작성했던 내용을 가져와 보았다. 

 

---

 

 

소프트웨어 릴리즈 단계

Alpha

• 버전 예시 : 1.0.0a1, 1.0.0a2, ...
• OO(회사명)에서의 알파 버전은 알파+베타를 포함합니다.
• 알파 버전은 동작이 불안정할 수 있고, Critical한 이슈를 포함할 수 있습니다. 최소한 구동은 가능해야 하며, 추가된 주요 기능이 어떻게 구현되었는지 확인해 볼 수 있는 정도면 됩니다.
• 알파 릴리즈의 주기는 개발팀에서 자유롭게 정합니다. 주요 feature N개를 추가하여 알파 릴리즈를 하고, 추가된 주요 내용을 함께 공유합니다.
• 검증팀, PM팀, Deploy팀, 등.. 기타 유관 부서에서는 알파 버전의 형상을 직접 확인할 수 있고, 각자가 예상했던 구현 내용과 일치하는지, 요구사항을 만족하는지 또는 미처 생각지 못한 구조적 결함 또는 설계 결함이 있는지 확인합니다.
• 알파 버전에서 도출된 Major 이상의 결함에 대해서는 개발팀 일정에 맞게 다시 수정하여 N번째 알파 버전에 다시 포함합니다.
• 알파 버전에서 도출된 Minor 결함에 대해서는 개발팀 일정에 맞게 다시 수정하여 N번째 알파 버전 또는 rc1 버전에 포함합니다.

 

RC

• 버전 예시 : 1.0.0rc1, 1.0.0rc2, ...
• Release Candidate
• 릴리즈 예정버전에 포함되어야 하는 모든 수정 사항(신규, 수정, 버그 수정)을 포함하여 rc1 버전으로 릴리즈 합니다.
• 알파 릴리즈 기간에는 전체 범위에 대한 테스트를 진행하지 않으므로 아직 검출되지 않은 잠재적 이슈를 포함할 수 있습니다. 다만 사전에 예상되는 이슈들에 대해서는 가능한 rc1 출시 전에 수정 부탁 드립니다.
• rc1 버전을 출시한 시점부터는 코드 프리징(Code Freezing)이 되어야 합니다.
  • rc1~rcN(=RTM) 내에서는 리포트된 이슈를 위한 수정 외에 협의되지 않은 다른 수정을 포함하지 않아야 합니다.
  • 코드 프리징이 지켜지지 않을 경우, rc 중간 버전에서 발생할 수 있는 side-effect issue에 대한 컨트롤이 쉽지 않습니다. 즉, 해당 rc버전부터 전체 테스트를 다시 시작해야할 수 있다는 의미입니다.
• rc 버전 내에서 도출된 결함에 대해 수정 범위 혹은 영향 범위가 넓은 경우, 예상되는 영향 범위 또는 결함 발생 원인과 수정 방향에 대해 충분한 커뮤니케이션 부탁드립니다.

RTM

• 버전 예시 : 1.0.0
• Release to Manufacturing (Release to Marketing)
• 마지막 RC 버전과 동일한 형상으로 최종 버전을 릴리즈 합니다.
• 최종 릴리즈 산출 문서를 포함하며, 해당 버전의 개발 단계가 종료됩니다.