2022年3月14日
Continuous Delivery
Harness社がHarness CDをどのように使っているか
社内実践の醍醐味：Harness社がHarness CDをどう使っているか紹介します。CIとCDのセットアップ、そしてなぜCDにこれほどまでに投資しているのか、その全てをご紹介します。
継続的デリバリー（CD）とは、ソフトウェア開発プロセスにおいて、あらゆる種類の変更の構築、テスト、設定、およびデプロイメントを行うことです。これには、新機能、設定変更、バグ修正、実験などが含まれます。さらに、これらは開発者のワークステーションから、複数の非本番環境を経て、最終的に組織の本番環境まで、継続的な方法で行われます。 今回は、CDとは何か、Harness社がHarness CDをどのように使っているかを探ります。 そうなんです、Harnessではシャンパンを自分たちで飲んでいるんです。では、その方法をご紹介しましょう。
継続的デリバリーに関わる主な構成要素とは
CDに関わる部品はたくさんあります。その中でも主なものを４つ紹介します。
- 継続的インテグレーション（CI）。CDプロセスの最初のステップはCIです。開発者のワークステーションで開発されたコードは、バージョン管理リポジトリーに継続的にコミットされ、パイプライン全体を自動的に行き渡ります。
- 非本番環境（NPE）。NPEは、社内の従業員とベータユーザーのみがアクセスできるように設定された環境です。多次元にわたるあらゆる種類のテストが、顧客ロールアウトの前にこれらの環境で行われます。パイプラインの各環境は、より会社の本番環境に近くなるようにする必要があることに注意してください。
- 分岐の戦略。CDは、新しい変更をバージョン管理システム（VCS）に取り込むのと同じくらい良いものです。異なるチームが、ブランチにプッシュしたり、安定したブランチをローカルにプルして開発を開始するなどの操作をスムーズに行えるようにする必要があります。
- フィードバックのループ。ソフトウェア開発パイプラインの各ステップ／ステージには、各ステップ／ステージの結果を示すフィードバックループが必要です。
HarnessがHarnessCDをどのように使っているか
他の人が 体験していることをどうしたら体験できるでしょうか。「相手の身になって考えなければ体験できない」です。 顧客が体験していることを体験するためには、まず自身が顧客となって、顧客に期待しているように自ら製品を使うことです。
Harnessでは、Harness製品を使用して、全ての環境（pre-QA、QA、Stage、Prod）でHarnessを構築、テスト、デプロイしています。基本的に私たちはリアルタイムシナリオで製品がどのように機能しているかを確認するために、自社でドッグフーディングしています。
以下は、Harnessサービスを構築、テスト、デプロイするためにHarnessが社内で設定しているワークフローと環境です。
CIセットアップ
プルリクエストのワークフロー。これがCDの始まりです。各開発者は自分のワークステーションでそれぞれのローカルブランチ内でコードを開発し、その変更をGitHubにプッシュし、GitHubで開発ブランチに対するプルリクエストを作成します。Harnessでは、GitHubとHarness CIEはGitHub Connectorを使って統合し、developブランチに対して作成されたPRリクエストに対して、複数のチェックが実行されるよう設定されています。
PRが発生するとすぐに、Harness CIEで一連のジョブ／パイプラインが 実行され、GitHubにステータスが報告されます。全てのジョブ／パイプラインが正常に実行された場合、GitHubはPRをグリーンとしてマークし、PRはdevelopブランチにマージする準備が整ったことになります。
CDセットアップ
PR Env（プルリクエスト環境）：Harness CDはサービスを最適な方 法でKubernetesにデプロイします。babysitが最小限であることは、デプロイも迅速に行えることを意味します。そのため、developブランチへのコードマージ／プルリクエストの一環として、開発者はHarness CIEを使用してサービスをDockerイメージにビルドし、プルリクエスト環境のセットアップを使用します。これはGKEクラスターで、開発者が個人レベルでテストの一環として個々のサービスをデプロイするものです。
これは、Google Kubernetesクラスタにサービスをテストしてデプロイするために行われます。プルリクエスト環境でテストされた後、開発者はコードをdevelopブランチに、サービスで使用される設定を設定リポジトリーにプッシュします。
非本番環境
PRE-QA
プルリクエスト環境でサービスがテストされると、設定リポジトリーにあるmasterブランチから設定が変更されます。次に、PRE-QA環境に適用され、６〜８時間ごとに異なるチームのサービスがデプロイされます。さらに、この環境に対して自動化スイートが実行され、結果が生成され、それに応じてさまざまなslackチャンネルに公開されます。
QA
これは、Harness CDを使用してセットアップされた別の環境で、より積極的な自動化スイートを実行します。さらに、この環境ではストレステストも行われます。この環境は本番環境とほぼ同じで、セットアップ全体を多面的にテストし、全てがうまく機能すること、セキュリティー脆弱性がないこと、バイナリーが複数の状況下で安定していることを確認します。
STAGE
これは、SaaS版のHarnessアプリケーションとは異なり、オンプレミスでのセットアップ版です。この環境には、HarnessサービスをQA環境と本番環境にデプロイするための複数のデプロイメントパイプラインが含まれています。この環境にはRBACが適用されており、関係者以外の人はデプロイメントパイプラインにアクセスできないようになっています。
HarnessがCDへの投資を増やす理由
CDは、何が本当に行われ、テストされたのかを確認することができます。さらに、CDは、これらの実践を採用する全ての企業にとって、多くのことを可能にします。
1. 全体的なテスト。CDは、開発者が自分の変更を単体テスト以上にテストすることを可能にし、本番サーバーにデプロイする前に多次元にわたってその変更を検証することができます。
2. 迅速なフィードバック。CDは、コードが複数の環境にわたって検証され、各環境からフィードバックが得られるため、ソフトウェアのデプロイに伴うリスクを軽減します。
3. Deployable readyの確認。CDは、main/masterブランチが常にデプロイ可能な状態にあることを確認することができます。全てのコミット／変更からリリースをデプロイすることが可能です。
4. 容易なデバッグ。巨大なチャンクを継続的にリリースするのではなく、小さなチャンクでソフトウェアをリリースするため、何か問題が発生した場合にデバッグする領域が非常に少なくなります。
5. リリース頻度。過去10～15年から今日までの各社のリリースの傾向を見てみましょう。リリースサイクルはおよそ数カ月に１回だったのに対し、現在では少なくとも週に２回となっています。リリースの頻度は飛躍的に高まっています。競争に打ち勝つために、できるだけ早くアップデートを展開したいと誰もが考えています。CDがなければ、この速いリリース頻度がアプリケーションや運用チームのボトルネックになります。手作業によるプロセスは、遅延やエラーを生み出す信頼性の低いリリースにつながっていました。
6. 透明性。CDのパイプラインに関わるスクリプトからセットアップまで、全て精査されます。そのため、CDパイプラインに加えられた変更を誰もが知ることができ、個人的な設定がパイプライン／ジョブに渡ることはありません。
結論
自社製品を使用している顧客が直面していることを本当に経験するには、BYOC（Be Your Own Customer）です。Harness社では、ビルド、テスト、デプロイにHarnessを使用することで、顧客に届く前にバグを発見することができます。さらに、全員が製品のギャップを見つけることに貢献でき、それがHarnessの機能開発につながります。そして、ユーザーエクスペリエンスの向上にもつながります。
引き続き、自社製品の活用方法についてお読みいただければと思います。JenkinsからHarness CIEへの移行に関する記事はこちらです。
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。