· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
강대권

개발환경의 효율적 개선


1. 소개

  • 프로젝트 에코시스템 or 개발환경의 효율적 개선
  • 강대권

2. 목차

  • 일하기 편하면서 좋은 품질을 낼 수 있는 개발 환경은?
  • Subversion을 이용한 소스관리
  • Trac을 이용한 이슈관리
  • 최종목표는 지속적인 통합

3. 일하기 편하면서 좋은 품질을 낼 수 있는 개발 환경은?


3.1. 목표

  • 개발환경을 개선해나간다는 목표를 가지고 초기에는 소스관리 정도로 시작해 점진적으로 이슈관리 그리고 지속적인 통합까지 확대적용
  • DRY(Don't Repeat Yourself)한 부분을 최대한 줄여 작업효율 극대화할 수 있는 개발환경 구축
  • 아래의 후기처럼 개발자의 개으름 제거
지속적인 통합 베타리더 후기 중 가장 와닿는 후기

“(인간적으로는 돌아볼 일 없는 이이긴 하지만) 래리 월은 개발자의 덕목 중 하나로 '게으름'을 꼽았었죠. 이 책에서는 게으르지 못한 개발자를 '고객의 신발은 빈틈없이 고쳐주면서, 정작 자신의 아이들을 위한 신발 수선은 잊어버리는 구두 수선공'이라고 꼬집고 있던데 어쩐지 이 구절에 저자의 의도가 다 담겨 있는 듯하네요. 자, 게으르고자 하는 개발자를 위한 멋진 친구 하나를 소개합니다. 이 책으로 다른 멋진 책을 집필하는 여유 시간을 얻을 수 있는 개발자들이 늘어나길 기대하고... 음 그리고 혹시 앰비언트 오브를 제게 선물할(아니 구경시켜 줄) 이를 찾습니다.”
    —김형준, http://tzara.wordpress.com

3.3. 도입 전 고려사항

  • 여러분들 '은 탄환'(늑대인간을 한방에 잡는 탄환, 묘책, 특효약의 뜻)이란 말을 들어보신적이 있으실 겁니다. 어떤 소프트웨어 제품이건간에 모든 문제를 해결해 주지는 않습니다. 제가 설명드리는 내용 또한 마찬가지 사고로 접근해야 합니다. 이것을 도입하는것만으로 모든것이 다 잘 될꺼라고 믿고 싶지만 현실은 그렇지 않고 냉정합니다. 그러기에 현명하게 대처하는 자세가 필요합니다. 이 내용을 도입하고자 하는 의지가 있는 사람은 팀장일수도 말단 사원일 수도 있습니다. 각기 롤별로 이것을 도입하는데 필요한 노력이 드는것은 차이가 있을것입니다. 하지만 가장 중요한 것은 팀 구성원간에 생각이 합쳐지지 않으면 공염불이 될 수 있다는 점을 반드시 명싱하시기 바랍니다.
  • 현재 이러한 프로세스가 적용되지 않은 곳에서 도입시도 전 꼭 알아두어야 할 내용은 어차피 이 프로세스도 다른 팀원의 개성을 존중하고 도입의 공감대를 형성하는 것이 가장 중요. 이런요소가 빠진 도입은 앙꼬빠진 찐빵과도 같다.

3.4. 도입 계기

  • [http]조엘 스폴스키[http]제안한 기준을 준수(?)해보면서 하나하나씩 적용해보다 보니 자연스레 팀 프로젝트 관리도구(subverion + trac + 지속적인 통합)라는 것을 프로젝트에 적용
  • 처음엔 소스관리를 해보고자 적용을 시작하였고 소스브라우징의 불편함으로 viewvc를 도입하여 1차적인 불만은 해소했으나 2차적인 viewvc의 인터페이스 부족으로 자연스럽게 trac을 도입하게 되었고 소스와 이슈를 통합하였고 배포라는 이슈를 해결하기 위해 지속적인 통합 솔루션을 적용

3.5. 개발환경

3.5.1. 대표적인 기존 팀 프로젝트 관리의 예
  • develop_current.png
    [PNG image (20.02 KB)]
    • 개발 흐름
      • 개발자는 개발서버의 공유된 소스폴더에 직접 접근하여 소스를 수정하고 TEST 웹서버에서 수정내역을 확인한다.
      • 테스트가 완료된 내역은 배포작업을 거쳐 운영서버에 반영된다.
    • 적용대상 개발환경
      • 1인 개발 or 다수의 개발자가 정확히 업무분장된 개발 시
    • 기존 개발환경이 가지는 문제점
      • UNDO 버튼 없는 에디터(개발환경)
      • 동일한 파일 작업 시 작업상태 보장 안됨(서로 다른 개발자가 하나의 파일을 동시에 수정할때)
      • 사본~, notice_YYMMDD 같은 dummy 파일 양산으로 인한 서버 리소스 낭비
      • 개발자가 맘만 먹으면 소스가 삭제될 수 있는 환경

3.5.2. 체계적인 팀 프로젝트 관리로 개선 예
  • develop_improve.png
    [PNG image (53.46 KB)]
    • 개발 흐름
      1. 개발자는 항상 작업 전 update 작업 수행
      2. 개발자는 작업 완료 후 작업소스 commit
      3. CI서버 배포처리
        1. 시스템 자동수행
        2. 프로젝트별로 미리 설정된 스케쥴(매 시간마다)을 통해 Subversion 저장소에 변경된 소스를 Checkout하고 배포처리 자동화 설정을 통해 변경된 소스를 Test PC IIS서버로 반영
        3. 사용자 직접수행
        4. 소스반영 작업은 스케쥴 처리 외에도 사용자가 직접 배포작업을 수행하는것이 가능
          1. 운영서버로 소스반영의 기존과 동일하게 개발자가 직접 반영. 향후 개선된 배포모델 적용예정
    • 소스버젼관리 시스템 도입에 따른 장단점
      • 장점
        • 버젼관리 시스템의 장점을 경험해보고 나면 이전의 개발환경으로 돌아가기 어렵다.
        • 모든 소스에 대한 이력사항 추적이 가능하다.
        • 소스 UNDO, REDO가 가능하다.
    • 단점
      • 버젼관리(Subversion) 개발체제는 개발자 로컬PC에 IIS를 설치해서 개발함에 따라 약간 번거로움
      • 버젼관리 시스템을 써보지 않은 사용자들에게는 조금 낯설은 방식이라 거부감이 있음
      • 사용법 필히 숙지해야함

4. Subversion을 이용한 소스관리

  • [http]SubversionBook
  • Subversion이 적용되는 가장 대표적인 사례 - [http]Starcraft2도 Subversion을 통해 개발
  • Subversion 외에도 무수히 많은 종류의 [http]SCM 소프트웨어들이 존재합니다.
  • Subversion은 명령행 인터페이스에서는 사용하는 명령어를 따서 svn이라고 줄여서 부르기도 합니다.
  • Subversion은 2000년 CVS 개발 멤버들이 의기투합하여 "CVS 대체"를 목표로 개발되었습니다.
  • CVS와 비교했을 때, Subversion은 다음과 같은 장점을 가진다.
    • 원자적으로 쓰기가 가능하므로, 다른 사용자의 쓰기와 엉키지 않는다.
    • 이름을 바꾸거나, 복사하거나, 파일을 삭제해도 revision history를 유지한다.
    • 이진 파일도 효율적으로 저장할 수 있다.
    • 디렉토리도 버전 관리할 수 있다. 디렉토리 전체를 빠르게 옮기거나 복사할 수 있으며, revision history도 그대로 유지한다.
    • 소스 저장고의 크기에 상관없이 일정한 시간안에 branching이나 tagging을 할 수 있다.
    • 소스 저장고 접근이 최적화 되었기 때문에, 소스 저장고에서 불필요한 네트워크 트래픽을 줄일 수 있다.
# Subversion Server는 접근성이 가장 좋은 Apache 서버방식을 택하였고 Apache moduel을 통해 서비스

4.1. Subversion을 이용한 개발


subversion_with_develop.png
[PNG image (59.3 KB)]

4.2. 저장소 디렉토리 구조

-- http://svn.samplerepository.org/svn/sample
 +--+---+- branches
    |   +--+- dav-mirror
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- svn-push
    |   +--- svnserve-thread-pools
    |
    +---+- tags
    |   +--- 0.10
    |   +--+- 0.10.1
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- 0.20
    |   +--- 0.30
    |   +--- 0.50
    |   +--- 1.01
    |
    +---+- trunk
        |--- src
        |--- doc
        +--- Makefile

4.3. 용어설명

  • 저장소
    • 리포지토리(Repository)라고도 하며 모든 프로젝트의 프로그램 소스들은 이 저장소 안에 저장이 됩니다. 그리고 소스뿐만이 아니라 소스의 변경 사항도 모두 저장됩니다. 네트워크를 통해서 여러 사람이 접근 할 수 있습니다. 버전 관리 시스템 마다 각각 다른 파일 시스템을 가지고 있으며 Subversion은 Berkeley DB를 사용합니다. 한 프로젝트 마다 하나의 저장소가 필요합니다.
  • 리비전(Revision)
    • 소스 파일등을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가 합니다. 저장소에 저장된 각각의 파일 버전이라 할 수 있습니다. Subversion의 경우 파일별로 리비전이 매겨지지 않고 한번 커밋 한 것으로 전체 리비전이 매겨 집니다. 리비전을 보고 프로젝트 진행 상황을 알 수 있습니다.
  • branches
    • 나무줄기(trunk)에서 뻗어져 나온 나무 가지를 뜻합니다. trunk 디렉토리에서 프로그램을 개발하다 보면 큰 프로젝트에서 또 다른 작은 분류로 빼서 따로 개발해야 할 경우가 생깁니다. 프로젝트안의 작은 프로젝트라고 생각하면 됩니다. branches 디렉토리 안에 또 다른 디렉토리를 두어 그 안에서 개발하게 됩니다.
  • tags
    • tag는 꼬리표라는 뜻을 가지고 있습니다. 이 디렉토리는 프로그램을 개발하면서 정기적으로 릴리즈를 할 때 0.1, 0.2, 1.0 하는 식으로 버전을 붙여 발표하게 되는데 그때그때 발표한 소스를 따로 저장하는 공간입니다. 위에서 보면 tags 디렉토리 아래에는 버전명으로 디렉토리가 만들어져 있습니다.
  • trunk
    • 단어 자체의 뜻은 본체 부분, 나무줄기, 몸통 등 입니다. 프로젝트에서 가장 중심이 되는 디렉토리입니다. 모든 프로그램 개발 작업은 trunk 디렉토리에서 이루어집니다. 그래서 위의 구조에서 trunk 디렉토리 아래에는 바로 소스들의 파일과 디렉토리가 들어가게 됩니다.

4.4. Tortoise SVN 오버레이 아이콘 설명

subversion_icon.png
[PNG image (64.46 KB)]

4.5. Subversion 설치

  • 본 설치문서는 http://www.pyrasis.com/main/SubversionServerForWindows 을 참조하여 작성하였습니다.
  • Subversion Server는 접근성이 가장 좋은 Apache 서버방식을 택하였고 Apache moduel을 통해 서비스

  • 서브버젼의 berkly db와 fss의 차이점을 설명
  • 서브버젼 changeset 비교를 winmerge로 설명

4.5.2. 설치

  1. Apache HTTP Server 2.0.63 프로그램 설치
  2. Subversion 1.4.6 프로그램 설치
    • 아파치를 먼저 설치한 경우 Subversion 인스톨러가 아파치를 인식해서 자동으로 httpd.conf 설정파일 변경
      subversion_install_with_apache_modules.png
      [PNG image (16.42 KB)]
  • httpd.conf 설정파일 변경내역
    • LoadModule dav_module modules/mod_dav.so 주석해제
    • LoadModule dav_svn_module "C:/Program Files/Subversion/bin/mod_dav_svn.so" 추가
    • LoadModule authz_svn_module "C:/Program Files/Subversion/bin/mod_authz_svn.so" 추가

4.5.3. 저장소 설정 및 Apache 설정

  • 저장소 생성
    mkdir c:\repos\svn
    cd c:\repos\svn
    svnadmin create sample
    
  • svnadmin으로 sample이라는 저장소를 만들면 c:\repos\svn 아래 sample이라는 디렉토리가 생깁니다. 이 디렉토리 안에는 Subversion이 제어하는 파일들이 들어있습니다. 저장소 생성 시 아무런 옵션을 주지 않으면 파일시스템으로 저장소가 만들어 집니다. sample 저장소의 전체 경로는 c:\repos\svn\sample이 됩니다.

  • Apache 설정
    1. 파일편집기로 C:\Program Files\Apache Group\Apache2\modules\httpd.conf 파일 맨 뒷부분에 아래와 같이 추가
      <Location /svn/sample> 
          DAV svn 
          SVNPath C:/repos/svn/sample
      </Location> 
      
    2. 설정을 마친 후 아파치 서버 재시작. http://localhost/svn/sample/ 으로 접속 후 아래의 메시지 확인되면 Apache와 Subversion 1차 연동 완료
      Revision 0: /
      
      Powered by Subversion version 1.4.6 (r28521).
      


  • Apache에서 ID로 사용자 인증
    • 이제 ID를 통해 인증된 사용자만 소스를 체크아웃하고 커밋 할 수 있도록 설정 하겠습니다.
      • 아파치에 사용할 패스워드 파일을 만듭니다. "htpasswd -c 패스워드파일명 사용자ID"
        cd C:\Program Files\Apache Group\Apache2\bin
        
        htpasswd -c ..\conf\passwd sampleuser
        
        "# htpasswd -c"는 패스워드 파일을 처음 만들 때의 옵션이고 사용자를 추가하고 싶을 때에는 "# htpasswd 패스워드파일명 사용자ID" 로 해주면 됩니다.
    • 방금 수정했던 파일편집기로 httpd.conf 파일의 맨 마지막 부분에 추가한 부분을 다시 설정 합니다.
      <Location /svn/sample> 
          DAV svn 
          SVNPath C:/repos/svn/sample
      
          AuthType Basic
          AuthName "Subversion Repository"
          AuthUserFile "C:/Program Files/Apache Group/Apache2/conf/passwd"
          Require valid-user
      </Location> 
      
      4줄이 추가 되었습니다. AuthType Basic은 Apache 기본 패스워드 인증입니다. !AuthName은 패스워드가 걸린 웹페이지에 뜨는 로그인창에 나올 문장입니다. !AuthUserFile은 방금 전 만들었던 아파치 패스워드 파일입니다. 절대경로로 적어주어야 합니다. Require valid-user는 인증된 사용자만 볼 수 있게 한다는 것입니다.
    • 설정을 마친 후 아파치 서버 재시작. http://localhost/svn/sample/ 으로 접속 후 사용자 인증 과정 확인되면 Apache와 Subversion 2차 연동 완료

  • 익명사용자(Anonymous)에 대한 Read 권한부여 설정
    • 웹 브라우저로 저장소를 보는 것과 체크아웃은 아무에게나(Anonymous) 할 수 있게 하고 커밋은 지정된 사용자만 할 수 있도록 하려면 httpd.conf에서 설정한 부분을 아래와 같이 바꾸어 주면 됩니다.
      <Location /svn/sample> 
          DAV svn 
          SVNPath C:/repos/svn/sample
      
          AuthType Basic
          AuthName "Subversion Repository"
          AuthUserFile "C:/Program Files/Apache Group/Apache2/conf/passwd"
          <LimitExcept GET PROPFIND OPTIONS REPORT>
            Require valid-user
          </LimitExcept>
      </Location> 
      
      이렇게 하면 저장소를 보거나 체크아웃을 할 때는 ID와 패스워드를 묻지 않고 커밋이나 디렉토리. 파일복사 등의 저장소를 변경하는 작업을 할 때에는 ID와 패스워드를 물어보게 됩니다.

4.5.4. 저장소 기본 디렉토리 구성

  • 기본 저장소 구조
    -- c:\repos\svn\sample
     +--+---+- branches
        +---+- tags
        +---+- trunk
    
  • 위 구조대로 svn 명령어를 통해 저장소에 디렉토리 생성
    svn mkdir http://localhost/svn/sample/branches -m "Initial branches" --username <사용자아이디> --password <패스워드>
    svn mkdir http://localhost/svn/sample/tags -m "Initial tags" --username <사용자아이디> --password <패스워드>
    svn mkdir http://localhost/svn/sample/trunk -m "Initial trunk" --username <사용자아이디> --password <패스워드>
    
  • 생성 결과 확인
    Revision 3: /
    
        * branches/
        * tags/
        * trunk/
    
    Powered by Subversion version 1.4.6 (r28521).
    


4.6. Subversion 기본 명령어


4.6.1. Import

맨 처음 프로젝트를 시작할 때 저장소에 소스들을 넣어야 합니다. 이럴 때 하는 것이 import 작업입니다. sampledir 이라는 디렉토리를 만든 뒤에 그 아래 다음과 같은 간단한 소스를 작성해 보십시오.

C:\Temp>mkdir sampledir

C:\Temp>cd sampledir

C:\Temp\sampledir>edit sample.c

#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.1\n");

  return 0;
}

이 소스를 저장소의 trunk 디렉토리에 import 하겠습니다. 아래 sampledir은 디렉토리입니다. 파일을 적으면 import되지 않습니다. 꼭 디렉토리를 만들고 그 디렉토리를 적어 주십시오. 저장소의 trunk 디렉토리에는 sampledir 디렉토리안의 sample.c 파일만 올라가게 되고 sampledir은 올라가지 않습니다. sampledir 아래 디렉토리를 만들었다면 그 디렉토리는 저장소의 trunk 디렉토리 아래에 올라가게 됩니다.

C:\Temp\sampledir>cd ..

C:\Temp>svn import sampledir http://localhost/svn/sample/trunk -m "sample.c import" --username <사용자아이디> --password <패스워드>
추가          sampledir\sample.c

커밋된 리비전 4.

이제 import가 제대로 되었는지 확인해 봅시다. list 명령을 이용해 trunk 디렉토리에 무엇이 있나 보겠습니다.

C:\Temp>svn list http://localhost/svn/sample/trunk
sample.c

4.6.2. Checkout

이제 부터 Subversion을 이용해서 프로그램 소스를 관리 할 수 있습니다. checkout을 해서 어디서든 소스를 받아 볼 수 있습니다. 방금 import를 하기위해 만들었던 sampledir은 지워도 됩니다.

svn checkout은 svn co로 줄일 수 있습니다. "svn checkout 저장소주소 로컬디렉토리" 의 형식 입니다.

C:\Temp>svn checkout http://localhost/svn/sample/trunk sample
A    sample\sample.c
체크아웃된 리비전 4.

checkout을 한 디렉토리 안에는 .svn 이라는 디렉토리가 있습니다. 이 디렉토리는 Subversion 저장소 정보가 들어 있기 때문에 지우면 안 됩니다.

4.6.3. Blame

Blame은 한 소스파일을 대상으로 각 리비전 대해서 어떤 행을 누가 수정했는지 알아보기 위한 명령입니다. 리비전, 커밋한 사용자의 ID, 소스 순서입니다.

sample# svn blame sample.c
     4 sampleuser #include <stdio.h>
     4 sampleuser
     4 sampleuser int main()
     4 sampleuser {
     5 sampleuser   printf("Sample Program Version 0.2\n");
     5 sampleuser   printf("Hello Subversion\n");
     4 sampleuser
     4 sampleuser   return 0;
     4 sampleuser }
     4 sampleuser

여기서는 커밋한 사용자가 한명 밖에 없으므로 전부 똑같이 나옵니다.

한 예로 여러사람이 커밋했을 경우 아래처럼 나옵니다.

     4 sampleuser #include <stdio.h>
     4 sampleuser
     4 sampleuser int main()
     4 sampleuser {
     7 epifanes     printf("Sample Program Version 0.3\n");
     6 pyrasis      printf("Hello Subversion\n");
     4 sampleuser
     4 sampleuser   return 0;
     4 sampleuser }
     4 sampleuser

특정 리비전만 지정해서 볼 수도 있습니다. 리비전을 지정하지 않으면 현재 리비전을 대상으로 합니다.

sample# svn blame -r 4 sample.c

5. Trac을 이용한 이슈관리

  • Trac 설치 및 Subversion과의 통합

5.2. Trac 설치

5.2.2. Trac 설치

  • Python
    1. Python 2.4.4
      1. Python 경로 환경변수로 등록
        python_environment_setting.png
        [PNG image (30.69 KB)]
    2. Python extensions for Windows
    3. mod_python(apache module)
    4. Subversion Python Bindings
  • Trac
    1. Trac 설치
      1. 압축풀고 python setup.py install
    2. DocUtils 설치
      1. 압축풀고 python setup.py install
    3. pysqlite 설치
    4. Clearsilver 설치
    5. SilverCity 설치

5.2.3. Trac Plugin 설치

  • [http]http://www.ncube.net/entry/윈도우에서-프로젝트-관리툴-Trac-설치와-기타-Plugin-설치
  • 개요
    • Trac plugin은 egg라는 python 배포패키지를 통해 설치를 해주어야 한다.
    • Trac plugin 제작자들이 egg파일을 직접 python 버젼별로 포팅해주는 경우도 있지만 이는 흔치 않은경우라 그냥 source를 egg파일로 만들어서 처리하도록 하는 습관을 만드는게 편하다.
    • Trac plugin 파일의 소스를 보면 setup.py이 있으며 python setup.py bdist_egg 명령을 수행해서 egg파일로 만들면 되고 Trac Admin - Plugins 페이지에서 Install Plugin 처리해주면 된다.
    • Trac plugin 설치하고 아파치 서버를 재시작하면 적용이 되고 특별한 경우는 trac.ini 설정파일을 수정하여 세세한 옵션을 설정할 수 있다.
    • 특정 Trac plugin을 python library로 설치를 하려고 하는경우 easy_install <plugin.egg> 명령을 통해 설치할 수 있다.

  • easy_install
c:\python24\python.exe ez_setup.py setuptools==dev
  • easy_install 설치완료 확인은 python24/scripts/easy_install.exe 파일 확인
  • Plugin
    • c:\python24\scripts\easy_install.exe을 통해 소스경로를 지정해주면 자동으로 설치됨
    • [http]Trac Plugin List

  • Web Admin
    1. [http]homepage
    2. 설치
c:\python24\scripts\easy_install.exe http://svn.edgewall.com/repos/trac/sandbox/webadmin
  1. 설정(trac.ini)
[components]
webadmin.* = enabled

c:\python24\scripts\easy_install.exe http://trac-hacks.org/svn/accountmanagerplugin/0.10
  1. 설정(trac.ini)
[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.api.accountmanager = enabled
acct_mgr.db.sessionstore = enabled
acct_mgr.htfile.abstractpasswordfilestore = enabled
acct_mgr.htfile.htdigeststore = enabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.http.httpauthstore = enabled
acct_mgr.pwhash.htdigesthashmethod = enabled
acct_mgr.pwhash.htpasswdhashmethod = enabled
acct_mgr.web_ui.accountmodule = enabled

trac.web.auth.LoginModule = disabled
acct_mgr.web_ui.LoginModule = enabled
acct_mgr.web_ui.RegistrationModule = disabled
  • 설정참고(trac.ini)
acct_mgr.web_ui.registrationmodule = disabled
  • 위의 옵션은 활성화 되면 anonymous 사용자가 직접 trac 페이지에서 register가 가능하다. 이 옵션은 프로젝트 초기 신규사용자를 등록할때 유용하며 사용자 등록이 마감되면 반드시 disabled 해놓아야 무분별한 사용자 등록을 막을수 있을것


5.2.4. Trac 프로젝트 생성

  • 작업 전
    • subversion 저장소 백업
subversion 폴더 백업 or bulk 뜨는 과정 기술
  • 프로젝트 생성
    • Trac 프로젝트 폴더 생성(폴더 생성하지 않고 진행할 경우 오류발생)
mkdir D:/repos/trac/test/ 
  • trac-admin을 통한 프로젝트 생성
c:\Python24\Scripts>python trac-admin D:/repos/trac/test/trac.db 

Trac [D:\repos\trac\test\trac.db]> initenv 엔터
project Name [My Project]> test 엔터
Database connection string [sqlite:db/trac.db]> 엔터
Repository type [svn]> 엔터
Path to repository [/path/to/repos]> D:/repos/svn/test 엔터
Templates directory [C:\Python23\share\trac\templates]> 엔터
Creating and Initializing Project -> 프로젝트 생성 시작

  • 사용자 권한설정
    • [http]권한설정 메뉴얼
    • 사용자 권한설정은 trac-admin 상태에서 아래 명령 수행
      • anonymous 권한 축소 처리
permission remove anonymous TICKET_CREATE
permission remove anonymous TICKET_MODIFY
permission remove anonymous WIKI_CREATE
permission remove anonymous WIKI_MODIFY
  • administrator user 관리자 권한 부여하여 추가
permission add administrator TRAC_ADMIN
  • htaccess 파일 생성
    • 사용자 관리 파일인 d:/repos/trac/test/.htaccess를 [http]htpasswd를 통해 administrator 하나만 생성. 암호는 "1234"로 생성

5.2.5. Trac 서비스 아파치 웹서버에 등록

  1. trac cgi 복사
copy c:\python24\share\trac\cgi-bin\trac.cgi "c:\Program Files\Apache Group\Apache2\cgi-bin" 
  1. httpd.conf 파일 설정
# module 추가
LoadModule python_module modules/mod_python.so

# httpd.conf 맨 하단에 Trac 서비스 설정 추가

Alias /trac "C:/Python24/share/trac/htdocs"

<Location />
  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend
  PythonOption TracUriRoot /
  PythonOption TracEnv "D:/repos/trac/test/trac.db"
  PythonOption TracLocale "English_KOREA"
</Location>

<Directory "C:/Python24/share/trac/htdocs">
  Options Indexes MultiViews
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

5.2.6. Trac 환경설정

  • trac.ini는 Trac 환경설정 설정파일이며 d:/repos/trac/test/trac.db/conf/ 디렉토리에 위치
  • Trac plugin설정은 완료된 상태라 가정
  • 아래 설정내역은 현재 운영중인 샘플 trac.ini파일임
# -*- coding: utf-8 -*-

[account-manager]
password_file = d:/repos/trac/test/.htaccess
password_format = htpasswd
password_store = HtPasswdStore

[attachment]
max_size = 1048576
render_unsafe_content = false

[browser]
downloadable_paths = /trunk, /branches/*, /tags/*
hide_properties = svk:merge
render_unsafe_content = false

[changeset]
max_diff_bytes = 10000000
max_diff_files = 0
wiki_format_messages = true

[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.api.accountmanager = enabled
acct_mgr.db.sessionstore = enabled
acct_mgr.htfile.abstractpasswordfilestore = enabled
acct_mgr.htfile.htdigeststore = enabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.http.httpauthstore = enabled
acct_mgr.pwhash.htdigesthashmethod = enabled
acct_mgr.pwhash.htpasswdhashmethod = enabled
acct_mgr.web_ui.accountmodule = enabled
acct_mgr.web_ui.loginmodule = enabled
acct_mgr.web_ui.registrationmodule = enabled
addcomment.macro.* = enabled
macropost.web_ui.* = enabled
trac.web.auth.loginmodule = disabled
trac.wiki.web_ui.wikimodule = disabled
tracnav.tracnav.* = enabled
tractags.* = enabled
webadmin.* = enabled

[header_logo]
alt = 
height = -1
link = 
src = 
width = -1

[logging]
log_file = trac.log
log_level = DEBUG
log_type = none

[mimeviewer]
enscript_modes = text/x-dylan:dylan:4
enscript_path = enscript
max_preview_size = 262144
mime_map = text/x-dylan:dylan,text/x-idl:ice,text/x-ada:ads:adb
php_path = php
silvercity_modes = 
tab_width = 8

[notification]
always_notify_owner = false
always_notify_reporter = false
always_notify_updater = true
mime_encoding = base64
smtp_always_bcc = 
smtp_always_cc = 
smtp_default_domain = 
smtp_enabled = true
smtp_from = 
smtp_password = 
smtp_port = 25
smtp_replyto = 
smtp_server = 
smtp_subject_prefix = __default__
smtp_user = administrator
use_public_cc = false
use_short_addr = false
use_tls = false

[project]
descr = Test Project Management System - Trac
footer = Visit the Trac open source project at<br /><a href="http://trac.edgewall.org/">http://trac.edgewall.org/</a>
icon = common/trac.ico
name = Test Project Management System
url = http://example.org/

[search]
min_query_length = 3

[ticket]
default_component = 
default_milestone = 검색로그 기능베타
default_priority = major
default_type = defect
default_version = 
restrict_owner = false

[timeline]
changeset_long_messages = false
changeset_show_files = 0
default_daysback = 15
ticket_show_details = false

[trac]
authz_file = 
authz_module_name = 
base_url = 
check_auth_ip = true
database = sqlite:db/trac.db
default_charset = EUC-KR
default_handler = TagsWikiModule
htdocs_location = 
ignore_auth_case = false
mainnav = wiki,timeline,roadmap,browser,tickets,newticket,search
metanav = login,logout,settings,help,about
permission_store = DefaultPermissionStore
repository_dir = D:/repos/svn/test
repository_type = svn
timeout = 20

[wiki]
ignore_missing_pages = false
render_unsafe_content = false
split_page_names = false

6. 최종목표는 지속적인 통합


6.1. 통합 빌드 머신

  • 통합 빌드 머신은 소프트웨어를 빌드하는 것을 그 유일한 존재 목적으로 삼는 별도의 컴퓨터를 말합니다. 통합 빌드 컴퓨터에서 CI 서버가 돌아가고, CI 서버는 버전 관리 저장소를 폴링합니다.

6.2. 지속적인 통합이 요구하는 컴포넌트

  • 버전 관리 저장소로의 연결
  • 빌드 스크립트
  • 몇 종류의 피드백 메커니즘(이메일 같은)
  • 소스 코드 변경 내역을 통합하기 위한 프로세스(수작업으로 하든, CI 서버를 활용하든)

6.3. 통합 머신 피드백 장치

  • 피드백 장치 결정 전 너무나 많은 정보는 피드백의 효과를 줄이는 "소음"이 될 수 있다는것을 염두하고 개발환경을 잘 고려해 적절히 선택
피드백 장치 설명 image
이메일 빌드 상태를 때에 맞춰 제공한다.
RSS 빌드 상태와 관련한 경고를 RSS 리더기로 보낸다.
SMS 빌드 상태에 대해 셀폰에 텍스트 메시지를 보낸다.
X10 시각적 방식으로 피드백을 보낸다. LAVA 램프와 빨간 경고등이 대표적인 예이다
Ambient Orb 빌드 상태를 알려주는 또 다른 시각적인 방식이다. 특정 정보에 따라 커스터마이징 될 수 있다.
모니터 Windows 태스크바에서 빌드 상태를 알려준다.
  • 위의 항목들은 효과적인 CI 시스템의 핵심이라 하겠습니다. 버전 관리 시스템에 변경 내역이 들어올 때마다 자동화된 빌드가 작동하고 일단 만들어놓고 나면, CI 시스템에 다른 기능을 넣을 수가 있습니다.
  • 기본적인 CI 시스템이 구축된 후 추가할 수 있는 기능
    • 소스코드 컴파일
      • 지속적인 소스 코드 컴파일은 CI의 가장 기본적이고 일반적인 특징 중 하나이며 지속적인 소스 코드 컴파일은 아주 흔하게 하는 일이라 CI와 동의어로 취급받는 정도
    • 데이터 베이스 통합
      • 테이터베이스 소스코드-데이터 정의 언어(DDL) 스크립트, 데이터 조작 언어(DML) 스크립트, 저장 프로시저, 분할 등등 역시 다른 소스 코드와 똑같이 취급
    • 테스트
      • 자동화되고 지속적인 테스트가 구비되어 있지 않은 CI는 CI가 아니라고 생각하는 사람이 많지만 필수 구성요소가 아니듯 기본적인 CI을 구축 후 적용해 나가는 목표중 하나로 염두해둬야 함
      • 자동화된 테스트가 존재할 때 소프트웨어를 수정하는 개발자는 좀 더 확실한 자심감을 갖고 개발에 할 수 있도록 도와줍니다.
    • 검사
      • 자동화된 코드 검사를 통해 여러 코딩 규칙을 강제함으로써 소프트웨어의 전체적인 품질을 높일 수 있습니다.
      • 대표적인 코드 검사도구로는 자바 코드를 검사하는 Checkstyle이 있으며 이를 이용해 코딩 표준과 품질 메트릭을 지속적으로 모니터링이 가능하게 도와줍니다.
    • 배포
      • 거의 대부분의 빌드는 배포를 목적으로 수행합니다.
      • 배포를 지속적으로 하게되면 어느 순간이라도 실제로 작동하는 소프트웨어를 배포할 수 있습니다. 물론 이것이 가능하게끔 하기 위해서는 버전 관리 저장소에서 소스 파일을 체크아웃하고, 빌드를 수행하고 테스트와 검사를 전부 성공시키고, 릴리즈에 꼬리표(tag)를 붙이며, 배포 파일을 잘 꾸며야 합니다.
        • CI 시스템의 핵심 목표는 항상 최근 코드를 가지고 소프트웨어를 빌드하고 테스트하는 것입니다.
  • 지속적인 통합이 주는 가치
    • 흔히 발생하는 일반적인 위험을 줄여준다
    • 반복적인 수작업을 줄여준다
    • 언제 어느 때라도 배포할 수 있는 소프트웨어를 생성해낸다
    • 프로젝트 가시성을 보다 좋게 해준다
    • 개발 팀이 소프트웨어 제품에 대해 보다 큰 자신감을 갖게 해준다

7. Q&A


8. 세미나의 목적과 방향성

  • 개발자들에게 무엇을 전달할 것인가?
    • 좋은개발환경이 개발자와 프로젝트에게 가져다 주는 혜택(?), 중요 포인트는 삶의 질과 품질의 개선에 주안점
  • 어떤 방법으로 설득하면 좋을까?
    • 지속적인 통합 시스템을 이용한 사례 소개
    • 관련 도서의 구절 인용
  • 세미나에 사용될 소스는 오픈소스를 이용하여 진행
    • daysago가 좋은 예제가 될듯싶음
  • trac + subversion + continuous integration 소개를 실 적용예를 들어 설명
    • 본격적인 세미나를 시작하기 전에 아래의 사례를 소개하고 진행하는 것이 효과적인 전달에 필수 요소
    • Visual C++을 이용해 software product를 만들어내는 곳에서 cruisecontrol .net 으로 적용한 예제
      • 누군가가 소스를 변경하고 처리하고 퇴근했을때 다음날 팀원이 빌드를 수행했을때 빌드가 깨지는 상황을 바로 캐치
    • Java를 이용한 web site개발에서도 마찬가지로 지속적인 통합 빌드프로세스에서 설정해둔 테스트 수트를 거치면서 에러가 발생했을때의 대응 예제
  • subversion 사용사례 발표내용 요약
    • Checkout, Update, Commit등을 실제 처리하는 UCC 제작
    • 두 개발자가 하나의 소스를 동시에 수정했을 때 대처하는 상황묘사 UCC 제작 WinMerge를 자연스럽게 소개
    • Subversion 상황별 아이콘은 첨부자료로 소개하고 아이콘은 실제 적용해 사용하면서 필요한 부분이라고 간략하게 소개
  • 훌륭한 참고 페이지
  • 설문항목
    • 어떤 방법론을 팀에 적용하여 사용하고 있는지?
      • 프로젝트 에코시스템(개발환경의 효율적 개선)은 애자일 방법론을 지향합니다.
    • 프로젝트에 개발환경을 개선하기 위해서 적용하고 있는 시스템은?
      • SUBVERSION
      • 이슈추적관리
      • 지속적인 통합
      • 설문을 통해 도입전과 후의 느낀점을 물어보는 시간을 가져보는것이 세미나에 도움이 될꺼 같음
  • [http]체계적으로 관리하는 것이 중요

13. 도입하면서


13.1. 도입 방안

현재까지 가장 효과적인 도입 방법(단, 혼자서 특정 솔루션이나 웹사이트를 맡고 있는경우 유용)

  1. 본인이 먼저 개발환경에 써보고 기존 개발환경에서 요구되는 사항을 충분히 만족하는지 확인
  2. 개발환경 변화의 이슈가 발생하였을때 은근슬쩍 얘기를 꺼낸다
    1. "본인의 개발환경은 그러한 이슈를 해소하여 운영하고 있다고..."
    2. 흥미유발과 동일한 문제에 대한 해결책을 체계적으로 제시
      1. 이것은 wiki로 적용방안을 체계적으로 정리하는 것이 중요

13.2. InfoQ

Kenny군이 소개해 준 사이트인데 Tracking change and innovation in the enterprise software development community를 표방

13.3. Mingle


13.3.1. Install for windows

  • 8080포트로 설치를 8090으로 변경한 후 프로그램 설치 완료
  • http://localhost:8090 접속
    • firefox로는 접근이 되는데 IE로 할 경우 페이지가 뜨지 않는 현상 발생
      • 설치 완료된 후 즉시 접근하면 접근안되다가 10분쯤 지나니까 되드라능 -_-;
 Internet Explorer에서 웹 페이지를 표시할 수 없습니다. 
   
   가능성이 높은 원인:
인터넷에 연결되어 있지 않습니다. 
웹 사이트에 문제가 발생했습니다. 
주소에 오타가 있을 수 있습니다. 
 
   가능한 해결 방법: 
     연결 문제 진단  
 
     추가 정보 
  • mysql과 stmp 셋팅 후 설치 마무리


ID
Password
Join
Words must be weighed, not counted.


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2008-05-15 16:16:03
Processing time 0.0283 sec