BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース すべての機能ブランチをデプロイして迅速なプロダクトフィードバックを得る

すべての機能ブランチをデプロイして迅速なプロダクトフィードバックを得る

ブックマーク

原文(投稿日:2019/12/12)へのリンク

継続的デリバリの限界を押し広げれば、ソフトウェア開発における人々のコラボレーションの方法を根本的に変えることができる。Christian Uhl氏はDevOpsCon Munich 2019で、GitLabとKubernetesを使用してすべての機能ブランチをデプロイすることにより、プロダクトオーナとステークホルダからのフィードバックを迅速に得る方法について講演した。

Uhl氏はまず、リリースのバンドルを行わない氏らの手法について説明した。この方法では、すべてのブランチは独自の環境にデプロイされ、すべての機能が実稼働に直接移行する。

最小限の実行可能なユニットを(全体をバンドルせずに)デプロイすることのメリットは、リスクの最小化にあります。Nicole Forsgren氏の著書"Accelerate"には、私よりもはるかに優れた説明がされていると思います。同書で紹介されているような低い障害レベルを、私たちは身を持って体験したのです。

ブランチのデプロイの判断は、動作上の障害(バグなど)ではなく、機能上の誤り(要件理解の誤りなど)を原因とする多くの問題が発生したことを確認した後で行われる。開発中にデプロイされたブランチのユーザーインターフェイスを、プロダクトオーナやステークホルダにも提示することで、より有意義な議論を迅速に行うことが可能になる、とUhl氏は言う。

継続的デリバリに対する氏らのアプローチはプロダクトレビューにも影響を与えている、と氏は説明する。

一般的にプロダクトレビューには、"私の機能はプロダクトオーナの厳しい目をパスするだろうか?"という意味での不安があります。 これが緊張と妥協につながるのです。皆が同じ立場で参加するようになれば、プロダクトレビューはコラボレーションになります。私たちの開発プロセスでは、他の方法では見つけられなかったような、アイデアに対する多くの微修正や改善点を見つけることができています。matmatch.comでは、多くの機能とアイデアを短期間に実現していると、自信を持って言うことができます。

Matmatchでは、GitLabやKubernetesの提供するツーリングを最大限に活用している。すべてのブランチをビルドし、Dockerコンテナ化し、生成名を付けてデプロイすると同時に、ルーティングも生成する。宣言的なデプロイメント構成では、ブランチをdomain.comではなくfeature1.domain.comにデプロイすることは、単にパラメータだけの問題なのだ、とUhl氏は説明する。コードレビューとステークホルダの承認が完了すれば、ブランチをマスタにマージして、デプロイをクリーンアップする。

DevOpsCon Munich 2019での講演を終えた、Matmatchのエンジニアリング責任者であるChiristian Uhl氏に話を聞くことができた。

InfoQ: 継続的パイプラインの改善を決断したきっかけは何でしたか?どのようなニーズがあったのでしょうか?

Christian Uhl: 私たちはスタートアップなので、準備期間(つまり、成功を証明するための時間)には限りがあります。それに、ビジネスを立ち上げた直後には、ユーザの望むものが何であるかは本当には分かっていないものです。ですから、開発したもののほとんどは間違っています — "夢の実現"のためには、それらを少しでも早く修正しなければなりません。

例えば当初、エンジニアがマテリアルのコレクションを"プロジェクト"として作成し、それらを共有できる機能があったのですが、使用率が非常に低いということがすぐに分かりました。そこで、個人個人がマテリアルを保存できるような機能を開発したところ、現在では非常に多く利用されています。

ユーザ価値の創造から気をそらすことのないように、ソフトウェアのデプロイは、完全に自動化された、取るに足らないようなものであるべきだ、と私たちは判断しました。何が機能するのか、何が超高速ではないのか、を見つける必要もあります。機能実装が終わってからユーザの行動記録を開始するまで、さらに2週間も待つ訳にはいかないのです。

InfoQ: パイプライン内でのテストは、どのように行われるのですか?

Uhl: ユニットテスト、統合テスト、エンドツーエンドテストで構成された、古典的なテストピラミッドを使っています。エンドツーエンドテストを最小限とする一方で、売上の根源とも言えるプラットフォームの基本コア部分は十分にテストできるように、特に注意を払っています。これらのテストはコミット毎に実施されます。すべてのステージが緑になるまで、マージは一切行いません。

機能が実稼働に入る前にステージング環境がなくなるので、開発者は、作成するテストを慎重に検討するように動機付けられます — 救ってくれるセーフティネットやQAチームはもうないのですから。つまり、"開発した人が運用する(You build it, you run it)"という考え方です。私たちの開発した自動化テストハーネスが、大きな問題は発生しない、という十分な自信を与えてくれます。また、提供されているクラウドサービスを使用することで、個々のテストステージを実行するための非常に強力なマシンをプロビジョニングして、テスト後には破棄することが可能になります。これによって、テスト実行時間を許容可能なレベルに維持することができるのです。

発生したエラーを迅速に発見して修正できるように、システムの可観測性にも力を入れました。システムで発生したすべてのエラーを追跡し、これを警告することによって、新機能で発生した問題を知ることができます。さらに、機能をリリースする前には、機能がユーザに受け入れられるか、あるいは無視されるかを知るために、いくつかのトラッキング機能も用意しています。ロールバック用のツーリングもありますが、実はまだ使ったことがありません。安心のための機能、といったところです。

InfoQ: 継続的デリバリパイプラインを構築する上で、どのような問題があって、どう対処したのでしょうか?

Uhl: まず最初に、ここに至るまでには大変な労力を必要としました。デプロイの自動化自体が大変な仕事でしたし、自信を持つために十分なテストを用意した上で、最終的にすべての構成を正しいものにしなければなりませんでした。作業を進めることができたのは、そこから得られるビジネス価値とアジリティを信じていたからに他なりません — ですが、行うべきことが他に山ほどあったスタートアップの初期段階で、それを正当化することは大変でした。プラットフォームの構築は一大事業ではなく、解決すべき小さなことの積み重ねでした。マージ後のクリーンアップが適切でなかったために、Kubernetesクラスタを吹き飛ばしてしまったことも何度となくありました。

ですか、技術的な問題だけでなく、当初は不安もたくさんありました — すべての機能を直接運用にデプロイするということには、恐怖感もあります。それによって得るメリットを説明するのに、多くの時間を費やしました。コアシステムに取り掛かる前に、最初にひとつ、またひとつ、というように、重要性の低いサービスを展開していったのです。この方法は多くの面で有効でした。

2017年に取り組みを始めてから、ツーリングは大きく改善されました。今から同じことを始めればずっと簡単にできると思いますが、当時はたくさんのことをキャッチアップしなければならなかったのです。

この記事に星をつける

おすすめ度
スタイル

BT