[QA : 업무 프로세스 관리] 소스 코드에 대한 버전 관리만 하고 있습니까?

소스 코드에 대한 버전 관리만 하고 있습니까?

📌 목적 : 빌드 버전 표준화를 통해 빌드 히스토리 관리와 버전의 의미를 부여하고, 체계를 만든다.

 

하드웨어와 달리 소프트웨어는 코드 커밋/머지/프리즈라는 시점이 존재하고, 개발이 되는 시점 마다 버전이라는 넘버링을 통해 이력을 관리합니다.

형상만 버전 관리?

이것은 개발자만 알아야 하는 영역이 아닌 개발에 참여하는 모든 사람이 알아야하는 정보입니다.

버전의 의미 부여는 회사마다 다를 수 있지만 보편적으로 사용하는 예시로 작성하였습니다.

 

버전 관리를 하지 않는 조직의 경우 아래 내용을 참고하시기 바랍니다.

1. 버전의 정책은 개발에 참여하는 모두가 같은 생각을 움직여야 합니다.
2. 버전은 약자이기 때문에 오해하지 않도록 이해하고, 교육되어야 합니다.
3. 약자의 의미를 명확히 이해하고 있을 때, 버전에 대한 의미가 가치를 가질 수 있습니다.
4. 형상관리 서버의 버전과 릴리즈 노트, 그리고 이슈 관리 시스템의 버전은 일치해야 합니다.
5. 테스트 완료 시점의 버전과 형상관리 서버의 버전은 일치해야 합니다.

 

일반적인 버전 체계

✔ 알파버전(Alpha) : 기획, 디자인, 현업(콘텐츠 개발)이 확인을 위한 버전 - ex) 1.0.0.a1 ~
✔ 베타버전(Beta) : QA 테스트를 통해 요구확인 및 기능에 대한 보증을 위한 버전 - ex) 1.0.0.b1 ~
✔ 출시 준비 버전(Release Candidate) : QA 테스트 완료 후 현업 검수를 위한 버전 - ex) 1.0.0.rc1 ~
✔ 출시 버전(Release To Manufacturing) : 현업 검수가 완료되고, 최종 버전으로 QA 검수까지 완료되어 출시를 위한 버전 - ex) 1.0.0.rtm

• 정책[1] .rtm 버전은 재빌드 없음
• 정책[2] .rc 최종 버전으로 .rtm 재빌드
• 정책[3] .rtm 빌드는 .rc 빌드와 소스가 동일하다고 개발에서 보증함
• (정보) 향후 CI/CD 구축된다면 새로운 프로세스 필요

 

개발 환경별 빌드해야 하는 경우

[개발/QA(스테이징)/운영] 서버 환경의 경우 : 테스트 요청 시 2벌의 빌드로 요청

• QA 서버로 빌드한 버전 1.0.0.b1 ~
• 운영 서버로 빌드한 버전 1.0.0.rtm

[개발/운영] 서버 환경의 경우 : 테스트 요청 시 1벌의 빌드로 요청

• 운영 서버로 빌드한 버전 : 1.0.0.b1 ~

[예외][개발/운영] 서버 환경이지만 개발 서버에서만 확인이 가능한 경우 : 테스트 요청 시 2벌의 빌드로 요청

• 개발 서버로 빌드한 버전 1.0.0.b1 ~
• 운영 서버로 빌드한 버전 : 1.0.0.rtm

 

버전별 의미

• major.minor[.build[.revision]]
• major.minor[.maintenance[.build]]
• major 변경 : 프로젝트 단위 변경 시 +1
• minor 변경 : 신규 기능 추가 반영 시 +1
• build/maintenance 변경 : 기능 수정 및 개선 항목 반영 시 +1

[참고] 위키피디아
변경과 중요성의 관계
차례열 기반 식별자는 배포판들 간의 변경의 중요성을 알리기 위한 목적으로 사용한다. 이는 식별자들 중, 어느 위치의 문자나 숫자를 변화할 것이냐의 결정은 이전 버전과에서 변경된 정도의 중요성에 따라 결정함으로써 이루어진다. 첫 번째 문자나 숫자가 수정될 수록 가장 중요한 수정이 가해졌다는 의미이며, 다음 순서로 넘어갈 수록 좀 더 그 의미가 줄어들게 된다.

버전 번호가 컴퓨터가 아니라 사람에 의해 기입되는만큼, 자의적인 수정을 막을 수 있는 방법은 없다. 어느 위치의 번호를 조작하느냐에 따라 경우에 따라 작성자의 의도와 달리 잘못된 인식을 심어줄 수도 있다. 일반적으로는 다음과 같은 순서로 이루어진다.

major.minor[.build[.revision]]

혹은

major.minor[.maintenance[.build]]

개발 단계를 지정하기
세번째 자리수가 숫자를 0으로 지정하여 아직 배포하기엔 불충분한 수준 (알파, 베타 버전)을 나타낼 수 있다. 또는 간혹 문자로 표기될수있다. 이는 테스트용 혹은 개발용으로만 사용할 수 있음을 나타낸다. 아래와 같이 세 번째 위치에 사용할 수 있다.

0 - 알파 버전 (alpha)
1 - 베타 버전 (beta)
2 - 발매 버전 후보 (release candidate)
3 - 발매 버전 (final release)

예를 들면 아래와 같다.
1.2.0.1 <- 1.2-a1 에서 수정
1.2.1.2 <- 1.2-b2 에서 수정 (약간 버그 수정하여 베타 버전으로 업그레이드)
1.2.2.3 <- 1.2-rc3 (발매 버전 후보)
1.2.3.0 <- 1.2-r (상업용 배포판)
1.2.3.5 <- 1.2-r5 (많은 버그를 수정한 상업용 배포판)

 

 

상황에 따른 버전

긴급배포(Hotfix) : 업데이트 후 혹은 VOC를 통해 인입된 이슈가 긴급하게 배포되어야 하는 경우 버전

- ex) 1.0.0.h1 ~

📌 정책 : 핫픽스 버전은 rc, rtm 빌드 없이 .h1 ~ 버전으로 배포

[참고] 위키피디아
핫픽스(영어: hotfix 또는 quick-fix engineering update, QFE update)는 제품 사용 중에 발생하는 버그의 수정이나 취약점 보완, 또는 성능 향상을 위해 긴급히 배포되는 패치 프로그램을 말한다.

대부분의 운영 체제와 수많은 독립형 프로그램들은 자동으로 핫픽스를 내려받아 적용할 수 있는 기능을 제공하고 있다. 스크래치로부터 이러한 기능을 만드는 대신에, 개발자는 필요한 라이브러리와 도구를 제공하는 오픈 소스 패키지(이를테면 StableUpdate, JUpdater)나 클로즈드 소스 패키지(이를테면 RTPatch)를 선택하는 경우도 있다.

마이크로소프트 윈도우 환경에서 핫픽스는 특정한 문제를 해결하는 조그마한 패치들을 가리키며 대부분 보안 허점에 해당하는 문제들을 해결한다. 이 핫픽스 파일들은 크기가 작으며 윈도 업데이트 (또는 마이크로소프트 지원)를 사용하여 컴퓨터 상에 자동으로 설치되는 것이 보통이다.

 

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa