CI/CD ハンズオン: シンプルだが機能的な継続的インテグレーション ワークフロー [パート 1]

CI/CD は、確立されたソフトウェア開発の定説です。インターネットには、CI/CD に関する記事やページが溢れています。これらは常に同じCI/CDイメージを持ちます。私が話しているイメージはご存知かと思います。

私はこのトピックに関する数十の記事を読み、エンドツーエンドの CI/CD パイプラインの実装を経験しました。実際には、 CI/CD パイプラインの実装は、記事を読み、CI/CD の全体像を理解し、理論を使用するよりもはるかに複雑です。 CI/CD パイプラインの開発には、学際的な経験豊富なチームが必要です。

この記事では、Python アプリケーションの最小限の実行可能な CI パイプラインを構築する方法について説明します。記事のコンテンツを他の言語や要件に適応させることができます。このサンプルでは、FastAPI と GitHub Actions を使用します。

CI: 継続的インテグレーション

既存の継続的インテグレーションの説明に 2 セント追加させてください。継続的インテグレーションとは、自動的にテストされ、承認され、提供可能なコードの変更をプロジェクト リポジトリに定期的にマージすることを意味します。

この例では、 GitHub Actionsを使用して、各「Pull Request」または「Push to Main」イベントで必要なチェックを自動的に実行し、コードがリポジトリの品質基準に準拠していることを保証します。市場には、 Jenkins 、 Travis 、 CircleCI 、 GitLab など、さまざまな CI/CD ツールのコレクションが提供されています。パイプラインの要件に最も適したものを選択してください。

ワークフロー例では、新しいコードがpre-commitを実行する書式設定ルールに従っていることを確認します。次に、 Pytestを使用して小規模なテストを実行し、最後にアプリケーションHelm ChartをKin D クラスターにインストールする中規模なテストを実行します。

継続的インテグレーションのワークフローは、チームの規模、成熟度、アプリケーション要件、分岐戦略によって異なります。

静的コード分析

コードの変更を実行せずに分析します。静的分析ツールは、コードが書式ルールに従っていること、非推奨または破損した依存関係を使用していないこと、および読みやすく十分に単純であることをチェックします。また、プログラミング言語に応じてアンチパターンやバグをコーディングすることも提案しています。

Pre-commit のインストール、設定、実行方法を説明します。 Pre-commit をSonarやSynkなどの他の分析ツールと組み合わせることができます。

事前コミット

Pre-commitは Python で書かれたツールです。リポジトリ上でこれを構成するには、YAML ファイルを作成し、各コミット前に実行するバージョン管理されたフックを追加するのと同じくらい簡単です。プリコミットは、フックに必要な依存関係を自動的に管理し、見つかったエラーを自動修正します。複数のファイルタイプをサポートしています: JSON、YAML、tf、py、ts など。

コードチェックをプッシュする前にローカルで実行することで、インフラストラクチャのコストを節約します。 CI で Pre-commit を実行して、プッシュされたコードの形式を確認できます。

Pre-commit ツールをインストール、構成、実行します。

 repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace

 $ pip install pre-commit $ pre-commit install $ pre-commit run --all-files

テスト

単体テスト、統合テスト、およびエンドツーエンドのテストの定義と範囲は、分散している場合があります。継続的インテグレーションの説明で行ったように、 Google のソフトウェア エンジニアリングのテスト タイプに 2 セントを追加します。

• 小: テストが高速です。小さなコード部分をテストします。テストダブルまたはモック環境 (SQLite など) を使用します。アーティファクトを構築する必要はありません。時間: ~ 60 秒。

• 中: 複数のコード間の相互作用をテストします。これには、アーティファクトの構築、サードパーティのアーティファクト (データベースなど) の使用、ローカルホスト ネットワークへの接続が含まれる場合があります。偽の環境 (docker-compose、Kind、Minikube など) または外部サービス (Azure Blob Storage や AWS S3 など) の使用。時間: ~ 300 秒。

• 大: 運用環境に似た環境 (パフォーマンス テストなど) を使用します。時間: + 900 秒。

  
  

継続的インテグレーション パイプラインに中規模/大規模のテストがあるかどうかは、要件によって異なります。

小さい

この例では、Pytest を使用してテストを実行し、FastAPI テスト クライアントを使用して環境を模擬します。秘密はありません。プログラミング言語テスト ツールは、アプリケーションをテストするために必要な依存関係をすべて提供する必要があります。

さらに、最小限のテスト カバレッジ チェックを追加し、結果の一部としてアップロードすることができます。テストカバレッジは扱いにくい指標です。高いテスト カバレッジは、コードが十分にテストされていることを暗黙的に意味するわけではありませんが、50% は 0% テストされたコードよりも大きいことになります。

中くらい

Kin D は、ローカル開発または CI に使用される docker-in-docker の軽量 Kubernetes クラスターです。 Kind を使用してテスト環境をセットアップし、それに対してテストを実行します。

1. Kind クラスターを作成する
2. Docker イメージを構築する
3. Docker イメージを Kind にロードする
4. MetalLB をインストールし、必要な CDR を適用します。
5. Ingress-Nginx をインストールする
6. Helm チャートをインストールする
7. OSホストをセットアップする

Docker イメージをロードする

イメージはレジストリからダウンロードできないため、Kind はイメージをダウンロードできません。 Kind では、使用する前に画像をロードする必要があります。

メタルLB

MetalLBは、ベアメタル Kubernetes ロードバランサーです。ロード バランサが必要な理由について詳しくは、 MetalLB Web ページをご覧ください。

Helm Chart を使用してインストールしたら、必要な CRD を作成できます。

 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"

Docker は、Kind クラスターのサブネット (例: 172.26.0.0/16) を作成します。 Kind ネットワーク インターフェイスを調べて、割り当てられた IP アドレス範囲を確認し、そのアドレスを IPAddressPool リソースの値として使用します。 MetalLB 構成の詳細については、 KinD Web ページを参照してください。

アプリケーションを公開する

Ingress-Nginx Helm Chart をインストールします。次に、アプリケーション Helm Chart をインストールし、Ingress オブジェクトを定義します。 ingressClassName プロパティを nginx に設定し、ホスト (例: api.local) を定義します。最後に、 /etc/host を変更して次の行を追加します。

 192.168.1.10 api.local

同じアドレスを指すホストを必要な数だけ定義できます。残りはNginxがやってくれます。

配達

必要なアーティファクトを配信する前に、ワークフローはリンティングとテストのステップを実行します。

私たちはCommitizenを使用してアーティファクトのリリースを管理します。 Commtizen はアーティファクトのバージョンを自動的に更新し、変更をプッシュします。構成されたタグ形式で新しい git タグが作成されます。最新の変更で変更ログを更新するように Commtizen を構成することもできます。

 [tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]

ワークフローは Commitizen 出力バージョンを使用して Docker イメージと Helm Chart タグを設定します。

結論

この記事では、シンプルだが機能的な継続的インテグレーションのワークフローを概略的に説明します。他のプログラミング言語で機能したり、要件に合わせたりするには変更が必要になる場合がありますが、一部のステップは簡単にエクスポートでき、そのまま機能するはずです。

CI/CD ハンズオン: 継続的デプロイメント [パート 2] 近日公開予定 …