1. 개요


  레드마인은 PMS(Project Management System)의 한 종류로, 루비 온 레일즈(Ruby on Rails)를 기반으로 작성된 시스템이다. 레드마인은 프로젝트 관리, 일정 관리, 형상 관리 통합, 이슈 추적 등의 기능을 지원하며, 다양한 플랫폼과 데이터베이스를 지원하고 있다. 

  레드마인에 대한 자세한 내용은 공식 홈페이지(http://www.redmine.org/)를 통해 확인 가능하다. 공식 홈페이지 역시 Redmine로 되어있으므로, 사용 전에 미리 리뷰를 하고 싶다면, 이 사이트를 통해 기능들을 확인하면 되겠다. 




  개인적으로 사용하면서 Trac과 유사한 환경이여서 사용에 그다지 어려움을 느끼지 못했으며, 기능이나 디자인 면에서는 Trac보다 오히려 나은 느낌을 받았다. 다만 Ruby on Rails라는  (지극히 주관적으로) 생소한 언어 기반으로 만들어져있다보니 설치가 만만치 않았다.


  앞에서도 언급했지만 이 포스팅은 어디까지나 "개인적인" 프로젝트 환경을 설치하는 것이 목적이고, 설치 과정보다는 활용에 그 목적을 두고 있다. 따라서, Redmine을 직접 설치하는 것 보다는, BitNami(http://bitnami.com/)에서 제공하는 패키지 버전인 BitNami Redmine을 설치하도록 한다. 


  설치에 앞서 간단히 알아보자면, BitNami는 오픈 소스에 대한 인스톨러나 패키지를 제공하는 Open Source Project이며, Bitrock이라는 우리에겐 다소 생소한 업체(개인적인 생각은, 매우 훌륭한 업체라는 생각이 들고... 상을 주고 싶다... ㅋㅋ)에서 관리되고 있다.(출처: http://en.wikipedia.org/wiki/BitNami)




  BitNami는 Redmine 외에도 Subversion, JBoss, Mantis, Tomcat, Trac 등 다양한 오픈 소스에 대한 인스톨러를 제공한다. 제공되는 방식에 따라 3가지 정도의 버전을 확인할 수 있다. 

  • Native Installers
    • 일반적인 PC나 서버에 설치하기 위한 인스톨러
    • Stand-alone Stack 형태로 제공되거나, Module 형태로 제공
      • Stand-alone Stack : 설치 시 단독으로 돌 수 있는 형태의 인스톨러
      • Module : 이미 설치된 Stack이 있다면 module을 설치하여, 기존 Stack의 기능에 결합할 수 있음
    • 윈도우, 리눅스, 맥OS 등의 플랫폼 지원
  • Virtual Machines
    • VMWare 또는 VirtualBox 등에 설치를 위한 인스톨러를 지원
  • Cloud Templates
    • Cloud Hosting에 설치할 수 있는 버전을 제공
  더 자세한 내용을 알고 싶다면, 공식 홈페이지(http://bitnami.com/learn_more/partners)를 참고한다. 

  이 포스팅에서는 BitNami Redmine 2.3.0 window용 인스톨러(stand-alone, native installer)를 이용하여 설치하는 과정을 간단히 살펴본다.


2. Bitnami-redmine-2.3.0-0-windows-installer.exe 설치


  먼저 공식 사이트에서 Redmine 인스톨러를 다운로드 받는다. 현재(2013.04.14) 2.3.0 버전이 사용 가능하며, 이 버전은 다음과 같이 구성되어 있다. 
  • Redmine 2.3.0
  • Apache 2.2.24
  • ImageMagick 6.7.5
  • MySQL 5.5.29
  • Subversion 1.7.5
  • Git 1.7.11.3
  • Ruby 1.9.3-p392
  • Rails 3.2.13
  • RubyGems 1.8.12

  다운로드 받은 인스톨러를 이용하여 설치를 시작한다. 설치 과정은 한국어를 지원하며, 대부분 Default 값을 적용하여 Next를 누르는 과정이므로, 다른 부분은 별도로 설명하지 않는다. 


※ 예전 아래 설정에서 이름을 한글로 넣었더니 Redmine이 작동을 재대로 하지 않아 애를 먹었던 적이 있었다. 되도록이면 영어로 설정하는 것을 추천한다. 

※ 이메일 지원 기능 역시 되도록이면 설치 이후에 설정파일을 통해 설정하는 것을 추천한다. 설정이 재대로 되지 않아 애를 많이 먹었던 것 같다.




  설치가 완료된 후, 다음과 같이 어플리케이션을 구동시키면 설치가 완료된다. 



  설치가 완료되면, 브라우져에서 localhost:[설정한 포트]로 접속을 시도한다. 이 때, 아래와 같은 화면을 확인할 수 있으며, 여기서 Access BitNami Redmine Stack 을 클릭하면 레드마인 페이지를 확인할 수 있다. 




  초기화면에서 로그인한 후, 다른 계정과 프로젝트를 등록하거나 기타 작업을 수행함으로써 Redmine을 사용할 수 있다. 





1. Clone 개요


  머큐리얼의 Clone은 저장소를 복사하는 것을 의미하며, 단순히 저장소의 "현재 상태"를 복사하는 것이 아니라, 저장소의 모든 변경 이력 등을 함께 복사하는 것을 의미한다. 머큐리얼은 모든 사용자가 자신의 저장소를 이용하여 이력을 확인할 수 있고, 유연하게 변경 사항을 Push, Pull 할 수 있다. 따라서, Clone은 여러가지 형태로 활용이 가능하다. 

  • 프로젝트를 Checkout하기 위해 Clone을 수행할 수 있다.
  • 프로그램에 실험적인 코드를 적용하기 위해 Clone을 한 후, 변경 사항을 적용하거나, 해당 코드를 버릴 수 있다. 이러한 작업을 위해 SVN은 흔히 branch를 사용하며, 머큐리얼 역시 branch 기능을 지원하긴 하지만, 머큐리얼의 Clone을 통한 branch는 훨씬 유연한 branch 기능으로 활용될 수 있다. 

2. Clone 절차

  Eclipse에서 MercurialEclipse를 통한 Clone은 다음과 같은 과정을 통해 수행한다. 
  • Clone을 수행할 원본 프로젝트를 가지고 있는 외부 저장소의 웹 서비스가 실행되어 있어야 하며, 해당 서비스 주소를 알고 있어야 한다. 
  • 이클립스에서 New > Project > Clone Exists Mercurial Repository 를 선택한다. 


  • 표시되는 창에서 URL에 외부 저장소의 주소를 입력한다. Next버튼을 클릭한다. 


  • Revision 선택 창에서는 Revision을 선택할 수 있는 여러 옵션을 제공한다. Revisions 탭을 선택하면 여러 Revision 중 하나를 Clone할 수 있다. 원하는 Revision을 선택하고 Finish를 누른다. 




1. Push, Pull 개요


  머큐리얼의 Push, Pull은 타 저장소로 변경 사항(changeset)을 전송하는 과정을 의미한다. Push와 Pull을 설명하기 이전에, 머큐리얼의 Revision과 Changeset의 개념에 대해 간단히 정리할 필요가 있다. 

  • Revision은 특정 시점에 저장소의 상태를 표시하는 번호이다. 이 번호는 순차적으로 올라가게 된다. 
  • changeset은 저장소의 변경 사항을 저장하는 단위이며, 하나의 changeset을 commit하거나 다른 저장소로부터 pull/update하게 되면, changeset을 받아오게 되며, Revision 번호는 하나 증가한다.
  • Revision 번호를 changeset과 동일한 것으로 보는 경향이 있는데 이는 잘못된 것이다. 이는 머큐리얼이 각자의 저장소를 가지고 각자의 변경 이력을 관리할 수 있는 저장소를 제공하는 특성(즉, DVCS의 특성)에 기인한다. 
  즉, Push나 Pull을 통해 changeset을 교환하는 순서에 따라 머큐리얼의 changeset 번호는 순차적이지 않을 수 있으므로, Revert 등의 기능을 통해 특정 Revision으로 돌아갈 때 유의해야 한다. 또한, 이러한 단점을 보완하기 위해, 특정 Revision을 Tagging 하는 기능이 있고, 이를 자주 작성하는 것을 권장한다. 
  더 자세한 설명은 Joel의 Mercurial 소개 사이트(http://hginit.com/)를 살펴보기 바란다. 


  앞에서 언급했듯이, 머큐리얼의 Push, Pull은 "변경사항(changeset)을 전송" 하는 형태이므로, 상당히 유연하게 동작한다. 예를 들면 

  • 중앙 저장소와 변경 사항을 Push/Pull 할 수 있다. 
  • 특정 사용자에게만 변경 사항을 Push/Pull하여 적용하도록 할 수 있다. 예를 들자면, QA에게 변경한 코드를 전송한 후, 테스트가 끝나면 중앙 저장소에 Push 하는 형태로 활용할 수 있다. 
  • 자기 자신이 Clone 한 저장소에 변경사항을 Push/Pull 할 수 있다. 


2. 외부 저장소로 변경사항 Push

  변경사항을 commit했다면, Revision 번호가 변경되었을 것이고, 이를 외부 저장소에 Push해야 한다. MercurialEclipse에서 Push 과정은 다음과 같은 과정을 통해 수행한다.
  • 먼저 Push를 받을 원격 저장소의 Mercurial Web Server가 동작하고 있어야 하며, 해당 웹 서비스의 주소를 알고 있어야 한다. 
  • 변경사항이 있는 프로젝트를 우클릭하고, Team > Push를 수행하면 다음과 같은 창이 표시된다. URL을 입력한 후, Next를 눌러 Push할 changeset을 확인한 후, Finish를 눌러 Push를 완료한다.


  • Push한 changeset을 원격 저장소의 웹서비스를 통해 확인한다. 



3. 외부 저장소로부터 Pull


  Pull은 Push와는 대비되는 개념으로, 외부 저장소로부터 현재 변경된 changeset을 받아오는 과정을 의미한다. 

  MercurialEclipse에서 Pull은 다음과 같은 과정을 통해 수행된다. 

  • 먼저 Pull를 받을 원격 저장소의 Mercurial Web Server가 동작하고 있어야 하며, 해당 웹 서비스의 주소를 알고 있어야 한다. 
  • 변경사항이 있는 프로젝트를 우클릭하고, Team > Pull를 수행하면 다음과 같은 창이 표시된다. URL을 입력한 후, Next를 눌러 Pull할 changeset을 확인한 후, Finish를 눌러 Push를 완료한다.



  • ※ 머큐리얼은 일반적으로 Pull을 수행하면, Update를 통해 수신받은 changeset을 현재 프로젝트에 반영하는 과정이 한 단계 포함하나, MercurialEclipse의 실행 옵션 중 Pull Option에 "update after pull"이 체크되어 있어, Pull을 수행한 직후에 update를 수행해주도록 되어있다. 다른 머큐리얼 환경 (특히 command로 Mercurial 수행시) 유의하도록 하자. 




Eclipse를 통해 생성한 프로젝트를 머큐리얼을 통해 공유하는 방법을 알아본다.



1. 공유할 프로젝트 생성


Eclipse를 이용하여 공유할 프로젝트를 생성한다.
이 과정은 일반적인 이클립스 프로젝트 생성 과정과 동일하므로, 별도로 언급하지 않는다.


Maven 프로젝트로 생성한 프로젝트에 간단한 예제 파일을 넣어 프로젝트를 생성한다.



2. Mercurial Repository에 프로젝트 공유

  프로젝트를 공유하기 위해 다음과 같은 과정을 수행한다. 
  • 프로젝트를 선택한 후, 우클릭하여 Team > Share Project를 선택
  • 표시된 창에서 Mercurial을 선택한 후, 다음 창에서 Finish를 눌러 프로젝트를 머큐리얼로 공유
  • 첫 공유 이후 commit을 수행하여 현재 프로젝트의 첫 commit을 수행


  하지만 이 과정까지 수행한 것은 현재 자신의 머큐리얼 저장소를 생성한 것에 불과하며, 이렇게 될 경우, commit과 update가 가능하긴 하지만, 외부 저장소에 소스가 공유되지는 않는다. 실제 외부 저장소에 commit을 수행하려면, push를 통해 외부 저장소에 현재 프로젝트 이력을 전송하는 과정을 거쳐야 한다. 


3. 프로젝트를 중앙 Repository에서 Cloning


  2번까지의 과정을 통해 프로젝트를 머큐리얼을 통해 관리하는 것이 가능하다. 하지만, 중앙 저장소에 프로젝트를 공유하는 과정이 남아있다. 

  프로젝트 생성을 이클립스를 통해 수행했으므로, 이 프로젝트를 공유하기 위해서는 중앙 저장소에서 이 저장소를 Cloning 하는 과정을 수행해야 한다. 아래의 과정을 통해 Cloning을 수행한다.

  1. MercurialEclipse를 이용하여 Mercurial Web Server를 실행한다. 이 과정은 이클립스에서 프로젝트를 우클릭한 후, Team > Serve 를 통해 가능하다. 


  2. localhost:8000을 브라우져로 확인해본다. 정상적으로 실행되었다면, 생성하고 Commit한 프로젝트에 대한 정보가 페이지로 보이게 된다. 

  3. 머큐리얼 중앙 저장소의 Workbench를 실행하고, File > Clone Repository 를 수행한다. Source에는 Mercurial Web Server를 동작시킨 PC의 웹 주소(http://ip:port)를 입력하고, Destination은 Cloning한 저장소의 로컬 저장 위치를 입력한다. (빨간 상자 부분에 IP와 port를 입력하면 된다.)



  4. Workbench에서 Cloning 한 저장소의 정보를 확인한다. 



모든 작업이 끝났다면, 중앙 저장소에 web config 파일에 해당 정보를 업데이트 한 후, 머큐리얼 웹 서버를 재시작함으로써, 이후에 중앙 저장소에서 서비스가 가능하도록 한다. 




  머큐리얼을 Eclipse에서 직접 사용하기 위해서는 MercurialEclipse 플러그인을 설치해야 한다. 이 포스팅에서는 MercurialEclipse 플러그인을 설치하는 방법을 알아본다. 


  MercurialEclipse 플러그인 홈페이지는 다음 주소(http://javaforge.com/project/HGE)에서 확인할 수 있다. 



이 홈페이지에서 Download Now 버튼을 찾아 이동한 페이지에서 Eclipse Plugin 주소(http://cbes.javaforge.com/update)를 확인할 수 있다.




해당 주소를 입력하여 MercurialEclipse를 선택하고, 설치를 진행한다.

(주: codeBeamer를 함께 설치했으며, Eclipse는 전자정부표준프레임워크 2.5를 사용했으나, 설치시 Plugin-dependency 관련 에러가 발생했다. 이는 codeBeamer 관련 에러인 듯 하며, Mercurial 사용에는 전혀 문제가 없다.)





설치가 종료되고 이클립스를 재시작하면, Eclipse에서 새로운 프로젝트 설치시, 다음과 같이 Mercurial Project를 선택할 수 있다.






1. Mercurial 설치 개요


  머큐리얼은 대표적인 DVCS(Distributed Version Control System) 중 하나다. 머큐리얼에 대한 설명은 내 블로그에 이미 정리된 포스트(http://silencer.tistory.com/57)가 있으므로, 생략한다. 

  현재까지 내가 머큐리얼을 사용하면서 직접적으로 느낀 장점과 단점은 아래와 같다. 

  • 장점
    • 빠른 커밋
      • 로컬 저장소에 이력을 저장하므로, 커밋이 빠르다. 로컬 저장소에 커밋이 빠르다는 점은, 그만큼 '커밋을 하는데 부담이 적다'라는 장점을 가질 수 있고, 이는 사용자가 변경사항에 대해 더 자주 커밋을 할 수 있도록 해준다. 
      • 단, 이 커밋은 중앙 저장소로의 커밋과는 다르다. 머큐리얼은 중앙 저장소로의 동기화를 위해 pull, push 라는 명령을 지원한다. (pull = svn의 update, push = svn의 commit과 같은 개념을 보면 됨)
    • 충돌이 비교적 적음
    • 설치/사용의 간편성
      • 서버/클라이언트 등을 설정해야 하는 SVN과 달리 머큐리얼은 자체가 서버/클라이언트 역할을 모두 할 수 있으므로 설치가 간편하다. 
      • 또한, TortoiesHg 라는 강력한 UI 툴을 지원하므로, 중앙저장소, 개발 환경에 관계 없이 머큐리얼과 TortoiesHg 패키지만 설치하면 되고, (물론, 이클립스 사용 시에는 머큐리얼 플러그인을 사용하는 게 좋다.) ToroiesHg를 통해 모든 명령어를 명령창 없이 GUI만으로 사용할 수 있다. 
    • 분기(branch)와 병합(merge)이 유연함
      • branch 명령을 지원하긴 하지만, 단순히 clone이라는 명령을 통해 프로젝트를 복사하는 것만으로 분기가 가능
      • clone 명령을 통해 분기한 프로젝트의 변경 사항을 기존 저장소로 push 함으로써 변경 사항을 merge 할 수 있음
  • 단점 
    • 중앙 저장소 동기화 빈도가 낮아짐
      • 시스템의 문제라기보단, 프로그램 사용상의 문제에 가깝다고 봐야 할 것 같음
      • 특히, SVN에 익숙한 사용자의 경우, SVN의 commit과 머큐리얼의 commit을 동일하게 여기는 경향이 생기는 듯함
      • 하지만, 중앙 저장소와 동기화하지 않는 DVCS는, 개발 툴이 지원하는 History 기능이나 마찬가지라는 생각이 듬
      • 또한, 동기화 빈도가 낮아질수록 충돌이 발생할 가능성은 점점 높아짐
      • 정기적인 push, pull 주기를 정하는 등의 별도 정책을 정하여, 중앙 저장소와 정기적으로 동기화를 수행할 수 있도록 하는 것이 좋을 것 같음

2. Mercurial 설치

  Mercurial 설치는 패키지를 다운 받아 Install 하고, 별도의 설정 없이 기본 값을 선택하면서 설치하면 된다. 자세한 설치 과정은 이 블로그의 포스팅(http://silencer.tistory.com/58)을 참고한다. 


3. Mercurial 설정


  머큐리얼 Workbench를 실행하면, 현재 생성된 Repository를 확인할 수 있으며, 여기서 여러가지 설정을 수행할 수 있다. 여기서는 설정에 대해 자세한 설명은 생략하고, 기본적인 설정만 진행한 후, 변경할 때마다 내용을 추가하기로 한다. 


  • Workbench에서 File > Settings를 선택하면 TortoiesHg Settings 창이 표시된다.
    • Commit
      • Username을 설정한다. Username은 이 PC에서 commit을 수행할 시에 사용자 이름을 나타낸다. 
    • Web Server
      • 웹서버 실행 시 홈페이지에 표시할 이름, 설명, 포트 등을 설정해준다. 또한, Allow  Push, Deny Push 등을 설정해주어야 하는데, 이는 중앙 서버에 Push 할 수 있는 사용자 이름을 의미한다. 

4. Repository 생성

  머큐리얼의 웹서버는 최소한 하나의 저장소가 존재할 때 실행이 가능하다. 실행을 위해 먼저 서버측에 테스트용 Repository를 생성한다.



  1. File > New Repository를 선택하면 위와 같은 창이 표시된다. 
  2. 알맞은 저장소 디렉토리를 설정한다. (주: 웹서버 상의 주소가 매핑될 때, Space나 한글을 구분하지 못하는 경우가 많으므로, Repository 주소는 항상 공백이나 한글이 없도록 하는 것을 추천한다.) 
  3. Create 버튼을 눌러 Repository가 생성된 것을 확인한다. 
  생성한 Repository를 아래와 같이 Workbench에서 확인할 수 있으며, Repository의 이름을 변경할 수 있다. 알맞은 이름으로 변경한다. 




5. 웹서버 실행


  머큐리얼의 Web Server를 띄운다는 의미는 단순히 이력을 확인할 수 있는 웹 페이지를 올리는 작업을 말하는 것은 아니다. 머큐리얼은 push를 받기 위해서는 Web Server가 동작해야 하며, 해당 포트를 통해 push 정보를 수신받게 된다. 



  1. 메뉴의 Repository > Start Web Server를 실행한다. 위와 같은 창이 표시된다.
  2. 포트를 설정하고, Start 버튼을 누른다. 

  아래쪽에 표시된 Config File에 주목해보자. Web Server 실행시, 기본적으로 Workbench에서 선택한 Repository를 실행하도록 되어있으나, 만약 다수의 Repository를 웹서버에 띄우고자 한다면, 미리 Config File에 다수의 Repository를 지정해두는 것이 좋다. 


[paths] 하위에 [프로젝트이름]=[Repository경로] 형식으로 지정하고, 이를 파일로 저장하고 매 실행시 이 파일을 로드하면, 다수의 Web페이지를 띄울 수 있다. 


※ 이 설정 파일의 물리 경로에 공란이 포함되어 (e.g. "Program Files") 인식이 되지 않는 경우를 겪은 적이 있다. 반드시 경로에 공란이 포함되지 않도록 주의할 것



6. 웹 서버 실행 자동화


  위와 같이 설정을 하더라도, 웹서버는 사용자가 WebServer를 실행시켜주기까지 동작하지 않는다. 그렇다고, 매 번 Web Server를 서버 부팅시마다 실행해주는 것은 너무 비효율적인 일이다. 간단한 방법을 통해 웹서버가 부팅시마다 켜질 수 있도록 해보자. 


  머큐리얼은 기본적으로 TUI 형식의 명령어를 지원한다. 머큐리얼과 관련된 명령을 수행하기 위해서는 hg(주: Mercurial=수은 -> 수은의 원소기호 hg)를 타이핑하고, 뒤에 수행할 작업을 인자로 전달해야 한다. 머큐리얼이 지원하는 작업 종류는 다음의 명령을 통해 확인할 수 있다. 


> hg help


  이 명령어 중, hg serve 라는 명령이 존재한다. serve 명령은 웹 서버를 실행해주는 명령이며, 이 때 필요한 옵션은 아래와 같은 명령으로 확인할 수 있다. 


> hg help serve

아래 이미지는 hg help serve 명령을 수행한 결과이다. 


  이 중, -d, -p, --web-conf 옵션 등에 주목할 필요가 있다. 대부분은 위에서 Web Server 관련 머큐리얼 설정에서 알아본 내용이므로, 별도의 부연 설명은 생락한다. 최종적으로 실행할 명령어는 아래와 같다. 


> hg serve -d -p [웹 포트번호] --web-conf [웹 설정 파일 경로]


  이 명령을 수행하면, 웹서버가 백그라운드 프로세스로 수행되게 된다. 프로세스의 이름은 hg.exe이므로, 종료를 원할 땐 참고하기 바란다. 


  이 명령을 배치파일로 만들어 시작 프로그램에 등록하거나, 배치 파일을 서비스 형태로 등록하면, 매 실행시마다 WebServer를 실행할 필요 없이 자동으로 머큐리얼 웹서비스가 실행된다. 아마도 시작 프로그램으로 실행시에는 사용자 로그인이 필요하거나, 별도의 조작이 필요하므로, 가장 이상적인 건 배치파일을 서비스로 등록하는 방법일 것이다. 배치 파일을 서비스로 등록하는 방법은 다음 포스팅과 외부 링크를 참고한다.


(다행히도, Windows 7에서도 호환성 문제 없이 잘 동작한다. 설치 과정에서 호환성 관련 경고를 한번 무시하는 것 빼고는 아래 절차와 동일하다.)


http://silencer.tistory.com/30


  1. 2013.04.24 17:15

    비밀댓글입니다

1. 개요


  평소 예제 프로그램 등을 작성하기 위해 사용하는 저장소가 여기 저기 분산되어 있는 상황(노트북, 컴퓨터, 회사 노트북 등등)인지라, 이를 통합할 필요성을 매번 느껴왔었다. 


  현재 집에서 사용하는 인터넷 공유기는 IPTIME 공유기로, 포트 트리거, WOL(Wake On Lan) 등의 기능을 충분히 지원하고 있다. (이전에도 마찬가지였지만, 요즘 공유기는 적어도 기능면에서는 왠만한 VPN 장비와 거의 동일한 기능을 지원하는 것 같다... ㅎㅎ) 게다가 개별 공유기에 사설 ip를 설정할 수 있는 기능을 지원하므로, 외부 IP가 변경된다해도 개발 서버로 사용하기에는 기능적으로 충분하다.


  잠시 인터넷에서 라즈베리파이라는 저가 PC(라고 표현해야할 지 모르겠으나 마땅히 표현할 단어가 생각나지 않는다.)를 본 적이 있다. 개인용 스트리밍 서버 등으로 사용하기에 최적이라고 하긴 하나, 700MHz 가량의 CPU를 사용한다고 해서 좌절한 적이 있었다. 개인용 개발 서버 구축을 위한 CPU로는 적당치 않은 듯 하다. 


  그러던 와중에, 최근에는 거의 사용하지 않는 집 노트북을 개인용 개발 서버로 사용하면 최적일 것 같다는 생각이 문득 들었다. 일단 아직까지도 쓸만한 성능을 가지고 있었고, WOL으로 원격 부팅을 지원하므로, 언제든 원할때마다 부팅이 가능하다. 또 한가지의 장점 중 하나는 노트북이기에 전원이 크게 소모되지 않는다는 점이다. 딱 하나 걸리는 점이 있다면, 노트북을 24시간 돌리게 되면 수명이 얼마나 버텨줄 것인가... 정도이긴 하지만, 이미 5년차의 노트북을 중고로 팔 생각은 없는지라... 


  이번에는 일단 Java 기반의 프로젝트 환경을 구성하는 것을 문서화할 예정이다. 개인적으로 

'개발 환경 설치를 위한 노력은 최소한으로' 라는 생각을 가지고 있으므로, 최대한 패키징이 되어있는 개발환경을 사용하도록 노력할 예정이다. 



2. 설치 프로그램 개요

  • 설치 환경
    • 운영체제: Windows 7 (32bit)
    • CPU: Intel(R) Core 2 Duo P8400 (2.26GHz)
    • RAM: 4.00GB

<설치할 프로그램 목록>


  • 설치할 프로그램 
    • TortoiesHg(2.7.2) with Mercurial(2.5.4)
      • DVCS(Distributed Version Control System)
      • 개인적으로, 네트워크가 유동적인 상황에서의 이력 관리가 가능하고, 로컬 이력의 커밋 속도가 빨라 즐겨 사용하고 있음
      • 단점으론, 중앙 저장소와의 동기화(Push)를 자주 하지 않게 된다는 점... 이럴 경우, Eclipse의 Local History 기능을 사용하는 것과 다름없는 상황이 되어 버린다는 점... ㅠㅠ 
      • 다운로드 : http://mercurial.selenic.com/downloads/
    • 전자정부프레임워크 서버용 개발환경 (2.0.0)
      • 정부/공공 사업을 위해 개발된 표준 프레임워크로, 해당 서버용 개발환경을 설치하면 SVN, Hudson, Nexus, Tomcat, Maven 등을 별도의 추가 설정 없이 설치 가능함
      • 자세한 내용은 홈페이지를 참고
      • 다운로드 : http://www.egovframe.go.kr/EgovDevEnvRelease.jsp?menu=3&submenu=2
    • BitNami Redmine (2.3.0)
      • Issue Tracking System, Project Management System]
      • Redmine을 설치하기 위해서는 다양한 실행 환경의 설치가 필요하며, 이 과정은 상당히 복잡하다(라고 개인적으로 생각한다). 설치를 Install 한번으로 가능하게 패키징하여 제공하는 사이트가 있으며(http://bitnami.com/), 이 사이트에서 다양한 다른 Open Source도 제공하고 있다. 
      • 다운로드 : http://bitnami.com/download/files/stacks/redmine/2.3.0-0/bitnami-redmine-2.3.0-0-windows-installer.exe?with_popup_skip_signin=1


대부분의 프로그램이 Install 한 번에 가능하므로, 모든 과정을 기록하진 않을 예정이다. 각 패키지간의 연결을 위한 설정이 필요한 부분을 주로 기록할 예정이다. 

'공부' 카테고리의 다른 글

개인용 Java 기반 프로젝트 환경 설치 - (1) 개요  (0) 2013.04.13

관심사의 분리 (Separation of Concerns)

  • 관심이 같은 것끼리 하나의 객체 또는 친한 객체로 모음
  • 관심이 다른 것은 가능한 따로 떨어져서 서로 영향을 주지 않도록 분리
  • 즉, 객체지향 설계의 기본 원칙인 High Cohesion, Low Coupling과 동일한 의미

리팩토링 (Refactoring)
  • 기존의 코드를 외부의 동작 방식에 변화 없이 내부 구조를 변경해서 재구성하는 작업 또는 기술을 의미

템플릿 메소드 패턴 (Templete Method Pattern)
  • 변하지 않는 기능을 슈퍼 클래스에 정의하고, 확장할 기능을 서브클래스에서 상속하여 정의하게 한다. 확장할 메소드를 템플릿 메소드라고 하며, 아래와 같은 방법으로 정의할 수 있다.
    • 추상 메소드 (abstract method) 
    • 훅 메소드 (hook operation) : 기본적인 연산을 제공하고, 필요할 경우 서브 클래스에서 이를 확장하도록 한다.

팩토리 메소드 패턴 (Factory Method Pattern)
  • 객체의 생성을 담당하는 메소드(팩토리 메소드)를 서브클래스에서 정의하거나 확장하는 패턴 (일종의 템플릿 메소드 패턴으로 볼수 있음)

객체 지향 설계 원칙 (SOLID)
  • 단일 책임 원칙 (The Single Responsibility Principle)
    • 특정 클래스를 변경해야 하는 이유는 오직 하나뿐이여야 함
    • 즉, 클래스는 하나의 목적에 대한 기능을 포함해야 함을 의미
  • 개방 폐쇄 원칙 (Open-Closed Principle)
    • 클래스나 모듈, 함수는 확장에는 열려있어야 하고, 변경에는 닫혀있어야 함
  • 리스코프 치환 법칙 (Liskov Substitution Principle)
    • 서브타입은 언제나 자신의 기반 타입(base type, super type)으로 교체할 수 있어야 함
    • 즉, instanceof 나 다운 캐스트를 사용한 코드가 (가급적) 포함되지 않도록 해야 함 
  • 의존 관계 역전 원칙 (Dependency Inversion Principle)
    • 구체적인 클래스/모듈/함수에 의존하기보다는 추상화된 것이 의존해야 함 
    • 추상화된 클래스/모듈/함수는 구상 클래스/모듈/함수에 의존해서는 안된다.
  • 인터페이스 격리 원칙 (Interface Segregation Principle)
    • 클라이언트는 사용하지 않는 메소드에 대해 의존관계를 맺으면 안됨
    • 사용하는 메소드만 인터페이스로 정의하여 제공받아야 함

높은 응집도(High Cohesion), 낮은 결합도(Low Coupling)
  • 모듈 변경이 일어날 때, 해당 변경이 모듈 내에서 전체적으로에 영향을 미친다면 High Cohesion 원칙을 지키지 못하여 발생하는 문제
  • 모듈 변경이 일어날 때, 해당 변경이 다른 많은 모듈에 영향을 미친다면, Low Coupling을 준수하지 못한 것  

전략 패턴 (Strategy Pattern)
  • 변경이 필요한 알고리즘을 인터페이스를 통해 분리하고, 이 인터페이스를 구현한 구상 클래스를 필요에 따라 바꿔 사용할 수 있도록 하는 디자인 패턴

팩토리 사용과 비교하여 어플리케이션 컨텍스트의 이점
  • 객체 요청자가 팩토리 클래스를 알 필요가 없음. 즉, 연관 관계를 제거할 수 있음
  • 어플리케이션 컨텍스트는 어플리케이션 전체에 대한 종합 IoC를 제공
  • 빈을 검색하는 다양한 방법을 제공

스프링 IoC 용어 정리
  • 빈 (Bean)
    • 스프링이 IoC 방식으로 생성, 제어를 담당하는 객체
    • managed object
  • 빈 팩토리 (Bean Factory)
    • 빈을 등록하고, 생성하고, 조회하여 돌려주는 등의 기능을 담당하는 객체
  • 어플리케이션 컨텍스트 (Application Context)
    • 빈 팩토리를 확장한 IoC 컨테이너 
    • 빈 관리 기능과 스프링의 부가 서비스를 추가로 제공
  • 설정정보/설정 메타 정보 (Configuration metadata)
    • 어플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위한 설정 정보
    • XML 또는 annotation 클래스
  • IoC컨테이너 (IoC Container)
    • IoC 방식으로 빈을 관리하는 객체 (빈 팩토리, 어플리케이션 컨텍스트와 동일하게 쓰이기도 함)

싱글톤 레지스트리 (Singleton Registry)
  • 스프링은 별도 설정을 하지 않으면, 여러 번에 걸처 빈을 요청하더라도 매번 동일한 객체를 돌려줌
    • 요청에 대해 매번 객체를 생성해야 할 경우, 객체가 매번 생성되고 사라지면서 성능상 부하를 일으킬 수 있음
  • 스프링은 평범한 자바 클래스를 싱글톤으로 활용할 수 있게 해줌
  • 여러 쓰레드가 동시에 접근할 수 있으므로, 주의해야 함   
    • 무상태(stateless) 방식 (상태 정보를 내부에 갖지 않도록 <-> 상태 유지 방식(stateful))으로 개발 해야 함
    • 스프링 빈 객체가 가질 수 있는 인스턴스 필드
      • 스프링 빈 : 스프링에서 싱글톤으로 관리하므로, 다른 스프링 빈 클래스가 매개변수로 가질 수 있다.
      • 읽기 전용 값 : static final / final 로 선언된 값

스프링 빈 스코프 (Scope)
  • 빈의 라이프 사이클 범위를 의미
  • 스코프 종류
    • Singleton
      • 스프링 빈의 기본 값
      • 컨테이너 내에 하나의 오브젝트만 만들어지며, 컨테이너가 존재하는 동안 계속 유지
    • Prototype
      • 컨테이너에 빈을 요청할 때마다 매번 새로운 오브젝트 생성
    • Request
      • 웹을 통해 새로운 HTTP Request가 생길 대마다 생성
    • Session
      • 웹의 세션과 유사

싱글톤 패턴의 한계
  • 상속이 불가
    • 생성자가 private로 선언되어 있으므로 상속이 불가능
  • 테스트의 어려움
    • 생성을 내부에서 수행하므로, 파라미터 등으로 테스트 값을 주입하기 힘듬
    • 테스트용 오브젝트로 대체하기 힘듬
  • 서버 환경에서는 싱글톤이 하나만 만들어지는 것을 보장하기 힘듬
    • 다수의 JVM에서 분산되어 설치되는 경우, 여러 개일 수 있음 
  • 싱글톤은 전역 상태
    • 객체 지향에서 권장하지 않는 프로그래밍 모델

의존 관계 주입 (DI, Dependency Injection)
  • 의존성 주입/의존 오브젝트 주입 등으로 번역
  • 의존관계를 런타임시에 연결해주는 작업을 의미
  • 의존 관계 주입의 세 가지 조건
    • 클래스 모델이나 코드에서는 런타임 시점의 의존관계가 드러나지 않음. 따라서 인터페이스에만 의존해야 함
    • 런타임 시점의 의존관계는 컨테이너 팩토리같은 제 3의 존재가 결정
    • 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 주입함으로써 만들어짐
  • 의존 관계 주입은 주입 대상과 주입 받는 대상이 모두 스프링 빈이여야 함

의존 관계 검색 (DL, Dependency Lookup)
  • 객체가 자신의 의존 오브젝트를 능동적으로 검색
  • getBean() 메소드를 사용하여 객체를 검색하여 받아오는 방식
  • 주입 받는 대상이 검색하며, 주입 받는 대상은 스프링 빈일 필요가 없음\



출처: 토비의 스프링 3 (이일민 저), GoF의 디자인 패턴 (에릭 감마 외), Java 프로그래머를 위한 UML (로버트 C. 마틴)

책을 구입한지 어언... 

1년이 되어가는 것 같다...


그동안 이런 핑계, 저런 핑계로 책을 읽지 못했다... 

그 중 가장 큰 이유는 아마도 나약한 내 정신력과

그냥 되는 대로 살자 식의 인생과의 합의? 


물론, Spring 관련된 교육을 일부 받긴 했지만...

일단 현재 종사 분야가 그리 Spring을 접할 만한 기회가 없기에 

많은 부분을 까먹은 것 같다. 


다시 공부를 시작할 겸해서

책에 있는 예제들이나 중요 개념을 내 나름대로 정리할 예정이다. 


책에 있는 것만 따라하는 건 그리 좋은 방법이 아닌 것 같다.

내 나름대로 진행하면서 그동안 공부했던 다른 툴이나 기술을 활용하여

예제를 완성해나가는 것도 나름 재미있을 것 같다. 


일단... 꾸준히 한번 시작해보자... 


참고 사이트 #1 : http://trac.tistory.com/


아직 TOW(Trac On Windows) 관련 유입 키워드가 많은 상황에서 

공식 홈페이지에서 이야기하는대로 TOW에 대한 추후 업데이트는 지원이 중단


간만에 이슈 트랙킹 시스템을 사내에서 사용하려던 나에겐 청천벽력 같은 소리였는데...

다행히도 공식 사이트에서 이에 대한 대안을 제시하고 있음 


참고 사이트 #2 : http://bitnami.org/


이 사이트에서 Redmine(뿐만 아니라 다양한 Open Source 어플리케이션) 설치 패키지를 지원하고 있음


Redmine은 기본적으로 Ruby On Rails 를 이용하여 개발되었다고 하며

Ruby On Rails라는 언어는 웹 개발에 있어서 생산성이 특히 뛰어난 언어로 알려져 있다. 

(위의 내용은 출처는 기억나지 않으나, 루비가 기존 웹 언어에 비해 10배의 생산성을 보여준다고 하는데... 사실 직접 사용해본 적이 없으니...)

허나, 내가 Redmine을 설치하면서 느낀건... 실행 환경을 설치하기 위한 노력도 10배가 든다는 점.... 


일단 사용할 프로그램 설치는 최대한 쉬운 방법으로... 라는게 내 지론인데... 

(난 프로그램 설치를 배우려는 것은 아니니까...)


BitNami에서 제공하는 Redmine Installer는 내가 원하는 목표에 딱 맞는 프로그램이였다...


... 딱 한가지 제외하면... 

현재 제공하는 2.3.0 (최신 버전)의 경우, 설치 이후 알수 없는 원인에 의해 

웹 서비스가 계속 죽는 현상이 발생하였다.. 

(이에 대한 내용은 추후 시간이 되면 추가 포스팅...)


현재 1.4.X대 버전을 이용중이며, 

큰 문제가 없다면 이 버전을 설치하는 게 가장 나을 듯하다. 



+ Recent posts