CI/CD は、確立されたソフトウェア開発の定説です。インターネットには、CI/CD に関する記事やページが溢れています。これらは常に同じ イメージを持ちます。私が話しているイメージはご存知かと思います。 CI/CD 私はこのトピックに関する数十の記事を読み、エンドツーエンドの CI/CD パイプラインの実装を経験しました。実際には、  の実装は、記事を読み、CI/CD の全体像を理解し、理論を使用するよりもはるかに複雑です。 CI/CD パイプラインの開発には、学際的な経験豊富なチームが必要です。 CI/CD パイプライン この記事では、Python アプリケーションの最小限の実行可能な CI パイプラインを構築する方法について説明します。記事のコンテンツを他の言語や要件に適応させることができます。このサンプルでは、FastAPI と GitHub Actions を使用します。  GitHub の例:  https://github.com/joan-mido-qa/continuous-integration-example  CI: 継続的インテグレーション 既存の継続的インテグレーションの説明に 2 セント追加させてください。継続的インテグレーションとは、自動的にテストされ、承認され、提供可能なコードの変更をプロジェクト リポジトリに定期的にマージすることを意味します。 この例では、  を使用して、各「Pull Request」または「Push to Main」イベントで必要なチェックを自動的に実行し、コードがリポジトリの品質基準に準拠していることを保証します。市場には、   、   、   、 GitLab など、さまざまな CI/CD ツールのコレクションが提供されています。パイプラインの要件に最も適したものを選択してください。 GitHub Actions Jenkins Travis CircleCI ワークフロー例では、新しいコードが を実行する書式設定ルールに従っていることを確認します。次に、  を使用して小規模なテストを実行し、最後にアプリケーション を  D クラスターにインストールする中規模なテストを実行します。 pre-commit Pytest Helm Chart Kin 継続的インテグレーションのワークフローは、チームの規模、成熟度、アプリケーション要件、分岐戦略によって異なります。 静的コード分析 コードの変更を実行せずに分析します。静的分析ツールは、コードが書式ルールに従っていること、非推奨または破損した依存関係を使用していないこと、および読みやすく十分に単純であることをチェックします。また、プログラミング言語に応じてアンチパターンやバグをコーディングすることも提案しています。  Pre-commit のインストール、設定、実行方法を説明します。 Pre-commit を や などの他の分析ツールと組み合わせることができます。 Sonar Synk 事前コミット は Python で書かれたツールです。リポジトリ上でこれを構成するには、YAML ファイルを作成し、各コミット前に実行するバージョン管理されたフックを追加するのと同じくらい簡単です。プリコミットは、フックに必要な依存関係を自動的に管理し、見つかったエラーを自動修正します。複数のファイルタイプをサポートしています: JSON、YAML、tf、py、ts など。 Pre-commit コードチェックをプッシュする前にローカルで実行することで、インフラストラクチャのコストを節約します。 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  Python フックの提案:    Python の静的型チェッカー Mypy:  Python 用の静的フォーマット チェッカー Ruff:  Python のコーディングのベスト プラクティスを提案する 改修: 標準コミットの使用とバージョン管理を保証します。 Commitizen: テスト 単体テスト、統合テスト、およびエンドツーエンドのテストの定義と範囲は、分散している場合があります。継続的インテグレーションの説明で行ったように、  テスト タイプに 2 セントを追加します。 Google のソフトウェア エンジニアリングの : テストが高速です。小さなコード部分をテストします。テストダブルまたはモック環境 (SQLite など) を使用します。アーティファクトを構築する必要はありません。時間: ~ 60 秒。 小 : 複数のコード間の相互作用をテストします。これには、アーティファクトの構築、サードパーティのアーティファクト ( など) の使用、ローカルホスト ネットワークへの接続が含まれる場合があります。偽の環境 (docker-compose、Kind、Minikube など) または外部サービス (Azure Blob Storage や AWS S3 など) の使用。時間: ~ 300 秒。 中 データベース : 運用環境に似た環境 (パフォーマンス テストなど) を使用します。時間: + 900 秒。 大 継続的インテグレーション パイプラインに中規模/大規模のテストがあるかどうかは、要件によって異なります。 小さい この例では、Pytest を使用してテストを実行し、FastAPI テスト クライアントを使用して環境を模擬します。秘密はありません。プログラミング言語テスト ツールは、アプリケーションをテストするために必要な依存関係をすべて提供する必要があります。 さらに、最小限のテスト カバレッジ チェックを追加し、結果の一部としてアップロードすることができます。テストカバレッジは扱いにくい指標です。高いテスト カバレッジは、コードが十分にテストされていることを暗黙的に意味するわけではありませんが、50% は 0% テストされたコードよりも大きいことになります。 中くらい  D は、ローカル開発または CI に使用される docker-in-docker の軽量 Kubernetes クラスターです。 Kind を使用してテスト環境をセットアップし、それに対してテストを実行します。 Kin  Kind クラスターを作成する Docker イメージを構築する Docker イメージを Kind にロードする MetalLB をインストールし、必要な CDR を適用します。  Ingress-Nginx をインストールする Helm チャートをインストールする OSホストをセットアップする Docker イメージをロードする イメージはレジストリからダウンロードできないため、Kind はイメージをダウンロードできません。 Kind では、使用する前に画像をロードする必要があります。 メタルLB   は、ベアメタル Kubernetes ロードバランサーです。ロード バランサが必要な理由について詳しくは、   Web ページをご覧ください。 MetalLB MetalLB  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 構成の詳細については、   Web ページを参照してください。 KinD アプリケーションを公開する Ingress-Nginx Helm Chart をインストールします。次に、アプリケーション Helm Chart をインストールし、Ingress オブジェクトを定義します。 ingressClassName プロパティを nginx に設定し、ホスト (例: api.local) を定義します。最後に、  変更して次の行を追加します。 /etc/host を  192.168.1.10 api.local 同じアドレスを指すホストを必要な数だけ定義できます。残りはNginxがやってくれます。  Kind を使用してローカル環境を起動、更新、削除するツールを開発します。開発者はこれを使用して、アプリケーションを簡単にデバッグしたり、報告されたバグをローカルで再現したり、CI でテストを実行したりできます。 この例は、Linux ベースのディストリビューションで動作します。 Windows/MacOSの場合はそのままでは動作しない場合があり、変更が必要になる場合があります。 配達 必要なアーティファクトを配信する前に、ワークフローはリンティングとテストのステップを実行します。 私たちは を使用してアーティファクトのリリースを管理します。 Commtizen はアーティファクトのバージョンを自動的に更新し、変更をプッシュします。構成されたタグ形式で新しい git タグが作成されます。最新の変更で変更ログを更新するように Commtizen を構成することもできます。 Commitizen   [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] 近日公開予定 …

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

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

About Author

コメント

ラベル

この記事は

Related Stories

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps

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