One Developer Experience - ビルド、デプロイ、そして実験：CI/CDへの期待と経験

このeBookの抜粋では、ソフトウェアエンジニアとDevOpsチームに期待されること、そしてCI/CDで最高のDXを提供する方法について解説しています。

私たちは文字列の外部化を解決しました。その方法と、そのために必要な要件をご紹介します。ヒント：社内で解決策を構築しました。

もし、あなたのソフトウェアが他の誰かや何かから利用できないなら、そのソフトウェアはソフトウェアと言えるでしょうか？この言葉は比喩ですが、ソフトウェアエンジニアとして、自分が作ったものが自分のローカルマシンにあっても、誰の役にも立ちません。最も単純に言えば、あなたは自分が変更したものをビルドし、テストし、デプロイする必要があるのです。

この記事は、eBook「One Developer Experience - Build, Deploy, and Experiment」からの抜粋を含んでいます。もし内容が気に入ったなら、最後までお付き合いください。無料です。



あなたのアイデアは、ユーザーの手に渡るまでに多くの環境とインフラのピースを通過する可能性があります。安全性を考慮しても、稼働中のシステムを段階的に更新するために、カナリアリリースなどのリリース戦略を上手に進めなければならないかもしれません。より多くの項目が開発者側にシフトするにつれ、インフラの自動化やDevSecOpsの実践など、幅広い知識を習得するのが難しくなっています。

Continuous IntegrationとContinuous Deliveryの進歩により、あなたが変更したものは、構築、パッケージ化、テストされ、新規または既存のインフラストラクチャーに安全にデプロイされます。自動化と専門知識をCI/CDパイプラインに配置し、さらに旅を続け、DXの目標を達成できます。本番環境へのより完全な旅は、以下のような旅になります。

コードから成果物への移行は、以下の図のようになります。

しかし、アーティファクトを得ることは旅の一部でしかありません。現代のソフトウェアデリバリーでは、信頼性を高めるステップと安全性をオーケストレーションする必要があります。自動化は、一貫性と優れた開発者エクスペリエンスを実現するための鍵です。高度に自動化された本番環境へのデプロイは、次のようになります（カナリアリリースを利用します）。

現代のソフトウェア技術者に期待すること

エンジニアは一般的に、生まれながらの最適主義者です。より効率的に仕事をする能力は非常に重要です。アジャイルなどのインクリメンタルな開発プラクティスの台頭により、仕事の速度と機能に対する要求は無限大になる可能性があります。ソフトウェアに対する唯一の制限は、まさに時間とリソースです。

また、ソフトウェアエンジニアは、常に学習が必要な分野で、技術を向上させようとする性質があります。前項で取り上げたように、DevSecOps運動によるセキュリティーやKubernetesによるアプリケーションインフラの自動化など、いくつかのパラダイムが開発者向けにシフトレフトされ続けています。エンジニアリングの負担は増え続けています。

現代のソフトウェアエンジニアは、良いDXを期待しています。生産性を上げるために増加し続ける作業時間のトレンドに逆らう必要があるソフトウェアエンジニアは、イノベーションのペースで構築とデプロイを行うことで、より早く労働の成果を見て充実感を味わうことができます。

ソフトウェア構築時のベストDX／Continuous Integration

開発者の開発環境の外まで、ポジティブなローカルビルドの体験を広げるには、考えなければならないことがあります。Continuous Integrationは、ビルドの自動化であり、ビルドを外部化することに重点を置いています。ただし、ビルドに含めるのはコンパイル済みのソースコードだけではありません。Continuous Integrationで最終的に得られるのは、リリース候補です。

エンジニアリングの効率化の中核となる考え方は、社内の顧客がいる場所に対応することです。ソフトウェア エンジニアにとって、これは彼らのツールやプロジェクトにできる限り近いところにいることです。最近の多くのアプリケーション インフラストラクチャーと同様に、開発者に任せるということは、ソースコード管理（SCM）のプロジェクト構造に含まれることを意味します。

「あらゆるコミットがビルドの引き金になる」というマントラに合わせてビルドの速度が上がると、開発チームは、チームメンバーあたり、１日に数回のビルドを生成する可能性があります。最新のコンテナー化ビルドを生成するために必要なパワーは、従来のアプリケーションパッケージングと比較して年々増大しています。

一般的に、反復可能で一貫した方法で自動テストを実行するための最初の試みは、Continuous Integrationパイプラインで行われます。開発者がローカルビルドで行っているのと同じコード／テストカバレッジが、ビルドパイプラインにも適用されるからです。

よくある分散システムの誤りは、１人の人間がシステムのエンドツーエンド全体を理解しているというものです。これは真実ではありません。新しい機能を追加したり、テストカバレッジを拡大したりすると、開発面でもテスト面でも、大きな泥沼に陥りがちです。テストスイートの実行時間や複雑さは、新しい変更があるたびに増加する可能性があります。インテリジェントな方法でテストを実行し、新しい変更に対して適切なテストのみを実行することで、テストカバレッジの複雑さに広く対処することができます。

インテリジェントな方法でテストカバレッジを実行することによって節約された時間を表示します。

カバレッジと変更のモデル化により、適切なテストカバレッジの決定を支援します。

ソフトウェア／Continuous Delivery導入時のベストDX

ソフトウェアの構築は通常、慣習的に行われますが、ソフトウェアのデプロイはかなりオーダーメイドになる可能性があります。ソフトウェアは、プロジェクトや製品チームに参加する前、参加中、そして場合によっては参加した後にも、さまざまな決定の集大成となります。アプリケーションとインフラストラクチャーの選択を全てうまく進めることは、特にユーザーのトラフィックがあるライブシステム上では、複雑で各チームに固有のものになる可能性があります。

開発統合環境への段階的な変更の導入は、開発者が環境を完全に制御できるため、通常はDX向けに行われます。しかし、本番環境への移行が進むにつれて、組織によっては開発者が本番環境に入ることを許されないというビジネス上の制約が生じるかもしれません。そこで登場するのが、Continuous Delivery（Continuous Delivery）です。

Jez Humble氏によるContinuous Deliveryの定義は次の通りです。

“Continuous Deliveryとは、新機能、設定変更、バグ修正、実験など、あらゆる種類の変更を、安全かつ迅速に、持続可能な方法で本番環境に、あるいはユーザーの手に届ける能力である”

安全とは、パイプラインが品質、テスト、および障害に対処するためのメカニズムを強制することを意味します。そして最後に、持続可能とは、パイプラインが少ない労力とリソースでこれら全てを一貫して達成できることを意味します。

Accelerateという本では、優秀なパフォーマーはリードタイムが1時間未満で、本番環境での変更の失敗率が15%未満であると書かれています。従って、優れたパイプラインは１時間以内に完成し、コードがエンドユーザーに届く前に異常やリグレッションの95%を捕捉します。

もし、コードが本番環境に届くまでに１時間以上かかったり、10回中２回以上デプロイに失敗するようであれば、パイプラインの設計や戦略を考え直した方がよいでしょう。実験には繰り返しが必要なため、１日を通して行う必要がある場合、全面的なデプロイを行うと、ターゲットとなる変更や実験を行うには時間がかかりすぎるかもしれません。次世代DXでは、実験が重要です。

結論

One Developer Experience eBookの抜粋をお楽しみいただけましたでしょうか。次回の抜粋では、DXのための実験の重要性について説明します。次の投稿まで待ちたくない方は、今すぐDX eBookをダウンロードしてください。
One Developer Experience eBook
無料です。

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