릴렉스

SSL 서버 인증서 생성을 위해 authority.cmd를 명령창에서 실행한다.

실행되어진 창에서 인증서 생성버튼을 클릭한다.

팝업창에서 hostname이나 IP를 입력하고 이 인증서로 https제공을 체크한 후에 OK버튼을 클릭한다.

바뀐 화면에서 키스토어 패스워드를 입력한다.

입력한 서버주소를 위한 새 서버 인증서를 생성했다는 메시지가 보인다.

완료되면 gitblit를 재시작한다.

1.     Git Server 선정과정

-       Git은 분산환경이므로 중앙저장소가 필요없다고 하지만 회사내에서 여러명이 사용하려면 중앙저장소가 필요하다. 이모저모 확인해보니 2가지로 나눌 수 있었다.

우선 서버제공방식 : 유명한 곳이 github인데 (이외에 몇군데 더 있더라) 무료인 경우에는 소스를 오픈해야 하며(오픈소스) 본인의 소스를 private하게 관리하면 비용이 필요하다.

           비용은 아래 캡처한 바와 같다.

비싼 가격은 아니라고 생각하지만 매달 적지만 계속 비용이 나간다고 회사에 말하기가 싫었다.

그래서 설치형으로 직접 설치하려고 조사를 해서 몇가지를 확인했다.

윈도우서버를 대상으로 하니 Bonobo Git Server와 Gitblit의 2가지가 나왔다.

우선 Bonobo Git Server를 설치해보았는데 권한설정등의 기능이 미약해서 Gitblit으로 설치했는데 원하는 기능이 모두 지원되었다. 한가지 아쉬운점은 branch별 권한이 설정되지 않는 부분이었지만 그정도로 만족하기로 했다. (서핑하다 보니 branch별 권한도 설정할 수 있는 설치형 git server가 있다고 본 것 같다. 하지만 이제는 귀찮다.)

2.     Git Server 설치

Gitblit의 홈페이지( http://gitblit.com )에서 설치파일을 다운받는다.

다운로드받은 압축파일을 설치를 원하는 위치로 이동하고 압축해제한다.

설치디렉토리 아래의 data/gitblit.properties 파일을 수정한다.

server.httpPort = 원하는 포트

server.httpsPort = 원하는 포트

server.httpBindInterface = 서버 URL

server.httpsBindInterface = 서버 URL

server.certificateAlias = 서버 URL

authority.cmd 또는 java –cp gitblit.jar com.gitblit.authority.Launcher –baseFolder data를 명령행창에서 실행한다. (컴퓨터에 자바가 설치되지 않은 경우 설치함)

(주의) 실행시에 비밀번호 7자 제한에 대한 경고가 아래와 같이 보일 수 있다.

비밀번호 제한을 해제하려면 아니오를 선택하여 JCE를 다운받는다.

unlimitedJCEPolicyJDK7.zip을 압축해제하고 jre/lib/security에 넣는다.

실행된 창에서 키스토어를 생성한다.

생성시 사이트 주소를 입력한다.

(예) www.aaa.co.kr

창에서 설정하기를 원하는 키스토어 비밀번호를 입력한다.

(예) 1234

data\gitblit.properties 파일에서 아래 부분을 위에서 설정한 키스토어 비밀번호로 변경한다.

변경전 : server.storePassword = gitblit

변경후 : server.storePassword = 1234

gitblit.cmd를 실행한다.

서버의 주소로 연결을 시도한다.

-       연결 실패시 위에서 설정한 포트를 방화벽에서 열어준다.

최초에 admin계정이 생성되어 있으므로 admin/admin을 입력하고 로그인 버튼을 클릭하여 로그인한다.

1.     지속적인 통합

CI (Continuous Integration) : 정의로서의 의미는 링크걸려있는 위키백과를 보면 되겠다. 내가 생각하는 의미는 개발시 단위 모듈별로 빌드 및 테스트를 계속 반복하여 버그(자체 버그 및 모듈간 연동 버그)를 조기에 발견하는데 적합하다. 점점 복잡도가 올라가는 현재 개발환경에서는 선택이 아닌 필수라고 생각된다.

CI를 하겠다고 해서 그냥 자동으로 되는 것은 아니며 (그렇다면 좋으련만) 물리적인 부분과 감정적(?)인 부분이 필요하다.

감정적인 부분이야 필요성을 조직원들이 인지하고 협업하면서 문화를 정착해나가는 부분이므로 글로 써봐야 소용이 없다. (CI를 글로 배웠나?)

그래서 관련 솔루션 구축 및 설정등의 물리적인 부분을 위주로 적으려고 한다.

2.     연관 솔루션

l  소스관리 : 모든 소스를 하나의 Repository에서 관리하기 위한 툴이다.

소스관리시에는 몇가지 원칙이 있다. 우선 빌드를 위한 모든 내용을 빼먹지 말아야 한다.

오픈소스 라이브러리를 사용하고 있다면 동일 버전의 해당 라이브러리를 소스와 동일 Repository에서 관리해야 한다. 이렇게 하지 않는 경우의 단점은 말하지 않아도…

반대로 Repository에서 빌드를 통해 생성할 수 있는 실행파일등은 관리대상에서 제외한다.

언제나 생성할 수 있는 결과물을 저장하여 생기는 용량의 증가와 이해의 어려움을 방지하기 위함이다.

소스관리 툴은 아래와 같이 여러가지 종류가 있다.

-       cvs : 예전부터 사용되던 오픈소스 버전관리툴로서 지금도 사용하는 곳이 있는지는 모르겠다. 오픈소스로서 비용부담없이 사용할 수 있어서 소스관리가 퍼지는데 큰 도움을 주었다. 지금은 더 좋은 툴들이 많아서 점유률이 점점 낮아지는중. 업그레이드도 안되는 것 같다.

-       svn : cvs를 개선한 툴로서 cvs를 만든 사람들이 단점을 보완해서 개발했다고 한다.

지금도 여러곳에서 사용하지만 git의 화려한 명성에 밀리고 있어 보인다.

개인적으로는 분산개발환경이 아니라도 git이 좋다고 생각한다. branch의 비용 때문에.

-       git : 이 문서에서 채택한 툴로서 DVCS(Distributed Version Control System)이다.

리눅스의 버전관리툴로 사용되며 유료/무료 호스팅도 많이 있으며 흔한 말로 대세이다.

빠른 속도, 단순한 구조, 비선형적인 개발, 완벽한 분산을 추구한다.

그외 Mercurial, Perforce등의 툴들이 있다고 하는데 이름만 들어봤다.

l  이슈 트래커

프로젝트 내의 모든 이슈를 처리하기 위한 툴이다. 하나의 Repository에서 모든 이슈를 관리하므로 처리이력이나 이슈간 관계를 처리하기 좋다.

이슈 트래커의 종류는 다음과 같다.

-       Mantis : 파이선으로 만들어진 이슈트래커로 이슈관리에 특화되어 있다.

가볍게 쓰기에 좋은 툴이다.

-       Jira : 아틀란시안의 툴로서 해당 회사의 제품을 쓴다면 사용하기 좋다. 10명까지는 가격도 싸고.. 하지만 그 이상의 사용자를 쓰려면 비용이 기하급수적으로 늘어난다.

-       Redmine : Ruby로 만들어진 이슈트래커로서 오픈소스 진영에서 가장 많이 사용하는 툴이라고 생각된다. 여러 플러그인을 통해 기능이 많이 확장된다. 거의 안되는게 없을 정도.

-       그외에 bugzilla, trac등이 있다. ,

l  CI툴

소스관리툴과 연동하여 지속적으로 빌드 및 단위테스트를 수행하는 툴이다.

종류는 다음과 같다.

-       cruisecontrol : 몇번 사용해보기는 했지만 왠지 어색했다. 사용한지 오래되기는 했지만 버그도 좀 있었던것으로 기억된다.

-       Bamboo : jira를 만든 회사에서 만들었으므로 jira와 찰떡궁합. 역시 유료…

-       Hudson : sun의 지원을 받다가 oracle의 지배를 받게 된 툴

-       Jenkins : hudson 개발자들이 oracle에게서 독립을 선언하고 새롭게 만든 툴로서 기능도 많고 사용하기 좋은 툴이다.

-       그외에 Anthill, Teamcity등이 있다.

3.     솔루션 선정

-       여기서는 소스관리에 Git, 이슈트래커에 Redmine, CI툴에는 jenkins를 사용하기로 했다.

선정사유는 별다른거 없고 가장 hot한 솔루션위주이다.

       -    윈도우 환경에서 설정하는 경우를 사례로 작성했다.