CI/CDを効率的に実装する方法

CI/CDを採用して、Harnessで組織の効率とデリバリーパイプラインを改善する方法を探ってみましょう。

DevOpsの人気は、ソフトウェア開発チームの間で高まり続けています。合理化されたワークフローにより、リリース頻度と展開サイクルが短縮され、バグの検出が迅速になり、エラーが発生した場合の効率的なロールバックが可能になり、チーム全体の生産性が向上します。DevOpsエンジニアは、コードの開発、テスト、リリースの各プロセスと実践が合理化され、非効率性、リスク、市場投入までの時間を確実に減らせるようになります。DevOpsをContinuous Integration（CI）とContinuous Delivery（CD）に組み合わせると、IT組織は、コードのデプイに関連する手作業を自動化して開発プロセスを合理化できます。組織の効率と配信パイプラインを改善するためにCI/CDを採用する方法を探ってみましょう。

Continuous Integration（継続的インテグレーション）

 まず、CI/CDとは何か、その利点は何かを見てみましょう。これらの２つの概念は一緒に説明されることがよくありますが、ソフトウェア開発プロセスではそれぞれに独自の役割があります。

継続的インテグレーションは、コードのビルドとテストを自動化するプロセスです。これには、SaaSビルドサービス（Harness Hosted Buildsなど）やソース管理システム（Gitなど）からコードを取得してコンパイルし、エラーがないことを確認するためのテストを行うオンプレミスのビルド用サーバーが必要です。これによって、エラーやミスやバグが発生するとすぐに発見されるようになり、ソフトウェアプロジェクトを順調に進められます。ビルドが壊れている場合は、修正されるまで残りのプロセスが停止します。その結果、ビルドプロセスが大幅に合理化されます。

Continuous Delivery & Deployment（継続的デリバリーとデプロイメント）

継続的デリバリーにより、リリースプロセスが自動化されます。コードが常にリリース可能な状態であることを保証します。このプロセスには、ビルドシステムからコードを取得し、ステージング環境を介してそれをルーティングして、リリースに適していることを確認することが含まれます。その結果、完全に自動化されたデプロイプロセスが実現します。これは、チームによって制御されるか、チーム外のトリガー（開発者がメインブランチにコードをプッシュまたはコミットするときなど）によってトリガーされます。CIとCDの大きな違いは、前者はコードの構築に重点を置いているのに対し、後者は最終製品のリリースに重点を置いていることです。

次の図は、CI/CDと継続的デプロイの違いを示しています。

継続的デプロイは、CI/CDプロセスの最終段階であり、最もわくわくする段階です。これは、チームがゼロタッチの自動化でコードをデプロイできるポイントです。これが、継続的デリバリーとデプロイメントの違いです。コードのデプロイが手動の介入によって行われる場合、それは配信となります。ただし、コードが手動の介入なしで自動化された方法で展開される場合、それは継続的デプロイメントと呼ばれます。

組織にCI/CDを実装する方法

組織にCI/CDを実装する前に、それを実装する理由、目標、どの指標に注目するかを理解する必要があります。例えば、DevOpsチームは通常、次の４つの主要な（DORA）メトリックに焦点を当てています。

• 変更のリードタイム
• 変更の失敗率
• デプロイメントの頻度
• 回復までの平均時間

CI/CDの目標が、従来のソフトウェアデリバリープラクティスからクラウドネイティブのプラクティスに移行するのと同じくらい簡単な場合もあります。このように、DevOpsの概念の基本を理解することが非常に重要になります。

まだ基本ができていない場合は、バージョン管理システムを採用し、ビルドシステムを実装し、ステージング環境を導入する必要があるかもしれません。これらの基本が整ったら、CI/CDプロセスを始められます：

• まず、CIから始めます。このプロセスにより、コードがテストされ、クリーンでデプロイの準備が整っていることが保証されます。
• その後にCDのパートに進むことができます。ここでは、コードをステージングにデプロイして、チームによるレビューの準備を整えられます。
• 全てが承認されたら、コードを本番環境にデプロイできます。

次に、さまざまなCI/CDツールを評価して、組織に最適なものがどれかを理解する必要があります。残念ながら世の中には、圧倒されるような数のツールがあります。この記事では、有名なCI/CDツールであるHarnessを使って、単純なhello worldアプリケーションでCI/CDがどう機能するかを説明します。CI/CDパイプラインが十分に確立されていると、チームは改善が必要な領域を特定し、システムに存在する可能性のあるリスクを軽減するための措置を講じることも容易になります。また、チームが成長し、時間の経過とともに変化するにつれて、プロセスの変更を実装することも容易になります。

Harness CI/CDチュートリアル

このチュートリアルでは、Harnessを使ってCI/CDパイプラインを作ることにのみ焦点を当てます。私たちはGitOpsの大ファンでもあり、デプロイを高速化するためにHarnessでGitOps-as-a-serviceを利用できるようにします。

CI/CDパイプラインを採用しているソフトウェア開発チームは、リスクを無視できる程度に抑えられ、バグの特定と修正を迅速に行い、ソフトウェアのデプロイを高速化できます。CI/CDを初めて使うときは、習得すべき新しい用語やプロセスが圧倒的に多いように思えるかもしれません。でもCI/CDパイプラインの設定は思ったより簡単です。

CI/CDパイプラインは、ソフトウェアの問題がエンドユーザーに届く前に、問題が発生しそうな場所をチームが特定するのに役立ちます。さらに、アップデートをより頻繁にリリースできるようになり、ユーザーにリリースする前に個々のコンポーネントまたはモジュールをテストする時間を短縮できます。Harnessは、非の打ちどころのない機能を備えたCI/CDのリーダーです。今日は、簡単なセットアップで数分でCI/CDを実装する方法を紹介します。

前提条件

• （オンプレミスで）CI/CDを行うための無料のHarnessアカウント
• アプリケーションをデプロイするための任意のクラウドプロバイダーからのKubernetesクラスターにアクセスできること（MinikubeまたはKindを使って単一ノードクラスターを作ることもできます）。
• Docker、できればDocker Desktop
• Node.jsをダウンロードしてインストールしてあること

まず、簡単なテストケースを使ってNode.jsのアプリケーションの中に単純な「Hello World!」を作ります。シンプルにするために、この単純な「Hello World!」アプリケーションは既に作成済みであり、それをGitHubにプッシュしておきました。このリポジトリーをフォークして作業を開始できます。

リポジトリーに表示されるDockerfileを使ってアプリケーションをビルドし、イメージとしてDocker Hubにプッシュします。次に、イメージをビルドし、コマンドを使ってDocker Hubにプッシュします。 

docker buildx build --platform=linux/arm64 --platform=linux/amd64 -t docker.io//: --push -f ./Dockerfile 

ビルドとプッシュが成功したら、Docker Hubアカウントに移動して確認できます。

フォークされたリポジトリーにdeployment.yamlファイルが表示されます。このファイルには、アプリケーションをKubernetesクラスターにデプロイするのに役立つデプロイメントyamlファイルが定義されています。この時点で、Kubernetesクラスターが稼働中であることを確認してください。

全ての設定が完了したら、CI/CDを実行するためのHarnessアカウントを設定します。無料のHarnessアカウントと最初のプロジェクトを作成します。Harnessにサインアップすると、新しいCI/CDエクスペリエンスと機能が提供されます。

必要なコネクター、GitHubリポジトリー、Docker Hub、シークレットがあれば追加します。Delegate in Harnessは、アーティファクト、インフラ、コラボレーション、検証、その他のプロバイダーをHarness Managerに接続するために、ターゲットクラスター（この場合はKubernetesクラスター）にインストール/実行する必要があるサービス／ソフトウェアです。Harnessを初めてセットアップするときは、Harness Delegateをインストールします。

以下に示すようにContinuous Integrationモジュールを選択し、必要なステージとステップを追加します。

Testステップのセットアップは次のように行われます：

「Push to Docker Registry」の手順は以下の通りです：

次に、デプロイパイプラインを設定します。

「Service」タブに必要な詳細を追加します。

「Environment」タブで環境タイプを定義します。

好みのデプロイメントを選択して、実行の戦略を決めます。

全て保存し、パイプラインを実行します。

CIとCDの両方が、指定された全ステップで１つずつ実行されていることが分かります。

おめでとうございます！Harnessプラットフォームを使い、アプリケーションのコードを正常に構築・テストし、Kubernetesクラスターにデプロイしました。

kubectl get podsコマンドを使って、このデプロイを確認できます。

deployment.yamlファイルで私たちが指定した仕様に沿って実行されている２つのレプリカを確認できます。

また、Kubernetesダッシュボードに移動して同じことを確認してください。Googleクラウド（GCP）を利用しているため、２つのポッドが稼働していることを確認できます。

Harnessプラットフォームにより、開発者は利用可能なさまざまなモジュールを活用してSDLCを簡単に合理化できます。今日はCIとCDモジュールを紹介しましたが、Harnessには現在、合計７つのモジュールがあります。

CCI/CDとDevOps

CI/CDは、あらゆるDevOps戦略に不可欠なものです。コードのレビューとテストのプロセスを自動化するのに役立ち、チームがソフトウェアをテストしてデプロイしやすくなります。また、継続的な改善の文化を作る上で重要な部分でもあります。CI/CDは特効薬ではないことを覚えておくことも重要です。DevOpsの文化と方法論を確立することが最初のステップです。DevOpsでのこれらのプロセスと方法論は不変なものではないことを覚えておくことも重要です。それらは常に進化しており、チームのニーズを満たすために必要に応じて微調整する必要があります。

Harnessとインテリジェントなソフトウェアデリバリーの使い方について詳しく知りたい場合は、無料で試してみてください。詳細なチュートリアル、ビデオ、リファレンスドキュメントについては、Developer Hubをチェックしてください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。