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

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

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

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

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

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

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

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

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

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

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

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



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

태클 대환영!
신고
Posted by 에코지오

댓글을 달아 주세요

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

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

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

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

지금 몸담고 있는 회사의 빌드관련 문서에는 build와 deploy를 이렇게 정의하고 있다.

- build : 소스를 실행가능한 모듈로 변환하는 것
- deploy : 빌드되어 실행가능한 결과물을 컨테이너에서 인식가능한 곳에 배치하는 것

build는 별로 어렵지 않지만 deploy는 곰곰이 생각할 것이 많다. 내용상으로는 install과 비슷하고, 번역용어가 distribution과도 헷갈린다.

실행가능한 모듈을 실행 가능한 곳에 위치시키고 설정하는 것. install 아닌가?  그러나 OS위에서 작동하는 소프트웨어에 대해서는 대개 install이라 하고, WAS같은 컨테이너에서 작동하는 어플리케이션이나 재사용 레포지토리에 저장되는 서비스모듈에 대해서는 deploy라고 구별하는 것 같다 (이게 소프트웨어와 어플리케이션/라이브러리의 차이에서 오는 개념구분인지도 모르겠다).

deploy 및 관련된 deployables, distribution의 개념에 대해 개인적으로 다시 정리해보았다.

* deployables(deployable application)
- 정의 : WAS같은 컨테이너 상에서 실행가능한 어플리케이션.
- 설명 : 자바 환경이라면 war,ear,jar 같은 것들을 말한다. deployables는 소프트웨어 distribution의 한가지 형태라고 봐도 될듯하다. 근데 이걸 뭘로 번역할지는? 배포물? 배포가능 어플리케이션?

* deploy (deployment)
- 정의 : deployables를 실제 컨테이너에 배치(arrange? allocate?)하는 작업. 
- 설명 : 간단히 말하면 어플리케이션을 WAS 상에 설치(install)하는 것이다. deploy는 전개,배치,배포 등으로 다양하게 번역되며 보통 디플로이 또는 배포라고 부른다. 그러나 배포라는 표현은 distribution과 혼동을 일으키기 쉽기 때문에 개인적인 의견으로는 배치가 더 맞는 표현이 아닐까 생각하지만, 역시나 배치라고 불렀을 때 batch와 발음이 같아서 또다른 혼동을 일으킬 수 있다.

* distribution
- 정의: 누군가에게 전달(delivery)하기 위해 패키징된 소프트웨어. (또는 그것을 전달하는 행위)
- 설명 : 사전적으로는 분배,배분,배포의 의미를 가지며 보통 배포본, 배포판으로 번역한다.

ps1. IBM 프로젝트 자동화 아티클에서는 deployment를 전개로, distribution을 배포로 번역했다. 헷갈리게시리...-.-;

ps2. 위의 deploy 정의는 웹어플리케이션 개발 영역에서나 통하는 정의이고 이전에 언급했듯이 메이븐에서는 아티팩트를 저장소에 올리는 걸 deploy라고 부른다. 그래서 메이븐 처음 접하면서 오해하게 되는 게, 메이븐이 웹어플리케이션을 WAS에 배포하는 것까지 간단하게 해준다고 생각한다. 천만에 만만에 콩떡인거다.

ps3. 소스를 컴파일/빌드하여 생긴 결과물을 뭐라고 부르는게 좋을까?
빌드결과물? 빌드산출물? 배포본? 에셋? 바이너리? 실행파일번들? 빌드모듈?
개인적으로는 빌드산출물이 맘에 든다.

ps3. deployables. 이건 deployable thing을 표현한 단어인데, cargo에서 아이디어를 따왔다. 실제 이런 단어가 있는건 아닌거 같다.
신고
Posted by 에코지오

댓글을 달아 주세요

  1. BlogIcon 에코지오 2008.11.15 08:06 신고  댓글주소  수정/삭제  댓글쓰기

    http://softwaredev.tistory.com/entry/빌드와-컴파일의-차이

  2. BlogIcon 에코지오 2009.10.07 10:55 신고  댓글주소  수정/삭제  댓글쓰기

    빌드결과물 : 실행파일도 좋은듯.



티스토리 툴바