일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Gradle
- hadoop
- elasticsearch
- Angular2
- Linux
- Spring
- 도메인주도설계
- Spring XD
- elastic search
- hdfs
- design pattern
- nginx
- hibernate
- Storm
- Spring Batch
- SBT
- 엘라스틱서치
- 스프링 배치
- 제주
- Clean Code
- docker
- intellij
- Java
- apache storm
- DDD
- 인텔리J
- Spring Boot
- spark
- Hbase
- scala
- Today
- Total
목록Story/Product Management (2)
욱'S 노트
릴리이즈 시나리오 1. 버젼을 릴리이즈로 변경한다. (pom.xml 혹은 build.gradle에서 변경)2. 릴리이즈를 수행한다.3. 해당 버젼의 소스를 태깅한다. (1.0.0, 1.0.1, 2.0.0)4. trunk의 마이너버젼을 올리고 스냅샷 버젼으로 변경한다. (1.0.0 릴리이즈 했으면 1.1.0-SNAPSHOT이 된다.)5. 즐겁게 새로운 기능을 개발한다. 배포한 버젼에서 오류 발생시 1. 1.0.0 소스를 기준으로 1.0.1 태깅을 생성한다.2. 1.0.1 태깅의 버젼을 1.0.1-SNAPSHOT으로 변경하고 버그를 고친다.3. 다시 릴리이즈 절차에 따라 1.0.1 릴리이즈를 수행한다.4. 고친걸 1.1.0 개발중인 곳에 잘 머지한다. 릴리이즈 예제(git)
항상 우리는 소프트웨어를 코딩해서 만들어내고 있지만 생각보다 많은 프로덕트에서 제대로된 버젼관리를 못하고 있는 것 또한 현실이다. 이에 전 회사 동료 및 여러 개발자분들에게도 조언을 구해도 딱히 정답이 없다는 것도 사실인 것 같다. 하지만 여기서는 내가 생각하는 가장 기본적인 버젼관리 방법을 정리해보겠다. Most used 프로덕트 버젼 관리에서는 명확한 convention이 있는 건 아니지만, 대부분의 오픈 소스들이 가장 많이 쓰는 방식은 아래와 같다. 여기서 내가 가장 선호하는 방식은 1.0.1-SNAPSHOT과 같은 방식이다. 메이져버젼이 올라갈 때는 하위 호환성이 없다는 것을 의미하며 마이너버젼은 기능의 변경 그리고 버그픽스를 위한 버젼을 남겨둔다. Qualifier의 역할은 maven과 같은 라..