자동화 도구를 이용한 빌드 / 배포 관리 및 통합 변경 / 형상 관리

1. 자동화 도구를 이용한 빌드/배포 관리 및 통합 변경/형상 관리 강 용석 yskang@kr.ibm.com IBM SWG / Rational Team

2. 목차 1. S/W개발에서의 빌드/배포의 역할 및 문제점 2. 빌드/배포 관리의 원칙 3. Build Forge 소개 4. 형상/변경 관리를 포함한 구현 시나리오

3. 목차 1. S/W개발에서의 빌드/배포의 역할 및 문제점 2. 빌드/배포 관리의 원칙 3. Build Forge 소개 4. 형상/변경 관리를 포함한 구현 시나리오

4. 빌드/배포 관리 – 소프트웨어 개발의 주요한 부문 • 개발 과정 중 주요한 프로세스이나 구조화되지 못함 • 개발 결과를 최종적으로 고객에게 인도될 주요한 상품으로 전환시키는 주요한 연결고리 • 개발 단계에 비하여 빈약한 협력 및 Best Practice • 빌드/배포의 중요성 증대… “소프트웨어 빌드 관리는 성공적인 소프트웨어 개발, 비즈니스와 IT의 생산성에 대한 영향도가 증대되고 있으며 IT조직에서 주요한 관심의 대상으로 대두되고 있다.” - IDC “일관성, 정확성, 재사용성이 결여된 빌드는 소프트웨어 개발에서의 병목현상을 초래하며 개발팀의 개발 활동에 중대한 영향을 미친다. 이를 해결하기 위하여서는 추가적인 자원의 투입이 필수적이다.” - Hurwitz “개발 과정 중 빌드는 지금까지 그 중요성이 간과되어 왔으나 개발 활동의 변화 및 컴플라이언스(Compliance)의 필요로 인하여 중요성이 증대되고 있다.” - Forrester

5. 개발 및 빌드 프로세스의 현주소 형상관리 시스템 다수의 개발팀 문제점 ◆ 프로세스가 중앙 집중 관리되지 못하고, 표준화 되어 있지 못하며 재사용할 수 없음. ◆ 표준 프레임워크를 따르지 않는 각각의 다른 툴들이 혼용되고 있음 ◆ 보안 및 권한 관리가 이루어 지지 않음 ◆ 다양한 프로세스들에 대해 통제력 상실 ◆ 프로세스들은 자동 문서화 되어지지 않음 ◆ 각 팀들 간의 역할/책임이 불분명 함 ◆ 빌드 시간이 너무 오래 걸림 테스트 및 운영용 빌드 시스템 빌드 관리팀 빌드 스크립트들 품질 및 배포 관리팀 테스트 및 배포 대상 시스템

6. 목차 1. S/W개발에서의 빌드/배포의 역할 및 문제점 2. 빌드/배포 관리의 원칙 3. Build Forge 소개 4. 형상/변경 관리를 포함한 구현 시나리오

7. 9가지 원칙 : • 완벽하게 재현 가능하게 하라 • 프로세스를 자동화하고 주요 시스템과 통합화 하라 • 물리적인 대상으로부터 프로세스를 추상화하고 데이터를 추출하라 • 프로세스와 아키텍처 구조를 최적화 하라 • 빌드를 가속화할 수 있는 기술을 적용하라 • 모든 관련자들을 중앙 집중화된 접근과 협력하도록 하라 • 빌드는 초기에 그리고 자주 하라 • 빌드 프로세스와 배포 프로세스를 연결하라 • 비즈니스 목표를 대상으로 성능을 측정하라

8. 1) 완벽하게 재현 가능하게 하라 의미 ? • 동일한 결과물을 만들 수 있는 프로세스를 작성할 수 있어야 한다. * • 일관성에 초점 ( 정확성의 의미가 아님 ) – 결과물을 재 작성하는 것은 좋은 결과물을 만드는 것이 아니라, 동일한 결과물을 작성하는 것. * 출처: Wikipedia

9. 1) 완벽하게 재현 가능하게 하라 왜 중요 ? • 문제를 해결하기 위하여 여러 차례 개발이 이루어질 수 있다.-- Standish Group • 모든 구성 단위에 대한 재현성에 대하여 간과. • 빌드는 다수의 이전 버전과 다수의 플랫폼을 대상으로 개발 작업이 진행될 경우 복잡성은 기하 급수적으로 증가. • 재현성은 감사에서의 필수 사항.

10. 단기적 오류 수정의 가속화 – 빠른 응답 이후 작업의 신뢰성 있는 베이스라인 제공 감사 및 보안 요구사항 충족 장기적 신뢰성 및 적시성 증대 ( 제품 릴리즈 , SLA’s) 능률 향상 컴플라이언스 관리 요소 기타 실질적인 이점 제공 일관성 제공, 시간 단축, 하드웨어 비용 절감 1) 완벽하게 재현 가능하게 하라 이점

11. 배포 대상 소프트웨어의 빌드, 테스트, 배포의 사람이 개입되지 않는 100% 자동화 능력 주요 시스템 간의 통합은 프로세스를 자동화하기 위한 필수 요소 자동화는 아래의 프로세스를 포함해야 함. – 전체(master) 빌드 포함 개발자의 점전적인(incremental) 빌드 QA 빌드 전체(Master) 빌드 패치 / 서비스 릴리즈 2) 프로세스를 자동화하고 주요 시스템과 통합화 하라 의미?

12. 일반적으로 개발, 형상 관리, QA, 빌드, 그리고 릴리즈 팀은 전체 빌드 및 릴리즈 프로세스 과정을 수작업으로 수행. 이러한 수작업은 오류가 발생 : 요청된 바이너리와 배포된 릴리즈 사이에 잠재적인 오류의 가능성. 오류 발생 가능한 일관적이지 못한 프로세스의 실행 수작업에 의한 프로세스 단계별 격리 현상 발생 대기 중 메시지가 표시되지 않을 경우, 모든 프로세스는 실패. 통합되지 않은 ALM 도구 사용 도구 간 부적절한 데이터의 공유 통합되지 않은 도구는 일관성 없은 프로세스 테이터를 발생시킴 프로세스는 형상관리에 상당히 의존함 “같은 분류의 지식” 제품의 복잡성의 증가에 따라 관리하기 어려움 2) 프로세스를 자동화하고 주요 시스템과 통합화 하라 왜 중요?

13. “우리는 빌드 준비 작업과 소스 코드의 레이블 작업을 자동화하여 빌드 작업 시간을 6시간 가량 단축시켰다.” -- Avaya 신속하고 일관성 있는 빌드, 배포 프로세스 구축 = 개발 주기 단축 신속한 소프트웨어 개발 주기 = 향상된 팀 생산성 형상관리, 빌드 팀은 효율적이지 못한 수작업, 반복적인 작업에서 벗어나 보다 생산적인 활동을 수행 운영 유지 활동 노력이 경감됨 소프트웨어 품질 향상 “회사 최고 경영층은 자동화된 빌드 프로세스와 제품 설치에 대하여 제품 출시 시간을 50%, 신뢰도를 70% 향상시킴으로 인하여 깊은 감명 받았다.” -- Vital PS 2) 프로세스를 자동화하고 주요 시스템과 통합화 하라 이점

14. 물리적인 시스템으로부터 중심 로직(logic), 구성, 프로세스 정보를 분리하여 작업하라. 서버들이 방대할 경우 추상화 작업을 통하여 소수의 서버를 사용하는 것과 같은 이점을 얻음. 다수의 환경 및 구성은 추상화 가능성을 내포. 3) 물리적인 대상으로부터 프로세스를 추상화하고 데이터를 추출하라 의미?

15. 물리적인 시스템에 대한 “하드 코딩(Hard coding)” 은 융통성 없는 빌드 , 배포 환경을 만든다 하드웨어 자원을 최적화하기 어려움 – 1 서버 / 1 프로젝트는 특정 장비의 과부하를 다른 곳은 낭비(idle)을 의미함 팀 구성원이 어느 장비가 사용 중인지 파악하기 어려움 – 오류 발생 가능성 운영 노력의 부담 가중 – 다수의 지역에 대한 수작업 구성 및 변경작업 고 위험 / 서버 장애 초래 3) 물리적인 대상으로부터 프로세스를 추상화하고 데이터를 추출하라 왜 중요?

16. 융통성의 증가 수작업으로 스크립트의 수정 없이 다른 서버에 대한 손쉬운 빌드 다른 종류 및 버전에 대한 빌드 수행 운영 노력의 경감 단일 장소에 대한 변경 구성 정보의 손쉬운 변경 하드웨어 활용도 증대 시스템의 균형적인 활용 및 융통성 증대 오류 감소 구성정보 관리 용이, 실수 제거 저 위험 및 신속한 복구 빌드 데이터의 손실로 인한 하드웨어 제거 신 시스템의 신속한 배포 및 사용 신속한 복구 기회 제공 3) 물리적인 대상으로부터 프로세스를 추상화하고 데이터를 추출하라 이점

17. 4) 프로세스와 아키텍처 구조를 최적화 하라 의미? • 복작성을 모듈화 하라. • 그러면, 재사용, 확장, 유지보수가 쉬워진다. • 지속적인 점진적 개선을 하라 • 이름과 사용법을 표준화에 포함해서 관리 • 관리하기 어려운 커다란 단위 빌드 스크립트, Make 파일, Ant 스크립트 등과 어플리케이션을 관리 가능한 작은 단위로 분리. • 이전 시스템(legacy application) 을 리팩토링(Re-factor). • 융통성있는 아키텍처를 구현 • 재사용을 강화하라 • 빌드 중복되는 기능을 위하여 스크립트를 여러 곳에서 중복해서 만들지 않음.

18. 4) 프로세스와 아키텍처 구조를 최적화 하라 왜 중요? • 시간이 지남에 따라 시스템의 크기와 복잡성이 증가한다. 그러므로 운영 및 확장을 위하여 아키텍처가 필요하다. • 빌드 시스템의 복장성은 생산성을 떨어뜨리며 비즈니스 요구사항에 즉각 대응하기 어렵게 함. • 모율화된 아키텍처는 복잡성을 감소, 시스템의 융통성을 증대, 불필요한 빌드 감소, 재사용성을 증대시킴. • 일관성 있는 이름 부여(naming)는 팀 자원의 공유 및 보다 빠른 오류 수정을 가능하게 함.

19. 모듈화된 시스템의 패치(patch)및 오류 수정 노력 감소 및 개발/릴리즈의 시간 절감! 불필요한 노력을 절감하여 생산성 증가 비즈니스 요구사항에 보다 효과적인 대응 통합 및 병합 새로운 제품 요구사항 새로운 기술의 즉각적인 대응 효율성 증대 빠른 빌드 및 릴리즈 주기 모듈화된 로직의 효과적인 재사용 환경 및 활용 방법(usage)의 공유 검색 및 조건 검색의 효과 증대 4) 프로세스와 아키텍처 구조를 최적화 하라 이점

20. 5) 빌드를 가속화할 수 있는 기술을 적용하라 의미? • 빌드 및 릴리즈 주기를 줄일 수 있는 원칙을 적용하고 기술을 사용한다. • 컴포넌트 및 실행(Step)을 병렬로 수행 • 컴파일, 소스 코드 추출, 테스트, 팩키징(packaging) • 가능하다면 하드웨어 풀(pool)을 최적화 • 수작업 및 비 효율적인 실행(Step), 컴파일에 대하여 적용. • 반복과 신속한(agile) 기법을 사용하여 최대의 효과를 얻음

21. 빠른 빌드 주기는 팀의 생산성, 그리고 어플리케이션의 가시성을 증대시킨다. 많은 소프트웨어 개발 활동이 효과적인 빌드의 성공에 의존 : 통합(Integration), 테스트, QA, 문서화, 요구사항 검증, 결함 관리, 릴리즈 빌드의 시간 단축은 빌드 결과 작업에 보다 많은 시간을 활용할 수 있도록 함. 빠른 빌드는 수시 빌드와 결과의 시각성 및 고품질을 얻을 수 있도록 함. 제품의 품질에 대한 이해 증대 5) 빌드를 가속화할 수 있는 기술을 적용하라 왜 중요?

22. 아래의 이득들 : 개발 생산성 향상 품질 향상 프로젝트 상태에 대한 시각성 증대 - 빠른 문제 발견 및 조치 가능 하드웨어 통합 –하드웨어 풀(Pool)의 효과적인 하드웨어 사용으로 하드웨어 활용도 증대 비용 절감 빠른 제품 출시 및 품질 향상 5) 빌드를 가속화할 수 있는 기술을 적용하라 이점

23. 지역적으로 분산된 개발 환경에서의 시각성, 공유성, 의사 소통을 용이하게 하라 모든 팀의 필수적인 요건 –소프트웨어 개발 프로젝트 정책 및 단계화를 통하여 지역(Global)간 협력 가능 6) 모든 관련자들을 중앙 집중화된 접근과 협력하도록 하라 의미?

24. 중앙 집중화된 접근 및 통제는 통하여 정보의 혼란을 제거하여 팀의 생산성 향상 및 데이터의 보안을 가능하게 한다. 단일한 방식은 접근으로 모든 사용자의 요구사항을 만족시킬 수 없음. 역할별 접근 및 보기(view) 기능 필요 개발자, 관리자, 테스터, 프로젝트 리더, 매니저 모두가 다른 요구사항으로의 협력이 필요함. 다수의 서버 및 개발 장비에 산재한 정보들은 보안 및 관리 정책을 필요로 함.; 팀 간 조직 간 데이터의 통합 관리 필요(big picture) 통제되지 못한 프로세스 및 팀 작업은 공유 및 생산성 향상을 기대하기 어려움; 의사 소통, 개발 일정, 품질 실패 6) 모든 관련자들을 중앙 집중화된 접근과 협력하도록 하라 왜 중요?

25. 개발팀간의 향상된 협력은 보안 및 생산성을 증대 시킨다. 중앙 집중화된 데이터를 통하여 접근 권한 단위의 보안을 구현. 전체 개발 주기를 통하여 향상된 시각성 및 사용성을 제공. 빌드 및 릴리즈 조직 간의 수작업으로 인한 비효율성을 제거. 웹 등을 통한 즉각적인 데이터 활용 저장소 접근 이력을 통한 컴플라이언스(compliance) 및 거버넌스(governance) 요건 충족 가능 빠른 의사 소통 : 수작업에 의한 데이터 전달 및 통보에 비하여 효과적인 개발, 오류 수정, 최적화 작업 가능 6) 모든 관련자들을 중앙 집중화된 접근과 협력하도록 하라 이점

26. 소프트웨어 개발에서 초기 결함을 빨리 발견하여야 하며 어플리케이션의 상태 또는 제품의 상태를 실시간으로 확인 가능하여야 한다. 빈번한 제품 개발 주기 ; 계획화 및 정형화(on-demand)가능 최소 일일 1회 ; 보다 빈번함 예정된 주기 및 마일스톤(milestone) 빌드와 통합 프로젝트에서의 소스변경에 따른 지속적인 통합 빌드 수행 테스트와 수시 자동 빌드의 통합 테스트 시나리오 기 작성 필요 7) 빌드는 초기에 그리고 자주 하라 의미?

27. 만약 당신이 빌드와 테스트를 수행할 수 없다면, 암흑 속에서 일하는 것과 같다. 개발 초기(initial) 및 구조화(construnction) 단계에서 어플리케이션을 빌드할 수 있는가는 프로젝트의 성공과 실패를 결정지을 수 있음 지속적인 빌드 작업 및 검증 작업 – 보다 큰 문제를 발생시키기 이전에 교정 작성 수행을 가능하게 함. 즉각적인 오류 수정 작업은 개발자의 생산성을 높여준다. 만약 문제가 1주일 이후에 발견된다면? 어플리케이션이 빌드되기 전까지는 당신은 품질을 측정할 수 없으며 비즈니스 요구사항을 만족시켰는지 확인할 수 없음. 7) 빌드는 초기에 그리고 자주 하라 왜 중요?

28. 고품질은 정시 제품 출시를 보장한다. 문제가 개발 초기에 발견 될수록 보다 적은 비용과 노력으로 교정할 수 있다. 보다 정확한 예측과 전망이 가능. 제품이 요구사항을 만족. 개발 초기에 사용자의 참여를 유도할 수 있으며 사용자의 요구사항을 쉽게 반영할 수 있음. 7) 빌드는 초기에 그리고 자주 하라 이점

29. 개발자와 사용자를 연결하는 프로세스를 자동화, 반복, 추적 가능하게 해야 한다. 목표에 배포 내부 배포는 개발 주기와 테스트, QA등의 프로세스와 통합하여 구현 가능 IT 운영- 최종 운영 환경에 배포 개발 중심의 제품 배포 내부와 외부(방화벽) ; 푸시(push), 풀(pull)방식 사용 기업 전체에 걸친 대량의 푸시(push)와 혼돈하지 않아야 함. Build Forge는 새로운 소프트웨어 배포 또는 일반 장비(desktop)에 패치를 적용하는 IT 운영 도구가 아님. 8) 빌드 프로세스와 배포 프로세스를 연결하라 의미?

30. 응용 소프트웨어의 생산과 배포의 처음과 끝을 연결하여 추적하는 능력 배포 단계로의 이전의 장벽 신속한 생산과 배포는 문제 해결을 위한 시간을 절약 감사 추적 요건 충족 자동화된 배포 환경은 수작업으로 인한 오류 가능성을 최소화함 불완전한 배포는 오류를 방생함 배포 대상 시스템과 도일한 환경 구성 예측하지 못한 결과에 대한 사전 점검 배포 활동(Step)의 재사용 8) 빌드 프로세스와 배포 프로세스를 연결하라 왜 중요?

31. 고품질의 배포환경은 응용 프로그램의 추적성을 높여줌 불완전한 데이터 전달의 오류 제거 배포 비용 및 오류 제거 감사 추적 요건 충족 배포 프로세스에서 하나의 연결 고리 역할 수행 실제 환경에서의 오류 수정 노력 절감 생산에서 제품 출시까지의 실제적인 데이터 제공 배포와 운영의 교량 역할 8) 빌드 프로세스와 배포 프로세스를 연결하라 이점

32. 기업 비즈니스 목표에 소프트웨어 공학과 IT 활동을 접목 목표 측정을 위하여 빌드와 릴리즈의 데이터로부터 리포트, 메트릭(metrics), 그리고 메타데이타를 추출. 릴리즈 주기 컴플라이언스(Compliance) 목표 품질 데이터 집계 예산과 자원을 어떻게 소비하는지 측정하고 의사 소통함 비즈니스와 부합되지 않는 데이터 검출 소프트웨어 IT에 투자 비용 가시화 9) 비즈니스 목표를 대상으로 성능을 측정하라 의미?

33. 측정할 수 없는 대상은 개선할 수 없다 품질 및 프로세스의 개선은 측정할 수 있는 대상으로부터 시작. CMMI, ISO, ITIL, 6 시그마 등. 대다수의 기업이 소프트웨어 개발과 IT 투자에 대한 측정(Metrics) 능력이 부족 IT프로세스, 목표는 점차 비즈니스 중심으로 이동 효과적인 감사 및 컴플라이언스 요구사항 충족 통제되지 못한 데이터는 고 위험을 내포함 팀/조직의 의사소통 기본 제공 9) 비즈니스 목표를 대상으로 성능을 측정하라 왜 중요?

34. 보다 시각정이고 신뢰도 높은 데이터는 의사결정에 필요한 데이터를 제공함 비교를 위한 베이스라인 설정 프로젝트의 상태 및 자원 개선을 위한 예측 가능 소프트웨어 팀과 IT조직에 비즈니스 가치를 명시화 정시 제품 출시 횟수 릴리즈별 수정 현황 즉각정인 감사 자료 제시 동일한 자원으로 상위 크기의 프로젝트 수행 지속적인 개선 및 최적화 현황 제공 9) 비즈니스 목표를 대상으로 성능을 측정하라 이점

35. 목차 1. S/W개발에서의 빌드/배포의 역할 및 문제점 2. 빌드/배포 관리의원칙 3. Build Forge 소개 4. 형상/변경 관리를 포함한 구현 시나리오

36. BuildForge를 이용한다면…… 다수의 개발팀 형상관리 시스템 Solution ◆ 중앙 집중화된, 자동화된, 재사용 가능한 빌드 및 배포 프로세스 확보 ◆ 다양한 툴들에 대한 지원과 동시에 권한 관리가 이루어짐 ◆ 빌드 및 배포 프로세스의 모든 단계에 대한 통제력 확보 ◆ 신속한 문제 발견 및 해결작업 가능 ◆ 자동화된 문서화 : 빌드 로그, BOM, 커스텀 보고서 등 ◆ 빌드 및 배포 성능 향상을 위한 다양한 기능 제공 테스트 및 운영용 빌드 시스템 빌드 관리팀 품질 및 배포 관리 팀 테스트 및 배포 대상 시스템

37. Build Forge – 재무적 효과 연간 비용 감소 효과 : $250,000-$25M

38. Build Forge – 기술적 효과 “신규 고객들도 오래된 고객이 얻는 효과와 비슷한 성능을 얻는 것으로 보아, Build Forge는 단기간에 목표된 성능을 구현해 낼 수 있는 제품으로 판단된다. -- Hurwitz & Associates

39. Build Forge는 기업 전체에 필요로 하는 프로세스를 설정하고 자동화할 수 있다. 엔터프라이즈 애플리케이션 배포 프로세스 관리 웹 기반의 관리 콘솔 분산 환경 접근 - 웹 접근, 롤 기반의 보안 Eclipse Plug-in 가속화 경보 추적 분석 워크플로우 통제 스케줄링 오류 감지 개발 형상 관리 제품 빌드 품질 보증 패키징 전개 프로세스 자동화 - 자동화 및 반복적인 애플리케이션 개발 생명주기 스크립트 Python, VBscript, Batch, Perl, KSH 형상관리 통합개발도구 언어 빌드 도구 테스트 도구 배포 도구 • Clearmake • Ant • NAnt • Make • GNUMake • NMake • Open Source • etc. • LoadRunner • TestDirector • WinRunner • Junit • etc. • Tivoli • WebLogic • WIS • etc. • ClearCase • StarTeam • Perforce • CVS • PVCS • VSS • Synergy • Subversion • etc. • Eclipse • RAD • Visual .NET • Java • C • C++ • C# • etc. UNIX, Windows Mac, Linux, Proprietary 운영체제(환경) Build Forge 시스템개요

40. 관리 구현 실행 BuildForge 관리 콘솔 BuildForge 서버 BuildForge 에이전트 Server Pool • BuildForge 엔진 • 프로젝트 절차 할당 • 경보 전송 • 자원 초기화 AIX Linux Windows Windows Windows Austin HP-UX AIX Windows Mac Solaris Linux • BuildForge 데이터베이스 • 프로젝트와 절차 • 서버 구성 • 환경 구성 • 사용자 및 권한 정보 • 빌드 통계 • 시스템 로그 • 에이전트 • 실시간 환경 구성 • 프로젝트 절차 실행 • 서버 상태 정보 출력 San Jose 도구 통합 BuildForge 사용자 화면 Bangalore • 도구 통합 • 형상관리, 빌드, 테스트,패키지,배포 시스템 • 관리 콘솔 • 사용자 관리 • 자원 구성 • 프로젝트와 절차 정의 • 빌드 일정 및 상태 관리 • 빌드 문제 관리 • 보고서 작성 및 분석 프로그램 소스 저장소 테스트 시나리오 배포 도구 형상관리 Web 접속 IDE Plug-ins Build Forge Architecture Build Forge는 크게 관리 콘솔, 데이터베이스, 에이전트, 도구 통합 및 사용자 화면으로 구성된다.

41. BuildForge 구성 BuildForge는 사용자가 원하는 일련의 작업을 정의한 “Step”, “Step”을 연결하여 작성한 “Project”를 구성하여 Customizing작업을 실시한다.

42. 프로젝트/프로세스 스케줄링 경고 오류 탐지 추적 Linux 컴파일 Solaris 컴파일 분석 워크플로우 시험 패키징 배포 Init Get Src 제어 보고서 환경 구성 Windows 컴파일 (main) Windows 연결 (main, ui) Windows 컴파일 (ui) 재사용 절차 운영 아키텍처 BuildForge 개발자가 복잡하고 다양한 빌드 환경에서 제품을 빠르고 신뢰성 있게 빌드하고 배포할 수 있도록 아래와 같은 일련을 과정을 통하여 지원한다.

43.  1회 예약 빌드 및 반복 빌드 스케줄 추가달력을 이용한 빌드 스케줄 모니터링 및 관리빌드 로그를 관리하여, 실패한 빌드의 재시작 기능   빌드 스케줄링 및 로그 관리 기능 BuildForge는 빌드 스케줄링 기능을 지원하며, 스케쥴된 빌드를 달력을 통해 모니터링 할 수 있다.   

44.  SMTP 서버 설정통보 그룹 관리단계(프로젝트 시작/완료/실패, 빌드 성공/실패) 별 통보 설정 및 프로젝트에 통보 그룹 지정 통보 템블릿 관리    빌드 Notification 기능 BuildForge는 e-Mail 통보 기능을 지원하며, 각각의 단계별로 지정된 그룹에게 통보할 수 있다.    

45. 빌드 권한 관리 및 SSO 지원 BuildForge는 Role-based 권한 관리를 기본으로 지원하며, LDAP과도 연동이 가능하다. 권한 관리 단위 • User(사용자) : 개별 사용자, 로그인 인증/이메일 통보/Access Group에 할당 • Access Group(액세스 그룹) : Permission에 지정되는 단위, User는 Access Group에 할당 되어야만 권한을 가질 수 있음 • Permissions(권한) : 시스템의 각 기능에 대한 권한, Access Group에만 할당 가능 • Ownership(소유권) : 자원(프로젝트/서버/단계 등)에 대한 소유권, 자원별 단일 Access Group만 지정 가능 권한 관리 • Role-based 시스템 • Access Group은 사용자가 조직에서 가지는 역할(Role)을 나타냄 • 역할(Role)별로 권한과 소유권을 가짐 • 사용자의 권한(Permission)은 사용자가 속해 있는 Access Group이 가지고 있는 권한의 합(Union)으로 결정 됨. • 권한과 소유권의 조합으로 어떠한 작업을 할 수 있는지 결정됨ex) 기존 빌드 프로젝트를 수정하기 위해서, 사용자는 해당 빌드 프로젝트에 대한 소유권과 ‘프로젝트 수정’권한을 가져야만 함 • Ownership(소유권) : 자원(프로젝트/서버/단계 등)에 대한 소유권, 자원별 단일 Access Group만 지정 가능 • SSO(Single Sign On)지원을 위해 BuildForge시스템과 LDAP을 연동 가능

46. 빌드 Repository 관리 BuildForge는 다양한 RDBMS를 이용하여, 빌드 프로젝트 설정 파일 관리, 빌드 별 로그관리 및 Archive 관리를 지원한다. 빌드 프로젝트 설정 파일 관리 • CheckPoints : 빌드 프로젝트의 설정 파일의 SnapShot을 저장하여, 빌드 설정 파일의 자체 버전 관리를 지원함 설정 파일의 CheckPoint들의 히스토리를 관리하여, 회귀 빌드 가능 • Import/Export 기능 : 빌드 프로젝트의 설정 파일을 export/import하여 버전 관리(파일 시스템 또는 외부 버전 관리 시스템 이용) 빌드 로그(이력) 관리 • 빌드 프로젝트 별 빌드 성공/실패 이력 관리 • 실패 빌드에 대해, 수동 빌드 재시작 가능 • 실패 빌드 프로젝트에 대해, 설정된 CheckPoint를 이용하여 회귀 빌드 가능 • 사용자별 이력 관리 : 사용자의 각 활동 메시지 로그 축적 빌드 Archive 관리 • 각 빌드 결과물은 Archive처리 됨 • 성공된 빌드에 대해 삭제 처리 가능 • 중요한 빌드 프로젝트의 경우 오류 방지를 위해 Locking 시킬 수 있음 • Archive된 빌드를 이용하여, 회귀 빌드 실행 가능

47. ClearCase BuildForge 자보_VOB Adaptor  \main 개 발 영 역 통합 영역 0 빌드를 위한 모니터링 View 자보_Dev 자보_Dev_Integration 0 0  빌드/릴리즈/배포 1 1 Baseline001 2 2 성공된 빌드를 CC에 반영하기 위한 View Baseline002 3  4   모니터링 View를 통해 ClearCase에 변경사항 발생 시, 자동으로 소스 가져오기 성공한 빌드의 경우, 자동으로 통합영역에 해당 소스를 Delivery 형상관리 시스템과의 연동 기능 BuildForge는 각종 SCM 툴(ClearCase, Perforce, CVS)과 Adaptor를 이용하여 연동할 수 있다. 특히 ClearCase의 경우에는 지정된 View의 변경을 감지하여, 자동으로 빌드 프로젝트를 시작시킬 수 있다.

48. ClearQuest 연동 ClearCase 연동 형상/변경 통합 화면 BuildForge에서 제공되는 형상/변경/빌드/배포 관리자용 통합화면으로서 형상대상의 Check In/Out 및 변경관리의 Defects 내역을 확인할 수 있다.

49. 빌드 프로젝트를 Browsing 빌드 프로젝트의 빌드 이력 Browsing 해당 빌드 이력에 대한 상세 정보 조회 Eclipse 및 RAD/RSA와의 연동 Eclipse에서 제공되는 형상/변경/빌드 개발자용 통합화면으로서 형상대상의 Check In/Out 후 빌드 및 빌드 Log를 확인할 수 있다.

50.  Build 스텝 관리오류내역소스 변경 리스트 Checkpoint 설정프로젝트 Baseline 설정          감사 및 추적 기능 BuildForge는 빌드 모듈의 구성 요소에 대한 Tracking기능을 위한 BOM(Bill Of Material)을 제공한다.