SVN, Redmine, Hudson, Ant 통합 개념 그리고 maven, nexus 란 무엇인가 개념잡기

◈ 개발도구의 도움으로 개발 (http://kfship.blog.me/100135212789)

    1. 웹 기반 프로젝트 관리 프로그램

       - 프로젝트에서 진행되는 이슈사항들 관리, 소스관리, 일정관리 등 프로젝트의 전반적인

          진행상황을 모니터링 하고 관리할 수 있는 프로그램이다. 이에 해당하는 툴에는 Redmine, Trac, Jira 등이 있다.

    2. Continuous Integration (CI)

       - 한국말로 직역해보면 "지속적인 통합" 으로 번역될 수 있다. 즉 CI 툴은 개발되어진 소스에 대해 지속적으로 컴파일,

         테스트, 보고서 작성 등의 작업을 수행하고 그에 대한 결과를 개발자 및 관리자에게 알려준다. 이와같은 작업이

         자동 혹은 반자동에 의해 일어나기 때문에 개발자 혹은 관리자는 그 밖의 자신의 업무에 충실할 수 있게 된다.

         여기에 해당하는 툴에는 Hudson, Cruisecontrol 등이 있다.

    3. 자동 빌드 프로그램

     - 프로젝트의 규모가 커질수록 직접 javac와 같은 1차적인 방법을 사용하여 빌드 하는 개발자는 많지 않고, 대부분

         Eclipse 등의 툴이 제공하는 Build 기능을 사용 프로젝트를 빌드 할 것이다. 자동 빌드 프로그램도 이와 같이

         환경파일의 설정에 따라 전체 프로젝트를 쉽게 빌드할 수 있는 환경을 제공해주는 툴이다.

         여기에 해당하는 툴에는 Ant, Maven 등이 있다.

    4. 버전 관리 프로그램

      - 여러명이서 작업을 하다보면 사로 작업하는 내용이 겹쳐서 작업 내용을 잃게되는 경우가 발생할 수 있다.

        또한 하나의 프로그램이 여러 고객의 필요를 맞추려다 보면 다양한 버전의 프로그램으로 변화될 수 있는데

        이럴 때 효과적으로 소스를 관리할 수 있게 도와주는 툴이 버전 관리 프로그램이다. 여기에 해당하는 툴에는

        SVN, CVS, GIT, Source Sfae 등이 있다.

위의 그림에서 개발자 혹은 관리자가 수행하고자 하는 작업은 "자동 혹은 반자동으로 통합된 소스를 빌드하고 배포하며, 효율적으로 프로젝트를 관리" 하는 것이다. 그럼 위의 그림에 나타나있는 숫자를 따라가며 어떻게 이러한 목적을 이룰 수 있는지 확인해보자.

    1. 첫째 과정은 프로젝트를 빌드하라는 명령을 내리는 것이다. 이때의 명령이 앞에 설명되었던

       "도구의 도움 없이 개발하는 경우" 와 다른점은, 개발자의 로컬 PC에 저장되어 있는 소스를 빌드하는 것이 아니라

       모든 개발자가 작업한 내용을 모아두는 SVN의 Repository (소스 저장소)에 저장되어 있는 소스를 빌드한다는 것에 있다.

       이 작업을 수행하기 위해서 인터넷 브라우저를 이용해 Hudson에 빌드 명령을 내려야 한다.

       이 때 Hudson에 빌드 명령을 내릴 수 있는 방법이 2가지가 있다. 

        1-1. Redmine을 통해 Hudson에 명령하는 경우 (Redmine은 Redmine-Hudson Plugin을 통해 Hudson에 명령한다)

        1-2. Hudson에 직접 명령하는 경우

       사실 어떤 방법을 사용해도 상관 없다.

       Redmine과 Hudson은 모두 웹 브라우저로 접속 가능하며 버튼 한번 누르는 action으로

       빌드가 실행되기 때문에 어떤 작업이 더 쉽다고 이야기 할 수도 없다.

       (만약 자동 빌드 옵션을 사용했다면 이같이 웹에 접속해서 버튼을 누르는 작업 또한 필요하지 않다)

         하지만 모든 작업을 Redmine에서 통합해서 관리하고자 한다면

         Redmine을 통해 빌드명령을 내리는 것이 더 나아보인다.

    2. 빌드명령을 받은 Hudson은 빌드할 준비를 해야 한다.

       즉 SVN Repository에 있는 소스를 지정된 디스크로 옮기는것이 그에 해당하는 작업이다.

       SVN Repository에 들어있는 소스는 SVN만의 특별한 구조를 통해 저장되어 있기 때문에 바로 빌드할 수 없다.

       그와 같은 이유 때문에 SVN Repository에 있는 소스를 특정 디스크로 복사하는 것이다.

    3. SVN Repository에 있는 최신 소스가 모두 특정 디스크에 복사되었다면 Hudson은 이번에 Ant에게 명령을 내려

        저장된 소스를 빌드하게 한다.

        (Hudson 설정파일에 빌드할 때 사용할 JDK 버전과 Ant의 빌드 환경 파일 build.xml의 위치를 저장해야 한다)

    4. Ant가 Hudson으로 부터 컴파일 명령을 받으면 2번 과정을 통해 저장된 소스를 빌드하고

        지정된 위치에 빌드된 파일을 저장 한다.

        이렇게 완성된 파일을 톰켓, 웹로직 등의 WAS 서버를 통해 서비스 한다면, Hudson을 통해 실행한 빌드 한번으로

        SVN 으로부터 파일 추출, 빌드, 배포까지의 모든 작업을 한꺼번이 처리할 수 있게 되는 것이다.

    5. 마지막으로 개발자, 관리자는 현재 프로젝트가 어떻게 진행되는지 모니터링하고 관리하고 싶어한다.

        이때 사용되는 것이 Redmine이다.

        Redmine은 설정을 통해 SVN Repository와 연결되며, 앞어서 설명한 것과 같이 plugin을 통해 Hudson에도 연결 된다.

        그 밖에도 Plugin을 통해서 그 기능을 지속적으로 확장할 수 있으며 이러한 확장된 기능을 이용해 통합적으로

        프로젝트를 관리한다. 대표적인 예가 이슈관리, 업무 배분, 일정관리, 소스관리, Wiki 등과 같 것들이다.

 

MAVEN

Java 기반의 프로젝트를  빌드,배포하려면 보통 써드파티 라이브러리나 기타 등등의 라이브러리를 필요한데

이를 효과적으로 관리할 수 있는 방법은 메이븐 + Artifactory 또는 넥서스를 사용하는 것입니다.

 

 - Maven + Artifactory : Java 프로젝트의 빌드, 테스트, 배포를 자동화 해주는 도구

                                      WEB-INF/libs 의 수많은 정체모를 jar들을 관리하기 아주 편해지며,

                                      이들 jar의 javadoc이나 소스코드를 보려 할 때에도 매우 편하게 접근할 수 있습니다. 

                                      단, 이런 잇점을 이용하려면 Eclipse에 maven 플러그인이 깔려 있어야겠지요.

                                      STS 를 사용해서 수월하게 적용할 수 있습니다.

 

maven을 사용하였을 때는 대체적으로 다음과 같은 혜택 

장      점	설            명
의존성 관리의 편의성	spring과 같은 오픈소스든 프로젝트에서 생산된 컴포넌트든 쉽게 의존성 관리가능
빌드 및 배포의 편의성	명령어 한번(또는 으로 프로젝트 전체 빌드를 쉽게 할 수 있습니다.  한번의 혜택이 이어져서 빌드 순서도 pom.xml에 기술된 dependency를 통해서  빌드 순서를 알아서 맞춰줍니다.  환경에 따라 빌드가 조금씩 다를 경우 profile을 통해 쉽게 빌드를 적용할 수 있는  메커니즘을 가지고 있습니다.
테스트 실행 및 코드 품질 검사의 용이성	명령어(또는 클릭) 한번으로 빌드를 수행할 수 있고, 해당 빌드 라이프 사이클에서  테스트 실행 및 코드 품질에 관련된 기능 실행이 쉽습니다
프로젝트 버전 관리의 용이성	명령어 한번으로 프로젝트의 버전을 명시할 수 있습니다

 

스터디 비용 및 유지보수 비용이 낮다고 판단하고 있기 때문에 프로젝트 규모가 클수록 비용 대비 효과는 커짐

비교적 간단하게 비교할 수 있는 방법은 빌드, 배포 및 의존성 관리, 버전관리에 드는 시간을 현재와 maven을 도입한 후 시간차를 비교해보시면 가능할 것 같습니다

 

                      다른 참고 : 안드로이드 메이븐 플러긴이라는 멋진 프로젝트가 있다구요!

                                      개발, 테스트, 출시 버전의 설정 차이 때문에 메이븐을 사용

 

NEXUS

 - 넥서스(= Maven Repasitory Server) : 넥서스는 라이브러리만 관리합니다.

                                     넥서스와 소스코드 버전 관리 도구는 역할이 다릅니다.

                                     소스에 대한 형상관리는 SCM(ex. subversion)이 하는데, 넥서스는 형상관리로부터

                                     빌드 바이너리를 분리를 하고, 쉽게 빌드 바이너리를 배포하고, 공유하게 해줍니다.

                                     메이븐 + 레포지토리 서버를 사용하게 되면 의존하는 라이브러리 관리를

                                     쉽게할 수 있을 뿐만 아니라 자체 제작한 바이너리의 배포 또한 편해집니다. 

                                     메이븐을 통해 내가 만든 바이너리를  deploy하면 자동으로 레포지토리 서버에 전송되고

                                     누군가가 내가 만든 라이브러리가 필요할 경우 POM에 선언만 해주면 바로 다운이 받아지기

                                     때문에 라이브러리 받는 데 시간이 오래 걸리기 때문에 팀 단위로 작업을 하신다면

                                     넥서스를 운용하시는 게 훨 나을 겁니다.

                                     한명만 라이브러리 받아두면 다른 분들은 순식간에 다운 받을 수 있습니다.

                                     또 넥서스를 돌리면 외부 maven repository에 없는 라이브러리도 등록해서 쓸 수 있습니다.

 

예를 하나 들어보죠.

A라는 조직에서 '고객'컴포넌트를 개발합니다. B라는 조직에서 '계약'컴포넌트를 개발합니다.  그런데 '계약'컴포넌트는 '고객'컴포넌트를 참조해서 사용합니다. 이 때 '계약'컴포넌트의 프로젝트에서 lib(클래스패스)에 '고객'컴포넌트를 넣어서 형상관리를 한다고 가정했을 때 '고객'컴포넌트.jar 파일을 '계약'컴포넌트의 프로젝트에 넣고 commit해야 하는데 누가 해야할까요? A조직은 자기네들이 개발하기는 했지만 다른 조직의 형상관리에 넣고 commit할 권리는 없죠. B조직이 한다면 매번 A조직의 최신버전이 올라왔는지 묻고 누군가가 최신버전을 받은 후 공유를 해야겠죠. 이러한 불편함때문에 형상관리로부터 빌드 바이너리를 분리시키고, 자동으로 업데이트를 받을 수 있는 메커니즘이 필요한대 이를 해결해 주는 것이 maven입니다. 그런데 문제는 maven을 통해서 이런 빌드 바이너리를 공유하려면 별도의 저장소가 필요합니다. 내 로컬에 있는 것을 다른 사람이 가져갈 수도 없고, 그렇다고 maven central과 같은 global repository에  회사의 자신인 '고객'컴포넌트를 배포할 수도 없습니다. 그렇기때문에 별도의 회사 또는 프로젝트의 maven repository가 필요한 것이고, 사내 maven repository로 사용할 수 있는 도구 중의 하나가 nexus입니다.  단점은... 스터디 비용과 유지보수 비용이 발생한다는 것이죠. 물론 혜택이 더 큽니다 ^^;;; 그러므로 maven을 사용하신다면 nexus와 같은 maven repository는 필수입니다.