AZ-400学習リソースを共有します 1-2 [DevOps プラクティスを発展させる – Azure DevOpsをはじめよう]

.NET, Azure, Azure DevOps, クラウド関連 /

こんにちは。 AZPower クラウドサービス開発本部 森です。

先日、Microsoft資格試験 AZ-400:Designing and Implementing Microsoft DevOps Solutionsを取得しました。

せっかくですので、これらの取得の際に作成した学習リソースを共有したいと思います。
長期にわたっての記事となりますので、大変ですがお付き合いのほどをよろしくお願いします。

なお、この前の記事は「AZ-400学習リソースを共有します1-1[DevOps プラクティスを発展させる – 既存のソフトウェア開発プロセスの評価]」です・

AZ-400 とは

AZ-400は開発プロセスで必要となるさまざまなツール(簡単にいうとAzure DevOpsとGit, VSCodeあたり)やプラクティスの知識を持っていて、
Azureの管理・開発に精通しているということを試される試験です。

そのため、受験資格としてAZ-103, AZ-104(Microsoft Azure Administrator)またはAZ-203, AZ-204(Developing Solutions for Microsoft Azure)の資格を保有している必要があります。

AZ-400とMS Learn

私がAZ-400の取得に活用したのが、MS Learnです。
簡単にいえば、前述の前提資格を取得した方で、こちらのコンテンツの内容がひととおり理解できれば取得できるのではないかと思います。
ただ、2020年8月6日時点でAZ-400のラーニングパスにある記事はすべて英語でした。

そのため、この学習リソースを利用するには少し英語のハードルが高くなっています。

私はAZ-400の資格取得の学習の目的で翻訳しました。
せっかくですからこれらの翻訳結果共有したいとおもいます。
今後のAZ-400の受験に役立てていただければ幸いです。

ただ、翻訳は専門ではないので、微妙な翻訳になっているかもしれませんが、ご容赦のほどを…。

あと、記事中のリンクは記事のソースと同じになるように設定しましたので、リンク先は英語の記事になっています。
加えて、本家の記事では知識確認のための試験が出るのですが、この部分に関しては翻訳していません。（勉強用のリソース以外でしたので…）

現在のラーニングパス

2020年8月11日時点で確認したところ、AZ-400用ラーニングパスが新しく更新されていました。
こちらは古いラーニングパスに基づくコンテンツですが、内容が古くなっているということはないので引き続き投稿します。

DevOps プラクティスを発展させる

DevOpsとは、エンド ユーザーに対する価値を継続的に届けることを可能にする、人、プロセス、製品の総称です。
その価値の継続的デリバリーに必要なツールを与える一連のサービスがAzure DevOpsです。
Azure DevOpsを利用すれば、あらゆるアプリケーションをビルドし、テストし、クラウドまたはオンプレミスにデプロイできます。
透明性、共同作業、継続的デリバリー、継続的デプロイを可能にするDevOpsプラクティスは、今後のソフトウェア開発ライフサイクルとして広がることでしょう。

このラーニング パスでは、DevOpsの旅を始めることになります。 このチュートリアルの内容は次のとおりです。

  • 現在のプロセスとテクノロジを評価する場合に利用する、Value Stream Map(バリュー・ストリーム・マップ）がどのように役立つかを確認する
  • Azure DevOps Organizationに無料でサインアップする
  • Azure Boardsを使った作業項目の計画および追跡方法を学習する
  • 複数のアジャイル チームにわたるスプリント ワークロードの最適化

Azure DevOpsをはじめよう

DevOps とは何か (そして何ではないか) を探り、Azure DevOps を始める方法を学びます。

ここでは、以下のことを学びます。

  • DevOpsとは何かを学び、何がエリートパフォーマーとローパフォーマーを分けるのかを見定める
  • Azure DevOpsが提供するサービスを認識する
  • Azure DevOps organizationを設定する

2-1. Introduction

Azure DevOpsは、チームがより効率的、協調的、安定した方法でコードをリリースするのに役立ちます。
チームに再び参加して、DevOps について学んでみましょう。
一緒に、Azure DevOps の実践を始めるために必要なことを発見しましょう。

前の章では、Tailspin Toysのチームに会いました。
彼らは新しいゲームに取り組んでいますが、リリースプロセスに多くの問題を抱えています。
これらの問題は、顧客に提供する製品の品質に影響を与えている。
チームは、変えなければならないことはわかっているが、どうすればいいかわからない。

新しいチームメンバーであるマーラは、DevOpsが助けになると信じています。
彼女の目標は、チームメイトを説得することです。
彼女は前のモジュールで始めたバリュー・ストリーム・マッピング（VSM）のエクササイズについて詳しく説明します。
うまくいけば、彼女の説明によって、なぜDevOpsが進むべき道なのかをチームに示すことができるでしょう。

学習目標

このモジュールでは、以下のことを学びます。

  • DevOpsとは何かを学び、エリートパフォーマーとローパフォーマーを分けるものは何かを見定める
  • Azure DevOpsが提供するサービスを認識する
  • Azure DevOpsでアカウントをセットアップする

前提条件

この学習パスのモジュールは段階的にラーニングパスを構成しています。

そのため、このモジュールを始める前に、DevOps プラクティスを進化させるの最初から始めることをお勧めします。

開発チームと再開

あらためて、一緒に仕事をするTailspin ToysのSpace Gameウェブチームを紹介しよう。

アンディの漫画

開発リードのアンディ

アミタの漫画描写

品質管理部(QA)のアミタ

ティムの漫画描写

運用チームのティム

マーラの漫画描写

開発者として入社したばかりのマーラ。アンディの部下になります。

マーラはDevOpsの経験があり、Azure DevOps を使用してチームがより合理化されたプロセスを採用するのを支援しています。

What is DevOps?

DevOpsとは、人、プロセス、製品が一体となって、顧客に価値あるものを継続的に提供できるようにすることです。
しかし、それは具体的にどのような意味を持つのでしょうか？
マーラがDevOpsとは何か、何がそうでないのか、そして何がエリートパフォーマーを成功に導くのかを説明するので、チームに参加してみましょう。

マーラはチームメイトとの短いミーティングを招集しました。
全員が現れましたが、誰も参加したがらないのです。
彼女はテーブルの上にドーナツの箱を置きました。

マーラ: こんにちは、来てくれてありがとう。
　私たちのバリュー・ストリーム・マップと、プロセスをより効率的にする方法についてお話ししたいと思いました。

　マーラの価値の流れの地図は、前回の会議からまだホワイトボードの上にあります。

価値の流れの地図を示すホワイトボード

マーラ: 私たちのバリュー・ストリーム・マップは、エンドユーザーに価値を提供する上で、どこで効率を落としているかを示しています。
他の誰もがそうであるように、私たちも改善することができます。
そして、どの分野に最初に取り組むべきかを決めることができます。

アンディ: これは、どこに問題があるかを示してくれますが、それに対して何をすべきかを示してくれません。

マーラ：そうですね。それでもこれは正しい方向性を示すためのエクササイズになります。
問題に対して何をすべきかについては、DevOpsがサポートする思います。　　
前の会社では、DevOpsによってデプロイ率が大幅に向上し、リードタイムが大幅に短縮され、インシデントも大幅に減少しました。　　
そこに到達するまでには時間がかかりましたが、それだけの価値はありました。　　
DevOpsは迅速な解決策ではありません。

ティム: 私の知り合いにもDevOpsエンジニアとして就職したばかりの人がいます。　　
もっと開発者向けの仕事だと思います。アンディ、あなたのように。

マーラ: DevOpsは職種ではないわ。

アミタ：そうですね。　　
私たちを助けてくれるソフトウェアプログラムやテンプレートはありますか？　　
DevOpsのスプレッドシートがあるかもしれませんね。

マーラ: DevOpsはソフトウェアの一部ではありません。

アンディ: どちらかというと方法論のようなものですね。

マーラ: そうでもないですね。

アンディ, アミタ, ティム: じゃあ何なの？

マーラ: 私の好きな定義はこうです。

DevOpsとは、エンドユーザーへの価値の継続的なデリバリーを可能にするために、人、プロセス、製品を結合することです。

実際、MicrosoftのクラウドアドボケイトであるAbel Wang氏は、私たちの大きな質問に素早く答えてくれる素晴らしいビデオを提供してくれています。Abel が DevOps をどのように定義しているか見てみましょう。

アベルに聞く (翻訳者注：ここではビデオが流れます。ビデオでアベルが話した内容をできるだけ意訳していますが、正しくは本編を参照ください。)

DevOpsとはなんでしょう。
さて、DevOpsとは何か？
面白いことに、「DevOpsとは何か」と言ったときに、10人にDevOpsとは何かと聞いたら、おそらく20の異なる答えが返ってくるでしょう。
しかし、MicrosoftにとってDevOpsは、本当に注意深く特別なことを意味しています。
DevOpsとは、エンドユーザーに価値を継続的に提供できるようにするための、人、プロセス、製品の統合です。
さて、「本当に注意深く」と言ったことに注目してください。
なぜかというと、その定義は私の上司が作成したものだからです。
だから、もし間違ってたらクビだ。
もう一つは、その定義の全ての言葉が非常に特別に設計されているからです。
重要なのは、エンドユーザーに継続的に価値を提供することであり、これは今の世界では不可欠なことです。

私たちの目標は、お客様に喜んでいただけるゲームを提供することです。
そのためには、DevOpsで利用する一連のプラクティスとツールを共有して一緒に進めましょう。

アミタ: それはどういう意味ですか？共有されたプラクティスとは？共有されるツールとは？

マーラ: プラクティスの意味はこうです。

  • アジャイル計画
    • 一緒に、チームと管理職の誰もが見られるように、仕事のバックログを作成します。何に最初に取り組む必要があるのかがわかるように、項目に優先順位をつけます。 バックログには、ユーザーストーリー、バグ、その他、私たちを助ける情報を含めることができます。
  • 継続的インテグレーション（CI）
    • コードをビルドしてテストする方法を自動化します。チームメンバーがバージョン管理に変更をコミットするたびに実行します。
  • 継続的デリバリー（CD）
    • CDは、ビルドからQAや本番環境へのテスト、設定、デプロイの方法です。
  • モニタリング
    • テレメトリを使用して、アプリケーションのパフォーマンスと使用パターンに関する情報を取得します。その情報を利用して、反復しながら改善していくことができます。

アミタ: 自動テストについては知りません。　　
　私のテストは手動で、アンディがコードを私に渡した後に行っています。　　
　私にはすべてのやり方を変える時間がありません。

ティム: あなた方の誰かを本番環境にデプロイさせる方法はありません。

アンディ: これは経営陣を怖がらせる。　　
　彼らは次のリリースより先のことは考えないし、いつも昨日のことを欲しがっている。

マーラ: 管理者のことを言っているのはわかります。　　
　私は、何がエリートパフォーマンスを発揮するチームを作るのかについて、この配布資料をまとめました。

何がエリートチームを作るのか？

マーラさんが用意してくれたハンドアウトがこちらです。
この情報は、世界中の技術専門家を対象に行われたDevOpsの調査レポートや調査に基づいています。

DevOpsは、企業が顧客の採用率や満足度を高めるための方法を実験するのに役立ちます。
それは組織のパフォーマンス向上につながり、多くの場合、収益性や市場シェアの向上につながる。

DevOpsはメトリクスを使用して、エリートパフォーマーとローパフォーマーを比較するための4つのカテゴリーを作成します。

エリートパフォーマー

  • より頻繁にデプロイする
    実際、1 日に何十回もデプロイするチームもあります。
    モニタリング、継続的テスト、データベース変更管理、セキュリティの統合などのプラクティスをソフトウェア開発プロセスの早い段階で行うことで、エリートパフォーマーは、より頻繁に、より予測可能性とセキュリティを確保したデプロイを行うことができます。

  • コミットからデプロイまでのリードタイムを短縮
    リードタイムとは、ある機能が顧客に届くまでにかかる時間のことです。
    小ロットでの作業、手動プロセスの自動化、デプロイの頻度を上げることで、これまで数週間から数ヶ月かかっていたものが、数時間から数日で実現できるようになります。

  • 変更の失敗率の低減
    本番で失敗したり、他の機能が壊れたりするような新機能は、自社とユーザーの間に機会損失をもたらす可能性があります。
    高いパフォーマンスを発揮するチームが成熟すると、時間の経過とともに変更の失敗率が低下します。

  • インシデントからより迅速に回復
    インシデントが発生した場合、エリートパフォーマーはより迅速に回復することができます。
    メトリクスに基づいて行動することで、エリートパフォーマーはより迅速に回復しながら、より頻繁にデプロイすることができるようになります。

クラウド・インフラストラクチャをどのように実装するかも重要です。
クラウドはソフトウェアデリバリのパフォーマンスを向上させ、クラウドの本質的な特性を採用しているチームは、エリートパフォーマーになる可能性が高くなります。

アウトソーシングはコストを節約し、柔軟な労働力を提供することができますが、適切な分野で使用する必要があります。
パフォーマンスの低いチームは、パフォーマンスの高いチームよりも、機能全体（テストや運用など）をアウトソーシングする傾向が強い。

結論

DevOpsは、多くのエリートパフォーマーが、競合他社よりも迅速に新機能や改善という形で顧客に価値を提供することができる主な理由です。この短いビデオでは、Abel氏がDevOpsについて学ぶべき理由を説明しています。

アベルに聞く(翻訳者注：ここではビデオが流れます。ビデオでアベルが話した内容をできるだけ意訳していますが、正しくは本編を参照ください。)

なぜDevOpsにこだわる必要があるのか？
DevOpsは非常に重要であり、DevOpsとは、エンドユーザーに価値を継続的に提供することを可能にするための、人、プロセス、製品の統合であることを忘れないでください。
さて、ここでもう一度言いますが、ここでの重要なステップやポイントは、継続的に価値を提供できる必要があるということです。
では、なぜ継続的に価値を提供することが重要なのでしょうか？
今日のビジネスのスピードは非常に速く、変化に対応できるように継続的に価値を提供しなければなりません。
そこで、ここで覚えておいていただきたいのが次のキーコンセプトです。
もしあなたがDevOpsのベストプラクティスを実装しないとき、競合他社が実装するか、あるいは実装したときには、必ずあなたを凌駕するものになるだろう。
これはDevOpsの理論だけではありません。
私たちは長い間DevOpsを行ってきたので、この事実を知っています。
では、なぜDevOpsが重要なのか？
それは、継続的に価値を提供する必要があるからだ。
そうしなければ、アウトイノベーションになり、アウトイノベーションになれば時代遅れになる。誰も時代遅れにはなりたくないですよね。

DevOpsではないこと

DevOpsとは何かを考える際には、それが何ではないかをしっかりと理解しておくことも重要です。

これらはDevOpsではありません:

  • 方法論である
  • 特定のソフトウェア
  • 組織の課題を迅速に解決する
  • ただのチームや役職（DevやOpsの役職は業界では一般的なものですが、ここで言うDevOpsはこれを指していません。)

What is Azure DevOps?

Azure DevOpsには、より良いチームコラボレーションのために使用できるツールがいくつか用意されています。
また、自動化されたビルドプロセス、テスト、バージョン管理、パッケージ管理のためのツールもあります。
これだけでもかなりの量になります。
最終的にはすべてのツールについて説明します。
今のところは、Azure DevOpsとは何か、どのようにして始めることができるのか、という概要を説明しながら、チームについていきましょう。

マーラ: アミタがツールについて尋ねてきたので、私はAzure DevOpsを使うことを提案します。

アンディ: クラウドにデプロイしていないのに、クラウドサービスであるAzureの何かを使うことができるのでしょうか？
それに、私たちはLinuxにデプロイしています。
それなのに、その提案は重要なことですか？

マーラ: これらのツールは、クラウド・オンプレミス問わずに利用できる素晴らしいツールです。
また、LinuxやWindows、他のプラットフォームにデプロイするかどうかも関係ありません。
Azure DevOpsは、エンタープライズグレードのツールチェーンを望む人のためのソリューションを提供する一連のサービス群です。
これらのツールは、先ほど説明したすべてのプラクティスを実現するのに役立ちます。

以下がその内容です。
Azure Boards Azure Boards これらはアジャイルなツールで、他のチームとの作業を計画し、追跡し、議論するのに役立ちます。
Azure Pipelines Azure Pipelines. これらは、あらゆる言語、プラットフォーム、クラウドで動作する CI/CD でビルド、テスト、デプロイを可能にしてくれます。
Azure Test Plans Azure Test Plans. これらは手動でのテストと探索的なテストツールです。

私が今使おうと思っていたのはこの3つです。他にも後から考えられるサービスが2つあります。
Azure Repos Azure Repos. これらは無制限にクラウドホスティングされたプライベート、パブリックのGitレポを提供しています。
Azure Artifacts Azure Artifacts. パッケージを作成、ホスト、共有することができます。

Abel氏がAzure DevOpsの5つの部分について説明している短いビデオがあります。

アベルに聞く(翻訳者注：ここではビデオが流れます。ビデオでアベルが話した内容をできるだけ意訳していますが、正しくは本編を参照ください。)

Azure DevOpsとは？
Azure DevOpsは私たちが持っている製品で、文字通り、あらゆるプラットフォームを対象としたあらゆる言語で、アイデアをエンドユーザーの手に渡ってソフトウェアの一部として機能させるために必要なすべてのものです。
つまり、たくさんのことが詰まっているということですね。
どういう意味でしょうか？
Azure DevOpsは、4つのDevOpsツールのスイートで、すべてのことができるようになります。
第一に、Azureボードがある
Azure Boardsでは、Azure Boardsを使用して、ソフトウェアプロジェクトの作業単位を追跡することができます。
次はAzure Reposです。
Azure Reposでは、これはソース管理システムです。
つまり、集中型のソース管理システム、またはGitのような分散型のバージョン管理システムを作成し利用することができます。
Azure Reposはそれを実現してくれます。
次に、Azure Piplelinesですが、Azure Pipelinesを使うと、パイプラインを素早く簡単に作成し、ビルド、リリースすることができます。
次に、Azure Testsですが、手動によるテスト計画を作成することができます。
そして最後に、Azure Artifactsがあります。これは、すべてのものを保存できるAzure Artifactsリポジトリです。
ご覧のように、もう一度。
Azure DevOpsとは？
ソフトウェアプロジェクトに必要なものはすべて揃っています。

アミタ: たくさんありそうだね。何から始めようかな？

マーラ: とりあえずAzure Boardsを使って計画を立ててみて、どのように行うか確認しましょう。
Azure DevOpsが提供するすべてのサービスを使う必要はありません。　　
必要なものだけを使えばいいのです。

ティム：じゃあ、まず何をすればいいの？

マーラ：簡単です。
アカウントと組織を設定するだけです。
すべてのプロセスは数分で終わります。

Exercise – Azure DevOps organizationの作成

マイクロソフトは、個人、小規模チーム、オープンソースプロジェクト向けに無料のAzure DevOpsアカウントを提供しています。
また、企業は、数千人のチームメンバーにスケールアップできるAzure DevOpsアカウントにサインアップすることができます。
無料の Azure DevOps organizationにサインアップして、そのサービスがどのようにDevOpsの旅に役立つのかを確認してみましょう。

注意
この学習パスでは、Microsoft がホストする Azure DevOps Services を使用します。
また、Azure DevOps Services のオンプレミス版である Azure DevOps Server もあり、これを自分のネットワーク上にインストールして実行することができます。

Azure DevOps 組織を作成する

それではマーラ達のチームと一緒に無料のAzure DevOps organizationをセットアップしましょう。

  1. dev.azure.comに移動します。
  2. Start freeボタンをクリックします。
  3. Microsoftアカウントを使用してサインインします。または、Microsoft アカウントをお持ちでない場合は、Create One! を選択し、手順を完了してください。
    > 注意
    > マイクロソフトが提供するアカウントを持っている場合、アカウントはhotmail.comまたはoutlook.comのドメインになっています。
  4. 利用規約、プライバシーステートメント、行動規範を確認し、同意する場合は「続行」を選択してください。
    > 注意
    > Azure DevOps組織を作成する者として、自動的にオーナーになります。アカウント名を決める際には、既存の法人を避けるといった考慮をしてください。

organizationを作成する

次に、organizationを設定します。ここではその方法を説明します。

  1. Azure DevOpsの組織を作成したことがない場合は、新しい組織の作成ボタンがあるウィンドウが表示されます。
    作成したことがある場合は、新しい組織を読み取るリンクが表示されますので表示されたオプションを選択します。
  2. Azure DevOps の利用規約とプライバシーの通知ウィンドウが表示されますので、[Continue] を選択します。
  3. dev.azure.com/フィールドの横にMicrosoft Learnモジュール用の組織を作成します。
    名前がすでに他に取得されていることを促された場合は、最後にいくつかの数字を追加して一意になるよう変更します。
    例）Tailspin0523
  4. プロジェクトがホストされる近くの場所を選択し、[Continue] を選択します。

続きの画面では、プロジェクトを作成するように促されますが、これは次の章で行います。

おめでとうございます。

次の章では、チームはAzure Boardsを使用して、最初のプロジェクトとバックログを作成します。

まとめ

このモジュールでは、DevOps とは何か (そして何ではないか) と、Microsoft DevOps スイートである Azure DevOps について学びました。
また、Azure DevOps にアカウントを設定し、組織を作成しました。

エリートパフォーマーとローパフォーマーを比較すると、エリートパフォーマーの方が、より頻繁に、より迅速に、そしてより少ない失敗でデプロイしています。
このような考え方を持つことで、彼らは変化する市場の状況にうまく適応し、新しい機能を試し、インシデントから回復力を高めて回復することができます。
DevOpsは、エリートパフォーマーへの道を提供します。

エリートパフォーマーであっても、変化は徐々に起こり、多くの場合、最も差し迫った課題や問題点から始まります。
DevOpsの実践には時間がかかります。

より深く学ぶには

今後のモジュールでAzure DevOpsをさらに深く掘り下げていきます。これらのリソースもチェックしてみてください。

KPIと品質指標の推奨事項

DevOpsでは、具体的で、測定可能で、時間的に拘束された目標を持つことをチームに推奨しています。
これらの目標を測定可能なものにするためには、チームが適切なメトリクスと主要業績評価指標（KPI）に合意することが重要です。
特定のビジネス成果に焦点を当て、投資収益率とビジネス価値の向上を達成する指標を選択することが重要です。
ここでは、すべての DevOps チームに適用される一般的に使用されるメトリクスと KPI のリストを紹介します。

より速い成果

  • デプロイの頻度(Deployment Frequency) デプロイの頻度を上げることは、しばしば DevOps チームにとって重要なドライバーとなります。
  • デプロイのスピード(Deployment Speed) デプロイの頻度を上げるだけでなく、デプロイにかかる時間を短縮することも重要です。
  • デプロイのサイズ(Deployment Size) 毎回どのくらいの機能、ストーリー、バグ修正がデプロイされているか。
  • リードタイム(Lead Time) ワークアイテムの作業を開始してからデプロイされるまでにどれくらいの時間がかかるか。

効率性

  • サーバーと管理者の比率(Server to Admin Ratio) プロジェクトは、指定された数のサーバーに必要な管理者の数を減らしているか。
  • スタッフと顧客の比率(Staff Member to Customers Ratio) 与えられた数の顧客にサービスを提供するために、より少ないスタッフ・メンバーが可能であるか。
  • アプリケーション利用率(Application Usage) アプリケーションはどのくらい利用されているのか
  • アプリケーションのパフォーマンス(Application Performance) アプリケーションのパフォーマンスは改善しているか、または低下しているか。(アプリケーションのメトリクスに基づく)

品質とセキュリティ

  • デプロイの失敗率(Deployment Failure Rates) デプロイメント (およびアプリケーション) が失敗する頻度は？
  • アプリケーションの障害率(Application Failure Rates)。設定の失敗、パフォーマンスのタイムアウトなど、アプリケーションの障害が発生する頻度。
  • 平均復旧時間(Mean Time to Recover)。障害からどのくらいの速さで復旧できるか。
  • バグ報告率(Bug Report Rates)。顧客がコードのバグを発見することは避けたいものです。発見される量は増えていますか、それとも減っていますか？
  • テスト合格率(Test Pass Rates)。自動化されたテストはどの程度機能していますか？
  • 不具合脱出率(Defect Escape Rate)。本番環境で発見されている不具合の割合はどのくらいですか？
  • 可用性(Availability)。アプリケーションが顧客に本当に利用可能な状態になっている時間の割合は何％ですか？
  • SLA の達成度(SLA Achievement)。サービスレベル契約（SLA）を満たしていますか？
  • 検出までの平均時間(Mean Time to Detection)。障害が発生した場合、それが検出されるまでにどのくらいの時間がかかりますか？

文化

  • 従業員のモラル(Employee Morale) 従業員は変化と組織がどこに向かっているかに満足しているか。彼らはまださらなる変化に対応する意思があるか。
  • 保持率(Retention Rates)。組織はスタッフを失っていませんか？

DevOpsの約束のひとつに「ソフトウェアをより速く、より高い品質で提供する」があります。
これらの約束は矛盾しているように見えるかもしれません。
従来、ソフトウェアをより早く提供すればするほど、品質は低くなります。
高品質のソフトウェアは常に時間がかかっていました。
しかし、DevOpsプロセスは問題を早期に発見するのに役立ち、通常は修正にかかる時間が短くなることを意味します。

一般的な品質評価基準

  • 失敗したビルドの割合(Failed Builds Percentage) – 全体的に、ビルドが失敗している割合は？
  • 失敗したデプロイの割合(Failed Deployments Percentage) – 全体的に、デプロイに失敗している割合は?
  • チケット量(Ticket Volume) – 顧客のバグチケットの全体的な量はどれくらいか？
  • バグバウンズ量(Bug Bounce Percentage) – CloseしたはずのバグチケットがReopenされている割合は何％ですか?
  • 計画外の作業の割合(Unplanned Work Percentage) – 実行されている作業全体のうち、計画外の作業の割合は何％ですか？
このエントリーをはてなブックマークに追加