Orbs レジストリには 405 以上の Orbs が登録されています。
驚くべきことですが、これらの Orbs のほとんどは、皆さんのようなユーザー、CircleCI の素晴らしいユーザーコミュニティ、そして CircleCI の新しいテクノロジーパートナープログラムに参加されている方々によって提供されています。ただし、CircleCI が公開している Orbs も 30 個近くあります。CircleCI 初のコミュニティ & パートナーエンジニアとして、私はここ数か月、できる限りユーザーが介入しなくても、これらの Orbs をビルド、テスト、およびデプロイできるようにする持続可能な開発パイプラインを作り出す作業に取り組んできました。
すべての Orb は異なるため、これは簡単な取り組みではありません。サードパーティツールやサービスをインストールして構成する Orbs もあります。さまざまなクラウドプロバイダーにデプロイしたり、外部環境でコードをテストしたりできるようにする Orbs もあります。また、一部の Orbs は、CircleCI プラットフォームをユーザーが簡単に利用できるようにするために使用される、既存の CircleCI の構成機能に対するシンタックスシュガー（糖衣構文）となっています。
これらのさまざまな種類の Orbs の開発をすべてサポートするためには、どのような継続的インテグレーションや継続的デプロイメントツールを利用したらよいでしょうか？さらに重要なことは、自分で Orbs を開発するときに、このようなツールをどのように利用するかということです。最終的には、誰かがプルリクエストを Orb リポジトリにマージするたびに、git pull と circleci orb publish を入力し、コンピュータの前で待っていることはなくなります。
このブログを読んでいらっしゃる方であれば、Orbs についてある程度の知識をすでに持っているのではないでしょうか？自分で、Orb を公開されていたり、CircleCI のプロジェクトで Orbs を使い始めていたりしている方もいらっしゃるでしょう。Orbs を初めて使用される方は、以前の Orbs 関連のブログをご覧ください。サポートエンジニアの Kyle Tryon が、初めて Orbs を書くための有用なヒントを紹介しています。彼はまた、CircleCI の Slack Orb (GitHub リンク）を作成した経験について公開しています（これは今のところ、 CircleCI の中で最も人気の高いOrbになっています）。さらに基本的な入門書をお探しの場合は、オーブの作成とコンフィグの再利用に関するドキュメントが非常に役立ちます。
このブログでは、新しい Orb のための、自動化された理想的な CI/CD プロセスな設定について説明します。私の次回のブログでは、Azure CLI Orb とこの Orb に組み込まれている自動化について詳しく説明します。
それでは、新しい Orb のための自動化のプロセスを説明していきます。このような自動化プロセスにはどのような最終目標があるのでしょうか？
バージョン管理
CircleCI は、DevOps エコシステムの中心として重要な役割を果たしており、中核となる概念は、「Infrastructure as Code（コードとしてのインフラストラクチャ）」です。Orbs はコードで示されるインフラストラクチャであり、他のソフトウェアと同じように、ビルド、テスト、デプロイする必要があります。そのためには、Orbs を Git リポジトリに配置する必要があります。
現在、いくつかの Orbs は非常に小規模なものです。自分で作成する Orb は、ある単純な操作を 1 つだけ実行するかもしれません。大規模な Orbs もあります（CircleCI が公開しているAWS ECS Orb)を参照してください）。小規模な Orbs、特に外部サービスの恩恵をあまり受けない Orbs の場合、いくつかのタイプの Orbs monorepo のほうが適切となる場合があります。実際には、複数の Orbs があるリポジトリであっても、テストが可能な Orbs は多くあります。CircleCI が公開した最初のいくつかの Orbs が保存されている circleci-orbs リポジトリで、このアプローチが実際に使用されています。
時間が経つにつれて、たとえば、サードパーティのデプロイを中心とする Orb など、複雑な多くの Orbs では、詳細なアプローチが必要であることがわかってきました。このような場合には、orb とリポジトリの関係を 1 対 1 にすると理想的です。CI/CD のロジックはすべてconfig.yml ファイル内に置く必要があります。単一のコンフィグファイルでいくつもの大規模な Orbs のインテグレーションテストと自動公開を管理しようとすると、すぐに手に負えなくなります。
多層テスト
Webサイトやアプリケーションをテストする際には、開発パイプラインにおける複数の箇所において、様々な方法でテストをすると思います。Orbs についても同じことを行う必要があります。
Orbs のエコシステム内で、このような階層の異なるテストとはどんなものがあるでしょうか。Orbs SDKのプレビューにある文章の言い換えになりますが、以下のような検証やテストが考えられます。
- スキーマ検証： これはたった一つの CLI コマンドで検証できます。Orb が正しい形式の YAML で記述され、Orb スキーマに準拠しているかどうかを確認します。
- ランタイムテスト：: この段階では、個別のテストを設定し、CircleCI ビルド内で実行する必要があります。
- 統合テスト：: これは、非常に高度な Orbs や、サードパーティサービスのための安定したインターフェイスとして公開されることを前提としたような Orbs でのみ必要となるテストです。Orb の統合テストを行うには、カスタムビルドと独自の外部テスト環境が必要です。
拡張テストという階層も考えられます。Orbs は本質的には CircleCI コンフィグを抽象化した断片です。つまり、特定の Orbs が期待する CircleCI のコンフィグを生成するかどうかをテストできます。実際には、拡張テストの正確性を維持するためには、Orb のソース自体だけでなく、対応する拡張された CircleCI コンフィグも管理し、これらの 2 つの整合性を保つことが求められるため、費用対効果があまり高くないことがわかりました。しかし、一部の Orbs では、この方法が役立つ場合があります。CircleCI のソリューションディレクターである Eddie Webb は、CircleCI Discussの Orbs テストのディスカッションで、このアプローチについて分かりやすく説明しています（具体例もあります）。
自動デプロイメント
私にとって、自動デプロイメントは、Orbs の開発プロセスを自動化する最終的な目標です。このような自動化を実現できなければ、拡張し続ける CircleCI の Orbs を維持することはできなかったでしょう。
初めて Orbs を作成される場合には、最初は、単純に手動で公開したくなるかもしれません。結局のところ、ここでは、いくつかの単純なシェルコマンドについて話しているだけですが、この誘惑に屈しないようにしてください。CircleCI は、プルリクエストを自分の Orb リポジトリにマージした後、更新された Orbs がレジストリにどうして表示されないのかという Orbs 作成者からの質問に何度も回答していますが、これは、Orbs のテストおよび公開プロセスにおけるデプロイメントを実際に自動化していないことによります。信じてください。経験上、最初から自動化しておくと、後で戻って自動化するよりもずっとスムーズに事を運ぶことができることが分かっています。
Orbs の自動デプロイメントにはいくつかの微妙な違いがあります。CircleCI CLI は、本番稼働用の Orbs を公開する 3 つの異なる方法を提供しています。
circleci orb publishを使用して、orb.yml ファイルをレジストリに直接公開できます。circleci orb publish promoteを使用して、以前に公開された Orbs の開発版を、セマンティックバージョニングされた製品版の Orbs に昇格できます。- 既存の製品版 Orb のバージョンをインクリメントできます。たとえば、
foo/bar@1.1.0からfoo/bar@1.1.1（パッチリリース）または1.2.0（マイナーリリース）、または2.0.0（メジャーリリース）にインクリメントできます。
私の経験上、実際には、開発版 Orbs を製品版 Orbs に昇格することが、最も有用な自動デプロイメントの仕組みであることが分かりました。この方法では、すべてのコミットで、Orb ソースコードの基本的なテスト/検証を行うことができ、その後で、条件付きで Orb の開発バージョンを公開し、開発バージョンの Orb で広範なテストを実行し、最後に、公開したばかりの開発バージョンの Orb を製品版に昇格できます。
まとめ
では、この方法でビルド、テスト、デプロイされた Orb の config.yml どのようになるでしょうか？最初にお伝えします。それほど複雑ではありません！CircleCI では、Orb開発の自動化の基本的な仕組みのほとんどを、「Orb」として抽象化しました。機能の例を確認するには、 先月 CircleCI が公開したAzure CLI Orbをご覧ください。小規模である程度簡易な Orb ですので、簡単に理解できるようになっていますが、サードパーティのクラウドプロバイダーである Microsoft Azure との統合であるため、複雑な部分もあります。この Orb の config.yml には、2 つの異なるワークフローが含まれています。1 つは基本的な検証と開発バージョンの公開であり、もう 1 つは、統合/使用テストと本番環境への Orb のデプロイメント（可能な場合）です。次のフォローアップブログでは、Azure CLI Orb とこれら 2 つのワークフローを全体的に説明していきます。
CircleCI のオープンソースエコシステムは拡大し続けていますが、Orbs はその中心であり、皆様が参加することでより多くの Orbs が利用できるようになります。GitHub または Bitbucket の自分の Orbs をcircleci-orbs トピックタグでタグ付けすると、他のユーザーがより簡単に見つけることができるようになります。質問やご意見については、CircleCI Discuss のOrbsのセクションに投稿してください。
その他の資料：
