• 카테고리
    • 전체 글

    • 카테고리1
    • 카테고리2
    • 카테고리3
    • 카테고리4
  • 태그
  • 방명록

'분류 전체보기'에 해당되는 글 1246건

  • 2009.08.06 고경오군의 책. - 위대한자들의 탄생.
  • 2009.08.04 CCNet 에서 MS Test 동작시키기 2
  • 2009.08.04 CCNet 구성하기
  • 2009.08.04 .NET Continuous Integration
  • 2009.08.04 학교 연구실에 한번 해봤던... 바로 그...
  • 2009.08.04 어떤 어려움이 있는지 고르는 어려움이 있군요.
  • 2009.08.03 소프트웨어 개발은 제품 생산라인이 아니란 말이다!
  • 2009.07.31 무엇을 생각한걸까?

고경오군의 책. - 위대한자들의 탄생.

잡글 2009. 8. 6. 10:03

고등학교 때 부터 내내 글쓰기 위해 다양한 노력하던 친구가 드디어 책을 발간했다.

글을 읽고난 리뷰는 여기를 클릭



책 제목은 위대한 자들의 탄생이라는 책.

예전 하이텔, 나우누리, 데이콤 등이 있던 통신 시절. 하이텔의 환타지 동호회 때 부터,
단편, 장편들을 다양하게 연재 했다. 사실 그 당시 환타지 장르가 한창 붐이 일어났고,
그 때 수많은 환타지 작가들이 탄생했다. 그 중  한 명이 될 줄 알았는데,
계속 참고 있었던 것 같다.

이번에 인생 가름길로 생각하고 작정하여 글을 썼고, 결국은 책을 냈다.
수많은 책을 집필하고, 어느정도 글쓰는 자로 명성을 얻은 사람들이나, 다양한 사람들의 글을 읽는 독자라는
입장을 기준으로 별로 신기할 것도 없는 작은 내용이겠지만,
최소한 글쓰는 사람을 아는 사람이라는 입장에서 보면 참 신기한 느낌이 드는 건 당연할까?

사실 이 책이 대박날지는 모르겠다. - 게다가 책이 어제 도착했는데, 읽어보지도 못했다 -
최소한 내가 아는 소설가라는 점에 그가 잘되길 빌 뿐이다.

출 퇴근때 짬짬히 한번 읽어봐야 겠다.
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

CCNet 에서 MS Test 동작시키기

기술자료/개발도구 2009. 8. 4. 17:44

MS Test 연동하기
요즘 TDD 학습에 피치를 올리고 있기 때문에, MS Visual Studio 안의 Test Unit을 사용중이다.

(NUnit이 .NET을 위한 Unit 테스트 프레임으로 다양한 기능을 제공한다고 한다. 또한 이 CCNet 안에서도 자체 지원되며 결정적으로 CCNet Config에서 간단하게 추가할 수 있다..

그러나 아직 NUnit을 한번도 사용해 본적이 없다. )

 

그런데 CCNet 에서는 MS Test를 적용하는 방법이 직접적으로 설정 할 수 없었다. (최소한 1.4.4 버전에선....)

대신 MS Test를 일종의 작업으로 돌려, 그 결과 값을 Report에 적용해줄 수 있었다.

그 중 googling을 통해 얻은 자료 중 하나가 바로 이것이다. (CCNet 에서 MS Test 결과를 적용하는 방법이 담긴 링크)

 

시작하기 전에

이 작업을 하려면 먼저 MS Test를 실행하는 방법을 어느정도 이해해야 한다.

IDE 도구에서야 Test의 Test 실행 버튼 한번이면 되지만, 여기서 작업이라는 형태로 만들려면, 외부에서 프로그램을 어떻게 띄워야 하는지 등을 알아야 한다.

  • 솔루션 전체를 한번 빌드 한다
  • 이전에 Test 결과 값이 있는 경우 삭제하는 배치 파일을 만든다. 그리고 그 배치를 실행할 수 있게 한다.
  • MSTest를 동작시키는 프로그램을 실행하며 동작시킨다.
  • 테스트 결과물을 CCNet에 연동한다.

이제 이런 방법으로 차근 차근 하나씩 적용하도록 한다.

 

준비 작업

맨 먼저 준비해야 될 작업은 작업의 기준이 되는 CCNet 설정파일이다.

이 설정 파일을 기준으로 하나씩 추가해야 하며 각 단계를 아래에서 계속 설명할 것이다.

이전 단계에서 설명한 내용을 기반으로 CCNetConfig를 이용해 구성했다면 다음과 같은 .config 파일을 열어볼 수 있다.

(.config 파일은 C:\Program Files\CruiseControl.NET\server\ccnet.config 를 의미한다. )

<!--<ccnetconfig><configurationVersion>1.4</configurationVersion></ccnetconfig>-->
<cruisecontrol>
  <project name="CQWorkflowViewer">
    <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
    <artifactDirectory>E:\Builds\CQWorkflowViewer</artifactDirectory>
    <sourcecontrol type="svn">
      <trunkUrl>file:///D:/Works/000.MySVN/CQWorkflowViewer</trunkUrl>
      <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
      <executable>C:\Program Files\VisualSVN\bin\svn.exe</executable>
    </sourcecontrol>
    <triggers />
  </project>
</cruisecontrol>

 

 

솔루션 전체 빌드하기.

맨처음에 난 이 내용을 이해하지 못했다. 그냥 MS Test를 동작시키면 되지 않을까 했다.

하지만, MS Test가 동작하려면, 테스트 코드가 컴파일되어 있는 DLL이 필요했는데, 이 DLL은 결국 솔루션 전체 Build가 되어야 생성될 수 있다.
(Unit 테스트 자체가 이곳 저곳의 클래스와 컴포넌트들을 거의 직접 연결하므로 어쩔 수 없는 것 같다.)

이 빌드 방법은 솔루션 파일(*.sln)을 직접 컴파일 해야 되기 때문에, Visual Studio의 힘을 빌릴 수 밖에 없다.

그래서 이 Task를 하나씩 조립해서 하나의 Task로 만들면 다음과 같다.

<devenv>
                <solutionfile>"E:\Builds\CQWorkflowViewer\Works\CQWorkflowViewer.sln"</solutionfile>
                <configuration>Debug</configuration>
                <buildtype>Build</buildtype>
                <executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com"</executable>
                <buildTimeoutSeconds>90</buildTimeoutSeconds>
 </devenv>

뭔가 낯선 이상한 XML 엘리멘트들이 튀어 나왔다.

이 작업 devenv라는 컴파일 구성요소를 설정하는 내용으로 위의 내용은 특정 솔루션을 전체 빌드하기 위한 내용이다. 

각 부품들을 하나씩 살펴보자.

solutionfile 부분은 이 프로젝트의 솔루션 파일의 위치를 정해준다. 작업 디렉토리를 기준으로 해당 솔루션 파일이 어디 있는지 확인해서 해당 내용을 적용해주면 된다.

configuration 부분은 전체 빌드 형태를 결정해준다. Debug 모드인지 Release 모드인지 등을 결정하는 것이다.

excutable에는 이 빌드 작업을 수행할 프로그램을 선택한다. x64나 기타 다른 위치에 설치 하지 않았다면 위의 경로로 넣으면 된다. 만일 틀리다면 devenv.com이 있는 위치를 찾아

넣어주도록 한다.

나머지는 필자도 잘 모르지만 일단 테스트해 본 결과 저 정도로 마무리 지으면 일단 제정신으로 도는 것 같다.

 

위의 XML 부품을 구성하고 이해했다면, 이제 ccnet.config 안에 끼워 넣도록 한다.

이 부품은 다음의 경로에 추가해주면 된다.

//cruisecontrol/project/tasks

경로라고 말한 부분은 바로 엘리멘트 트리 순서이다.

XML로 표현하면 다음과 같은 구성이 되어줘야 한다는 것이다.

     <cruisecontrol>

        <project ...>

           <tasks>(여기를 의미하는 것)</tasks>

        </project>

     </cruisecontrol>

우리 원본 ccnet.config에 보면 tasks 라는 엘리멘트를 볼 수 없는데, 이 부분은 추가해줘야 한다.

자, 이렇게 해서 조립하면 다음과 같은 ccnet.config가 된다.

 

<!--<ccnetconfig><configurationVersion>1.4</configurationVersion></ccnetconfig>-->
<cruisecontrol>
  <project name="CQWorkflowViewer">
    <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
    <artifactDirectory>E:\Builds\CQWorkflowViewer</artifactDirectory>

    <tasks>

<devenv>
                <solutionfile>"E:\Builds\CQWorkflowViewer\Works\CQWorkflowViewer.sln"</solutionfile>
                <configuration>Debug</configuration>
                <buildtype>Build</buildtype>
                <executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com"</executable>
                <buildTimeoutSeconds>90</buildTimeoutSeconds>
 </devenv>

    </tasks>
    <sourcecontrol type="svn">
      <trunkUrl>file:///D:/Works/000.MySVN/CQWorkflowViewer</trunkUrl>
      <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
      <executable>C:\Program Files\VisualSVN\bin\svn.exe</executable>
    </sourcecontrol>
    <triggers />

  </project>

</cruisecontrol>

 

테스트 결과 파일 삭제하기.

MS Test를 돌리게 되면 그 결과물을 XML 형태로 만들어 주게 되는데, 이 파일이 위치해 있으면 MS Test가 무조건 실패하게 된다.

그래서 MS Test를 동작 시키기 전에 반드시 해당 파일이 있으면 낼름 지워주는 기능을 하는 배치 파일(.Bat 또는 .Cmd)을 만들어 주도록 한다.

실제 이 결과물이 어디에 저장되는지는 다음에 정의할 MS Test 관련 설정을 할 때 결정되는데, 여기서는 그 결과물이 테스트 프로젝트가 있는

위치에 저장된다는 가정하에 설정하도록 하겠다.

먼저 적당한 위치에 .Bat 도는 .Cmd를 만든다. 여기서는 E:\Builds\CQWorkflowViwer 폴더에 deleteReport.bat라는 파일을 만들도록 하겠다.

그 내용은 다음과 같다.

IF EXIST E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer\testResults.trx DEL /f E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer\testResults.trx

원리는 간단하다. 파일이 있으면 지우고 없으면 지우지 않는다. 뭐 그정도?

그리고 난 뒤에 위에서 만든 작업 처럼 이번 것도 작업으로 만들어 준다.

이번에는 단순히 실행만 하면 되므로 devenv 엘리멘트가 아닌 exec 엘리멘트를 사용한다.

이 엘리멘트로 구성하면 다음과 같이 만들 수 있다.

<exec executable="deleteReport.bat">
   <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
   <buildArgs></buildArgs>
</exec>

특별한 설명은 필요 없지만, 일단 간단하게 각 엘리멘트 및 속성 값을 설명하면 아래와 같다.

exec는 이 작업이 단순 실행하는 작업을 의미하는 것이다. 실행할 내용은 executable 이라는  속성값에 값을 넣으면 된다.

baseDirectory는 이 실행이 진행되는 위치를 의미한다.

이 내용을 지금까지 만든 설정 파일이 추가해 보자. tasks는 앞서 만들었으니 이제 그 다음에 넣어주면 될 것이다.

<!--<ccnetconfig><configurationVersion>1.4</configurationVersion></ccnetconfig>-->
<cruisecontrol>
  <project name="CQWorkflowViewer">
    <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
    <artifactDirectory>E:\Builds\CQWorkflowViewer</artifactDirectory>

    <tasks>

<devenv>
                <solutionfile>"E:\Builds\CQWorkflowViewer\Works\CQWorkflowViewer.sln"</solutionfile>
                <configuration>Debug</configuration>
                <buildtype>Build</buildtype>
                <executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com"</executable>
                <buildTimeoutSeconds>90</buildTimeoutSeconds>
 </devenv>   

      <exec executable="deleteReport.bat">
         <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
         <buildArgs></buildArgs>
      </exec>

</tasks>   

<sourcecontrol type="svn">
      <trunkUrl>file:///D:/Works/000.MySVN/CQWorkflowViewer</trunkUrl>
      <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
      <executable>C:\Program Files\VisualSVN\bin\svn.exe</executable>
</sourcecontrol>

      <triggers />

  </project>

</cruisecontrol>

 

MS Test 동작시키기.

모든 준비작업은 끝났다. 이제 실제적으로 동작해야하는 작업을 수행한다.

이번에는 MSTest를 동작시킨다. 이를 위해서 하는 방법은 위의 방법과 거의 동일하다.

단지, 몇가지 MSTest를 동작시키기 위한 파라미터 값만 조정하면 된다.

<exec executable="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe">
   <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
   <buildArgs>/testcontainer:bin\debug\TestProjectCQWorkflowViewer.dll  /resultsfile:testResults.trx</buildArgs>
   <buildTimeoutSeconds>90</buildTimeoutSeconds>
</exec>  

 

앞서 테스트 결과 삭제 목록의 내용 중에서 특이 점은 buildArgs 부분에 파라미터 값들이 정의된다는 사실이다.

테스트를 동작시키기 위한 DLL 정보와 테스트 결과를 저장하기 위한 그 리포트 출력용 파일 이름 정도이다.

실행할 주체가 mstest.exe 인 C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe 정도 뿐이다.

여기서 경로등을 주의해서 넣어주면 된다.

만일 mstest의 특별한 기능들이 더 필요한 경우 http://msdn.microsoft.com/en-us/library/ms182489%28VS.80%29.aspx 를 참고해서

파라미터 값들을 조정해주면 된다.

이를 추가하면 아래와 같이 된다.

<!--<ccnetconfig><configurationVersion>1.4</configurationVersion></ccnetconfig>-->
<cruisecontrol>
  <project name="CQWorkflowViewer">
    <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
    <artifactDirectory>E:\Builds\CQWorkflowViewer</artifactDirectory>

    <tasks>

<devenv>
                <solutionfile>"E:\Builds\CQWorkflowViewer\Works\CQWorkflowViewer.sln"</solutionfile>
                <configuration>Debug</configuration>
                <buildtype>Build</buildtype>
                <executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com"</executable>
                <buildTimeoutSeconds>90</buildTimeoutSeconds>
 </devenv>   

      <exec executable="deleteReport.bat">
         <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
         <buildArgs></buildArgs>
      </exec>

<exec executable="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe">
   <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
   <buildArgs>/testcontainer:bin\debug\TestProjectCQWorkflowViewer.dll  /resultsfile:testResults.trx</buildArgs>
   <buildTimeoutSeconds>90</buildTimeoutSeconds>
</exec>

</tasks>   

<sourcecontrol type="svn">
      <trunkUrl>file:///D:/Works/000.MySVN/CQWorkflowViewer</trunkUrl>
      <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
      <executable>C:\Program Files\VisualSVN\bin\svn.exe</executable>
</sourcecontrol>

      <triggers />

  </project>

</cruisecontrol>

 

 

리포트 결과를 CCNet에 보고하기.

이제 마지막 부분이다. 위의 내용 까지는 최종 테스트 결과물을 만드는 과정이다. 이제 그 테스트 결과물을 빌드 결과물로써 나타내게 해주면 된다.

지금까지는 tasks 안에 들어갔지만, 이번에는 tasks 밖에서 publishers 라는 엘리멘트 안에 작업을 해주어야 한다.

기본적인 작업들이 들어가는데, 그 중 추가적인 작업 결과물은 여기서 처리해주어야 한다.

결론적으로 해당 처리를 위한 XML은 아래와 같다.

<publishers>
   <merge>
      <files>
         <file>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer\testResults.trx</file>
       </files>
   </merge>
   <xmllogger />

</publishers>

 

publishers 나, merge, files은 XML 형식에 맞추기 위해 필요한 내용이고, xmllogger는 다른 기능을 위해 준비된 내용이다.

우리가 집중할 부분은 file 부분으로 이 안에 xml 형식으로 된 리포트 파일만 걸어주면 된다. 앞에서 예제로 설정한 내용을 기준으로 본다면,

테스트 작업 후, E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer\testResults.trx 라는 파일이 생기게 된다.

 

자 이것을 추가하면 아래와 같이 정리된다.

<!--<ccnetconfig><configurationVersion>1.4</configurationVersion></ccnetconfig>-->
<cruisecontrol>
  <project name="CQWorkflowViewer">
    <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
    <artifactDirectory>E:\Builds\CQWorkflowViewer</artifactDirectory>

    <tasks>

<devenv>
                <solutionfile>"E:\Builds\CQWorkflowViewer\Works\CQWorkflowViewer.sln"</solutionfile>
                <configuration>Debug</configuration>
                <buildtype>Build</buildtype>
                <executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com"</executable>
                <buildTimeoutSeconds>90</buildTimeoutSeconds>
 </devenv>   

      <exec executable="deleteReport.bat">
         <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
         <buildArgs></buildArgs>
      </exec>

<exec executable="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe">
   <baseDirectory>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer</baseDirectory>
   <buildArgs>/testcontainer:bin\debug\TestProjectCQWorkflowViewer.dll  /resultsfile:testResults.trx</buildArgs>
   <buildTimeoutSeconds>90</buildTimeoutSeconds>
</exec>

</tasks>   

<sourcecontrol type="svn">
      <trunkUrl>file:///D:/Works/000.MySVN/CQWorkflowViewer</trunkUrl>
      <workingDirectory>E:\Builds\CQWorkflowViewer\Works</workingDirectory>
      <executable>C:\Program Files\VisualSVN\bin\svn.exe</executable>
</sourcecontrol>

      <triggers />

<publishers>
   <merge>
      <files>
         <file>E:\Builds\CQWorkflowViewer\Works\TestProjectCQWorkflowViewer\testResults.trx</file>
       </files>
   </merge>
   <xmllogger />

</publishers>

 

  </project>

</cruisecontrol>

 

이제 실제로 서버를 실행해 보면, MSTest까지 수행하고 그 결과 값에 따라 Build 성공 실패가 보이기 시작할 것이다.

 

PS. 웹에서 이 결과 리포트를 보고 싶을때.

굳이 필요한 기능은 아니지만, 빌드 결과물을 보여주는 웹화면에서 이 Test 결과 내용도 보고 싶다면 추가적인 작업을 해야 한다.

CCNet의 웹을 띄우기 위해서는 http://<<서버이름>>/ccnet 이라고 치면 된다.(설치 중 Web Url을 변경하거나 조작한 경우 다른 이름이 될 수 있다.)

그래서 화면이 뜨면 각종 리포트를 위한 웹 화면을 볼 수 있는데, 그 중 이 Test 결과도 볼 수 있다.

그러나 MS Test는 기본 값이 아니기 때문에, 이 리포트용 웹사이트에 한가지 작업을 더 수행해주어야 한다.

 

작업을 하려면, 맨 먼저 해당 웹사이트가 있는 폴더로 이동한다.

CCNet이 설치된 폴더에서 webdashboard 라는 폴더이며, 그 안에 있는 dashboard.config 파일을 열도록 한다.

 

그리고 <xslReportBuildPlugin description="....... > .... </xslReportBuildPlugin> 항목들이 쭉 늘어선 곳에다 다음 줄을 추가한다.

    <xslReportBuildPlugin description="MSTest Report" actionName="MSTESTReport" xslFileName="xsl\MsTestSummary.xsl"/>

SNAG-0050.png

 

이제 다시 웹을 띄운 후 프로젝트를 클릭해서 들어간다.

SNAG-0053.png

오른편쪽에 항목들 중 자신이 실패한 빌드 번호를 클릭한다.

SNAG-0054.png

이번엔 왼편에 Report나 Log 목록들이 있는데 그 중 MsTest Report를 클릭한다.

SNAG-0055.png

 

오른편에 해당 오류가 발생한 내용이 표시된다.

SNAG-0056.png

 

이 글은 스프링노트에서 작성되었습니다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

CCNet 구성하기

기술자료/개발도구 2009. 8. 4. 17:44

설치 및 구성하기.

설치 쪽은 최재훈 님께서 마이크로스프트웨어에 기고했던 글을 참고하면 된다.

http://kaistizen.net/EE/index.php/imaso/continuousintegration_2008_04/

 

일단 기본적으로 설치하면 각 사용할 파일들은 C:\Program Files 위치에 저장된다.(x64에서는 다른 위치에 저장될 수 있지만, 아직 테스트 해보지 않았음)

맨처음 CCNet 서버를 설치하면 설치 완료 후 별다른 반응을 보이지 않는다.

시작 -> 모든 프로그램 -> CruiseControl.NET -> CruiseControl.NET 을 실행하면 도스 창에 무언가 버글 버글 뜨고, 화면이 멈춰 있는 것을 볼 수 있다.

SNAG-0030.png
이게 콘솔 화면으로 띄우는 CCNet 인데, 설정 디버그나 결과들을 확인하고 싶을 때 이렇게 해서 확인하면 된다.

만일 설정 파일이나 설정 정보가 안정적으로 동작한다고 생각된다면, 이런 식의 도스 창 같은 것을 띄우지 않고 서비스로 동작하게 할 수 있다.

시작 -> 제어판 -> 관리 도구 -> 서비스 에 들어가서 CruiseControl.NET Server 서비스를 시작해 주면 된다.

SNAG-0031.png

만일 서버 리붓후에도 계속 켜지게 하고 싶은 경우에는 시작 유형을 수동에서 자동으로 변경해주면 된다.

 

주의 : 만일 서비스 상태로 띄우다가, 도스창(디버그용)을 띄우면 안된다. 만일 도스창용으로 띄우고 싶으면, 반드시 서비스로 동작 중인 CCNet을 죽이고수행해야 한다.

 

설정 파일 구성하기

CCNet 의 설정파일은 C:\Program Files\CruiseControl.NET\server 폴더 안에 있다. 파일 이름은 ccnet.config 라는 이름으로 되어 있으며, 이 안의 값을 어떻게 정의하냐에 따라, 빌드 서버가 어떻게 동작하는지를 결정하게 된다. 모든 내용은 XML 기반으로 구성되어 있어, 가독성에서 꿀리는 부분은 없다.

그.러.나. 이 안의 각 Element 들이 어떻게 들어가는지 값들이 어떻게 들어가는 지에 대한 설명은 모두 영어로 된 도움말의 도움을 받아야 한다.

http://confluence.public.thoughtworks.org/display/CCNET/Configuring+the+Server 를 보게 되면, 설정 파일 내에 설정할 수 있는 다양한 내용들이 있다.

간단하게 테스트 하는 수준이였다면, 내가 찾아들어간 방식대로 한번 시도 해보자.

 

  1. CCNetConfig 프로그램 실행하기.

    앞서 언급한 프로그램 중 하나이다. 설정 파일인 XML 파일을 설정하는데 Visual Studio의 속성값 편집하듯이 편하게 구성되어 있다.
    물론 전체적인 내용이 딱 한눈에 안들어오긴 하지만, 이 정도의 가이드가 있다면 큰 도움이 될 것이다.

    실행하면 아래와 같은 화면이 떨렁 나올 것이다.
    SNAG-0032.png
    당황하지 말고 File -> Open을 해서 C:\Program Files\CruiseControl.NET\server 폴더 안의 ccnet.config 파일을 선택한다.

    Open 할때, OpenFileDialog 에서 아래쪽에 있는 Version을 꼭 선택해주시기 바란다. 현재 CCNet이 설치된 버전을 확인해서,
    1.1인지, 1.2 인지..아니면 1.4 인지를 꼭 체크해서 그에 맞는 버전을 선택한다.
    SNAG-0033.png

    열리면 아래와 같이 왼쪽에 트리 형태의 내용이 뜨게 된다.
    SNAG-0034.png

  2. 새로운 프로젝트를 추가하기.
    자 이제 실제 Build 작업을 수행할 프로젝트를 선택한다. File 이라는 메뉴 아래에 있는 아이콘을 선택하거나 CruiseControl 이라는 항목에서 오른쪽 버튼을 눌러 컨텍스트 메뉴에서 프로젝트 추가를 하던 어떤 식이든 Add Project를 하도록 한다.
    SNAG-0035.png
    프로젝트 이름을 입력하는 창에 이번에 Build 할 솔루션 이름을 넣는다. (달라도 되는지는 테스트 해본적이 없어서 -_-;;)
    SNAG-0036.png
  3. 프로젝트 기본 속성값 넣기.
    이제 프로젝트에 대한 기본 속성값을 넣도록 한다. 왼쪽 트리에서 입력한 프로젝트 명을 클릭하면 오른쪽에 속성 창이 뜬다.
    SNAG-0038.png  
    언어적 장벽이 큰 문제가 없다면 아래쪽 간단한 설명을 도움받아 값을 넣어주면 된다. 
    이 중 최소 컴파일이 되기 위한 내용들을 채워보자면 다음과 같다.
    여러가지 내용들이 들어갈 수 있지만 최소 다음 내용 정도를 채우면 된다.

    • (Name) : 이름. 제일 중요하기도 하지만, 프로젝트 만들때 결정되니까 가급적 손대지 말았으면 좋겠다.
    • ArtifactDirectory : 프로젝트에 대한 산출물 디렉토리. 상대 경로로 설정되어 있다면 CruiseControl.NET 서버가 설치되어 있는 디렉토리에 프로젝트 이름을 기준으로 구성된다. 산출물 디렉토리는 빌드 로그, 배포물 등등 빌드의 결과물로 저장될 내용들이 저장되는 장소이다. 가급적 이 폴더는 프로젝트 별로 틀리게 설정해주어야 빌드에 대한 각종 결과물들이 정상적으로 보이게 된다. 단 경로를 입력할 때 중간에 공백이 들어가 있더라도 쌍따옴표 표시(")는 필요없다.
    • SourceControl : 소스 버전 관리 도구에 대한 설정을 한다. 이 CCNet에서 자동으로 최신버전을 받아서 빌드를 수행할 때 소스를 받게되는 위치를 의미한다.
    • WorkingDirectory : 프로젝트에 대한 작업 디렉토리. The Working Directory for the project (this is used by other blocks). 상대 경로로 설정되어 있다면 CruiseControl.NET 서버가 설치되어 있는 디렉토리에 프로젝트 이름을 기준으로 구성된다. 작업 디렉토리는 통합 수행을 하는 프로젝트에서 체크아웃된 버전을 포함한다. 이 경로는 프로젝트 별로 틀리게 설정해주어야 빌드시 오류가 발생되지 않는다.  단 경로를 입력할 때 중간에 공백이 들어가 있더라도 쌍따옴표 표시(")는 필요없다.    
  4. 채운 내용을 예제로 캡처한 내용이 다음과 같다.
    (각 값은 필자 프로젝트를 기준으로 맞춘 내용이므로 적절히 자신의 환경에 맞게 구성해 주어야 한다. )
    프로젝트 명 : CQWorkflowViewer

    산출물 디렉토리 : E:\Builds\CQWorkflowViewer
    작업 디렉토리 : E:\Builds\CQWorkflowViewer\Works
    소스버전관리 : SubVersion,
        - 서브 버전 프로그램 위치(소스버전관리 형태에 따라 다름) : C:\Program Files\VisualSVN\bn\svn.exe
        - 서브버전 URL : file:///D:/Workfs/000.MySVN/CQWorkflowViewer
        - 소스 처리 경로 : E:\Builds\CQWorkflowViewer\Works
    SNAG-0039.png

  5. 저장 버튼을 눌러 저장한다.

 

동작 확인

구성이 완료되었으면 이 빌드가 정상적으로 동작하는지 꼭 확인하도록 한다.

서버를 무작정 동작시키진 말고, 콘솔 모드로 동작하게 끔 한다.

    시작 -> 모든 프로그램 -> CruiseControl.NET -> CruiseControl.NET

을 클릭해서 실행한다. 

일단 서버는 레디상태. 자 이제 실제 빌드를 강제 동작시켜 본다.

 

이 때 간단하게 시도해 볼 수 있게 해주는 도구가 바로 CCTray 이다.

CCTray를 일단 설치해 놓고 무조건 실행해보자. 그러면 화면 오른쪽 아래에 CC 라는 아이콘이 보인다.

SNAG-0040.png

거기서 오른쪽 버튼을 클릭해서 열어 보면 메뉴가 나오는데 그 중 Settings에 들어간다.

SNAG-0041.png

설정 화면이 뜨면 거기서 Add 버튼을 클릭해서 들어간다.

SNAG-0042.png

 

빌드 서버가 몇개든, 프로젝트가 몇개든, 여기서 Add를 통해 계속 추가해주면 된다.

이제 설정 화면이 뜨는데, 그 안에 서버를 추가해주면 된다. Add Server 버튼을 클릭한다.

SNAG-0043.png

Add Server 버튼을 클릭하면 총 3가지 유형의 서버를 선택할 수 있다. 원격에서 CCNet 서버를 접근하는 방법을 넣는 방법들인데,

IIS를 이용하여 접속하여 CCNet에서 제공하는 Dashboard 사이트를 통해서 접근하는 방법.

.NET Remote 기법을 이용하여 직접 연결하는 방법(이 때는 포트를 21234를 사용한다.)

CCNet 이 아닌 CC for Java 같은 솔루션  접근을 위해 HTTP GET 메소드를 사용하는 특별한 페이지들을 이용하여 접근하는 방법이 있다.

대개의 경우는 2번째 방법을 통해 접근하는게 좋다. (첫번째 방법으로 해보지는 못했다.)

SNAG-0045.png

자 그럼 서버 목록에 서버가 하나 추가되었고, 그 서버에서 Build 처리가 가능한 프로젝트가 하나 뜨게 된다.

즉 CCTrary에서 제어할 프로젝트(빌드 서버내에 다양한 프로젝트를 넣을 수 있으므로)를 선택적으로 적용할 수 있게 된다.

SNAG-0046.png

자 OK 해서 일단 설정 창을 닫고 다시 CCTray 아이콘을 더블 클릭하거나 메뉴에서 Show Status Window를 클릭하도록 한다.

그러면 아래와 같은 창이 뜨면서 아까 선택한 서버의 프로젝트가 트리형식으로 나타난다.

SNAG-0047.png

자 이제 추가한 프로젝트를 선택한 후 Force Build를 클릭하도록 한다.

만일 실패하면 CC 아이콘이 빨개 지고, 성공하면 녹색으로 나오게 된다.

 

도스 창을 보게 되면 처음에 대기화면에서 무언가 화면 가득 쌓여 있다. 아이콘이 빨갛게 된 경우에는 반드시 그 오류 내용을 도스창을 통해 찾아보도록 한다.

SNAG-0048.png

 

주의!

여기서는 설정 오류 뿐만 아니라, 빌드 하다가 발생되는 오류나, 기타 등등 다양한 사유에서 발생되는 모든 형태의 오류로 인해 아이콘이 빨개진다.

반드시 정상적으로 빌드 되는 소스를 가지고 테스트를 진행하도록 한다.

그래야 설정이 정상적이라는 것을 믿고 진행할 수 있는 것이다.

하다 못해 윈도우 창만 떨렁 띄우는 프로젝트라도 미리 컴파일 해서 아무 이상이 없는지 꼭 확인해주도록 한다.

 

성공하면 아래화면 처럼, 맨 믿줄에 Integration complete: Success로 뜨고 아이콘도 녹색으로 바뀐다.

SNAG-0049.png

이 글은 스프링노트에서 작성되었습니다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

.NET Continuous Integration

기술자료/개발도구 2009. 8. 4. 17:44

애자일 방법론들을 가만히 보면 몇가지 공통 사항이 있다.

가장 특징적인 하나는 TDD(Test Driven Developing)이고 다른 하나는 CI(Continuous Inegration)이다.

전자는 일단 범위도 넓고, 중요도도 무척 높지만, 여기까지 언급하기에는 범위외이기 건너간다.

 

CI란  지속적인 통합 빌드로 주기적으로 계속 통합하여 빌드를 유지하는 것이다.

이게 중요한데, 개인이 만드는 소프트웨어에 자신의 IDE 도구들을 사용하여 필요할 때마다 빌드를 하고 테스트를 하겠지만,

팀 단위의 개별 개발을 할 때는 전혀 다른 문제다. 대부분 CI를 하지 않는 곳에서는  BingBang 빌드라고 하여,

특정시점(중간 통합 단계)에 다른 이들의 코드를 한꺼번에 싣는 작업을 수행하곤 한다. 운좋으면 짧은 시간에 완성할 수 있겠지만,

대부분은 컴파일 부터 오류가 발생되어 모두 나자빠지고 그 부분의 수정에 온 힘을 기울이게 된다.

(특히 의존성이 높은 클래스나 컴포넌트의 수정으로 인해 발생되는 오류들이 무척 많은 편이다.)

그렇다고, 매번 누군가가 최신버전을 다운 받은 후 매일 매일 빌드하는 짓도 곤혹스럽다. 바로 이런 작업을 수행하는 도구를 필요로 했다.

 

맨 처음에는 이 도구를 개발할까 생각했다.

혼자 이런 저런 기능을 파악하고, Visual Studio의 프로젝트 파일을 열어 이런 저런 조사를 하면 뭔가 나오지 않을까 했다.

하지만, 생각보다 내용도 많고, 범위도 컸다. 최소한의 기능만으로 만든다고 해도, SCRUM - 30d 기준으로 2~3 sprint(약 3달)정도의

개발 공정이 필요했다. 게다가 당장 확장을 하려면 이 또한 큰 작업이 될 공산이 컸다.

이 때 우연히 찾은 도구가 있는데, 바로 CruiseControl.NET 이였다.

 

링크 따라가기

아무 생각 없이 찾았던 도구인데, 링크에 링크를 따라가다 찾게 되었다.

맨 처음에는 SCRUM 관련 자료를 찾는 도중 애자인 인 여의도라는 블로그에서 허드슨(CS Server Hudson) 이라는 도구를 보여주었다.

이건 뭐야 하는 마음에 허드슨 관련 자료를 찾다가 이번엔 Toby's Epril 이라는 블로그를 통해  Atlassian 이라는 회사를 알게 되었다.

이건 또 뭐야 하면서 무슨 솔루션 이름인 줄 알았는데 알고 보았더니 각종 제품 및 도구를 만드는 회사였다.
게다가 이번에 읽고 있는 Scrum and XP from the Trenches에 보면 각 Sprint와 Task 정보를 Jira 라는 도구로 일부 저장 관리 한다고 했다.

그 Jira라는 도구를 만든 회사가 바로 이 Atlassian 이라는 회사였다.  이번에는 이 회사에서 만든 CI 도구가 있는데,

애석하게도 라이센스가 있었다. 가격을 지불해야 했고, 몇가지 조정적인 작업이 필요했다.

지금 있는 회사에서도 범용적으로 빌드 관리할 때 사용되는 Build Forge라는 제품을 판매하고 있다. - 즉 굳이 이런 도구 찾을 필요는 없었을 것이다. -

 

하지만, 애석하게도 그 놈의 Build Forge가 다양한 플랫폼에 다양한 형태의 Build를 제공해야 하기 때문에, 조작이 감이 딱 오지 않았다.

더 결정적인 것인 그 놈의 툴의 가격이 예술을 넘어 사치품에 가깝게 만들어 버렸다. 많아봐야 나 혼자쓰는데 이건 좀 너무 하다 싶었다.

 

결국 Atlassian에서 만든 CI나 Build Forge나 일단, 가볍게 동작하며 라이센스에 연연하지 않아도 될법한 제품을 찾아야 됬다.

어차피 개인 내지 많아봐야 1~2명만 쓸 예정이기에 굳이 다양한 기능 보다는 어느 정도 통합빌드를 지속적으로만 할 수 있으면 되겠다는 생각에 찾기 시작했다.

검색어를 Continuous Integration .NET 으로 찾아보았고,

그 결과 찾은 것이  CruiseControl.NET 이였다.

 

특징.

일단 Open Source License 정책을 가지고 있다. 그래서 배포나 구성에 있어 제약이 없었다. 그리고 .NET 기반의 프로젝트를 간단하게 빌드 할 수 있고,

설치 프로그램도 의외로 작았다. 다양한 버전 관리 도구들과 연결 되어 Build 전 최신 버전, Base Line의 Source를 알아서 가져와, 필요할 때 원하는 만큼

Build를 수행할 수 있다. 다양한 외부도구들을 지원해 가장 마음에 드는게 바로 Tray Icon으로 나오는 CCTray라는 프로그램이였다.

필요시 원격에서 강제로 Build를 할 수도 있고, 현재 맨 마지막 Build 결과도 바로 확인할 수 있다.

관리자들이 참 좋아하는 빌드 깨트린 자가 누구인지도 명확히 찾을 수 있다. ㅋ

 

다운 받는 곳.

CCNet은 SourceForge 중 CCNet 프로젝트에서 다운 받는다.

    http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET

각 버전 별로 나열되어 있는데, 특정 버전을 선택하면 아래 쪽에 관련 프로그램 별로 다운 받을 수 있는 링크들이 나온다.

CruiseControl.NET-1.X.X-Setup.exe 라고 적힌 파일이 바로 이 CCNet 서버의 내용으로 이 파일은 반드시 다운 받도록 한다.

CruiseControl.NET-CCTray-1.X.X-Setup.exe라고 적힌 파일도 다운 받는데, 이 파일이 원격에서 CCNet 서버의 정보를 확인하거나 강제 빌드 시킬 수 있도록 하는 실시간 원격 확인 도구이다.

 

일단 위의 파일들이 준비되었으면 이번에는 CCNet 설정을 쉽게 도와주는 도구인 CCNet Config라는 도구를 다운받는다.

  http://ccnetconfig.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17322#DownloadId=43769

CCNet 서버 설정은 모두 XML 형식으로 정의하게 끔 되어 있는데, 처음부터 이 XML 형식의 내용을 넣기에는 메뉴얼 보면서 넣기가 영 귀찮고 힘들다.
(어느정도 익숙해지면 쉽다고는 하는데, 그닥... 감은 안온다.) 그래서 위의 도구를 다운 받아 설치하도록 한다.

 

 

이 글은 스프링노트에서 작성되었습니다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

학교 연구실에 한번 해봤던... 바로 그...

잡글 2009. 8. 4. 12:37

eXtream Programming.
2001년도 즈음에 샀던 XP 관련 서적을 읽고 섣부른 판단으로 한번 적용해 보려는 의지 만빵시절에
썼던 짧은 글... 그 글 링크가 여기다.

결론을 말하자면 100% 실패.
아무 생각없이 짧은 직감을 믿고 달려 들어 결국 일주일만에 실패했다.
만약 그 때 회고라는 것을 해서 내 것으로 받아들이면서 진행했으면
좋았을텐데. 아니 그 전에 팀원들의 전원 동의를 얻으면서 했으면 좋았을텐데,
애석하게도 미련퉁이 처럼 그냥 적용해봤다.

지금 생각해도 얼굴 후끈거릴 만큼 어리석게 접근했던 것 같다.

천천히 다양한 글들과 경험담, 그리고 생각을 하며 하나씩 정리해보고 있다.
XP 코치나, 스크럼 마스터까지는 어렵겠지만, 최소한 XP란 이런거고 스크럼이란
이런 것이며, 한번 해보지 않겠는가? 라고 말할 수 있도록 스스로를 학습하고 있다.

스스로가 변해야 뭐든지 진행된다고 생각하며 스스로를 변화하기 위해
현재도 한걸음 한걸음 걷고 있다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

어떤 어려움이 있는지 고르는 어려움이 있군요.

잡글 2009. 8. 4. 09:51
종합 병원 갈때 고민하는 것 중에 하나가 내 병 증상에 맞는 과를 찾는 것이다.
감기가 걸려 몸살이 났을 때 어느과를 가야 할까?
대가리가 아프면 신경외과로 가야 할까?

여튼 그 문제를 이번엔 네이트가 보여줬다.
오늘 갑자가 문자 보내기가 안되길래 신고하려 했더니..


질문 유형을 저렇게 쭉 나래비를 까는 저 센스.. 누구의 머리에서 나온걸까?
문제로 인해 머리가 후끈 해진 상태에서 저 목록을 보면서 머리를 식히라는건지 후후.

정말이지 환상적인 고객을 위한 자세인 것 같다. 된장.

나만이라도 저런거 만들때 저러지 말아야 겠다.
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

소프트웨어 개발은 제품 생산라인이 아니란 말이다!

잡글 2009. 8. 3. 09:29
많은 소프트웨어 방법론들을 보면(전부는 아니지만, 대개 유명하다고 싶은 것들을 몇가지만 보면),
오랜 역사와 시행착오, 그리고 경험을 축적하여 공학적으로 정리한 방법들을 다양하게 시도하고
제공한다. 건축 메타포의 형태로 끄집어 내 정리한 부분도 있고, 각종 제품 생산 라인을 정리한 부분도 있다.

공장에서 제품을 생산하는 예를 들어보자.
생산라인 A를 통해 최종 제품 A를 만든다. 맨 처음 사람은 제품 프레임을 꺼내 몇가지 선들을 붙이고 정리해서 컨테이너 벨트 위에 얹는다. 그 다음 사람은 다시 파워 유닛을 꺼내 프레임에 얹고 나사로 고정한다. 그렇게 흘러 흘러 맨 나중의 사람이 그 제품을 마무리하고 포장을 한다.

공장 생산 만능 주의 - 작업 흐름과 분업 그리고 예측이 가능해야 생산이다! 라고 생각하는 - 에 빠지신 분들에게는 정말이지 저 생산방식이 가장 효율적이고 완벽하다고 생각한다. - 또한 많은 공장들은 저렇게 생산하며, 큰 문제없이 잘 해오고 있다. - 그런데 왜 소프트웨어는 저렇게 안돼?

공장과 소프트웨어의 개발을 가만히 매칭 시켜보면, 우리도 그 공장 메타포를 은근히 이해하고 이용하고 있다.
컨테이너 벨트가 바로 일종의 폭포수 모델의 메타포라고 생각한다면, 컨테이너 벨트 옆에 앉아 부품을 하나씩 끼우는 사람들이 아키텍처, 설계자, 개발자, 테스터의 역할을 한다고 보면 된다. 이 공장 메타포가 이해가 안될지도 모르겠지만, 가만히 생각해 보면 이런 핑계를 대고 있지는 않는지 한 번 주변을 보자. 프레임이 구축되지 않아서, 설계가 빠져서, 이전 부분을 개발하는 개발자가 덜 개발을 하고 아파서 등등.....
이게 바로 공장 형태의 개발을 중시하는 모습이지 않을까 싶다.

자, 그럼 우리의 소프트웨어도 완벽한 분업과 완벽하게 시간을 잴 수 있겠네? 라고 미리 짐작하실 분도 있고, 아니면 그래서 우리 소프트웨어가 납기 못맞추고 제대로 못만든다고 생각할 수도 있다. ( 후자의 경우는 대개 작업 초반자가 깽판? 을 부려서 그런 현상을 발생한다고 생각한다. 설계 미스, 아키텍처의 부실 등등 )

그런데 내 생각은 다르게 보고 있다.
소프트웨어의 개발은 그 컨테이너 벨트 위에서 벌어지는 것이 아니라, 바로 그 컨테이너 벨트 자체를 만드는 것이라고 생각한다. 그리고 그 컨테이너 벨트를 이용하는 쪽이 고객이라는 사실이다.
공장마다 컨테이너 벨트의 종류와 배치가 전혀 틀리다. 생산품에 따라 전혀 틀리다. 몇가지는 비슷할 지 모르겠지만, 대개 틀리다. 또 어디서는 직선의 컨테이너 벨트가 다른 공장에서는 "ㄱ"자로 휜 형태의 컨테이너 벨트일 수 있다. 어디는 속도가 시속 1KM로 진행되면, 어디는 시속 1.5KM로 컨테이너 벨트가 흐른다.

고객이 가진 조건과 형태가 매번 할때마다 판이하게 틀리다. 공통화 시킬 요소가 너무 적다는 생각이다.
(윗 말에 반박의 내용으로 "MS 윈도 같은 경우 다양한 분야에서 다양하게 쓰인다" 라고 건넬지는 모르겠지만,  그게 그렇게 간단하게 만들어졌다고 생각한다면, 당신은 프로그래밍을 모르시거나, 정말이지 낙관주의자 인듯 싶다.MS 윈도 프로젝트는 애들 장난하는 프로젝트가 아니다. 수천명의 개발자가 다양한 생각과 다양한 의견 충돌을 어떻게 어떻게 조율하고 조정해서 만들어지는 것이다. 정말이지 MS 윈도가 지금까지 끌어온 윈도 시리즈를 보고 있으면 윈도 개발팀-그룹에 대한 무한 영광을 올리고 싶다)
우리가 닥쳐서 일하고 있는 SI라는 환경은 바로 이런 곳이다. 매번 고객의 요구가 바뀐다. 또 시대의 흐름에 필요한 컨테이너 벨트가 필요한데, 그 컨테이너 벨트를 만드는데 시간이 많이 걸리고, 변화에 유연하지 못하면 요 근좌 유행하는 소량 다품종 생산과 거리가 멀다. 고객은 컨테이너 벨트에 지랄하고, 개발자는 돈 조금 줘 놓고, 제멋대로 이것 저것 만들어 달라는 고객에 지랄한다.

왜 이런 현상이 발생했을까?
나의 주관적인 생각에는 다음과 같이 요약되지 않을까 싶다.

개발자측은 개발자 측 대로 컨테이너 벨트가 있어 이 안에서 나름 순서에 맞는 제품을 만든다.
(즉 가급적 똑같은 형태의 여러개의 제품이 나오길 기대한다.)
고객은 고객 측 대로 개발자의 생산품으로 컨테이너 벨트가 구축되어 돈벌이를 위한 제품을 만든다.
(즉 자기 입맛에 맞는 환경 구성용품을 사길 원한다.)

서로간의 양보가 없다면 이건 절대 끝나지 않는 무한루프의 게임이 된다.
근래 공부한 내용 중에 한가지를 대안점으로 들자면 바로 SCRUM 이다. (럭비의 SCRUM 작전이라고 한다. 무슨 긴 문장의 약자 따위는 아니다 ) 고객이 필요로 하는 점들을 나열한 뒤, 고객이 필요로 한다고 판단된 최소한의 기능을 구현하여 시연까지 될 수 있는 아주 작은 단위(2주? 3주? 한달? 그렇게 일정 기간 단위로 나눈)로 점진적으로 개발한다는 것이다. 초기에는 혼란의 연속이고 끊임 없는 개발일지는 모르겠지만, 조금씩 조금씩 하다가 보면, 미처 서로간에 놓치고 있던 문제점이나 생각을 정리하고 볼 수 있지 않을까? 고객이 원하는게 무엇이며, 개발자 측이 보여줄 수 있는게 무엇인지를 조금이나마 더 명확히 볼 수 있을 것이라 생각이 든다.

한번 고객과 개발자 측이 이런 문제로 무한루프에 빠져 있는 상황이라면, 한번 읽어보고 조금씩 하나씩 실천해보는 것도 좋을 것같다. 나 역시 이런 실천 방법들을 고민하고 생각하며 공부하고 있는 중이다.
(추천 도서 : 스크럼과 XP)
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

무엇을 생각한걸까?

잡글 2009. 7. 31. 13:00
국내 네이키드뉴스를 진행했던 회사.
사장과 각 임원진은 잽싸게 사무실 빼고 도주하고, 그 뒤에 남은 앵커들과 실 업무자들은
내동뎅이 쳐 졌다는 뉴스였다.
(동영상 뉴스 URL : http://www.tagstory.com/video/video_post.aspx?media_id=V000347140 )

뭔 생각을 했을까?
아마 아무런 생각이 없었고, 그냥 챙긴돈만 다시 회수해간 뒤,
자신의 돈이 자신의 주머니에 챙겨졌음에 만족하고 숨어버린걸까?

이런 죄질의 사람들은 두번다시 싹이 트지 않도록 절대 감시하에 둬야 할 것 같다.
아예 뽄을 뽑아서 인생을 조지지 않는 이상, 계속 이런 피해자들을 양산 할 것이며
(대개 이런짓 저지르는 사람들이 다른 사람을 잘 현혹 시킨다. 그럴싸 하게...)
뻔뻔하게 고급 승용차 몰고 고급 술집에서 돈 펑펑 쓰며 카지노를 들락 거린다.

국외로 튀었으니 국제 범죄자 이름으로 등재시키고,
국내에는 모든 출/입 관련 해서 금지시키고 - 혹여 들어오면, 전재산 몰수 부터 시작해서
감옥에 평생 썩혀야 할 것 같다. - 3대를 뿌리 뽑아야 할 것 이다.

자신에게 별 피해가 없으니 이렇게 제멋대로 해서 큰 피해를 주는 자들은 말살이 답인듯 싶다.

또 괜히 흥분했다.
728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

  • «
  • 1
  • ···
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • ···
  • 156
  • »
250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

«   2025/06   »
일 월 화 수 목 금 토
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30

Google Apps Engine me2dayzm 좀 Buscuit e-book 것 Visual Studio SharePoint 개발환경 Azure me2photo 인터파크 Tutorial 친구 블로그 협업 지름신 java 비스킷 twi2me windows 2010 매뉴얼 오류 me2sms MOSS 2007 수 moss 불만 WSS

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015-2025 Socialdev. All Rights Reserved.

Copyright © 2015-2025 Socialdev. All Rights Reserved.

티스토리툴바