Architecture Decision Record
← 決定記録の例

Microsoft Azure DevOps

目次:

概要

課題

プロジェクトのビルド、統合、デプロイ、ホスティングに devops を使用したい。Microsoft Azure DevOps を検討しています。

  • 開発者体験を、devops のセットアップ(例: 設定)と継続的な使用(例: 高速なビルド時間)の両方において、高速で信頼できるものにしたい。

  • プロジェクトのアプリ、データベースなどのホスティングに、Microsoft Azure 全体を使用することを検討したい。

決定

Microsoft Azure DevOps は採用しないことに決定しました。

状態

決定済み。重要な新しい情報が届いたとき、またはそのときには、見直しに対してオープンです。

詳細

前提

書籍『Accelerate』にあるような、通常の devops の前提すべて。

  • 高速なビルドは大きな助けになる。これはフィードバックループを加速させる。

  • 代替ベンダーのパーツを入れ替えることができる。つまり、より高速な自前のビルドサーバーを持ち込んだり、独自に選んだバージョン管理システムを使用したり、セルフホストの継続的インテグレーションサーバーと連携したりしたいかもしれない。

  • 合理化された使いやすさは、開発者体験にとって、そしてひいては一貫性、明確さ、セキュリティ、学習曲線の容易さといった微妙な領域にとって、大きな助けになる。

  • 何かが壊れたり問題が生じたりしたとき、その問題を報告する効果的な方法が欲しい。これは特にセキュリティ関連の問題にとって重要である。

制約

既知のものはありません。Azure は、外部ツールとうまく連携するという公表されたコミットメントを持っています。

ポジション

Microsoft Azure Devops と、現行である AWS を比較して検討しました。

Azure DevOps、Azure Pipelines、Azure Repo、Terraform による Azure での新しいサーバーの立ち上げを試しました。

Microsoft の担当者からサポートを得ることを試しました。

ブログや Hacker News で同業者から情報を収集しました。

論拠

Azure DevOps は優れた提供サービスを宣伝していますが、それらは期待に応えず、互いにうまく連携せず、サポートも貧弱です。

私たちの直接の経験:

  • Azure のセットアップは UI の寄せ集めで、一部は Microsoft アカウントと重複し、一部はそうではありません。たとえば、Azure サインイン、Microsoft.com サインイン、Live.com サインインなどがあり、すべてが同時に関わってきます。

  • セットアップ中に軽微なセキュリティ上の問題に遭遇しましたが、解決策が見つかりませんでした。多くの Microsoft 担当者に多くの方法で報告を試みましたが、成功しませんでした。Microsoft セキュリティには報告に成功し、修正しない(won't fix)という返答がありました。

  • 文書はしばしば間違っているか古くなっています。少なくともその一部は Microsoft の検索エンジンの貧弱さによるもので、一部は平均以下の SEO によるものです。

  • Terraform のセットアップは十分に文書化されており、動作します。しかし、Microsoft がベンダーとビジネス関係を築いて、連鎖的な Terraform セットアップの例を作成しているため、AWS と比べて Terraform のサポートは弱いです。

同業者の経験:

  • 自分たちでブラインド評価を行った後、同業者の経験を探しました。見つけたものは、私たちの経験を裏付けるものでした。

  • 同業者は、ビルド時間に関する追加の問題と、自前のビルドサーバーを持ち込む際の問題を報告していました。これらの問題は、UI の問題よりも大幅に深刻です。ビルドを行うことがビルドパイプラインの中核的な目的であり、1 日に多数のビルドを行うことを想定しているためです。

  • 議論の場で、Azure のチームメイトによる優れた参加が見られました。これについて Microsoft に称賛を送ります。特に Azure の PM でありコーダーでもある Edward Thomson には、その参加、率直さ、技術的な説明に感銘を受けました。

影響

Microsoft Azure DevOps を選択すると、Azure を選択しない場合よりも、時間とコストの面で高くなる(約 3 倍)可能性が高いようです。

関連

関連する決定

Azure DevOps を選択する場合、Azure Repo、Azure Pipeline など、多くの関連する提供サービスがあります。Azure Devops を選択すると、より多くの Azure の機能を使用しやすくなるか、他のベンダーの機能を使用しにくくなる可能性があると考えています。

Microsoft は開発者体験において大きな進歩を遂げており、開発者ツール(例: GitHub)や依存関係(例: Citus)の大規模な買収を行っているのを目にしています。

Azure DevOps を選択する場合、Microsoft が買収した提供サービスを選ぶことを重視したくなるかもしれません。また、組織への拒絶反応(たとえば、スタッフの離職リスク)の可能性があるため、買収した提供サービスにはより注意/評価をして臨みたくなるかもしれません。

関連する要件

ビルド時間を非常に高速にしたい。そのために高いプレミアムを支払うことを受け入れます。非常に素早く反復したいからです。

信頼性を非常に高くしたい。そのために高いプレミアムを支払うことを受け入れます。金融取引や機密取引など、価値の高いユースケースをテストしているからです。

上位 4 つの devops KPI には平均復旧時間が含まれており、これには高速なビルドと高い信頼性が必要です。

関連する成果物

ビルドシステムが、Artifactory など他のシステムで使用するのに適した成果物を出力することを望みます。

関連する原則

容易に元に戻せる。Azure DevOps を、現行の AWS と並行して評価できます。

メモ

Microsoft Devops CI: An Unsatisfying Adventure

https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/

ブログ記事。

「ソフトウェア開発者として、品質の高い製品を素早く安価に作ることがいかに難しいかを身をもって知っています。それは時に正しくできる芸術の一形態であり、他の時にはオバマ政権時代の政府の医療保険サイトのようなものに堕落します。結果として得られる製品に対する私たちの制御のレベルはさまざまで、失敗の責任はしばしば意思決定の階層における間違った人々に押し付けられます。Microsoft の Azure DevOps(旧 Visual Studio Team Services)は、明らかに善意があるにもかかわらず、悪い決定と貧弱な実行の完璧な嵐です。」

Hacker News の議論のハイライト

https://news.ycombinator.com/item?id=18983586

「私の職場では Azure DevOps を広範囲に使用しており、GitHub、Gitlab、セルフホストのソリューション、Jenkins、TeamCity を使った後では... Azure DevOps は最下位です。」

「UI はどこをとってもひどくぎこちないです。私にとって最悪なのはプルリクエストです。プルリクエストで人と一緒に作業するのは信じられないほど大変です。『ある』特定の問題を指摘することさえできません。私たちにとっては、すべてが壊れています。」

「Azure Devops は私が愛したいと思うものです。UI は変わり続けますが、ずっと前からある根本的なバグは直りません。」

「ツールはうまく統合されておらず、UI は本当に遅く、お気に入りのリポジトリのアクティブなプルリクエスト、ビルド、リリースなどのダッシュボードビューもありません。ビルド/デプロイの時間は異常なほど遅いです。」

「Azure Boards(Work Items、Boards、Backlogs など)も使ってみました。うわあ。バラバラのアイデアの完全な UI の混乱です。1 つのことをうまく実装する代わりに、2 ダースのことをひどく実装しています。」

Windows Development MVP

ここにいる Windows Development MVP です。これらの問題についてもっと声を上げなかったことに、私にも責任の一端があると感じています。しかし、UX の問題について「驚いた」と聞いて、がっかりしていると言わざるを得ません。私は(たとえばローンチ前の頃から)あなた方に UX がひどいと伝え続け、「分かっている、直している」という返答を聞き続けてきました。私はフィードバックを正式にまとめて、パイプを通して届けるつもりです。続報をお待ちください。私は地元(ベルビュー)にもいるので、比較的単純なオープンソースの .net/wpf/uwp アプリでパイプラインを作ってみるために、ぜひお伺いしたいです。お互いにとって目を開かされる経験になると思います。

いくつかの例:

  • サブモジュールを含む git リポジトリでパイプラインを構築できない

  • 一部のカスタムツールのために PATH を編集することが不可能だと分かった

  • 新しいパイプラインの体験はまったく意味をなさず、新規ユーザーがあちこちクリックしていると、結局は間違ったドキュメントにたどり着く。

Edward Thomson(Azure PM)の概要

あなたのプルリクエストをマージするコードを書きました。Microsoft の Azure DevOps のプログラムマネージャー。以前は GitHub、Microsoft、SourceGear でバージョン管理ツールのソフトウェアエンジニア。

https://www.edwardthomson.com/

libgit2 の共同メンテナー。https://libgit2.github.io

All Things Git(Git に関するポッドキャスト)の共同ホスト。https://www.allthingsgit.com/

開発者ツールに関するニュースレター、Developer Tools Weekly のキュレーター。https://developertoolsweekly.com/