올챙이시절 기록소

Version 버전정책 만들어 보기 본문

2016/5월

Version 버전정책 만들어 보기

allroundplayer 2017. 9. 20. 15:14


삼국통일의  원을 세우는 유비의 마음으로


버전정책을 수립하게 되었다.


제품은 여러가지 컴포넌트로 구성되어 있고


마찬가지로 각 컴포넌트도 고유한 버전을 가져야 한다.





타산 지석의 기지를 발휘하여 오라클센세는 어떻게 하나 확인 해보았다.


다른 제품과 비교해 보진 않았지만, 역시 최고 존엄이라 생각한다.


SQL> select comp_name, version from dba_registry;


COMP_NAME   VERSION

-------------------------------------------------- --------------------

OWB           11.2.0.4.0

Oracle Application Express   3.2.1.00.12

Oracle Enterprise Manager   11.2.0.4.0

OLAP Catalog   11.2.0.4.0

Spatial            11.2.0.4.0

Oracle Multimedia   11.2.0.4.0

Oracle XML Database   11.2.0.4.0

Oracle Text            11.2.0.4.0

Oracle Expression Filter            11.2.0.4.0

Oracle Rules Manager   11.2.0.4.0

Oracle Workspace Manager   11.2.0.4.0

Oracle Database Catalog Views           11.2.0.4.0

Oracle Database Packages and Types   11.2.0.4.0

JServer JAVA Virtual Machine   11.2.0.4.0

Oracle XDK            11.2.0.4.0

Oracle Database Java Packages    11.2.0.4.0

OLAP Analytic Workspace   11.2.0.4.0

Oracle OLAP API           11.2.0.4.0


* 우리회사 제품의 버전도 이렇게 확인 가능하면 얼마나 좋으려나


* 릴리즈 정책 ( PSR, PSU, CPU, SPU )도 정말 잘 만들었다.  







버전에 사용된 각 숫자는 무슨의미가 있을까?


그것이 제일 중요한 것 





한글로 번역해도 어렵다 그냥 이렇구나 하고 넘어가자.


제일 중요한 것은 관계자에게 설명이 가능해야 한다는 것이다




감을 잡고 싶다면 아래블록의 내용을 조금 더 읽어보자


개발 단계를 지정하기

첫 번째 문자가 숫자를 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 (많은 버그를 수정한 상업용 배포판)


이런들 저런들 어떠하리, 중요한 건 관계자에게 설명이 가능해야 한다


우리 회사에선 이미 1.0.0 과 같은 3자리 버전 정책을 사용중이다.  


하지만 숫자가 변경될 때, 기준이 모호하다.  (큰 변화, 중간변화, 작은변화)






제일 중요한 것을 정하지 못하였다. 


( ... )


기존의 틀을 따라야함이 답답하지만,


할 수 있는 범위내에서 최선을




각 콤포넌트의 버전표기법은 이와 같다





$1 : 제품군 (3자리)


$2 : 콤포넌트는 (1~10자리)


$3 : 날짜 (6자리 YYMMDD)


$4 : 차수 ( 2자리 )








제품 버전( 콤포넌트의 집합 )에는 


(  QA용어로는 BASELINE이라고도 한다.  )


숫자버전을 기입하여 기존프로세스에 혼동이 없게 하였다.


mfo533_170920.01





1년이 지난 지금은 이렇게 잘 사용하고 있다.









그러나 Baseline에 사용되는 각 숫자에 의미와


Git을 사용할 때 브랜치정책을 정하지 못한 건 아쉽다.




Comments