(웹)어플리케이션을 '개발' 서버에 배포(deploy)할 때는 소스저장소의 중심개발축(HEAD)에서 전체 최신 개발소스를 가져와서 빌드하고, 빌드결과 파일들을 일괄적으로 통째로 전부 배포해도 대부분 큰 문제가 없다.

배포코스 설계에서 설명한 것처럼 빌드서버중심 코스에서는 빌드서버에서 빌드 후 개발서버로 전송하여 배포하면 될 것이고, 소스저장소중심 코스에서는 개발서버에서 빌드 및 배포를 모두 처리하면 될 것이다.

그러나 배포 대상 서버가 '운영' 서버라면 개발소스 전체를 무차별적으로 배포하는 것은 문제가 된다. 버그가 고쳐지지 않은 모듈, 검증이 덜된 모듈, 아직 공개해서는 안될 모듈 등이 함께 반영될 수 있기 때문이다.

따라서 중심개발축의 개발소스 중에서 stable하고 production-ready 상태의 소스만 선별해서 운영에 반영해야 한다

그럼 어떻게 선별할 것인가? (내가 아는 한) 실현 가능한 선별방법 2가지가 있다(이전 글 참조).

○ 중심개발축으로부터 빌드된 전체 파일들 중에서 반영할 파일들을 하나하나 수작업으로 골라내는 방법
○ 소스저장소에 릴리스 브랜치를 만들어서 여기에 반영할 소스만 모아놓는 방법

전자는 컴파일,테스트,코드검사,패키징,배포까지의 흐름 중간에 사람이 개입하게 되어 자동화가 불가능하는 점, 배포모듈의 정합성이 깨질 가능성이 큰 점 등 여러가지 문제점을 안고 있기 때문에 권장하지 않는 방식이다.

대개는 널리 알려진 후자의 방법을 택한다.(어느 나라? 누구? 어느 분야에서?)
외국의 자료(사이트, 책 등)를 살펴보면 보통 아래와 같은 내용이 포함된다(주관적인 판단일 수 있음).

- 어플리케이션은 외부에 릴리스하는 방식으로 배포(distribution)됨
- 브랜치는 릴리스 브랜치(Release Branch)로 불림
- 주요 마일스톤/릴리스 마다 새로운 브랜치를 생성
- 주로 릴리스 브랜치에서 버그를 픽스하고 중심 개발축으로 파일을 병합함
- 동시에 여러 릴리스 브랜치가 유지보수됨
- 주로 릴리스 브랜치 -> 중심 개발축으로 소스가 병합됨

그러나 이러한 설명은 솔루션/프레임워크/라이브러리의 개발,유지보수 환경에 치우쳐 있다는 느낌을 갖는다(솔직히 Agile, TDD, Maven에 대해서도 마찬가지 느낌을 갖고 있다).
외국에서 '개발'은 솔루션 개발이 default일지 모르나, 국내에서는 개발이라고 하면 (SI/SM프로젝트에서) 웹시스템 개발이 default라고 생각한다.

다음은 내가 생각하는 국내 개발환경에 적합한 배포 방식이다(웹시스템 개발/유지보수에 초점).

- 어플리케이션은 외부에 릴리스되는 것이 아니라 운영서버에 배포(deployment)됨
- 그래서 릴리스 브랜치 대신 배포 브랜치(Deploy Branch)라고 이름 바꿈(또는 운영브랜치?)
- 기능추가시 중심 개발축에서 배포브랜치로 운영에 반영할 소스파일을 추가
- 기능수정시 중심 개발축의 소스 수정 후 배포브랜치의 소스와 병합
- 개발 도중 발견된 버그는 중심개발축의 소스를 고친 후 배포브랜치의 소스에 병합시킴
- 운영에서 발견된 버그는 일단 배포브랜치의 소스를 고쳐서 운영에 반영한 뒤에 중심개발축에 병합함
- 하나의 배포 브랜치만 생성하여 유지보수
- 주로 중심개발축 -> 배포 브랜치로 소스가 병합됨



고백하건데 이렇게 하는게 국내환경에서 좀더 실용적일 거라고 생각은 하지만, 아직은 실전 프로젝트에서 이를 적용해본 적은 없다. 해보지도 않고 떠들다니...살짝 부끄럽군... -.-;;

태클 대환영!
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

  1. dohwaji 2008.10.24 20:19 신고  댓글주소  수정/삭제  댓글쓰기

    태클은 아니고요.^^ 그냥 경험담..

    브랜치와 병합기능을 써보니
    소스에 CVS Keyword($Date$,$Revision$등)가 있을 경우
    소스가 수정되고 커밋될 경우 head와 branch가 영영 달라지게 됩니다.
    즉 그 이후 부턴 병합을 위한 비교가 안되요. 제약사항이 발생합니다.

    CVS Keyword를 쓰지 않으면 상관없구요.
    일반적인 SI코딩 규칙에 CVS Keyword가 빠지지 않더라구요...

흔히 개발서버나 테스트서버에 웹어플리케이션을 배포할 때는 프로젝트의 모든 빌드된 파일(class,jsp,html,...)을 한꺼번에 배포한다.

그러나 운영서버 반영은 상황이 다르다. 운영서버에는 전체 어플리케이션 파일을 한꺼번에 배포하지 않고 테스트가 통과된 검증된 파일만 반영해야 하기 때문이다. 또한 대개 업무팀에서 특정 기능 또는 화면을 골라서 운영에 반영해달라고 요청이 들어온다.

전체 프로젝트 소스에서 일부만 운영에 반영하기 위해 어떻게 하는게 최선일까?

1. FTP 프로그램 등에서 그냥 반영할 파일을 골라서 업로드하는 방법.
난 지금껏 이 방법을 써왔다. 물론 시스템오픈 전에 막바지 구축단계에서.

2. 무조건 최신 소스를 받아서 반영.
소스저장소의 중심개발축(HEAD, Trunk)에 소스를 받아서 빌드하고 그냥 전부 일괄로 반영. 배째라식.

3. 중심개발축 소스를 태깅하고 태깅된 소스를 받아서 반영.
태깅은 전체소스에 다 태그를 붙이기 때문에 반영할 소스가 아닌 것도 반영될 수 있다. 정말로 반영을 원하는 것만 가져오려면 운영에 반영할 소스들만 커밋하게 해야 하는데 이게 쉽지 않다.

4. 운영 반영용 브랜치(릴리스브랜치)를 따서 반영하는 방법
릴리스 브랜치를 만들고 중심개발축에서 운영에 반영할 소스만 골라서 릴리스 브랜치에 병합한 뒤
릴리스브랜치 소스를 커밋한다. 이후 운영반영용 빌드는 릴리스 브랜치의 소스만 취합해서 빌드,테스트하고 운영서버에 반영하는 식이다.

관련 책이나 자료를 보면 4번 방법을 많이 적용하는 것이 정석이라고 나온다.
그러나 내 경험도 그렇고 내 주위에는 1,2번 방법으로 흔히 처리한다. 내가 SM 경험이 없고 SI만 해봐서 그런 걸수도 있고...

시스템 오픈 전에는 그냥 1,2번 방식으로 하고 오픈 후 안정화되고 나면 4번 적용하는게 맞는걸까?

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

  1. 최자 2010.06.15 14:40 신고  댓글주소  수정/삭제  댓글쓰기

    에코지오님 글 잘 보고 갑니다.

    운영서버에 소스 반영시 일부 파일만 골라서 반영하기 글에서 4번 위주로 구성할려고 하는데요..

    관련 서적 있으시면 추천 좀 해주세요. 혼자서 할려니 구성에 조금 무리가 있는것 같습니다 ^^

  2. BlogIcon Tresa 2012.02.09 21:00 신고  댓글주소  수정/삭제  댓글쓰기

    이 블로그 입니다 아주 식사 . I 이 없습니다 에 가족 .



티스토리 툴바