テストは不正行為、コンパイルは疑わしい

この記事では、継続的インテグレーション (CI) の概念、利点、欠点、およびデモンストレーション例について説明します。

歴史的レビュー

まず、その歴史を簡単に振り返ってみましょう。

1999 年、Kent Beck は、エクストリーム プログラミングに関する最初の著書でこのトピックを詳しく調査しました。 2001 年に、最初のオープンソース CI ツールの 1 つである CruiseControl が誕生しました。

CI を使用する理由

CI の目標は、コードがコミットされるたびに自動テストを実行することです。これにより、コードが常に機能し続けることが保証されます。コードが変更されるたびに、回帰の問題が発生していないことが確認されるため、これを継続的インテグレーションと呼びます。

メリット

• エラーを早期に発見: 問題は迅速に特定され、タイムリーな対応が可能になります。
• 品質の向上: 体系的なテストにより、より堅牢なコードが保証されます。
• 時間の節約: 自動化されたパイプラインにより、繰り返しの手動テストの必要性が軽減されます。

デメリット

• 初期コスト: CI のセットアップには、多額の初期投資と専門知識が必要となる場合があります。
• 実行時間: パイプラインが複雑な場合、開発者がコードを検証するのにかかる時間が長くなる可能性があります。

仕組み

その仕組みを理解する前に、いくつかの用語を理解しましょう:

• ジョブ: スクリプトの実行に使用されるコンテナー (通常は Docker) のインスタンス。これには、コマンド、テスト、またはエコーなどの単純な操作が含まれる場合があります。
• パイプライン: 順番に、または並行して編成された一連のジョブ。コミットごとに、変更を検証するためにこの一連のアクションがトリガーされます。

原理は単純です。各ジョブはステータス コード (成功または失敗) を返します。ジョブが失敗した場合、パイプラインは構成に応じて停止するか、後続のステップをスキップします。

実践ドリル

GitLab CI ベースの例を使用します。 .gitlab-ci.yml ファイルを通じて設定できます。

基本的な例

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

コンパイルフラグ

コンパイル フラグを追加するには、2 つの方法があります:

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>

テストカバレッジ

テスト カバレッジは、gcovr や Cobertura などのツールを CI パイプラインに統合することで測定できます。

<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 中国語 Web サイトの他の関連記事を参照してください。