다음을 통해 공유


제어된 체크 인 빌드 프로세스를 사용하여 변경 내용 유효성 검사

빌드에 손상을 주는 변경 사항을 개발자가 체크 인하면 소규모 팀의 경우 상당한 혼란을 겪을 수 있으며, 규모가 큰 팀의 경우에는 생산성 손실, 일정 지연으로 인해 더 높은 비용을 감수해야 할 수도 있습니다. 제어된 체크 인 빌드 정의를 만들면 이러한 문제로부터 코드베이스 일부 또는 전부를 보호할 수 있습니다.

참고

제어된 체크 인 빌드는 TFVC 아이콘 TFVC 팀 프로젝트에서만 사용할 수 있습니다.Git 아이콘 Git 팀 프로젝트에서는 사용할 수 없습니다.

수행할 작업

  • 제어된 체크 인 빌드가 팀에 미치는 영향 이해

  • 제어된 체크 인 빌드 프로세스 정의

  • 빌드 프로세스의 기능 및 성능 향상을 위한 지침

  • 팀 차단 방지

  • 제어된 체크 인 빌드 및 개인 빌드 수동 실행

제어된 체크 인 빌드가 팀에 미치는 영향

팀에서 제어된 체크 인 빌드 프로세스를 적용할 경우 개발자가 제출하는 변경 내용은 보류 집합에 저장되어 자동으로 빌드되며 빌드 시스템에 의해 테스트될 수 있습니다.

제어된 체크 인 대화 상자

체크 인 프로세스는 이 빌드가 성공적이어야 완료될 수 있습니다. 자세한 내용은 제어된 체크 인 빌드에 의해 제어되는 보류 중인 변경 내용 체크 인을 참조하십시오.

제어된 체크 인을 우회해야 하는 사용자가 있을 경우 해당 사용자 그룹을 위해 빌드의 체크 인 유효성 검사 재정의 권한을 허용으로 설정할 수 있습니다. 자세한 내용은 Team Foundation Server에 대한 사용 권한 참조을 참조하십시오.

제어된 체크 인 빌드 프로세스 정의

  1. 팀 탐색기에서 팀 프로젝트에 연결되어 있는지 확인한 후(키보드: Ctrl+0, C) 빌드 페이지를 엽니다(키보드: Ctr +0, B).

  2. 새 빌드 정의 링크를 선택하거나 빌드를 선택하여 바로 가기 메뉴를 열고 빌드 정의 편집을 선택합니다.

    TF225001 오류 메시지가 나타나면 빌드 컨트롤러를 구성합니다.

  3. 트리거 탭에서

    • 제어된 체크 인을 선택합니다.

    • (선택 사항) 빌드 프로세스의 효율성을 높이려면 최대 n개의 제출 병합 및 빌드를 선택합니다. 자세한 내용은 팀 중단 방지를 참조하십시오.

  4. 보안 설정 탭의 작업 폴더 표에서 이 빌드 정의가 제어할 버전 제어 폴더를 빌드 에이전트의 로컬 폴더에 매핑합니다.

    다음 지침을 따릅니다.

    • 빌드 프로세스가 제대로 작동하도록 하고 성능을 향상시키려면 빌드 프로세스에 필요한 파일이 들어 있는 이러한 폴더만 모두 포함합니다.

    • 다른 제어된 체크 인 빌드 정의의 작업 영역 탭에도 지정된 버전 제어 폴더를 지정하지 않았는지 확인합니다.그렇지 않으면 사용자가 이러한 폴더에 파일을 체크 인할 경우 어느 빌드 정의를 큐에 대기시킬지 결정하라는 메시지가 나타납니다.

    • 매핑을 지정하는 방법에 대한 자세한 내용은 빌드 작업 영역 사용을 참조하십시오.

  5. 성능 향상을 위해 빌드 기본값 탭에서 이 빌드는 저장 폴더에 출력 파일을 복사하지 않음을 선택합니다.

  6. 프로젝트 매개변수의 빌드 아래 프로세스 탭에서 빌드하려는 솔루션이나 코드 프로젝트를 지정합니다.

  7. 프로세스 탭에서 개발자를 불필요하게 지연시키지 않고 체크 인이 팀에서 요구하는 특정 코드 품질 표준을 충족할 수 있도록 매개 변수를 설정합니다.

    자세한 내용은 이 항목 뒷부분의 빌드 프로세스 기능 및 성능 향상을 참조하십시오.

  8. 다른 탭에서 빌드 프로세스 옵션을 지정합니다. 자세한 내용은 빌드 정의 만들기 또는 편집을 참조하십시오.

빌드 프로세스의 기능 및 성능 향상

빌드를 처리하는 데 필요한 시간을 최소화하려면 프로세스 탭에서 빌드 프로세스 매개 변수의 값을 지정할 때 다음 지침을 고려해야 합니다.

TF 버전 제어 또는 Git

  • 작업 영역 정리 또는 리포지토리 정리: 성능 향상을 위해 이 값을 False로 설정합니다. 이렇게 설정하면 팀에서 리팩터링 중 추가된 일부 유형의 결함을 놓칠 수 있습니다.

Build

  • 구성: 이 매개 변수를 비워 두면 각 솔루션 및 프로젝트에 기본 플랫폼과 구성이 사용됩니다. 성능을 최적화하려면 다음 지침을 따르십시오.

    • 플랫폼-구성 쌍의 빌드 속도가 다른 쌍의 빌드 속도보다 더 빠른 경우 이 매개 변수에 플랫폼-구성 쌍을 지정합니다.

    • 플랫폼-구성 쌍은 가능한 한 적게 지정합니다.

  • 클린 빌드: 성능 향상을 위해 이 매개 변수를 False로 설정합니다. 이렇게 설정하면 팀에서 리팩터링 중 추가된 일부 유형의 결함을 놓칠 수 있습니다.

빌드, 고급

  • 코드 분석 수행: 성능 향상을 위해 이 값을 사용 안 함으로 설정합니다.

테스트, 고급

  • 테스트를 사용하지 않도록 설정:

    • 성능 향상을 위해 True를 선택합니다.

    • 코드가 특정 테스트를 통과해야 하는 경우 False를 선택한 다음 빌드에서 실행할 테스트 집합을 정의합니다. 필요한 테스트만 실행하여 성능을 향상시킬 수 있습니다. 테스트를 지정하려면 범주 또는 우선 순위를 기준으로 필터링합니다. 자세한 내용은 빌드 프로세스에서 테스트 실행을 참조하십시오.

기호 게시

  • 기호를 게시할 경로: 성능 향상을 위해 이 값을 비워 둡니다.

고급

  • 에이전트 설정

    • 이름 필터 또는 태그 필터: 이 빌드를 실행하도록 특별히 지정된 빌드 에이전트에 이 빌드 정의를 바인딩하는 데 빌드 에이전트 이름 또는 태그를 사용합니다. 이 빌드 에이전트는 팀의 성능 기대치를 충족할 수 있도록 이 빌드를 빠르게 처리하는 강력한 하드웨어에서 실행되어야 합니다.

      예를 들어, 빌드가 완료될 때까지 15분을 기다려도 사용자와 사용자 팀은 개의치 않을 수 있습니다. 코드가 성공적으로 체크 인되었는지 확인할 수 있을 때까지 8시간을 기다려야 하는 상황은 받아들이지 않을 것입니다.

    • 최대 실행 시간: 이 값을 합리적인 수준의 작은 숫자로 설정합니다. 예를 들어 팀에게 15분은 적당하지만 8시간은 너무 길 수 있습니다.

기본 템플릿 빌드 프로세스 매개 변수에 대한 자세한 내용은 빌드 프로세스에 기본 템플릿 사용를 참조하십시오.

팀 차단 방지

각 제어된 체크 인 빌드 정의에서는 실행 중인 빌드가 한 번에 하나만 있을 수 있습니다. 따라서 규모가 크고 작업이 활발한 팀에서는 제어된 체크 인 빌드의 대형 큐를 개발할 가능성이 높습니다. 다음의 모범 사례를 따르면 팀의 작업 진행이 중단되는 것을 방지하는 데 유용합니다.

  • 트리거 탭에서 빌드 프로세스의 효율성을 늘리려면 최대 n개의 제출 병합 및 빌드 옵션을 선택하고 지정된 배치에서 함께 빌드하려는 최대 체크 인 수를 지정합니다. 일반적으로 이 옵션을 사용할 경우 많은 중단의 위험이 없습니다. 각 체크 인은 개별적으로 커밋되거나 거부됩니다.

    예를 들어, 일괄 처리에서 함께 빌드된 세 가지 체크 인이 빌드에 성공하지 못했다면 세 체크 인의 개별 빌드가 큐에 대기됩니다.

    그러나, 이 옵션에서는 하나의 체크 인이 다른 사용자를 방해할 수 있는 위험이 있습니다. 예를 들어, 여러 체크 인이 같은 파일을 수정할 때 버전 제어 충돌이 발생하는 경우가 있습니다. 이 경우 이전 체크 인은 커밋되고 이후의 체크 인은 거부됩니다.

  • 빌드 에이전트에서 체크 인되는 코드의 품질을 확인하는 데 필요한 작업만 수행하도록 빌드를 정의합니다. 자세한 내용은 이 항목 앞부분의 프로세스 탭의 설정에 대한 지침을 참조하십시오.

  • 강력한 하드웨어(예: 고속 프로세서 및 고속 하드 디스크)가 있는 빌드 컴퓨터를 제어된 체크 인 빌드 정의에서 사용하는 빌드 에이전트 전용으로 설정합니다.

제어된 체크 인 빌드 및 개인 빌드 수동 실행

변경 내용을 보다 확실하게 체크 인하려는 개발자는 보류 집합의 빌드를 수동으로 큐에 대기시킬 수 있습니다. 이 방법을 사용할 때는 빌드가 성공할 경우 시스템에서 다음에 수행될 작업에 대한 두 가지 옵션 중 하나를 지정할 수 있습니다.

  • 컴퓨터에서 변경 내용 체크 인(수동으로 제어된 체크 인 빌드): 제어된 체크 인이 필요하지 않지만 개발자가 체크 인 전에 코드의 유효성을 자발적으로 검사할 수 있도록 하는 팀에서 이 옵션을 사용하면 편리합니다.

  • 컴퓨터에서 변경 내용 체크 인 안 함(개인 빌드): 보류 집합에 있는 일부 변경 내용의 유효성만 검사하고 변경 내용을 체크 인하지 않으려는 개발자는 이 옵션을 사용할 수 있습니다.

자세한 내용은 큐에 빌드 대기시키기을 참조하십시오.