* 이 환경은 Eclipse Rich Client Platform 이라는 책에서 제공하는 방법입니다. 다양한 환경에 반드시 동일하게 구축되리라는 법은 없습니다. 단지 Plug-in 개발에 있어 가장 편한 방법이라 소개하는 것입니다. – 물론 제 기억을 위한 부분도 있죠. 한마디로 참고만 하세요~ 입니다.

0. 시작하며..

현재(2009년 12월 3일 기준)까지 안정화된 이클립스 버전은 3.5.1 입니다. 각종 책에서는 3.X 지원이라고 하나 대부분 3.0에서 3.2 기준으로 구성되어 있어, 급변(?)된 UI와 메뉴 배치 등에서 화면 그대로 따라하기가 어렵더군요. 이에 3.5.1 기준으로 다시 적어봅니다.

1. 이클립스 SDK 받기.

이클립스는 http://www.eclipse.org 에서 다운 받을 수 있습니다.
위쪽의 메뉴 항목 중에 있는 Downloads 를 선택하면 됩니다. (다운로드 링크)
이 중에 Projects 라는 탭이 있는데 일단 이 탭을 크릭하고 filter by tag에서는 all을 누릅니다.

아래에 이클립스 관련하여 다양한 프로젝트들이 나열되는데, 그 중 Eclipse Project를 클릭합니다.
여기서 중앙즈음에 각 Build에 딸린 각종 버전별 리스트들이 나오는데 그 중 Lastest Release에 해당하는 Build Name을 클릭하세요(보통 버전명이 찍힙니다.)

클릭하면 그 버전에 딸린 각종 SDK들을 다운 받을 수 있는 링크로 이동하게 됩니다.
이 중 받아야 되는 SDK는 총 3가지 입니다.

  • Eclipse SDK
  • RCP SDK
  • Delta Pack

먼저 Eclipse SDK는 각종 Plug-in을 개발할 때 사용될 라이브러리와 함께, 이클립스 개발 플랫폼을 제공합니다. 당근 필요하죠.

그리고 RCP SDK. RCP가 바로 이클립스 기반으로 응용프로그램을 만드는 것인데, 그 실행 대상이 될 마루타 같은 역할을 하게 됩니다. 이게 있어야 RCP 개발이 쉽습니다. (Plug-in 개발시에도 이 RCP Pack이 있으면 편합니다. 개발툴 내에 직접 Plug-in을 일일히 꼽지 않아도 실행 테스트에서 부터 디버그 까지 다 되니깐요)

마지막으로 Delta Pack. 이건 타 플랫폼에서도 동작하는 프로그램을 만들 때 사용합니다. 당장은 쓸데는 없지만, 일단 받아는 놓으세요.

2. Eclipse 설치.

Eclipse 솔루션의 특징은 Install이 필요 없다는 점입니다. 그냥 압축 풀어 적당한데다 넣어두면 되죠.
자 이제 Eclipse SDK와 RCP SDK를 각각 다른 폴더에 압축을 풉니다.
그러면 둘 다 eclipse라는 폴더를 가지고 있을 겁니다.

여기서는 개발 환경이 Windows라는 가정으로 시작해 봅니다. (지금 이 문서를 쓰는 환경도 Windows인데가, Linux에서는 아직도 익숙치 않아서 –_-;;)

개발을 하기 위한 적당한 드라이브를 선정하죠. 전 C: 보다는 D:에서 작업하는게 익숙해서 D:를 기준으로 설명드립니다. 다른 위치이신 분은 적당히….

먼저 D:\ 에 Eclipse SDK에서 압축을 풀어 생성한 eclipse 폴더를 복사합니다.
그리고 JAVA SDK 폴더 안쪽에 보면 jre 라는 폴더가 있는데( C:\Sun\SDK\jdk\jre  - SDK나 JRE 설치 위치에 따라 폴더 위치가 다릅니다. IBM의 Java VM 인 경우라면 또 다르겠죠?) 이 폴더를 Eclipse 폴더 안에 복사합니다. 물론 저 jre 폴더가 Path에 걸려 있으면 상관 없지만, jre 버전이 까탈 스럽다면, 그냥 Eclipse 내에 복사해 놓는게 편합니다.

마지막으로 D:\ 위치에 target 이라는 폴더를 만들고, 그 안에 RCP SDK에서 압축을 풀어놓은 eclipse 폴더 통채로 복사해 놓습니다.

최종적으로 위의 내용대로 수행을 하셨다면, 아래와 같은 형태로 구성이 될 것입니다.


3. Eclipse SDK와 RCP SDK를 연결하기.

이제 모든 밑준비는 끝. 마지막으로 SDK 간의 연결작업을 합니다.
실제 코딩 작업을 할 때 사용되는 IDE와 디버그에서 사용될 IDE가 분리되어 있기 때문에, 이 연결관계를 명확히 해주어야 이클립스에서 정상적으로 동작하게 됩니다.

먼저 이클립스를 실행합니다. Eclipse SDK를 통해 압축을 푼 eclipse를 실행하시면 됩니다. (RCP SDK에서 받은 eclipse는 독자적으로 실행되지 않습니다.)

맨처음 뜨면 Workspace를 설정하게 되어 있는데, 이 곳이 소스코드와 빌드된 결과 값을 담게될 중요한 위치입니다. (이클립스의 워크스페이스의 개념은 다른 이클립스 관련 서적이나 문서를 통해 파악해주시기 바랍니다.) 이 위치를 잡아주시면, 이클립스의 첫 화면을 보실 수 있습니다.

자 이제는 위의 메뉴에서 보시면 Window 라는 항목이 있는데 그 Window를 클릭하시고, Preference 에 들어가 주시기 바랍니다 (Window > Preference)
그러면 아래와 같은 화면이 뜹니다.

이 설정 창이 뜨면 왼쪽 트리 메뉴를 타고 진행하시면 됩니다. Plug-in Development > Target Platform을 선택합니다. 그러면 Target Platform을 설정하는 화면이 뜨는데, 그 중 Running Platform(Active)를 선택한 뒤, Edit 버튼을 클릭하세요.

맨 처음 Location Tab이 떠 있는데, 그 아래에 위치된 항목을 클릭한 뒤, Edit 버튼을 클릭하세요.
아마 기본 값이 ${eclipse_home} 라고 되어 있는데, 이 부분을 target\eclipse로 변경해주세요. 간단하게 browse 버튼을 클릭하시면 경로를 찾으실 수 있습니다

저 같은 경우에는 RCP SDK 가 D:\target\eclipse 이므로 이 위치로 잡아준 것이죠. Finish를 클릭하여 새로 열린 창을 모두 닫고, 최종적으로 Prefernce 창에서 아래쪽에 있는 Apply 버튼을 눌러 주시고, OK 해주시면 됩니다.

4. 정리

까먹을까봐 적은 글입니다. 뭐 별로 어려운 부분은 없습니다. 지금 이클립스 RCP를 통해 Plug-in 개발에 대한 개념을 잡으려고 합니다. 생각보다 쉬운 일은 아니네요 ㅋ

새로운 내용이나 정리될 사항이 나오면 계속 포스팅을 해야 겠군요

728x90

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

설치 및 구성하기.

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

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

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

가장 특징적인 하나는 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/07/13 오전 9:30 ~ 오후 5:30
  • 교육자 : 강승억 차장
  • 장소 : 동부 CNI 지하 1층 수성관
  • 교육 내용.

    • Build Forge(이하 BF)의 기본적인 정리.
    • Project 생성 방법.
    • Project Step 구성.

      • Build 시에 동작하는 순서를 정의
      • 예전 7.0에 비해 비교(If) 반복(Loop) 기능 추가.

        • 7.1 부터 사용가능.
        • If : 조건에 따라 Ture일때, False(Else)일때 명령어 창을 구분하여 처리. (.runwait 사용하여 처리가능). 환경 변수를 잘 활용.
        • loop : 조건이 False가 될때 까지 계속 실행됨.
      • Command 방식의 명령어를 안에 넣어서 동작.

        • Unix에서는 특정 Shell, Windows에서는 Dos 창 명령어들이 사용가능.
        • Batch 파일을 호출하는 방식으로 적용가능.
        • dot Command 라고 해서 BF 자체적으로 제공하는 명령어들이 있음.
        • dot Command는 대략 30개 정도 존재. ( Console의 Help 참고)
        • .bset, .run .runwait 등이 자주 쓰임.
      • 실행 결과관련.

        • 단계 실행 결과가 Pass 혹은 Fail 표시. 결과 값이 0이면 Pass.
        • exit 상태에 따라 적용되는 형태를 변화. 필터 적용도 가능. Filter는 정규표현식으로 적용,
    • Library

      • Project의 실행 안되는 형태.
      • Selector 설정이 되면 Project, 안되면 Library
      • 각종 Step 정의 내용 중 Build에 직접적으로 참여하지 않는 경우, Step만 저장하는 경우 사용.
    • 환경 변수 적용 범위

      • Scope는 총 3가지로 Server > Project > Step.
      • 같은 범위 - 예를 들면 Step 1, Step 2 등등 -에서는 환경변수 영향을 받지 않음.
      • 상위 범위는 하위 범위에 영향을 받음.
      • 단, 하위 범위의 특정 변수의 이름이 상위 범위와 겹치면 하위 범위의 값으로 대체.
      • 환경 변수 Array 스타일은 Unix의 경우 ":" Windows의 경우 ";" 임.
      • Chain은 Step과 Scope가 동일하지만, Chain의 부모 Step의 환경변수를 그대로 받음.
      • 만일 프로젝트 내 변경이 심할 경우(Unix -> Windows -> HP 등등 ) 환경 변수를 모두 set 처리하여
        값이 Reset 될 수 있도록 해야 함.
      • Chain 자체도 별도 환경변수를 가질 수 있다.
      • 환경 변수 설정 방법

        • .bset 인 경우 값을 설정.
        • .append 인 경우 현재 있는 값에서 뒤쪽에 붙임.
        • .prepend 인 경우 현재 있느 값에서 앞쪼겡 붙임.
    • Server

      • Logical Server와 Physical Server는 분명 다름.
      • BF에서의 Server는 Logical Server로 Physical 설정과 다름.
      • Abstract 특성으로 Physical 서버의 설정이 바뀌거나 추가/삭제 되더라도 Build의 큰변경없이 적용가능. ( 물리적인 서버에 대한 의존성이 낮게 구성될 수 있음 )
      • 서버 별로 인증정보를 만드는 것이 추후 편함.
      • .get , .put 명령을 사용하여 Agent <--> Server 간에 파일 전송 가능( 만일 FTP 같은 포트가 막힌 경우 사용. 단, 속도가 그다지 빠른편은 아니고, 파일에 대한 안정성도 떨어짐 )
    • Collector

      • 서버의 물리적 상태 조사.
      • CPU, RAM, HDD 뿐만 아니라, 네트워크 정보, 운영체제 타입, 컴파일러, 링커, 그 밖에 추가적으로 정의된 정보들을 수집.
      • 여기서 수집된 정보는 manifest 라는형태로 남겨짐.

        • 서버의 상세 정보가 담김.
        • 일종의 환경 변수 처럼 각종 조건을 설정할 때 귀중한 조건 데이터가 됨.
        • 이 정보는 Selector에서 활용.
      • 7.0 까지는 Server 상에 환경 변수로 추가적인 환경변수 처리를 했으나, 7.1 부터 collector 자체적으로 환경변수를 설정할 수 있음.
      • 운영체제에 의존적. 운영체제나 설정에 따라 N개의 collector 존재.
      • 필요시 Collector에서 추가적으로 수집해야 될 값을 정의할 수 있음.

        • 수집할 때, Command Line을 이용하여 값을 가져온 후 정규표현식으로 다듬는다.
      • BF_ 이나, _로 시작하는 값들은 설정없이도 가져옴.
      • 7.1 부터 .include라는 명령을 통해 다른 Collector 정보를 가져올 수 있음.

        • 같은 이름의 값이 있는 경우, append 면 array 스타일로 set 이면 덮어쓰게 됨.
    • Selector

      • Collector에서 설정된 값 또는 환경 변수의 값들의 조건에 따라 Project가 동작할지 말지를 선택.
      • Selector 설정되면 Project. 안되면 Library가 됨.
    • Chain

      • Step에 대한 특정 분기나 하위 작업을 구성할 때 사용.
      • Step의 조건에 따라 독자적으로 실행되거나 Sub rootain 처럼 동작될 수 있게 함.
      • .run을 쓰면 비동기(Chain의 동작의 결과와는 상관 없이)로 동작하고, .runwait을 쓰면 동기(Chain의 동작이 실패하면 실패, 성공하며 계속 진행)
      • Step의 분기 작업에 보통 이용.
      • Console의 Property를 사용하면 목록에 각 Chain 적용 정보가 표시되나, 만일 Step내의 Command로 처리할 시에는 Chain 적용정보가 전혀 표시되지 않음.
      • Loop 처리는 바로 이 Chain의 기능을 이용하여 조건이 False가 될때까지 계속 동작하게 된다.
    • Thread

      • Thread는 Step의 속성 중 하나로 No, Yes, Join 세가지.
      • Yes 부터 Join까지의 각 Step이 한 그룹

        • 예를 들면 아래의 경우 Step 1~3이 그룹 A, Step 4가 그룹 B가 됨.
          Step 1 ( Thread : Yes )
          Step 2 ( Thread : Yes )
          Step 3 ( Thread : Join )
          Step 4 ( Thread : Yes )
        • 그룹 A가 모두 실행이 완료되어야 그룹 B가 실행됨.
        • 만일 Max Job이 만들어지는 Thread 숫자보다 작으면 Thread의 숫자도 제한을 받는다.
          예) Max Job이 1인 경우 Step ! -> Step 2 -> Step 3 로 실행된다.
      • 응용 : Thread를 Build 서버별로 만들면 동시에 여러 빌드 서버가 동작할 수 있음.
        Server1 - Selector [ Inline ] - Step 1
        Server1 - Selector [ Inline ] - Step 2
        Server1 - Selector [ Inline ] - Step 3
        Server2 - Selector [ Inline ] - Step 1
        Server2 - Selector [ Inline ] - Step 2
        Server2 - Selector [ Inline ] - Step 3
        Server3 - Selector [ Inline ] - Step 1
        Server3 - Selector [ Inline ] - Step 2
        위와 같을 때 Inline 자체에 Thread로 걸면 Server 별로 Thread 동작.
        만일 Thread 설정이 없다면 Step 순서대로 동작(물리적으로 서버가 분리되어 있어도 마찬가지)
    • Apdator

      • 명령 실행 방법, 결과 값을 표시해줄 수 있도록 만드는 I/F의 일종.
      • XML(정확히는 XAML 형태)형태로 정의
      • 설정 되는 순간 모든 Step의 0순위로 실행됨.
        ( 만일 Adaptor의 동작 결과 아무런 결과 값이 없는 경우 더 이상 실행되지 않음 - 로그 조차 안남음 : 예. 소스 변경 여부에 따라 빌드 할 지 말지를 결정할 때. )
      • Adpator의 Link를 통해 설정가능.
        필요시에는 Command Line에서 직접 실행가능.
        .source {어뎁터이름} {파라미터} : 소스 버전 관리
        .defect ㅖ어뎁터이름} {파라미터} : CQ계
        .Test {어뎁터이름} {파라미터}  : 테스트용
      • XML Format Schema

        • Interface 이름 및 기본 설정 정의 <interface/>
        • 실행 명령어 정의 <execute/>
        • 결과값 뽑아내기 : 정규식 활용 <resultblock/>
        • BOM(Bill Of Material)로 결과 전달 내용 <bomformat />

 

2회차 교육

  • 2009/07/14 오전 9:30 ~ 오후 4:30
  • 교육자 : 강승억 차장
  • 장소 : 동부 CNI 지하 1층 수성관
  • 교육 내용

    • Build 유형.

      • 통합 빌드 : 일반적인 형태. 버전을 통합하여 처리.
      • Continus Build : 변경 사항에 따른 일부 빌드 처리. - 근래 대세를 이루는 형태.
    • Job

      • 동작될 Project 혹은 Library의 활동 내역.
      • Job의 Start에서 혹은 Project의 Run Command를 통해 실행.
      • Job 목록에서 Filter 처리가능. 만일 Fail 시에 (Fail 갯수/Warning 갯수)로 전체 갯수 표시.
      • Job -> Start 에서 표시되는 항목 중 Selector 조건에 합당한 Job에 한하여 Start 가능한 항목 표시
      • 특정 Job만을 독자적으로 실행할 수 있음

        • 원칙적으로 Library는 독자 실행이 불가능하나(Selector 때문) Job에서 전제조건을 넣어 독자 실행가능.
        • ntegration 단계도 설정 가능.
        • 주의 : 7.1에서 설정 내용 중 "PATH" 항목이 중복되어 표시되는데, 그 중 맨 아래쪽의 Path 내용으로 Set 되어 처리됨.
      • Job의 Step 목록에서 특정 Step에 대해 처리 중지 및 일시 정지 처리 가능.
      • Job의 실행 순서.

        • 서버 DB 데이터 조건별 Select 처리.
        • Waiting 처리 ( Server Selector의 할당 처리 / 세마포 설정에 따른 대기 )
        • Job Queuing
        • Job Excution.
      • Job의 All 탭에 있는 항목은 수정/제어 불가능 -> Complete 항목에서 적용가능 ( Lock / Purge )
      • 완료된 Job을 클릭해서 들어가면 상세 정보를 볼 수 있음 ( 왼쪽 아래 Pane에 표시)

        • Bill of Materials
    • Schedule

      • 자동으로 특정 Project를 실행할 때 사용.
      • cron 매커니즘을 이용하여 처리 ( * 이면 매번, / 붙이면 특정 일자별 )

        • 값이 * 이면 매번 수행( day = * 이면 매일, month = * 이면 매월)
        • /? 형태로 값이 매겨지면 ? 주기로 실행 ( day = */2 이면 2일 마다 실행)
        • days는 요일 0이면 일요일 1이면 월요일 ~ 6이면 토요일.
      • UI 상에 달력에 있는 박스 내 숫자는 실행될 Project의 실행 횟수를 의미
    • Plug-in

      • Build Forge Frequency

        • Build Forge 관련 정보 접근 혹은 업데이트 처리.
        • Eclips 뿐만 아니라 VS시리즈도 지원
      • Build Forge Reflector

        • "pre-flight" 방식으로 특정 버전의 소스에서 자신의 Test 코드를 임시적으로 추가 Build 적용 가능.
        • Eclips만 지원.
        • User License가 개발자 만큼 필요할 수 있음.
    • 보안.

      • Role 기반 보안 -> 그룹을 기반으로 구성. 사용자 별 권한 설정을 할 수 없음.
      • 그룹은 하위 그룹을 가질 수 있음
      • 직책(또는 부서)별 Role 별 권한 설정을 해야 추후 구분 구성이 쉬움.
        개발1팀 그룹, Build Engineer 그룹 식으로 별개의 그룹으로 구성하여 묶어 처리.
      • LDAP(및 AD)를 통해 사용자 계정을 가져 올 수 있음

        • 단, LDAP의 정보는 반드시 1회 이상 Login을 해야 정보를 가져옴.
        • 가져 온 뒤, 해당하는 Group에 맞게 설정해야 함.
    • API

      • 7.0 버전 이하는 Perl 만 지원. 더욱이 API가 직접적 접근을 위한 함수 나열식.
      • 7.1 버전 이상에서는 Abstract 형태의 각 기능별 Class 구성.

        • Java, Perl 지원.
      • 라이센스 형태에 따라 지원 여부가 다름
    • Report 기능

      • 독자적인 License가 추가적으로 필요.
      • 주요 리포트

        • 전체 리포트 가짓수는 8가지 정도 있음
        • Capacity : 현재 물리적 서버들의 가용성을 체크하는 Report. 사용량이나, 소모 자원 정보들을 나열.
        • Quality : 프로젝트의 Pass/Fail 의 정도 및 결과 내역을 나열.
    • 제품 Scue 및 라이센스

      • 제품 Scue.
      • Express Edition : 최초 Start Pack 형태로 나온 초소형 버전. 7.0.2 버전 이후로는 사라짐.
      • Standard Edition : 기본 형태로 최대 25명 접속 가능. 비공식적으로 Dynamic Server Management 가능.
      • Enterprise Edition : 150명 접속 가능. Dynamic Server Management 가능
      • Enterprise Plus Pack : 250명 접속가능 및 User License도 포함.
      • 라이센스

        • 제품 Server 및 Console 라이센스 - 접속 가용성에 대한 라이센스.
        • 사용자 라이센스 - 접속 사용자 라이센스. (동시 접속 기준)
  • 기타 발전 내용

    • Adaptor 적용.

      • 형상 관리 등의 BF 내 확장 기능을 붙일 수 있는 I/F .
      • 특정 Schema를 근간으로 한 XML 형식의 데이터.
      • XML 데이터를 생성해주는 도구가 있으면 좋을 듯 싶음.
      • 문제점 : 제품 Scue에 따라 이 Adaptor 기능에 대한 라이센스르 별도로 사야될 수 있음.
    • Express 버전 단종.

      • 더 이상의 지원은 없을 예정. 7.0.2.가 마지막 형태.
    • 운영체제 제약.

      • 2003( XP도 포함 예정 )에 대한 지원도 없앨 예정이라고 함.

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

728x90
전에 간신히 방법을 찾았다가, 스키마 DB를 초기화 하는 바람에, 해당 VB 스크립트를 분실했었다.
어제 간신히 ActiveX 만들어서 실험하려고 했는데, 안되서 짜증나 퇴근했었다.
겨우 겨우 찾았다.
(아래 링크는 PDF 파일 링크임)


위의 링크 내용은 레쇼날 엔지니어와 핑퐁 메일을 주고 받은 내용 같다.
요는 이렇다.

Form에 추가한 ActiveX의 속성에 들어가 InitScript를 만들어 연결하면,
param 이라는 파라미터를 받게된다.

param안에 object를 들고오면 되는데 방법은 간단하다.

Dim ctrlTest

Set ctrlTest = param.objectItem
이 간단한걸...

왜 CQ API 목록에는 없는거야?

728x90

SQL 2005 에 있는 SQL Server Management Studio(이하 SSMS)라는 프로그램으로 DB관리를 하면 이런저런 다양한 작업을 할 수 있다.  예전에 분리되어 있던 DB관리도구와 Query 분석기가 하나로 합쳐진데다, Visual Studio 와 유사한 I/F 덕에 많은 이득이 보고 있다.

그런데, 무수히 많이 생기는 Query들의 관리가 어려울때가 있다.
특히 DB관련해서 작업을 할때, 팀 별로 관리하거나, 별도 Query를 저장하려고 하면, 그 불편함은 가중된다.

예를 들자면, DB 내 저장 프로시저가 생겼을 때, 개발 서버에서 생긴 저장 프로시저를 다시 운영서버로 옮길려고 하면, 쿼리를 다시 생성해 올려야 한다. 그리고 해당 생성/변경 쿼리는 또 다시 저장하지 않고 날렸다가, 맨 나중에 산출물 만들려고 하다가 보면, 처음 부터 끝까지 쿼리 내용을 끄집어 내곤 한다.
또, 몇가지 관리 차원에서 특정 데이터가 존재하는지 여부를 하기위한 테스트 쿼리를 짜놓고는 까먹다가, 다시 쓸려고 하면, 사라져 없어져 이후에 더 이상 작업이 불가능하거나 다시 쿼리를 작성하는 경우도 발생한다.

그래서 고민해본 결과 버전 관리도구가 이 SSMS 와 연결되면 될 것 같다는 생각이 들었고, 어느정도는 맞아 들었다. 이에 연결 방법을 소개하도록 한다.

(참고 사이트 : http://www.kevingao.net/sourcesafe/integrating-sourcesafe-vss-with-sql-server-2005.html )

1. 구성 방법

  1. Visual Source Safe 혹은 Team Explorer 설치하기.   
    일단 Visual Source Safe는 2005 이상 버전이면 큰 문제 없이 연결된다. Visual Source Safe 2005를 설치방법은 그냥 Next 연발이기 때문에, 그리 어렵지 않다.
    그에 반해 Team Explorer는 조금 다르다. Team Explorer를 받아서 설치해도 SSMS에는 적용되지 않는다. 이에 MS 다운로드 사이트에서 별도로 더 받아와야 한다. 다운로드를 위한 해당 링크는 아래와 같다.
    http://www.microsoft.com/downloads/en/results.aspx?freetext=MSSCCI&displaylang=en&stype=s_basic
    ( 만일 위의 링크가 깨졌다면 MSSCCI 라는 검색어로 http://download.microsoft.com 에서 검색하면 나온다. ) Team Explorer 2008가 설치되어 있다면 Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider를 2005가 설치되있다면, Visual Studio Team Foundation Server MSSCCI Provider를 다운 받아 설치하도록 한다.

    일단 설치가 정상적으로 되었으면 다음 단계로 넘어가도록 한다.

  2. 버전 컨트롤러 선택.
    이제 Visual Source Safe 2005를 설치하던 MSSSCCI를 설치하던 버전 관리도 도구와 연결할 수 있는 클라이언트가 설치되었다면 모든 준비는 된 것이다. 이제 SSMS를 실행하도록 한다. 일단 해당 DBMS와 연결하도록 한다.

    일단 정상적으로 DBMS와의 연결이 되었다면 이제 메뉴에 있는 도구(T) –> 옵션(O)에 들어가도록 한다.
     
    옵션 창이 떴으면 왼편에 있는 트리 중에, 소스 제어를 선택한 뒤, 오른편에 있는 선택 상자에서 자신이 설치한 소스제어 도구를 연결하도록 한다.
    일단 확인을 클릭하면, 설정한 버전 관리도구에 따라 로그인 창이나 설정 창이 다르게 뜰 것이다. 해당하는 도구에 맞게 정보를 넣어주면 된다.  (로그인 및 설정 방법등은 각 버전관리 도구의 도움말을 참고하면 된다.)
  3. 솔루션 적용
    연결이 성공적으로 되었으면 이번엔 솔루션 탑색기를 열도록 한다. 여는 방법은 메뉴에서 보기(V) –> 솔루션 탐색기(P) 를 선택하면 우측에 솔루션 탐색기를 볼 수 있을 것이다. 버전 관리를 하기 위한 소스는 Query 같은 내용인데, 이를 묶는 역할을 하는 부분으로 반드시 있어야 한다.
     

    이제 파일(F) –> 새로 만들기를 선택한 뒤, 프로젝트를 선택한다.

    그러면 프로젝트 종류를 선택하도록 요청 받는데, 그 중 SQL Server 스크립트를 선택하도록 한다.
    또한 아래 쪽의 내용을 보고, 솔루션 이름이나, 솔루션이 저장될 위치들을 적절하게 설정하도록 한다.

    솔루션이 만들어지면 오른편(혹은 왼편)에 솔루션 탐색기 영역에 새로 만들어진 솔루션이 뜰 것이다. 이제 솔루션위치에서 소스제어에 솔루션 추가를 선택하여 해당 소스제어 서버에 소스를 등록하도록 한다. (필요에 따라서는 솔루련이 아닌 프로젝트만 추가할 수도 있다)


2. Hind 만의 SQL 버젼관리 방법

이 SSMS에서의 버전관리는 애석하게도 DB에 대한 스키마를 관리하지는 않는다. 단지 각종 Query나 연결정정보에 대해서만 관리하게 된다. 간단해서 좋기는 하지만, 역시 세밀한 작업을 수행하기에는 문제가 있다. 혹시나 DB를 직접 버전관리를 하지 않을까 상상하신 분들은 이 버전관리 방법과는 맞지 않다. !!! 주의해주셔야 할 부분이다. 여튼 쿼리만이라도 버전 관리를 하겠다면 계속 진행하면 좋을 것 같다.

일단, 괸리를 할 때 나름대로 사용해 본 결과 제한 요건들이 많이 보인다. ( 2008용에서는 개선되지 않았을 까 조심스럽게 짐작해 본다. ) 그래서 그 제한 요건을 고려하면서 생각해본 결과 아래와 같은 방법을 정리할 수 있었따.

  1. 쿼리 동작 형태에 따라 프로젝트를 만들어 구성한다.
    쿼리를 만들다보면 보통 CRUD, 즉 Create Read Update Delete 와 같은 Action 별로 쿼리가 생긴다. 그런데 Visual Stdio와는 다르게 프로젝트 내에 새로운 Folder 추가가 되지 않느다. 무조건, 연결, 쿼리, 기타 이렇게 3가지의 폴더 안에 모든 파일을 때려 박게 될 것이다. 간단한 DB 업무야 그냥 그냥 쭉 넣는다고 하지만, 규모가 있다보면 Create 쿼리만으로 트리를 가득 매꾸게 된다.  이런 경우를 대비해 각 동작별로, 혹은 별도의 분류 규칙에 따라 새로운 프로젝트를 생성하도록 한다.
    즉 생성용 프로젝트, 업데이트용 프로젝트, 테스트 쿼리용 프로젝트 등등을 만들어 구성하는 것이다. 최소한 이처럼 구성하면 작업하는데 훨씬 수월 할 것이다.
  2. 네이밍 룰을 맞추어 구성한다.
    분류별로 프로젝트로 구성한다고 해도, 결국 많은 수의 쿼리들이 한줄로 나래비를 펼칠 것이다. 최소한 이런 형태가 계속 지속될 수밖에 없기 때문에, 분류하게 좋은 형태의 묹열 나열이 필요로 한다.
    가급적 Action 별로 네이밍을 구성하여 나중에 해당 쿼리를 찾아보기 쉽게 구성하는 것이 좋다.
  3. ALTER 문장이 정상적으로 동작하는지 미리 테스트를 한다.
    사실 여러 팀작업을 하게 되면 결국 테이블 구조나 DB 구조를 변경하게 된다. 이 때 사용되는 명령이 ALTER인데, 이 ALTER는 다양한 상황에 따라 동작 여부가 갈린다. 그런 경우 이전에 어떤 DB가 들어 있는지에 따라 ALTER의 형태가 바뀔 수 밖에 없을 것이다. 만일 ALTER가 전혀 안될 것 같은 경우 이전 버전의 DB에서 비정상적으로 동작할 수 있다. 반드시 체크한 뒤 배포하도록 한다.

이상이 현재 DB 에서 사용하는 버전 관리인 것 같다. 물론 제한적이며 기능적으로 한계가 많고, DB를 직접하는 것이 아닌 거의 쿼리만을 처리하는 것이기 때문에, 원하지 않을  수 았을 것이다  하지만, 최소한 버전관리도구를 써서 협업을 하고 있다면 도전 해보는 것이 어떨 까 싶다.

728x90

이에 대한 문서는 방대하니 많고, 많은 커뮤니티에서는 오르락 내리락 하던 문건이기 때문에 다시 언급하기는 그렇지만, 일단, 까먹기 전에 기록해두는게 좋을 것 같아 언급한다.

IBM의 참고 사이트는 아래의 링크를 참고한다.
http://www.ibm.com/developerworks/wikis/display/rationalcccq/Creating+logins+for+SQL+Server+2005 

1. SQL 2005 내에 DB 생성.

맨 처음 SQL 2005용 DB를 생성하려면, Microsoft SQL Server Management Studio를 띄우도록 한다. 그리고 난 뒤, 왼편에 “개체 탐색기”에 있는 트리에서 “데이터베이스”를 선택한 뒤, 오른쪽 버튼 클릭(컨텍스트 메뉴 띄우기)하면 메뉴가 뜨는데, 그 중 “새 데이터베이스(N)”을 클릭한다.

2. 새 DB 옵션 설정.

“새 데이터베이스(N)”을 클릭하면 새로 생성될 DB에 대한 각종 옵션을 넣게 된다.  총 3가지 분류가 있는데, 각 부분을 나누어 설명한다.

  1. 일반 옵션
    일단 “데이터베이스 이름”에 데이터베이스 이름을 넣는다. 여기서는 Test를 위한 Schema로 cqschemaTest로 만들었다. 그리고 DB에 대한 성능 보장이 필요하다면 “데이터베이스 파일(F)” 항목에서 처음 크기와 증분 크기를 결정해서 적용해주는 것이 좋다.
    나머지 옵션들은 기본 값으로 구성하면 된다.
  2. 옵션
    특별히 설정하는 것은 없지만, 그래도 신경을 써주는 것이 좋다.
    ”데이터 정렬”에서는 “Korean_90_CS_AI_KS_WS” 를 선택해 준다. 원래 다른 곳에서는 이 부분의 값을 기본값으로 하라고 했는데, 왠지 잘 안된 느낌이다. _CS_ 부분이 바로 Case Sensitive 라고 해서 대소문자 구분을 확실하게 해주는 옵션이다. 일단 이래야 CQ에서 949가 제대로 뜨는 것 같다.
    “복구모델”은 안정성에 따라 구성하는것이 좋다. 안전하게 다룰라면 역시 “전체”를 선택하고, 단순히 복구 로그의 중요도가 무척 낮은 단순 테스트용도라면  “단순”으로 선택해주면 된다.
    그리고 “호환성 수준”을 “SQL Server 2000(80)”으로 해준다. 이게 반드시 필요한지는 모르겠지만, 그대로 불안한 마음에 설정했는데, 나쁜것 같지는 않다. – 아직 SQL 2005의 자세한 기능은 모르지만, 보안상의 이유로 틀어 막은 부분을 풀지 않을까라는 생각이다. -  나머지 항목은, 알면 상관 없지만, 잘 모른다면 안 건드리는 것이 좋을 것 같다.
  3. 2.3 파일 그룹.
    DB파일을 다중으로 구성할 때 사용되는 옵션인데, 여기서는 그 부분에 대한 고려 사항은 없으므로 생략한다.

3. 사용자 생성.

이제 CQ에서 접속할 때 사용될 계정을 생성한다. 이미 만들어진 sa를 쓰면 되지 않나… 라고 생각하시는 분도 있지만, 그런 행동은 보안 상으로 최악의 시나리오를 만드는 것이고 CQ 관련 Installation 가이드에서도 절대 하지 말라는 이야기 뿐이다. 가급적 별도 계정을 만들어 구성한다.
또한 이 구성을 하려면, “서버 인증” 이 “Window 인증 모드”이면 안된다 반드시 “혼합모드(SQL Server 및 Windows 인증 모드)”이여야 한다. 인증 변경에 대한 자세한 설명은 아래의 링크를 참고하세요.
http://godori12.tistory.com/tag/MS%20SQL2005....

  1. 계정 생성.
    DB 생성만큼 쉽다. 먼저 Microsoft SQL Server Management Studio를 실행한다. 그리고 좌측의 “개체 탐색기”를 따라 들어가 “보안 –> 로그인” 폴더 위에서 오른쪽 버튼을 클릭해서 나오는 컨텍스트 메뉴 내용 중 “새 로그인(N)..” 을 선택한다.
  2. 신규 - 일반
    “새 로그인(N)…”을 클릭하면 “로그인 – 신규” 창이 뜨는데, 맨 처음 나오는 항목이 “일반” 항목이다.
    먼저 로그인 이름에는 사용할 ID 이름을 넣는다. 여기서는 cqroot라고 했다.
    인증 유형 두가지를 선택하게 끔 되어있는데, 그 중 “SQL Server 인증(S)”을 선택한다. 그리고 해당 ID에서 사용할 새로운 암호를 넣는다.
    반드시 “암호 정책 강제 적용(F)”는 반드시 끄도록 한다. 나머지는 기본값으로 두고 다음 항목으로 넘어간다.
    0 
  3. 신규 – 서버 역할.
    여기는 절대 아무것도 체크하면 안된다, CQ에서 접속할 때 DB 접근 관련 권한에 오류가 발생할 수 있기 때문이다. 그대로 모든 체크를 비우도록 한다. 혹여 체크되어 있다면 반드시 체크를 끄도록 한다.
  4. 신규 – 사용자 매핑.
    여기가 제일 중요한 부분이다.
    사용할 DB 앞에 반드시 “매핑” 열에 매핑해준 뒤,  “사용자”와 “기본 스키마”안에 새로 만들 계정의 ID를 똑같이 넣도록 한다.  이 부분은 반드시 지켜줘야 하는데 안그러면 CQ에서 빈 스키마 생성시 오류가 발생한다. 주의하고 넣도록 한다. 
    그리고 해당 DB 항목을 체크하면 아래 쪽에 “데이터베이스 역할 멤버 자격(R)” 내용 중 db_owner 도 체크해 준다.
     
  5. 신규 – 보안 개체 및 상태.
    별 다른 설정 내용은 없다 기본값 그대로 해서 두면 된다.

4. CQ 스키마 생성.
이제는 CQ 스키마를 생성한다. 여기서 부터는 예전에 해왔던 CQ 생성방법과 동일하다.

  1. ClearQuest Maintenance Tool을 실행한다.
  2. 아이콘 중 Create 아이콘을 클릭한다.
  3. 우측에 있는 “Vender:”에서 “SQL_SERVER”를 선택한다.
    선택하면 아래의 텍스트 박스가 몇개 더 붙는다.
  4. “Physical Database Name:” 에는 아까 만든 데이터베이스 이름을 넣는다. 여기서는 cqschemaTest 이므로 cqschemaTest 라고 넣어주면 된다.
  5. “Database server name:" 에는 현재 DB서버가 동작하고 있는 서버의 서버 이름을 넣느다.
  6. “Administrator name”에는 앞서 만든 계정을 넣는다. 여기서는 "cqroot” 이다.
  7. “Administrator Password”에는 해당 계정의 암호를 넣는다.
  8. 나머지는 그대로 두고 “다음(N)>”을 클릭한다.
  9. ClearQuest Data Code Page에서 949(Korean Unified Hangeul Code ))를 선택한다.
  10. Create sample database의 체크를 끈다. (나중에 필요할 때 즈음에 만들어도 되므로 당장 만들필요는 없다. ) 그리고 “마침”을 클릭하면 된다.
  11. 정상적으로 완료 되면 아래쪽 버튼 중 “Done”이 생기는데 클릭하면 된다.

여기까지 무사히 도착했다면 작업이 완료된 것이다.

하지만, 사용자 환경은 무척이나 다양하기 때문에, 다양한 상황에 따른 다양한 에러가 발생할 수 있다.
가급적이면 Google 같은 곳에서 해당 문제점을 검색해 보면 어느정도 해결은 가능한다. 일단 필자가 지금까지 겪었던 오류들이 이것 저것 많았지만, 추수려 보면 크게 3가지 정도 발생한 것 같다. 각 에러와 그 대처 방법은 아래와 같다.

  1. 1. Database에 로그인을 할 수 없습니다.
    이 경우에는 대부분이 DB 서버가 죽었거나, 오류가 발생했을 때, 혹은 도메인\사용자 ID 스타일의 계정 – Windows 인증 계정을 사용할 때 발생된다. 앞에서 설명에서 언급했듯이 Windows 계정으로 하지 말고 반드시 Server 인증 방식으로 변경해서 처리해 줘야 한다.
  2. “select from master…” 뭐시기 하는 오류가 보일 때.
    대부분은 앞에 사용자 계정 설정 할 때 “사용자 매핑” 처리가 잘못된 경우이다. 반드시 “사용자”와 “기본 스키마” 항목에 사용자 ID 넣어 준다.
  3. 949 언어를 지원하지 않는다.
    앞서 설정한 내용 중 데이터베이스 생성할 때, “Korean_90_CS_AI_KS_WS” 를 선택해주라고 했는데, 일단 이걸로 선택하면 큰 문제없이 동작한다. 혹시 언어 코드가 잘못되거나 이상하게 동작한다면 반드시 체크 해보록 한다.

각 옵션은 만들고 난 뒤 “속성”에 들어가 수정할 수 있으므로 찬찬히 확인하도록 한다.

728x90

+ Recent posts

728x90