HarnessのGit Syncエクスペリエンス

Git Syncは時間を節約し、CI/CDをより簡単にします！GitでYAMLファイルを作成/修正するだけで、新しいパイプラインを作成し、維持することができます。

DevOpsの登場により、開発とデプロイの境界線は曖昧になりました。エンジニアリングチームは、設定ファイルと継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインを作成し、維持し、使用することが求められるようになりました。ウィザードで設定ファイルを作成し、次へをクリックする従来の方法は、開発者にとって大きな手間となります。私たちは、コードを書くのと同じように設定ファイルを書きたいのです。Git Syncエクスペリエンスの主な目的は、ユーザーのCI/CD体験をコードを書くのと同じくらい簡単にすることです。

Git Syncを使って、ユーザーのために以下のような素晴らしい開発者体験を作り出したいと思いました。

1. GitにHarnessの設定を保存したり、Gitから取得したりすることができる。
2. GitのYAMLファイルを変更するだけで、Harnessの設定を変更できる。
3. GitでパイプラインYAMLを追加するだけで、新しく作成したマイクロサービスのCI/CDパイプラインを簡単に作成できる。
4. コードを保守するように、設定を保守する。

課題と解決策

Git Sync

Gitの体験で最も重要なのは、双方向の同期（UI側の変更はGitにプッシュされ、Git側の変更はHarnessに反映されること）を可能にすることです。

同じデータが２つの異なる場所に保存されている状況では、どの場所が真実のソースとなるかを決めなければなりません。私たちはここで、Gitを真実のソースとして維持するGitOpsの哲学に従いました。この決定により、私たちの顧客は、Gitで見ているものは何でも本当の状態であり、それを確認するためにUIにアクセスする必要がないことを保証することができるのです。ユーザーがGit Sync対応プロジェクトに変更を加えるときは、まずGitに変更をプッシュし、その後Harnessで変更を適用するようにしています。

次に解決した課題は、Harnessの変更をどのようにGitにプッシュするかということでした。思いつく素朴な解決策は、次のようなものです。

1. Harness に変更があった場合、Gitリポジトリーがなければクローンする。
2. Gitリポジトリーに変更を追加する。
3. 変更をコミットしてプッシュする。

Gitリポジトリーを完全にクローンしてローカルで管理するというこのやり方は、スケーラブルではありませんでした。

次の解決策は、さまざまなGitプロバイダーが提供するAPIを利用することでした。私たちはオープンソースのscmサービスを作りました。これは、一般的なGitプロバイダーの全てを包むラッパーです。Gitに変更をプッシュするには、SCM サービスにリクエストを送り、SCMサービスが変更をそれぞれのGitプロバイダーにプッシュします。変更が Git側にプッシュされたら、Harness側でその変更を適用します。

次の問題は、ユーザーのGitファイルでの変更をどのようにHarnessに適用するかです。

この問題を解決するために、Gitプロバイダーのwebhooks機能を利用します。ユーザーが設定リポジトリーに変更をコミットするたびに、Harness側でWebhookリクエストを受け取ります。このリクエストには変更に関する詳細が含まれており、これを利用してHarnessのエンティティに変更を適用しています。

複数リポジトリーのサポート

開発者が設定ファイルを保存する際には、さまざまなパターンがあります。一般的なパターンは以下の通りです。

1. 設定ファイルは、コードリポジトリーそのものと一緒に保存される。
2. 設定ファイルは、コードとは別のリポジトリーに保存される。
3. prodの設定ファイルを１つのリポジトリーに、prod以外の設定ファイルを別のリポジトリーに保存し、選ばれた開発者だけがprodの設定にアクセスできるようになる。
4. 異なる環境の設定ファイルを異なるブランチに格納する。
5. パイプラインを１つのリポジトリーに、その他の設定ファイルを別のリポジトリーに格納する。

私たちは、上記の全てのユースケースをサポートするために、柔軟な設計を心がけました。

ユーザーは、同じプロジェクトで複数のGitリポジトリーを使用することができます。各設定をプッシュする前に、変更をプッシュするリポジトリーを選択するようユーザーにお願いしています。これにより、ユーザーは自分の望む方法でGitリポジトリーを維持することができる柔軟性を得ることができます。

Harnessフォルダー

全てのHarnessエンティティは、ユーザーのリポジトリー内の.harnessフォルダに同期されます。.harnessフォルダ内の全てのファイルを処理し、他のファイルは無視します。.harnessフォルダの中では、ユーザーはYAMLファイルを好きなフォルダー構造で保存することができます。

全てのコネクターを１つのフォルダーに、パイプラインを別のフォルダーに保存したり、プロジェクト／チームごとにYAMLファイルをグループ化したりすることができます。この柔軟性により、ユーザーはコードと一緒にHarnessの設定を保存したり、別のリポジトリーに別々に保存したりすることができます。ユーザーは全てのフォルダーの中からデフォルトのフォルダーを選択することができます。

まとめ

Git Syncは、最新のDevOpsソリューションに多くの可能性をもたらします。設定変更を簡単に行う方法を提供し、開発者がCI/CDパイプラインをセットアップして維持するための全体的な時間を短縮するのに役立ちます。

ほとんどの組織におけるCI/CDプロセスは、退屈でマニュアル的なものです。運用チームは、パイプラインの維持、更新、実行に終始しています。さらに、開発チームと運用チームとのコミュニケーションのミスマッチが、本番環境の問題につながることもあります。Git Syncを使えば、新しいパイプラインの作成と保守を、GitでYAMLファイルを作成/変更するだけで行うことができます。

月曜日には、Gitブランチについての姉妹記事を公開する予定ですので、ご期待ください。その間、私たちの新しいGitOpsの発表を読んでみてはいかがでしょうか。

編集：Gitブランチに関する記事が公開されました。

この記事は、Deepak Patankar、Abhinav Singh、Akash Nagarajan、Rama Tummalaの協力で執筆されたものです。

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