테스트는 부정행위이고, 컴파일은 의심이다

이 기사에서는 CI(지속적 통합)의 개념, 장점, 단점 및 시연 사례를 살펴봅니다.

역사적 검토

먼저, 역사를 간략히 살펴보겠습니다.

1999년 Kent Beck은 익스트림 프로그래밍에 관한 첫 번째 저서에서 이 주제를 심도 있게 탐구했습니다. 2001년 최초의 오픈 소스 CI 도구 중 하나인 CruiseControl이 탄생했습니다.

CI를 사용하는 이유는 무엇인가요?

CI의 목표는 모든 코드 커밋 후에 자동화된 테스트를 실행하는 것입니다. 이렇게 하면 코드가 항상 기능적으로 유지됩니다. 코드가 수정될 때마다 회귀 문제가 발생하지 않는지 확인하기 때문에 이를 지속적 통합이라고 부릅니다.

장점

• 오류 조기 발견: 문제를 신속하게 식별하여 적시에 대응할 수 있습니다.
• 품질 향상: 체계적인 테스트를 통해 더욱 강력한 코드가 보장됩니다.
• 시간 절약: 자동화된 파이프라인은 반복적인 수동 테스트의 필요성을 줄여줍니다.

단점

• 초기 비용: CI 설정에는 상당한 초기 투자와 전문 지식이 필요할 수 있습니다.
• 실행 시간: 파이프라인이 복잡하면 개발자가 코드를 확인하는 데 걸리는 시간이 길어질 수 있습니다.

작동 방식

작동 방식을 이해하기 전에 몇 가지 용어를 알아보겠습니다.

• 작업: 스크립트를 실행하는 데 사용되는 컨테이너(일반적으로 Docker)의 인스턴스입니다. 여기에는 명령, 테스트 또는 에코와 같은 간단한 작업이 포함될 수 있습니다.
• 파이프라인: 순차적으로 또는 병렬로 구성된 일련의 작업입니다. 각 커밋은 변경 사항을 검증하기 위해 일련의 작업을 트리거합니다.

원칙은 간단합니다. 각 작업은 상태 코드(성공 또는 실패)를 반환합니다. 작업이 실패하면 파이프라인은 구성에 따라 후속 단계를 중지하거나 건너뜁니다.

실습

GitLab CI 기반 예제를 사용하겠습니다. .gitlab-ci.yml 파일을 통해 구성할 수 있습니다.

기본예

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

플래그 컴파일

컴파일 플래그를 추가하는 방법에는 두 가지가 있습니다.

1. Makefile의 규칙을 전달합니다.
2. CI 명령에 플래그를 직접 전달합니다.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

테스트 및 신고에 기준 사용

Criterion은 C 언어 단위 테스트 라이브러리입니다.

기준 설치

Criterion을 테스트하기 전에 Criterion을 설치해야 합니다.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

다단계 시공

단위 테스트와 기능 테스트를 여러 단계로 분할하여 다음을 수행할 수 있습니다.

• 더 잘 정리됨
• 더 나은 결과 보기

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

Clang을 사용하여 코드 형식 지정

깨끗한 코드 기반을 유지하려면 코드 형식이 중요합니다.

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

캐시

어떤 경우에는 파이프라인이 실행될 때마다 파일이나 폴더를 다시 로드하지 않도록 캐시하는 것이 유용합니다.

일반적인 예는 JavaScript의 node_modules/ 폴더입니다.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

물론 필요한 경우 파이프라인 구성의 추가 옵션을 사용하여 캐시를 지울 수 있습니다.

아티팩트

아티팩트는 여러 작업에서 공유하거나 다운로드할 수 있는 CI 생성 파일입니다.

예: 테스트 또는 보도 보고서.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

테스트 범위

CI 파이프라인에 gcovr 또는 Cobertura와 같은 도구를 통합하여 테스트 범위를 측정할 수 있습니다.

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

신고

이 코드 블록을 사용하면 적용 범위 보고를 병합 요청에 통합하여 적용되지 않은 코드와 적용 비율을 확인할 수 있습니다.

<code>clang_format:
  stage: format
  before_script:
    - apt-get -qq update && apt-get -qq install -y clang-format autotools-dev autoconf-archive gcovr libcriterion-dev
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror</code>

맞춤형 환경

특정 Docker 이미지를 선택하여 CI의 기본 환경을 지정할 수 있습니다.

<code>cache:
  paths:
    - node_modules/

install:
  script:
    - npm install</code>

위 내용을 결합하면 다음과 같은 예를 얻을 수 있습니다.

<code>artifacts:
  paths:
    - build/
    - reports/</code>

.h 파일과 before_script 파일이 누락되었습니다.

추가 보충제

정크 파일을 검사하여 make clean이 제대로 작동하는지 확인할 수도 있습니다.

<code>test-coverage:
  stage: test
  script:
    - gcovr --html --html-details -o coverage.html
  artifacts:
    paths:
      - coverage.html</code>

요약

지속적인 통합은 매우 강력한 도구입니다. 설정하기가 어려울 수 있지만 이점은 엄청납니다.

위 내용은 테스트는 부정행위이고, 컴파일은 의심이다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!