Kubernetesベストプラクティス第2版

第2章. 開発者のワークフロー

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

Kubernetes は、ソフトウェアを確実に演算子するために構築された。アプリケーション指向のAPI、自己修復特性、ソフトウェアの停止時間のないロールアウトのためのデプロイのような便利なツールで、アプリケーションのデプロイと管理を簡素化する。これらすべてのツールは便利だが、Kubernetes向けのアプリケーション開発を容易にすることはあまりできない。そこで登場するのが、開発者のワークフローだ。多くのクラスタは本番アプリケーションを実行するように設計されているため、開発者ワークフローからアクセスされることはほとんどないが、開発ワークフローがKubernetesをターゲットにできるようにすることは非常に重要であり、これは通常、開発向けのクラスタまたは少なくともクラスタの一部を持つことを意味する。Kubernetes向けのアプリケーションを容易に開発できるように、このようなクラスタをセットアップすることは、Kubernetesを成功させるために非常に重要だ。もしクラスタ用にビルドされるコードがなければ、クラスタ自体は大したことを成し遂げていないことになる。

目標

開発クラスタを構築するためのベストプラクティスを説明する前に、そのようなクラスタに対する目標を述べておく価値がある。最終的なゴールは、開発者がKubernetesクラスタ上で迅速かつ容易にアプリケーションを構築できるようにすることであることは明らかだが、実際のところそれは何を意味し、開発クラスタの実用的な機能にどのように反映されるのだろうか？

これに答えるために、開発者とクラスターとの相互作用の段階を特定することから始めよう。

最初のフェーズはオンボーディングである。このフェーズには、ユーザがクラスタにログインできるようにすることと、最初のデプロイに向かわせることが含まれる。このフェーズの目標は、最小限の時間で開発者の足を濡らすことだ。このプロセスの主要業績評価指標（KPI）目標をセットする必要がある。妥当な目標は、ユーザが何もない状態からHEADで現在のアプリケーションを30分以内に実行できるようになることだろう。チームに新しい人が加わるたびに、この目標に対してどのように取り組んでいるかをテストする。

第二段階 は開発である。これは開発者の日々の活動である。このフェーズの目標は、迅速な反復とデバッグを保証することだ。開発者は、素早く繰り返しコードをクラスタにプッシュする必要がある。また、コードを簡単にテストし、正しく演算子されていない場合にデバッグできる必要もある。このフェーズのKPIを測定するのはより難しいが、プルリクエスト（PR）や変更をクラスターで稼働させるまでの時間を測定したり、ユーザが認識している生産性の調査、またはその両方によって推定することができる。また、チームの全体的な生産性でも測定できるだろう。

第3のフェーズはテストである。このフェーズは開発と織り交ぜて行われ、投稿やマージの前にコードを検証するために使われる。このフェーズの目標は2つある。第一に、PR を提出する前に、開発者が自分の環境のテストをすべて実行できるようにすること。第二に、コードをリポジトリにマージする前に、すべてのテストを自動的に実行すること。これらの目標に加えて、テストを実行するのにかかる時間のKPIも設定すべきである。プロジェクトが複雑になればなるほど、テストにかかる時間が長くなるのは当然だ。そうなってくると、PRを提出する前に開発者が初期化検証に使えるような、より小さなスモークテストセットを特定することが重要になってくるかもしれない。また、 ...