※本記事は2022年1月28日に公開された記事の翻訳版です。
この記事は、「Developer Productivity Engineering Camp」ブログシリーズの一部として、CI/CDチームの by Yuji Kazamaがお届けします。
はじめに
こんにちは、Continuous Integration（CI）/Continuous Delivery（CD）チーム エンジニアリングマネージャーのYuji Kazamaです。CI/CDチームは、Developer Productivity Engineering Campに所属しています。この記事では、以下の質問に答えながら、チームの簡単な紹介をします。
- チームは何を達成しようとしているのか（ミッション）
- チームはどのようにそのミッションを実現しようとしているのか（戦略）
ミッション
私たちのミッションは次のとおりです。
「CI/CDを通じて、開発者に最も生産的な開発体験を提供する」
私たちのチームの主な顧客は、メルカリグループのすべての開発者です。チームが顧客のために存在する理由は何かという質問に答えるために、私たちの背景について説明させてください。
私たちのアプリケーションがモノリシックであったとき、アプリケーションがより複雑になるにつれて、より多くの問題が発生しました。CI/CDの観点から言うと、テストとリリースのプロセスがより困難になっていました。サービスに変更を加える際、すべての変更のマージ、テスト、デプロイを待つ必要があったため、デプロイは遅くなっていたのです。さらに、不適切なアップデートがデプロイされれば、サービス全体が停止しました。
上記の問題を解決するために、モノリシック・アーキテクチャからマイクロサービス・アーキテクチャにマイグレーションすることにしたのですが、その後は、モノリシックのときのような方法でテストすることができなくなりました。たとえば、マイクロサービスが他のサービスを呼び出すには、ローカル関数ではなくリモートネットワークで呼び出さなければなりません。つまり、テストで対処しなければならない障害点が増えるということです。他のサービスへの呼び出しを再試行すると、それらのサービスでDDoSが発生する可能性があるため、適切な保護の仕組みを提供する必要がありますが、これもテストしなければなりません。
歴史的な理由から、開発環境と本番環境の間にはいくつかの違いがありました。たとえば、サービスは、開発環境と本番環境の間では異なるデータセンターでホストされる場合がありました。インフラとプロビジョニングが異なることで、テストがより困難になりました。
昨年、サプライチェーンの問題が原因の、大規模なセキュリティインシデントがありました。どのようなソフトウェアにも、サプライチェーンに脆弱性をもたらす可能性があります。システムがより複雑になるにつれて、アーティファクトの整合性を保証するためのチェックとベストプラクティスを実施することが重要になります。
これらの問題を解決するには、CI/CDプラットフォームに頼る必要があります。私たちのチームは、リリース・スピードと信頼性を実現するためのプラットフォームを提供するために存在しています。私たちは、リスクを最小限に抑え、社内の開発者がより容易にテストとデプロイを実施できるようにします。
戦略
戦略とは、チームがどのようにそのミッションを実現するかの手段です。以下は、私たちのチームが従う戦略です。
- データドリブンな意思決定
- 便利なツールとインフラの提供
- 健全なテスト文化の育成
データドリブンな意思決定
適切にデザインされたCI/CDパイプラインがあれば、フィードバックループが高速になり、開発チームは自信を持ってソフトウェアをリリースできます。測定していないものを改善することはできません。プロダクトの改善に向けて具体的な進歩を遂げるためには、測定可能なメトリクスを定義する必要があります。
チームでは、開発の生産性に悪影響を与える問題がどこにあるかを知るために、ハイレベルの CI/CDメトリクスを定義しました。
ただし、モニタリングは生産性を維持するのに充分ではありません。対応を要するモニタリング結果についてのアラート（開発者と私たちに送信される自動通知）が必要です。また、現在のプロセスと結果を定期的にレビューし、それが引き続き効果的に使用されていることを確認しなければなりません。
便利なツールとインフラの提供
私たちがCI/CDを通じて開発プロセスで使用されるツールを 提供するのは 、それが私たちのミッションを実現するための取り組みの中心であるからです。社内開発者の目標を達成するためには、 ツールがいかに簡単に使用でき、どれほど役立つかを検討する必要があります。
テストインフラは、生産性の高いソフトウェア開発にとってクリティカルなコンポーネントです。安定していて、開発者やQAエンジニアからのさまざまな要件に沿った使いやすいものでなければなりません。デプロイのインフラもまた、生産性の高いソフトウェア開発にとってクリティカルです。開発者が簡単にデプロイパイプラインを構築して使用できるように、安定していて使いやすく、デフォルトの状態でセキュアである必要があります。
健全なテスト文化の育成
私たちの基本的な目標は、プロダクトを頻繁にリリースするために、問題のある変更をできるだけ早く、自動的に検知することです。ただし、すべてのコミットですべてのテストを実行することはできません。コードの変更とは関係のないテストの不安定性や誤作動から生じる障害によって、開発者がすべてのコミットでブロックされるようでは、開発者にとってコストが高すぎます。開発ワークフローと本番ワークフローでどのテストを実行するかを定義する必要があります。必要なテストのタイプには以下が含まれます。
- 機能テスト
- セキュリティテスト
- パフォーマンス、負荷、ストレステスト
- デプロイ構成のテスト
- カナリアテスト
- カオスエンジニアリング
サービスに変更を加えなければならない頻度と速度が高いほど、それらをテストするためのより迅速な方法が必要になります。健全な自動テスト文化では、開発者もテストを書くことが奨励されます。また、このような文化では、定期的なテストが確実に実行されます。失敗したテストをすばやく修正することに重点を置くことで、プロセスに対する高い信頼性が維持されます。そのためには、私たちはエバンジェリストとして自動化テストとベストプラクティスを推進しなければなりません。
終わりに
この記事では、私たちCI/CDチームについて簡単に紹介しました。チームの活動に関する記事もいくつか公開する予定ですので、楽しみにしていてください。
メルカリではエンジニアを募集しています。上で説明したプラットフォームはまだ完全には実現されていませんが、そのようなプラットフォームを目指す会社で私たちと一緒に働きたい方は、以下のポジションのご応募をお待ちしています。
