DB2 Change Management Expert, Part 2: DB2 Change Management Expert로 데이터베이스 버전 제어하기 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 샘플 코드 영어원문  제안 및 의견 피드백

난이도 : 중급

Carolyn Henry, 정보 개발자, IBM
Marcia Miskimen, 소프트웨어 엔지니어, IBM
Jayashree Ramachandran, 개발자, IBM
Sailaja Bandlamoori, 테스팅 담당자, IBM

2008 년 3 월 25 일

데이터베이스가 언제, 어떻게 변경됐는지 궁금해 본 적이 있나요? IBM® DB2® Change Management Expert가 있다면 더 이상 궁금해 할 필요가 없습니다. 이 도구는 변경을 추적함으로써, 다른 팀 구성원들과 협업하는 과정에서 데이터베이스에 변경 및 수정 사항이 발생하는 것을 감사(audit)하는 데 도움을 줍니다. 이 글은 DBA 조직이 이클립스 팀과 DB2 Change Management Expert를 사용하여 협업을 강화하고 일정한 감사 경로를 확보하는 방법을 설명합니다. 이 글을 통해 라이브러리 제어 시스템에 연결하고 라이브러리 제어에서 변경 관리 프로젝트, 모델, 스크립트를 저장하며 변경을 감사하는 방법을 다룹니다. 또한 라이브러리 제어에서 찾아오는 방법과 변경을 취소할 때 배치 스크립트를 사용하는 방법을 찾아볼 것입니다.

개요

데이터베이스를 유지, 관리하는 것은 사실 변경으로 시작해, 변경으로 끝난다고 해도 과언이 아니다. 특히 데이터베이스 품질 관리가 목적이라면 변경 사항을 잘 관리해야 한다. 데이터베이스 애플리케이션이 의도한 대로 작동하도록 해야 한다는 것이다. 즉, 자연스럽게 변경이 이루어지고, 문제가 발생했을 때 조사에 착수할 수 있어야 한다. 데이터베이스는 활동을 기록할 수 있지만 기록을 분석하는 것은 어렵다. 결국 기록만으로는 데이터베이스 변경을 완벽히 그려낼 수 없다. 그러므로 소프트웨어 개발 관련 몇 가지 기술이 데이터베이스에 적용될 필요가 있는 것이 아닐까? 소프트웨어 개발에서 변경을 추적하는 전통적인 접근은 몇 가지 유형의 변경 관리, 시스템, 프로세스, 도구 등을 사용하는 것이다. 이 접근을 구현 관리, 변경 관리, 소스코드 제어, 라이브러리 제어, 버전 제어 등 많은 이름으로 부른다. 이 글에서는 버전 제어(version control)라는 용어를 쓰도록 하자.

애플리케이션이나 제품 코드 자체의 변경 관리 프로세스는 널리 알려져 있다. 대다수 프로그래머는 자신의 코드를 확인하는 방법에 익숙하고 어떤 소프트웨어 출시에 어떤 버전이 따르는지 알고 있다. 하지만 애플리케이션 개발의 다른 업무를 담당하는 사람들은 이 요소들의 중요성을 잘 알고 있지 못하다. 이 사람들이 버전 제어 도구를 사용하는가? 아키텍트의 디자인, 프로젝트 매니저의 계획, 작성자의 문서나 테스터의 시나리오와 결과는 어떠한가? 데이터베이스 관리자는 어떤가? 애플리케이션은 코드 그 이상이다. 출시에 관련된 모든 분야는 통합돼야 한다. 애플리케이션의 부분으로서의 객체는 버전 제어 도구나 프로세스의 부분이어야만 한다.

전체적인 프로세스

다음 그림은 DB2 Change Management Expert와 버전 제어 시스템을 사용하여 전반적인 데이터베이스 변경 프로세스를 보여준다.

DB2 Change Management Expert와 이클립스

DB2 Change Management Expert는 DBA가 변경을 추적하고 다른 변경을 가하는 다른 DBA와 협업하며 변경 기록을 감사, 관리하고 더 이상 필요없는 변경을 뒤집거나 취소하는 데 사용하는 도구다.

DB2 Change Management Expert는 이클립스 기반 도구다. 이클립스는 리치 클라이언트 애플리케이션을 제공하는 플랫폼 독립적인 오픈 소스 소프트웨어 프레임워크다. 이클립스 플랫폼에서 다른 도구 개발자들도 통합된 도구를 쉽게 만들고 제공할 수 있다. 이 프레임워크는 DB2 Change Management Expert를 위해 통합 개발 환경(Integrated Development Environment)을 개발하는 데 사용됐다. 이클립스 플랫폼에 대해 더 자세한 정보를 원한다면 이 문서의 참고자료 절을 참조하기 바란다. DB2 Change Management Expert 내에서 성공적인 버전 제어 프로세스는 이클립스 팀(Eclipse Team) 기능 사용을 포함한다.

이클립스 팀 통합은 DB2 Change Management Expert 버전 제어 기능의 주요 구성요소다. 이클립스 팀 구성요소는 저장소 도구로 완벽하고 풍부한 저장소 솔루션 기능을 이클립스 워크벤치에 통합하는 메커니즘을 제공한다. 이 글의 예는 이클립스 팀 기능을 설명한다. 이클립스 팀에 대한 더 자세한 정보는 이 글의 참고자료 절을 참조하기 바란다.

데이터베이스에 변경을 가하고 난 후 DB2 Change Management Expert 프로젝트(모든 리소스 포함)는 버전 제어에서 확인되어야 하고 표시돼야 한다.

이클립스 팀을 사용하여 DB2 Change Management Expert 프로젝트를 보관할 수도 있다. 변경 추적을 위해 프로젝트를 보관해야 한다. 변경 개발 프로세스 중에 보관할 수도 있고 변경을 배치하기 전에도 보관할 수 있다. 이 경우 반복 작업을 해야 하고 다른 팀 구성원이나 DBA가 변경을 하거나 변경에 참여할 수 있으며 다른 이들도 변경된 것을 검사하거나 수정할 수 있다.

위로

Data Design Project와 데이터베이스, 버전 제어 간의 관계

데이터베이스 변경 프로젝트를 관리하는 데 다른 방법으로 버전 제어를 할 수도 있다. 공식 또는 비공식적 버전 제어 시스템을 사용하는 것이 그것으로, 버전 제어 시스템은 머신의 파일 시스템만큼이나 간단할 수도 있고, CVS(Concurrent Visioning System)나 IBM Rational Clear Case 같은 완벽한 버전일 수도 있다. 이 글은 대다수의 예에 CVS를 사용한다.

DB2 Change Management Expert는 변경해야 할 다른 리소스 그룹에 프로젝트를 사용한다. Data Design Project는 전형적으로 데이터베이스의 생명주기를 추적한다. 프로젝트는 이클립스 팀 기능을 사용해 공유될 수 있으므로 변경에 몇몇 DBA가 협업할 수 있다. 변경은 Data Design Project에 의해 특정 시간대에 표현된다. 변경이 배치되면 리소스는 대체로 버전 제어 시스템에 위임되고 표시된다. 변경을 취소하거나 특정 변경을 감사하기 위해 태그나 라벨을 사용하여 변경이 저장된 곳으로 돌아갈 수 있다.

Data Design Project는 더 복잡한 데이터베이스에서 특정 데이터베이스 애플리케이션의 생명주기를 관리하는 데 쓰일 수 있다. 어떤 경우 특정 DBA나 DBA 팀이 테이블이나 스키마를 관리한다. Data Design Project는 이 환경들을 맞추고자 한다. 이 경우 몇 가지 Data Design Project가 단일 데이터베이스를 나누고 관리한다. 단일 Data Design Project는 다중 데이터베이스를 관리하는 데 쓸 수 있는데 이 데이터베이스들이 본질적으로 복사 데이터베이스일 때 그렇다. 이를 다중 프로비저닝(multiple provisioning)이라 부르는데, 변경은 단일 데이터베이스를 위해 우선 만들어지고 다중 데이터베이스로 배치된다는 뜻이다.

CVS나 IBM Rational Clear Case 같은 이클립스로 플러그인되는 버전 제어 시스템은 DB2 Change Management Expert와 가장 잘 통합된다. 하지만 DB2 Change Management Expert가 모든 데이터 파일과 폴더를 로컬 파일 시스템에 저장하므로 이클립스와 통합되지 않는 버전 제어 시스템이라도 DB2 Change Management Expert 리소스를 관리하는 데 쓸 수 있다. 또한 공식 버전 제어 시스템 없이 변경을 관리할 수 있다. 이 글에서는 그러한 상황을 버전 제어 시스템을 사용하지 않고 DB2 Change Management Expert를 사용하는 방법 절에서 설명한다.

버전 제어 시스템과 함께 DB2 Change Management Expert 사용하기

이 예는 다른 DBA가 만든 변경과 대등한 변경을 감사하는 데 버전 제어를 사용하는 방법을 보여주고 그림은 DB2 V9을 사용한 DB2 Change Management Expert를 보여준다. 이 예는 다음의 네 가지 부분으로 나뉜다.

1. Jaya는 데이터베이스를 변경한다.
2. Jaya는 버전 제어 시스템에 프로젝트를 위임하여 프로젝트를 공유한다.
3. Eric은 프로젝트를 확인하고 추가로 변경한다.
4. Jaya는 Eric이 변경한 것이 마음에 안 들어 이를 뒤집는다.

중요: 이 시나리오에서는 CMEDEMO 데이터베이스를 사용한다. 이 글의 다운로드 절에서 sample01.zip 파일을 받아 DDL(CreateCMEDEMO.chx)을 사용하여 이 데이터베이스를 만들고 설정한다. 그리고 sample01.zip 파일의 내용을 로컬 디렉터리로 추출한다. 데이터베이스를 설정하는 방법은 다음과 같다.

1. File -> New -> Data Design Project를 선택하여 Data Design Project를 만들고 이를 test라 칭한다.
   
   그림 2. 새 Data Design Project
   
   
   
2. DB2 Change Management Expert의 Data Project Explorer 뷰에서 CreateCMEDEMO.chx 파일을 프로젝트 테스트에 임포트한다. CMEDEMO 프로젝트에서 SQL Script 폴더의 내용을 확장하고 CreateCMEDEMO.chx 파일을 오른쪽 클릭하고 Run SQL을 선택한다. 적절한 데이터베이스 버전이 선택됐는지 확인한다. 사용자 이름과 비밀번호를 넣고 Create Deployment Project and Script file을 체크하지 않은 상태로 둔다. Finish를 클릭한다.

   Database Explorer 뷰에서 CMEDEMO 데이터베이스가 생성됐는지와 연결이 존재하는지 확인한다. 이제 다음 단계로 넘어가자.

Part 1. DBA 중 한 사람인 Jaya가 데이터베이스를 변경했다.

Jaya는 다음 단계를 따라야 한다.

1. TestAudit이라는 새 배치 스크립트를 만든다. 배치 스크립트는 변경 관리 프로세스를 추적하는 DB2 Change Management Expert 리소스다. 변경될 데이터베이스의 위치와 이름을 New Deployment Script 마법사에 지정할 수 있다. 지정한 데이터베이스에는 두 가지 모델이 만들어질 것이다. 모델은 데이터베이스의 표현이다. 그 중 한 모델인 베이스 모델(base model)은 데이터베이스의 현 상태를 나타내고 다른 모델인 타겟 모델(target model)은 새 변경을 정의하기 위해 편집할 수 있는 모델이다.
2. 타겟 모델을 변경한다. 예를 들어 CL_SCHED 테이블에 CHAR(128) 유형의 LOCATION이라는 새 행을 만든다. 새 행은 속성 뷰에 추가될 수 있다. 변경 후 모델을 저장한다.
   
   그림 3. CL_SCHED 테이블에 있는 'LOCATION' 데이터 행
   
   
   
3. 배치 스크립트를 연다. Outline 뷰에서 Change Commands를 오른쪽 클릭하고 Generate Change Commands를 선택하여 변경 명령을 생성한다. 그러면 Generate Change Commands 마법사가 보인다. 변경 명령에 더해 마법사는 또한 데이터 보존 명령을 만든다. 배치에 따라 생성될 데이터 파일을 위해 파일 시스템에 위치를 지정해야 한다. 마법사에서 오토 캐스트를 선택하면 행 데이터 유형을 임포트나 익스포트할 때 생기는 충돌을 피할 수 있다.
   
   그림 4. Generate Change Commands 마법사에 의해 생성되는 변경 명령 목록
   
   
   

Part 2. Jaya가 변경을 마쳤다. Jaya는 이를 버전 제어 시스템에 추가하여 이미 프로젝트를 공유하고 있다. 변경은 이후 버전 제어 시스템에서 뺄 수 있고 변경 관리 프로세스를 지속하는 데 쓸 수 있다. 또한 필요에 따라 다른 관리자가 변경을 감사할 수 있다. 두 명 이상의 DBA에 의해 변경이 이루어지면 쉽게 결합, 조정할 수 있다.

이 예에서는 CVS가 버전 제어 시스템이다.

1. CVS 서버를 설치하고 저장소를 설정한다.
2. DB2 Change Management Expert에서 CVS Repository Exploring 퍼스펙티브를 연다. 이 퍼스펙티브에는 다양한 저장 공간을 추가할 수 있는 CVS 저장소라는 뷰가 있다.
3. 뷰를 오른쪽 클릭하고 New -> Repository를 선택하여 DB2 Change Management Expert Data Design Project를 위한 저장 공간을 추가한다. 다음 대화상자가 보인다.
   
   그림 5. 추가 CVS 저장소 대화상자
   
   
   
4. 필수 필드에 정보를 넣고 Finish를 선택한다. 이제 CVS Repository 뷰에 추가한 저장소가 보일 것이다.
   
   그림 6. Repository Exploring 뷰와 새 저장소 위치
   
   
   저장소의 내용을 훑어보기 위해 드릴다운(drill-down)할 수 있다.
5. Data 퍼스펙티브로 바꾼다. CVS에서 확인하고픈 프로젝트를 선택해 오른쪽 클릭하고 Team -> Share Project를 선택한다.
   
   그림 7. Share Project 마법사
   
   
   
6. 기존 저장소 위치(이전 단계에서 이미 추가했다)를 선택한다. 모든 기본사항을 수용하고 Finish를 클릭한다. 주의: 모든 DB2 Change Management Expert 리소스를 ASCII 유형으로 받아들일 수 있다. 이제 이 특정 저장 위치에 접근 권한이 있는 DBA는 프로젝트를 점검, 검사, 변경할 수 있다.

Part 3. 또 다른 DBA인 Eric은 프로젝트를 점검하여 추가로 변경할 수 있다. Eric은 다음 단계를 따라야 한다.

1. CVS Repository Exploring 퍼스펙티브를 연다. CVS Repository 뷰에서 프로젝트를 선택한 후 오른쪽 클릭하고, Check Out을 선택한다. 이렇게 하면 현 작업공간에 이 프로젝트의 복사본을 만든다. 이제 프로젝트와 관련 파일을 수정할 수 있다.
2. 타겟 모델을 편집한다. 모델에서 EMP_PHOTO table을 없애고 변경 명령을 재생성한다. Part 1의 이 프로세스를 따르면 된다.
3. 이 변경을 마친 후 데이터베이스 모델을 검사한다. 모델에 원하는 결과가 없다면 Jaya가 만든 버전으로 돌아가 새 변경을 취소할 수 있다. 변경을 취소하려면 Data Project Explorer의 프로젝트(또는 프로젝트의 개별 리소스)를 오른쪽 클릭하고 Replace With -> Latest from Head를 선택한다. 이렇게 하면 EMP_PHOTO 테이블이 다시 타겟 모델에 추가된다. 주의: EMP_PHOTO 테이블의 새 변경은 로컬에 만들어질 것이고 확연히 위임되지 않는 한 CVS에서 확인할 수 없을 것이다.
4. 실제 데이터베이스 편집기에서 타겟 모델을 열고 이를 다시 수정한다. 다음은 모델을 변경할 수 있는 예다. 변경이 완료되면 모델을 저장하고 변경 명령을 재생성한다. 취소 명령 또한 생성될 것이다.
   1. COMPLETION_CODE라는 새 테이블과 INTERGER 유형의 CODE 행, 유형 VARCHAR(128)의 DESC를 추가한다. COMPLETION_CODE 테이블에 CODE 행을 기본키로 한다.
   2. PROJECT TABLE에 INTERGER 유형의 CODE라는 새 행을 추가한다. PROJECT 테이블의 CODE 행을 널(nullable)이라 정의하자.
   3. PROJECT 테이블의 CODE 행과 COMPLETION_CODE 테이블의 CODE 행 기본키 사이의 참조키 관계를 만든다.
5. Deploy Changes를 선택하여 변경을 타겟 데이터베이스에 배치한다. 주의: DB2 Change Management Expert에 배치할 때 변경은 작업공간의 배치 기록 파일에 기록된다. 이 배치 기록은 또한 테스트 프로젝트와 함께 CVS에서 확인된다.
6. 변경은 Deployment Script Editor의 개요 페이지에 지정된 연결에 반하여 배치될 것이다. 작업공간에 연결이 존재하지 않으면 타겟 데이터베이스를 위해 같은 이름으로 새 연결을 만들어야 한다. 이를 위해 Database Explorer 뷰에서 Connections -> New Connection을 선택한다. New Connection 마법사가 나타날 것이다.
   
   그림 8. New Connection 마법사
   
   
   
7. Team -> Commit을 선택하여 CVS에 변경이 이루어졌는지 확인한다.

이제 팀 전체가 Jaya와 Eric이 변경한 것을 검사할 수 있다.

Part 4. 첫 번째 DBA인 Jaya는 프로젝트를 점검하고 Eric이 변경한 것을 검사한다. Eric이 데이터베이스에 배치한 변경을 취소하고자 한다면 다음 단계를 밟아야 한다.

1. 배치 스크립트를 열어 Deployment Script Editor의 Undo Changes 탭에서 Deploy Undo Commands를 선택한다.
2. 처음부터 변경 프로세스를 시작하기 위해 배치 스크립트를 재설정하거나 모델을 다시 수정하여 배치하고자 하는 변경 명령을 생성한다.

배치 스크립트를 열고 배치 스크립트 편집기의 메뉴 아이템을 클릭하여 배치 스크립트를 재설정할 수 있다. Deploy -> Reset을 선택한다. 이렇게 하면 배치 스크립트를 재설정하는 데 도움을 주는 마법사가 뜬다.

위로

버전 제어 시스템 없이 DB2 Change Management Expert 사용하기

버전 제어 시스템에 접근할 수 없어도 DB2 Change Management Expert를 사용할 수 있을까? 물론이다. 하지만 여전히 감사나 목적 추적을 제어해야 하는데 DB2 Change Management Expert에 DB2 변경사항이 모두 저장되어 있다면 어떻게 하겠는가? Data Project 정보는 시작할 때 정의한 DB2 Change Management Expert Workspace에 저장돼 있다. 작업공간은 로컬 디스크에 있는 디렉터리 세트이므로 버전을 위해 파일을 설정한 것처럼 이 파일들을 모두 묶어두기만 하면 된다.

이 글의 예를 사용하되, 버전 제어 시스템이 없다고 가정하자.

저장소를 사용하여 변경을 저장하면 작업공간에 있는 리치 히스토리(rich history)라는 장점을 얻을 수 있다. 감사 목적이나 변경 취소에 히스토리가 필요할 때가 있다. 프로젝트 파일만 관리한다면 어떤 변경이 언제, 누구에 의해 됐는지 추적하는 것은 담당자 마음이다.

다른 사용자와 전체 작업공간을 공유할 수 있는가?

기술적으로는 그렇다. 예로 공유된 드라이브에서 전체 작업공간만 공유하는 것은 가능하다. 하지만 누군가가 작업공간을 연 상태에 다른 누군가가 작업공간을 열고자 한다면 파일이 사용되고 있다는 오류 메시지를 받을 것이다. 작업공간을 공유하는 데 따른 또 다른 단점은 모든 설정도 공유되기 때문에 누군가가 설정을 변경하면 커스터마이제이션을 잃을 수 있다는 것이다. 그러므로 작업공간을 공유하는 것은 권하고 싶지 않다.

여러 명의 DBA와 파일을 공유하는 방법은 무엇인가?

프로젝트 파일을 공유하는 방법은 몇 가지가 있다. 가장 간단하고, 여기서 설명한 접근은 전체 프로젝트를 아카이브(ZIP 파일)로 익스포트하고 다른 사용자가 이 프로젝트를 자기 작업공간에 임포트하게 하는 것이다. Jaya와 Eric이 데이터베이스 변경을 작업하고 있는 위의 시나리오를 보자면 Jaya는 현재 Part 1의 끝인 모든 변경 명령을 생성한 후다. 파일을 버전 제어로 확인하는 대신 이제 Jaya는 변경을 보존해야 하고 다른 DBA가 프로젝트 상에서 작업할 수 있게 해야 한다. 이를 위해 Jaya는 다음 단계를 밟아야 한다.

1. 프로젝트를 선택하고 File -> Export를 선택하여 Export 대화상자를 불러온다.
2. General 폴더를 확장하고 Archive File을 선택한 후 Next를 클릭한다.
3. 다음 화면에서 프로젝트, 출력 파일 위치, 파일이름과 포맷(ZIP이나 TAR)을 선택한 후 Finish를 클릭한다. 이렇게 하면 ZIP 파일을 디스크에 만든다.
4. Jaya는 DB2 Change Management Expert를 나올 수 있고 익스포트된 ZIP 파일을 Eric이 쓸 수 있다.

이제 Eric이 프로젝트에 작업할 차례다. CVS를 점검하는 대신 Eric은 프로젝트를 수동으로 작업공간에 가져와야 한다. Eric은 다음 단계를 따라야 한다.

1. 작업공간에서 File -> Import를 선택한다.
2. General 폴더를 확장하고 Existing Projects into Workspace를 선택한다.
3. Select archive file을 사용하여 Jaya가 익스포트한 아카이브 파일의 위치를 훑는다. 아카이브 안의 프로젝트가 Projects 목록 박스에 나타날 것이다.
4. 프로젝트를 선택하고 Finish를 클릭한다.

이제 프로젝트는 Eric의 작업공간에 있고 프로세스의 Part 3에서 설명한 것처럼 변경을 처리할 수 있다. Eric이 변경을 하고 DDL을 생성할 때 배치 스크립트는 Jaya와 Eric의 변경을 포함한다(Eric은 Jaya가 변경한 것을 삭제하거나 수정할 수 있지만 여기서는 그러지 않았다).

Part 3에서 Eric은 테이블을 제거하지만 마음을 바꿔 CVS의 프로젝트 버전으로 복구한다. 버전 제어 시스템을 사용하지 않는다면 어떻게 이렇게 하는가?

CME는 작업공간에 약간의 로컬 히스토리를 갖는다. 이 특정 시나리오에서 Eric은 타겟 모델에서 EMP_PHOTO 테이블을 삭제할 수 있고 Data Project Explorer 뷰에서 타겟 모델을 오른쪽 클릭해 다시 제자리로 돌려놨다가 Replace with Local History를 선택할 수 있다. Eric은 이전 변경으로 복구할 수 있다. 모든 경우에 해당하지 않고 작업공간에서 작업할 때만 가능하다. 즉, Eric과 Jaya는 서로 변경한 것으로 복구할 수는 없다.

프로세스의 Part 4에서 Eric이 프로젝트를 아카이브(ZIP/TAR) 파일에 익스포트한 후 Jaya는 작업공간에 이 프로젝트를 가져올 수 있다. Jaya는 작업공간에서 기존 프로젝트를 삭제해야 하고 Eric이 만든 새 프로젝트 아카이브를 임포트해야 한다. 이 프로젝트는 Part 1에서 Part 3까지의 모든 변경을 가질 것이다. 하지만 Jaya는 Eric이 변경한 로컬 히스토리에 접근할 수 없을 것이므로 이전 변경으로 복귀하는 것이 더 어렵다.

이 시나리오를 통해 협업 환경에서 버전 제어 시스템이 얼마나 중요한지 알 수 있다.

전체 프로젝트 파일의 변경을 공유하는 것의 대안적 접근으로 개별 모델이나 배치 스크립트를 공유하고 DB2 Change Management Expert의 결합 및 마이그레이션 기능을 사용해 변경을 통합하는 접근이 있다. 이 접근을 사용하려면 세세한 것에 더 주의를 기울여야 하지만 여러 개의 또는 더 복잡한 변경을 처리할 때 더 큰 유연성을 제공할 수 있다. 어떤 접근을 사용하든 버전 제어 시스템보다 더 풍부한 히스토리 기능은 없다.

결론

DB2 Change Management Expert와 버전 제어 시스템을 사용하면 비즈니스 요구를 관리하는 데 큰 도움이 된다. 두 도구를 모두 사용하면 애플리케이션 개발 주기에서 모든 변경을 추적하는 데 더욱 능률적이다. 버전 제어 시스템 없이도 DB2 Change Management Expert와 잘 설계된 개별 시스템을 사용할 수 있다. 다행히 이 글은 DB2 Change Management Expert가 부족함을 채워줄 수 있는 방법을 찾아보라고 권유한다.

위로

다운로드 하십시오

	다운로드 방식에 대한 정보

참고자료

• 한국 developerWorks Information Management 존: DB2에 대해 더 알아보자. 기술 문서, 교육, 다운로드, 제품 정보 등을 찾아보자.
  
  
• developerWorks 기술 행사와 웹 캐스트를 통해 최신 기술을 익히자.
  
  
• Eclipse.org: 이클립스에 대한 더 많은 정보를 접할 수 있다.
  
  
• Eclipse.org의 Team Repository Projects와 플러그인 페이지를 통해 이클립스 팀 기능에 대해 더 자세히 알아보자.
  
  
• 개발 리소스를 공유하는 방법에 관한 더 일반적인 정보는 developerWorks의 "Share and Share Alike"를 보자.
  
  
• 기술 주제에 관련된 책은 technology bookstore에서 찾아보자.
  
  

• developerWorks에서 직접 받을 수 있는 IBM 시험판 소프트웨어로 다음 개발 프로젝트를 만들어보자.
  
  
• IBM 제품 평가 버전을 받아 애플리케이션 개발 도구와 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 미들웨어 제품들에 익숙해지자.

• 한국 developerWorks 블로그를 확인하고 한국 developerWorks 커뮤니티에서 활동하자.
  
  

필자소개

		Carolyn Henry는 IBM Silicon Valley Laboratory(San Jose, CA)의 DB2 and IMS Tools 그룹의 정보 개발자다. 2004년부터 DB2 Change Management Expert 팀에서 일하고 있다.

		Marcia Miskimen은 IBM Silicon Valley Laboratory(San Jose, CA)의 정보 관리 도구의 소프트웨어 엔지니어다. 2003년부터 멀티플랫폼 도구 지원 분야에서 일하고 있다.

		Jayashree Ramachandran은 IBM Silicon Valley Laboratory(San Jose, CA)의 정보 관리 도구 그룹의 개발자다. 2004년부터 DB2 Change Management Expert 팀에서 일하고 있다.

		Sailaja Bandlamoori는 IBM Silicon Valley Laboratory(San Jose, CA)의 정보 관리 도구 그룹의 테스팅 담당자다. 2006년부터 DB2 Change Management Expert 팀에서 일하고 있으며 전에는 z/OS 클라이언트/서버 시스템 테스트 분야에서 일했다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로