Eclipse를 활용한 효율적인 팀 개발 및 배포 전략

0. 목차

• 0. 소개
• 1. CVS 등을 통한 효율적인 팀 개발
  • 1.1 CVS 및 기타 버전관리툴 소개
    • 1.1.1 CVS 개념
      • CVS 저장소
      • 저장소 접속과 권한
      • 작업을 수행하기 위한 파일 사본 가져오기(checkout)
      • 동기화(synchronize), 갱신(update), 작업 공간의 수정 사항 반영(commit)
      • 충돌(conflict)
      • 충돌나는 변경 사항 해결하기
      • 수정중인 작업자 추적
      • 태그(tagging)
      • 분기(branches)와 HEAD
      • 분기의 병합(merge)
      • 이력(history) 및 차이점 보기(diff)
      • 참고 자료
    • 1.1.2 기타, SubVersion, VSS(Visual Source Safe), Perforce
  • 1.2 eclipse 설정과 기본 사용법
  • 1.3 SCM Best Practices
    • 1.3.1 GUI 툴 사용
    • 1.3.2 개발자 작업공간(Workspace or Sandbox)
    • 1.3.3 소스 코드 라인(Codelines)
    • 1.3.4 브랜치Branching)
    • 1.3.5 변경사항 전파(Propagation)와 병합(Merging)
    • 1.3.6 소프트웨어 빌드(Builds)
    • 1.3.7 조직에서 제도화하기(Process)
    • 1.3.8 결론
• 2. Ant, Maven 을 이용한 빌드 및 배포
  • 2.1 Ant
  • 2.2 Maven 2
    • Project object model(POM)
    • Maven 2 디렉토리 구조
    • 프로젝트 라이프사이클(Project lifecycles)
    • Transitive dependencies
    • Dependency scopes
    • 프로젝트 커뮤니케이션(Project communication
• 3. 토론
• 참고문헌
• 문서에 대하여

0. 소개

이 문서는 오픈 소스 자바 어플리케이션을 개발하기 위해 이클립스가 어떻게 사용될 수 있는지에 대해 설명한다.

팀 개발을 위해서 CVS 등의 버전관리 툴과 함께 이클립스를 사용하는 방법에 대하여 알아보고, Ant, Maven 등을 통한 빌드 자동화 시스템에 대해서 알아보도록 한다. Eclipse 는 버전 3.1 을 이용하였다.

CVS 와 Ant 등을 이용한 개발 프로세스는 다음과 같다.

1. CVS 등을 통한 효율적인 팀 개발

소프트웨어 개발 환경에서 기술적으로 가장 중요한 것은 소스 버전 관리이다. 개발팀에서 작성하는 모든 소스는 버전 관리가 되어야 한다. 프로그램 소스는 물론이고 스크립트, SQL, 각종 문서, 설정 파일들까지 포함해야 한다. 소스 버전 관리의 목적은 작업 기록의 보존을 통해 문제가 발생했을 때 원인을 추적하거나 이전 상태로 되돌리기 위한 것이다. 또한 이러한 정보로 버그 추적이나 감사(audit), 퍼포먼스, 품질 관리 목적에 사용할 수도 있다.

보통 소스 버전 관리를 위해서 CVS(Concurrent Versions System)를 많이 사용한다. CVS는 80년대부터 개발되어 오고 있으며, 오픈 소스 개발을 위한 사실 상의 표준이 되어 버린 버전 제어 도구이다. CVS를 좀 더 개선한 Subversion도 있고 여러 가지 상용 툴도 있지만 여전히 CVS가 오픈소스 공동체에서 가장 많이 쓰이며 IDE와도 잘 통합되어 있다.

소스 관리는 사실 SCM(Software Configuration Management)의 일부분이기도 하다. SCM은 소스에 대한 버전 관리 뿐 아니라 소프트웨어의 기능성 수준에 대한 변동 기록, 버그 수정 내역, 요구사항의 변화 등을 종합적으로 관리하는 것을 말한다. 소프트웨어의 새 버전이 발표되면 보통 릴리스 노트(Release Notes)가 같이 배포되는데 이런 것이 SCM의 대표적인 산출물이다.

상용 SCM 툴도 많지만 보통은 소스 관리에 CVS를 쓰고 이외에는 이슈 트래커를 쓰는 것으로 SCM의 대부분의 영역이 커버됩니다. 소스 외의 형상 관리는 사실 업무 요청 관리와 기능적으로 아주 비슷하기 때문이다. 오픈소스와 친한 사람이라면 버그질라(bugzilla)를 접해본 적이 있을 것이다. 버그를 보고하고 버그가 수정되는 과정을 기록으로 남기고 조회할 수 있게 해주는 시스템이다.

여기서는 eclipse 에서 제공하는 CVS 기능과 기타 plugin 을 통해 소스코드를 개발 팀과 공유하는 기능을 알아보고, 효율적인 버전관리 방법에 대해 살펴보도록 하자.

1.1 CVS 및 기타 버전관리툴 소개

1.1.1 CVS 개념

먼저 몇 가지 기본적인 CVS 개념을 살펴보자.

CVS vocabulary Repository The repository is where the files are stored, often on a server. Sometimes also called a depot (e.g. with Perforce). Commit A commit (or, more rarely, install, submit, check-in or ci) occurs when you copy the changes you made on the local files to the directory (the version control software takes care of knowing which files changed since the last time the two were synchronized). Change A change represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems. Change List / Change Set On many version control systems with atomic multi-change commits, a changelist identifies the set of changes made in a single commit. This can also represent a sequential view on the source code, allowing source to be examined as of any particular changelist ID. Check-Out A check-out (or checkout or co) copies a working copy from the repository (it can be seen as the opposite of an import). Update An update (or sync) copies the changes that were made to the repository into your working directory (it can be seen as the opposite of a commit). Merge / Integration A merge or integration brings together (merges) concurrent changes into a unified revision. Revision A revision or version is one version in a chain of changes. Import The term import is used to describe copying the local directory tree in its entirety from your machine to the repository. Export An export is similar to a check-out except that it creates a clean directory tree without version control metadata (often used prior to publishing the contents). Conflict A conflict occurs when two changes are made by different parties to the same document or place within a document. Since the software may not be intelligent enough to decide which change is 'correct', a user is required to resolve the conflict. Resolve The act of user intervention to address a conflict between different changes to the same document.

CVS 저장소

CVS 서버는 다수의 모듈(modules)을 포함하고 있는 저장소(repository)를 관리한다. java.net의 저장소의 경우 개별 프로젝트는 자신만의 모듈을 가지고 있다.

모듈은 디렉토리와 함께 버전이 부여된 파일을 포함하고 있다. 버전이 부여된 파일은 하나의 파일에 대한 이력을 나타내며, 다수의 개정 이력(revisions)을 포함한다. 파일에 변경이 가해질 때마다, 새로운 개정본(revision)이 생성된다. .java, .xml, .properties 등의 텍스트 기반 파일의 경우, 각각의 개정본은 이전 개정본에서 개정된 내역만을 포함하며, .exe, .jar, .pdf 등의 이진 파일의 경우, 각각의 개정본은 완전한 파일 내용을 포함하게 된다.

CVS는 또한 개정본 생성자와 개정본에 대한 주석, 그리고 개정본 번호도 함께 기록한다. 개정본 번호들은 자동으로 갱신되는데, 대부분의 경우, 파일의 첫번째 개정본 번호는 1.1이고 이후에는 1.2 등의 순서로 갱신된다.

repository    moduleA/          versionedFile1             (revision number="1.1" user="dave" comment="Created")             (revision number="1.2" user="mike" comment="New cache implementation")             (revision number="1.3" user="lucy" comment="Fixed defect D113")          versionedFile2             (revision number="1.1" user="dave" comment="Created")             (revision number="1.2" user="dave" comment="Updated after feedback from Lucy")          directory1/                versionedFile3                   (revision number="1.1" user="lucy" comment="Initial version")                ...    moduleB/        ...

저장소 접속과 권한

CVS 클라이언트는 다양한 프로토콜을 사용하여 서버에 접속할 수 있다. 가장 일반적으로 사용되는 프로토콜은 다음과 같다:

• pserver, CVS를 위한 간단한 프로토콜로 java.net을 이용하여 일반적인 작업을 하는 정도에 적합하다.
• ssh, 추가적인 보안을 위해 SSL을 사용하지만, 보통은 인증서 생성과 같이, 대개 약간의 추가적인 설정 작업이 요구된다.
  접근 권한은 모듈 단위로 설정된다. java.net 저장소의 경우, java.net에 로그인한 모든 사용자는 누구라도 모든 프로젝트 모듈들에 대해서 읽기 권한을 갖게 된다. 프로젝트 모듈에 대한 쓰기 권한은 모듈을 등록한 소유주나 프로젝트 개발자들에만 부여된다.

작업을 수행하기 위한 파일 사본 가져오기(checkout)

저장소에 접속한 이후에는 하나 이상의 모듈을 가져올 수 있다. 이를 checkout 이라고 하는데, *체크아웃*을 하면 CVS에서 여러분의 컴퓨터로 모듈의 최신 내용이 복사되어, 여러분은 모듈 복사본을 가지고 원하는 작업을 수행할 수 있게 된다.

동기화(synchronize), 갱신(update), 작업 공간의 수정 사항 반영(commit)

CVS 클라이언트를 사용하여 로컬 파일과 저장소 파일 사이의 *동기화*를 할 수 있다. 동기화 과정에서 로컬 파일과 CVS의 최신 모듈 사이의 차이점을 볼 수 있다. 이러한 차이들은 다음과 같이 분류 할 수 있다:

• Incoming changes - 저장소에 변경이 생겼지만 로컬 파일에는 반영이 안된 경우.
• Outgoing changes - 여러분의 로컬 파일에 변경이 생겼지만 저장소에는 반영이 안된 경우.
  CVS 클라이언트에서 저장소의 변경 사항(incoming changes)의 일부 혹은 전부를 반영하여 로컬 파일을 갱신(update)할 수 있다. 모듈에 대한 쓰기 권한을 가지고 있는 경우, 로컬 파일의 변경 사항(outgoing changes) 중 필요한 만큼을 저장소에 반영(commit)하는 것도 가능하다.

충돌(conflict)

CVS는 자동적으로 저장소의 변경 사항과 작업 공간의 변경 사항 가운데서 충돌하는 내용을 감지한다. 개발자 A와 B가 동시에 같은 파일을 수정하고, A가 먼저 이를 저장소에 반영(commit)하고 난 후에 곧바로 B가 자신이 변경한 내용을 저장소에 반영하려고 할 때 이러한 충돌이 발생한다.

아래 다이어그램을 보자. 숫자로 된 화살표는 일의 발생 순서를 나타낸다. Alice가 Bob보다 먼저 변경사항을 저장소에 반영하고 Bob이 동기화를 하게 되면 Bob은 상충이 발생했다는 것을 알게 된다.

충돌나는 변경 사항 해결하기

파일에서 상충되는 변경 사항이 발견 될 경우, 파일을 저장소에 반영하기 전에 상충되는 변경 사항에 대해 병합(merge, integrate)을 수행해야 한다. CVS는 한 파일의 서로 다른 행의 변경 사항들에 대한 병합은 자동으로 수행한다. 다만 같은 행에서 변경이 발생할 경우, 개발자가 직접 병합 을 실행해야 한다. 나중에 보겠지만 이클립스는 개발자의 병합을 돕는 매우 훌륭한 GUI를 제공한다.

수정중인 작업자 추적

CVS에서는 동시 수정 가능 잠금 방식(optimistic locking)을 사용하여 누구라도 CVS 저장소에 접근에 동시에 파일을 수정 가능하지만, 누가 어떤 것을 수정하고 있는지 알아낼 수 있도 있다. 파일 수정 작업을 시작할 경우, 클라이언트가 이 사실을 서버로 알리도록 설정될 수 있다. 만약 누군가 파일을 수정하려고 하면 이미 그 파일이 수정 중이라는 경고를 받을 수 있다. 이것은 수정 사항의 충돌을 피하는 유용한 방법이다.

태그(tagging)

개발할 때 여러분은 종종 다음과 같은 이정표(milestones)들에 도달하게 된다:

• "기본 시스템은 작동중이고 모든 테스트는 통과 했음"
• "account 작업 전의 리팩토링"
• "account 작업 후의 리팩토링"
• "릴리즈 1.4"
• "발견된 D113에 대한 수정 완료"
  이러한 이정표를 표시해두는 것(marking)은, 변경 사항을 추적하고, 필요한 경우, 이전 상태로 파일들을 되돌릴 수 있도록 보장해주는데 있어 필수적이다.
  CVS에서는 모듈에 태그를 붙임으로써 이정표를 표시하게 된다. 태그는 모듈 안에 있는 각각의 파일들에 대한 단일 개정본(single revision)을 취합한다.
  
  
  
  태그의 이름은 이정표와 관련있다. ALL_TESTS_PASS와 같은 것은 직관적인 예다.

사용자는 모듈의 태그가 부여된 개정본을 저장소에서 가져올 수 있다. 설령 태그가 삭제되거나 변경되었다 하더라도 태그가 붙었던 버전의 모듈 내용물은 항상 같을 것이다.

분기(branches)와 HEAD

분기(branch)는 일련의 독립적인 개발 흐름을 유지하기 위해 쓰인다. 기본적으로 저장소의 내용과 작업 공간의 내용의 동기화를 위해 update나 commit 명령을 사용하면, HEAD라고 불리는 기본 분기(trunk 라고도 불리운다) 상에서 작업이 이루어진다.

사용자는 필요에 따라 새로운 분기를 생성할 수 있다. 분기는 항상 루트 태그(root tag)라 불리는 태그부터 반드시 시작되어야 하며, 루트 태그의 이름에는 특별한 규칙이 없다.

분기를 사용하는 목적인 대개 공식 배포(release)의 병렬적인 개발을 관리하기 위함이다. 예를 들어 어플리케이션의 1.4 버전을 공식 배포(Release) 했고 계속해서 HEAD 분기에서 2.0 버전을 개발하기 시작했다고 해보자. 만약 치명적인 버그가 1.4 에서 발견되었다는 사용자의 보고가 있다면 RELEASE1-4-0을 루트 태그로 사용하여 분기를 만들 수 있다.

태그는 HEAD에서 정의되는 것과 마찬가지로 다른 분기에서도 정의 될 수 있다. 가능하다면 한 수준 정도(one level)의 분기를 고수하는 것이 가장 좋지만, HEAD 이외의 분기에서도 또 다른 분기를 만들 수 있다.

태그가 부여된 버전은 변하지 않는다. 모듈의 태그가 부여된 버전에 대해서는 변경 사항을 저장소에 반영할 수 없고, 수정을 하려면 루트 태그를 사용하여 분기를 생성해야 한다. CVS에서는 분기에 속한 변경 사항들만 저장소에 반영 할 수 있다. HEAD는 기본 분기로 특수한 형태의 분기이다.

분기의 병합(merge)

필요한 경우에 변경 사항을 특정 분기에서 다른 분기로 병합 할 수 있다. 예를 들어 위 그림에서, 버그를 수정한 1.4.1의 변경 사항을 2.0.0 정식 배포판에 포함시키기 위해서 HEAD 분기로 병합을 할 수 있다. 두 개의 분기 사이의 병합은 저장소와 작업공간의 변경 사항 동기화와 유사하며, 마찬가지로 상충이 발생하는 경우는 이클립스 GUI를 활용하면 좀 더 수월하게 해결할 수 있다.

이력(history) 및 차이점 보기(diff)

CVS는 개별 파일이나 파일 조합의 변경 이력을 볼 수 있는 다양한 방법을 제공한다. 또한, CVS를 이용하면 각각의 수정본, 태그 그리고 분기들 사이의 차이를 볼 수 있다.

참고 자료

• 이클립스 3.1 도움말의 CVS를 이용한 팀 프로그래밍은 개념 수준의 개요를 제공한다.
• CVS를 이용한 오픈 소스 개발이라는 책은 매우 좋은 내용을 담고 있지만 명령 행을 통해 CVS를 사용하는 것을 전제하고 있다. 기본적인 개념을 설명하는 장에서 CVS에 관련된 거의 대부분의 사항을 다루고 있다.

1.1.2 기타, SubVersion, VSS(Visual Source Safe), Perforce

• Subversion
  • CVS의 단점인 디렉토리 삭제, 이동이 자유로우며,
  • 원자적 커밋(atomic commit) 및 서버로 아파차웹서버를 사용하여 확장성을 용이하게 하였고,
  • Eclipse 플러그인, TortoiseSVN 등 다양한 client 들도 등장하고 있다.
  • 장점은 박재성님의 Subversion을 좋아하게 되는 10가지 이유 참조.
  • Subclipse 플러그인으로 eclipse 와 연동가능하다.
  • 플러그인 설치 및 연동 법
• VSS
  • MS 제품으로 Visual Studio 제품군에 포함되어 있다.
  • 개인적으로 간단히 사용하기에는 편하다.
  • VSS 설치와 Eclipse와의 연동 문서 참조
• Perforce
  • 상용이나 오픈소스 프로젝트를 위한 라이센스 지원
  • 편리한 GUI 툴 제공
  • 대부분의 IDE 플러그인 지원

    작업중인 내역	변경된 내역	브랜치 관리

1.2 eclipse 설정과 기본 사용법

cvsnt설치 및 eclipse 에서 cvs연결하는 방법은 다음의 사이트들을 통해 익힐수 있다.

• 설치 및 eclipse 와의 연동 및 사용법(기초, 플래쉬강의)
• Eclipse와 CVS를 이용하여 팀 작업하(자바지기)기

제대로 연결 되었다면 CVS Repositories perspective 에서 다음 화면을 볼수 있다.

1.3 SCM Best Practices

지금까지는 사용법에 관해 알아보았다. 실제 팀내 개발이 제대로 이루어지려면 모든 개발자들이 사용법 숙지를 기본으로 해야 한다.

프로젝트가 커지고 모듈이 많아지고 릴리스가 계속 되고 있는 복잡한 제품을 관리하고 있다면 이런 것 외에 알아야 할 것이 더 있다.
업계에서 알려진 효율적인 버전관리법에 대해 알아보도록 하자.

1.3.1 GUI 툴 사용

자동화와 관련된 것이 아니라면 콘솔창은 매우 불편하다. 우리의 두뇌를 명령어 익히는 작업에서 보다 고차원적인 일을 하도록 유도해야 한다.

eclipse를 사용한다면 대부분의 SCM 이 plugin 형태로 지원되므로 history, diff, merge등을 편하게 사용할 수 있다. Windows 사용자라면 TortoiseCVS(추천), WinCVS 등을 이용하면 revision graph 등 CVS 를 좀 더 편하게 사용할 수 있고, Araxis Merge 같은 상용 merge 툴을 사용해도 좋다.

1.3.2 개발자 작업공간(Workspace or Sandbox)

개발자가 빌드, 테스트, 디버그를 하는 공간이다.

• 워크스페이스를 공유하지 말라.
• 관리되지 않는 워크스페이스에선 작업하지 말라.
• 코드라인과 항상(자주) 동기화 시켜라.
• 자주 체크-인(check-in) 하라. process 를 수립하는 것이 좋다.

1.3.3 소스 코드 라인(Codelines)

소스 파일들의 의미있는 집합을 얘기한다.

• 각 코드라인마다 정책을 정하라.
• 코드라인마다 책임자를 두어라.
• 메인라인(mainline, trunk)을 유지하라.
  

1.3.4 브랜칭(Branching)

새로운 코드라인을 만드는 것을 의미한다.

• 필요할 때만 브랜치 하라.
• 단순 복사가 브랜치는 아니다.
• 정책이 틀려질때 브랜치하라.
• 최대한 늦게 브랜치하라.(충분히 검토하고 하라)
• 코드 동결시키기 보다는 브랜치하라.
  

1.3.5 변경사항 전파(Propagation)와 병합(Merging)

한쪽 코드라인에서 변경된 사항을 다른 쪽에도 반영시키는 것을 말한다.

• 원본에 대한 변경은, 브랜치 된 이후 가장 적게 변화된 브랜치에서 하라.
  (ex. 릴리즈 브랜치에서 버그를 코친후 변경사항을 메인라인에 병합(merge) 한다.)
• 일찍, 자주 전달하라.
• 적합한 사람에 병합을 맡겨라
  (ex. 소스(source) 코드라인 책임자 또는 대상(target) 코드라인 책임자)

1.3.6 소프트웨어 빌드(Builds)

소스 파일을 제품으로 바꾸는 과정이다.

• 소스와 툴이 제품이 된다.
• 원본 소스를 모두 체크-인 하라.
• 빌드된 오브젝트들을 소스와 분리하라.
• 공통적인 빌드 툴을 사용하라.
• 자주 빌드하라.
• 빌드 로그와 산출물을 모두 저장하여 유지하라.

1.3.7 조직에서 제도화하기(Process]

위의 모든 과정들의 규칙.

• 변경 패키지를 추적하라. (변경 패키지란, 특정 버그나 기능추가로 변경된 파일들의 묶음을 의미)
• 변경 패키지의 전달(propagation) 내역도 추적하라.
• 요구사항과 변경 패키지를 구별하라.
• SCM에 있는 모든 프로세스, 정책, 문서, 제품, 컴포넌드, 코드라인, 브랜치, 작업 에 책임자를 두어라.
• 문서는 항상 최신버전으로 유지하고, 활용하라.

1.3.8 결론

"툴은 잘 사용했을 때 좋은 것이다".

단순히 CVS , Subversion, Clearcase, perforce, accurev, 등의 SCM 툴을 설치하고 명령어 몇개를 사용한다고만 해서 제대로 쓰고 있다는 것은 아니다. 프로그래밍 언어만 안다고 해서 프로그래밍을 잘 안다고 할 수 없듯이, SCM 툴을 활용하는 데도 그만한 시간과 노력이 필요하다.

이슈 추적 시스템 여기에서 직접 소개하지는 않았지만 Issue(bug) tracking system(버그 추적 시스템, 이슈 추적 시스템)의 사용도 고려해 봐야한다. 버그를 추적하고 메모를 기록하고 작업 목록을 유지하는 훌륭한 도구이다. 모든 문제점과 기능 요청 사항을 한 곳에 모을 수 있으므로 프로젝트 관리에 도움을 준다. 유명한 것으로 버그질라, Mantis, TUTOS, Atlasian의 JIRA등이 있다.

2. 빌드 및 배포 자동화

프로젝트 컴파일은 귀찮은 일이다. 믿을 만하고 반복가능하게 만들어야 한다. 일관성과 정확성을 보장하는 훌륭한 방법은, 팀이 하는 모든 일을 자동화하는 것이다. XP(Extreme Programming)의 지속적인 통합(Continuous Integration)에서는 빌드 자동화를 가장 중요하게 다룬다. 빌드는 비어 있는 디렉토리 하나를 가지고 프로젝트를 밑바닥에서부터 만드는 과정으로, 무엇이건 여러분이 생산해 내고 싶은 최종 제품을 만들어 낸다.

프로젝트 빌드의 전형적인 단계 자동화의 기본적인 개념 및 프로세스는 비슷하다. (0.소개 부분의 그림 참조) Check-out : 저장소(repository)에서 소스코드를 가져온다. update 를 통해 가져오기도 한다. Build, test : 툴에서 제공하는 파일(ex. build.xml, makefile, project.xml 등)을 이용하여 빌드한다. 회귀테스트 등을 수행한다. Deploy : 실제 사용자에게 보내질 전체 제품을 만든다.(ex. CD, 웹사이트에 배포) 예제와 문서 등이 포함되기도 한다. Test : 테스트를 실행한다.

잘 관리되고 있는 프로젝트는 매일 빌드(daily builds)를 한다. 매일 야밤에 빌드를 수행하여 그 성공/실패 결과를 이메일등을 통해 개발자들에게 알리거나 다음날 아침에 확인할 수 있게 한다.

이런 빌드를 자동화하기 위해 여러가지 툴을 사용할 수 있는데, 유닉스/리눅스 환경에선 오래 전부터 make를 사용해 왔다. Makefile 이라는 파일에 빌드를 위한 스크립트를 작성한후 make 명령을 실행하면 빌드가 된다.

하지만 make에서 지원하는 기능이 너무 빈약해서 빌드가 복잡할 경우 Makefile에 모든 빌드 과정을 기술해야 하기 때문에 Makefile이 복잡해져서 유지보수가 힘들다는 문제가 있다. 그래서 자바 진영에서는 make를 넘어서는 툴을 만들고자 했고 그래서 2000년 7월 Ant가 등장했다. 그러나 Ant 역시 한계가 있었기 때문에 Ant를 한 단계 더 발전시킨 Maven이 등장했다. 현재 대부분의 오픈소스 자바 프로젝트는 Ant나 Maven 둘 중의 하나를 빌드 도구로 사용하고 있다.