2010년 4월 13일 화요일

release 관리

제품에 대한 릴리즈 정책은 중요하다.
우리는 SVN으로 형상관리를 하고 있으며 trunk/branches/tags 로 관리되어 지고 있다.
trunk는 현재의 Main Stream으로 진행중인 개발코드가 관리 되어지며 tags에는 릴리즈된 버전, branches에는 현재 릴리즈된 버전의 패치 버전을 관리 하게 된다.

개발자들은 trunk 로 작업을 하게 되고 릴리즈된 버전의 버그나 오류가 발견됐을 시의 패치를 할 경우 tags에 있는 릴리즈 버전을 branches로 옮겨서 해당 버그를 패치 하기 위해 branches 를 체크아웃 받아서 작업을 수행하게 된다.

패치가 완료가 되면 패치버전을 추가 시켜서 릴리즈를 한다.
지금 까지가 현재 우리가 적용하고 있는 정책이다.

현재 개발 버전 : 1.0.0-SNAPSHOT
제품 릴리즈 버전 : 1.0.0
즉 현재 개발 버전에 SNAPSHOT을 빼고 릴리즈.
패치가 필요할 경우  : 1.0.0.0 - > tags에 릴리즈 된 것을 branches 로 옮긴다

제품 릴리즈에 적용하고 있는 기술을 maven-release-plugin을 사용하고있다.
제품에 대한 버전 변경관 배포를 자동으로 해주는 maven 플러그인이다.

 maven-release-plugin을 적용하기 위해 pom.xml에 다음을 추가해준다.

펼쳐두기..



현재 Main Stream을 tags로 옮기기.

새로운 워크스패이스를 만들어서  trunk 에 현재 릴리즈 할것을 모두 체크아웃 받자.
> svn co --username nextree  http://localhost/svn/nextree /trunk

trunk > mvn release:prepare
- > release버전, tags 라벨, 다음 개발버전(SNAPSHOT)지정.

위의 작업이 완료되면.
pom.xml에 추가되어 있는 모듈들이 trunk하위에는 다음 개발버전으로 변경되어 있고 tags하위에는 추가한 라벨 하위에 release버전으로 추가되어있다.

prepare 에서 실패를 하였을 경우
> mvn release:rollback

prepare가 성공을 하였다면
mvn release:perform
perform을 실행하면 release된 버전들은 개발 아티팩토리에 deploy 한다.

이제 개발자들은 새로운 SNAPSHOT으로 개발을 해야 하므로 버전 업된 SNAPSHOT들을 아티팩토리에 배포하여준다.





2010년 4월 2일 금요일

NSIS로 배포된 RCP 실행파일 만들기

 필요사항

2, 모두 설치를 하였으면 에디터를 실행 해보자.

파일 - > 스크립트 작성 마법사


* 프로그램 배포자 : 플라워팀
* 프로그램 웹사이트 : http://www,flowerteam.kr/console

* 인스톨 경로를 고정 하려면 체크박스 해체.
* 사용할 약관 경로 설정
** 처음에 기본적으로 나오는 폴더가 있는데 그 폴더를 선택하고 X
**트리 아이콘을 클릭하면 EditDirectory 창이 나오고 설치할 디렉토리의 경로를 잡아준다
* 프로그램 시작 메뉴 : Flowerteam/blooma

* 위의 방식대로 했다면 nsi 파일이 생성된다.
* .nsi 파일은 NSIS 에서 제공하는 스크립트로 작성되어 있다.
* 기본 설치 파일을 컴파일 하면 exe 파일이 생성된다.

* 스크립트 수정
- 삭제 부분을 모두 지우고
  RMDir /r "$INSTDIR"
  RMDir /r "$SMPROGRAMS\Flowerteam"
  DELETE $DESKTOP\blooma.lnk
로 수정.

- 완료가 되었으면 NSIS - > 스크립트 컴파일
- BloomaSetup.exe 파일이 생성된다.

실행.



svn dump and load

SVN 저장소 백업 및 복구는 매우 중요하다.

예를 들어 현재 192.168.10.xxx 서버를 사용하고 있는데 서버가 고장이 났거나 특수 사정으로 인하여 서버를 바꿔야 한다 - >  192.168.10.aaa 로 서버가 바뀌었다고 가정.

물론 개발자들이 가지고 있는 소스를 다시 aaa 서버로 이관 시키면 된다고 생각 할 수 있겠지만 그것보다는 xxx 서버의 저장소 정보를 주기적으로 백업하여 관리하다가 aaa서버로 이관 시키고 개발자들은 싱크를 맞추는 것이 좋다.

저장소 백업: svnadmin dump {저장소 경로} > {파일명}
- 리비전 정보까지 모두 백업 된다.

저장소 load : svnadmin load {저장소 경로} < {파일명}