(웹)어플리케이션을 '개발' 서버에 배포(deploy)할 때는 소스저장소의 중심개발축(HEAD)에서 전체 최신 개발소스를 가져와서 빌드하고, 빌드결과 파일들을 일괄적으로 통째로 전부 배포해도 대부분 큰 문제가 없다.
배포코스 설계에서 설명한 것처럼 빌드서버중심 코스에서는 빌드서버에서 빌드 후 개발서버로 전송하여 배포하면 될 것이고, 소스저장소중심 코스에서는 개발서버에서 빌드 및 배포를 모두 처리하면 될 것이다.
그러나 배포 대상 서버가 '운영' 서버라면 개발소스 전체를 무차별적으로 배포하는 것은 문제가 된다. 버그가 고쳐지지 않은 모듈, 검증이 덜된 모듈, 아직 공개해서는 안될 모듈 등이 함께 반영될 수 있기 때문이다.
따라서 중심개발축의 개발소스 중에서 stable하고 production-ready 상태의 소스만 선별해서 운영에 반영해야 한다
그럼 어떻게 선별할 것인가? (내가 아는 한) 실현 가능한 선별방법 2가지가 있다(이전 글 참조).
○ 중심개발축으로부터 빌드된 전체 파일들 중에서 반영할 파일들을 하나하나 수작업으로 골라내는 방법
○ 소스저장소에 릴리스 브랜치를 만들어서 여기에 반영할 소스만 모아놓는 방법
전자는 컴파일,테스트,코드검사,패키징,배포까지의 흐름 중간에 사람이 개입하게 되어 자동화가 불가능하는 점, 배포모듈의 정합성이 깨질 가능성이 큰 점 등 여러가지 문제점을 안고 있기 때문에 권장하지 않는 방식이다.
대개는 널리 알려진 후자의 방법을 택한다.(어느 나라? 누구? 어느 분야에서?)
외국의 자료(사이트, 책 등)를 살펴보면 보통 아래와 같은 내용이 포함된다(주관적인 판단일 수 있음).
그러나 이러한 설명은 솔루션/프레임워크/라이브러리의 개발,유지보수 환경에 치우쳐 있다는 느낌을 갖는다(솔직히 Agile, TDD, Maven에 대해서도 마찬가지 느낌을 갖고 있다).
외국에서 '개발'은 솔루션 개발이 default일지 모르나, 국내에서는 개발이라고 하면 (SI/SM프로젝트에서) 웹시스템 개발이 default라고 생각한다.
다음은 내가 생각하는 국내 개발환경에 적합한 배포 방식이다(웹시스템 개발/유지보수에 초점).
고백하건데 이렇게 하는게 국내환경에서 좀더 실용적일 거라고 생각은 하지만, 아직은 실전 프로젝트에서 이를 적용해본 적은 없다. 해보지도 않고 떠들다니...살짝 부끄럽군... -.-;;
태클 대환영!
배포코스 설계에서 설명한 것처럼 빌드서버중심 코스에서는 빌드서버에서 빌드 후 개발서버로 전송하여 배포하면 될 것이고, 소스저장소중심 코스에서는 개발서버에서 빌드 및 배포를 모두 처리하면 될 것이다.
그러나 배포 대상 서버가 '운영' 서버라면 개발소스 전체를 무차별적으로 배포하는 것은 문제가 된다. 버그가 고쳐지지 않은 모듈, 검증이 덜된 모듈, 아직 공개해서는 안될 모듈 등이 함께 반영될 수 있기 때문이다.
따라서 중심개발축의 개발소스 중에서 stable하고 production-ready 상태의 소스만 선별해서 운영에 반영해야 한다
그럼 어떻게 선별할 것인가? (내가 아는 한) 실현 가능한 선별방법 2가지가 있다(이전 글 참조).
○ 중심개발축으로부터 빌드된 전체 파일들 중에서 반영할 파일들을 하나하나 수작업으로 골라내는 방법
○ 소스저장소에 릴리스 브랜치를 만들어서 여기에 반영할 소스만 모아놓는 방법
전자는 컴파일,테스트,코드검사,패키징,배포까지의 흐름 중간에 사람이 개입하게 되어 자동화가 불가능하는 점, 배포모듈의 정합성이 깨질 가능성이 큰 점 등 여러가지 문제점을 안고 있기 때문에 권장하지 않는 방식이다.
대개는 널리 알려진 후자의 방법을 택한다.(어느 나라? 누구? 어느 분야에서?)
외국의 자료(사이트, 책 등)를 살펴보면 보통 아래와 같은 내용이 포함된다(주관적인 판단일 수 있음).
- 어플리케이션은 외부에 릴리스하는 방식으로 배포(distribution)됨
- 브랜치는 릴리스 브랜치(Release Branch)로 불림
- 주요 마일스톤/릴리스 마다 새로운 브랜치를 생성
- 주로 릴리스 브랜치에서 버그를 픽스하고 중심 개발축으로 파일을 병합함
- 동시에 여러 릴리스 브랜치가 유지보수됨
- 주로 릴리스 브랜치 -> 중심 개발축으로 소스가 병합됨
- 브랜치는 릴리스 브랜치(Release Branch)로 불림
- 주요 마일스톤/릴리스 마다 새로운 브랜치를 생성
- 주로 릴리스 브랜치에서 버그를 픽스하고 중심 개발축으로 파일을 병합함
- 동시에 여러 릴리스 브랜치가 유지보수됨
- 주로 릴리스 브랜치 -> 중심 개발축으로 소스가 병합됨
그러나 이러한 설명은 솔루션/프레임워크/라이브러리의 개발,유지보수 환경에 치우쳐 있다는 느낌을 갖는다(솔직히 Agile, TDD, Maven에 대해서도 마찬가지 느낌을 갖고 있다).
외국에서 '개발'은 솔루션 개발이 default일지 모르나, 국내에서는 개발이라고 하면 (SI/SM프로젝트에서) 웹시스템 개발이 default라고 생각한다.
다음은 내가 생각하는 국내 개발환경에 적합한 배포 방식이다(웹시스템 개발/유지보수에 초점).
- 어플리케이션은 외부에 릴리스되는 것이 아니라 운영서버에 배포(deployment)됨
- 그래서 릴리스 브랜치 대신 배포 브랜치(Deploy Branch)라고 이름 바꿈(또는 운영브랜치?)
- 기능추가시 중심 개발축에서 배포브랜치로 운영에 반영할 소스파일을 추가
- 기능수정시 중심 개발축의 소스 수정 후 배포브랜치의 소스와 병합
- 개발 도중 발견된 버그는 중심개발축의 소스를 고친 후 배포브랜치의 소스에 병합시킴
- 운영에서 발견된 버그는 일단 배포브랜치의 소스를 고쳐서 운영에 반영한 뒤에 중심개발축에 병합함
- 하나의 배포 브랜치만 생성하여 유지보수
- 주로 중심개발축 -> 배포 브랜치로 소스가 병합됨
- 그래서 릴리스 브랜치 대신 배포 브랜치(Deploy Branch)라고 이름 바꿈(또는 운영브랜치?)
- 기능추가시 중심 개발축에서 배포브랜치로 운영에 반영할 소스파일을 추가
- 기능수정시 중심 개발축의 소스 수정 후 배포브랜치의 소스와 병합
- 개발 도중 발견된 버그는 중심개발축의 소스를 고친 후 배포브랜치의 소스에 병합시킴
- 운영에서 발견된 버그는 일단 배포브랜치의 소스를 고쳐서 운영에 반영한 뒤에 중심개발축에 병합함
- 하나의 배포 브랜치만 생성하여 유지보수
- 주로 중심개발축 -> 배포 브랜치로 소스가 병합됨
고백하건데 이렇게 하는게 국내환경에서 좀더 실용적일 거라고 생각은 하지만, 아직은 실전 프로젝트에서 이를 적용해본 적은 없다. 해보지도 않고 떠들다니...살짝 부끄럽군... -.-;;
태클 대환영!
'Build&Deploy' 카테고리의 다른 글
| [셀레늄] verify와 assert의 차이점 (1) | 2009.04.20 |
|---|---|
| [셀레늄] 최신 브라우저 별칭 (0) | 2009.04.20 |
| 자동화환경에서 WAS를 핸들링하는 방법 (0) | 2008.10.23 |
| 웹어플리케이션 배포 패키징 유형 3가지 (0) | 2008.10.02 |
| 배포를 위한 어플리케이션 전송 방법 (0) | 2008.10.02 |
