'전체 글'에 해당되는 글 1243건

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도 포함 예정 )에 대한 지원도 없앨 예정이라고 함.
      

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