Azure DevOps を1年間使ってみて押さえておくべきと思ったこと

これはAzure DevOpsアドベントカレンダー5日目の記事です。

qiita.com

仕事でも個人でも Azure DevOps Services を使って1年くらい経ちました。 Azure DevOps Services を選択してから現在までの経験の中で、これから使う方々が押さえておくべきであろう事柄の要点を綴ります。 機能や価格などは本記事執筆時点のものです。

割安

azure.microsoft.com

Basic Plan では Boards というプロジェクトマネジメント機能、Repos というリポジトリホスティングレビュー機能、 Pipelines というコミットや周期をトリガーとしたジョブ実行機能を使うことができます。 これらが連携することにより、計画、成果物更新、テストをつなげることができます。 荒っぽいですが、OSS で言えば Redmine + Gitea + Jenkins、アトラシアン製品で言えば JIRA + Bitbucket + Bamboo に相当します。

価格は1月1ユーザー672円です。 単純に、計画、成果物更新、テストを連携する機能の有無で比較するなら商用ツールとしてはとても割安だと思います。 もちろん UX や組織との親和性は別途熟慮する必要はありますが、機能でみればという意味です。 Pipelines でたくさんのジョブを実行するとなると別料金がかかります。 私たちの用途ではそれを含めても割安に思えました。

これだけで DevOps ができるわけではない

DevOps - Wikipedia

∞ の形で表される DevOps のサイクルを実現するためには、市場に出したプロダクトがどう使われているかを観測して次のソフトウェア要求を導出するプロセスが必要ですが、 Azure DevOps にはそのための機能はありません。

サービスレベルとセキュリティ

企業でクラウドサービスを導入するには、ましてや開発の基盤に据えるサービスであるからには相応のサービスレベルとセキュリティが求められます。 それを確かめるためには Data security, Azure DevOps Services というページを読むことをおすすめします。 docs.microsoft.com

また、Azure 全般について国際標準の認証、法令順守がまとめられているページも参考になります。(例:ISO 27001、GDPR) docs.microsoft.com

ユーザー管理のセキュリティについては Azure DevOps だけでなく Azure Active Directory と合わせて知る必要があります。 ここはソフトウェア開発ツールだけを探している人々には気づきにくい盲点ではないかと思います。 必要なセキュリティ機能を使うためには Azure Active Directory の料金が必要となるかもしれず、 Azure DevOps の料金と合わせたら予算オーバーしてしまったということがないよう気を付ける必要があるでしょう。 azure.microsoft.com

サービスレベルについて。Twitter では知人がまれに「GitHubが落ちてるから今日は仕事できない」という旨のツイートをすることがあります。 Azure DevOps についてもそういったことはあります。 ここ1年で私がサービスダウンを観測した日数は2、復旧時間は4時間以内でした。 これくらいであれば商用サービスとして十分ではないでしょうか。

Azure DevOps が生きてるかは https://status.dev.azure.com/ で確認することができます。 いつもは安定稼働しているので緑色なのですが9月には真っ赤な日もありました。

英語

UI、公式ドキュメント、公式GitHubプロジェクト、公式サポートサイトは全て英語です。 ググればだいたい Qiita がヒットする、日本代理店のサポートを受けられるという環境に慣れており、 英語の技術情報に触れる機会に乏しい方にはつらいかもしれません。

オンプレ版からの移行はハード

これは他のトピックからみれば人を選ぶ狭いものですが、オンプレ版 (Azure DevOps Server または Team Foundation Server) からの移行はとてもハードです。 公式の移行ツールはあります。だから、「移行元と移行先情報を入力してボタン1つ押せば終わりっしょ」と思ったら大間違いです。 移行方法を解説した動画の再生時間は70分もあります。 Microsoft SQL Server, Azure Storage, Azure Active Directory の利用経験があればよし、なければ苦戦するはずです。

docs.microsoft.com

Boards は慣れるまでの鬼門

Repos は特にドキュメントを読まなくても、Git さえ使ったことがあれば試しているうちに慣れると思います。 Boards は別です。Work item を作るだけでも複数の方法があるので迷います。 特に最初にチームのルールを決める人はかなり独自の概念を理解する労力を必要とするでしょう。 例えば公式ドキュメントにある Choose a process というページは Boards を理解する上でトップクラスに重要であり、以前に解説を書きました。 masskaneko.hatenablog.com

docs.microsoft.com

API

Azure DevOps ではたくさんの API がサポートされており、ライブラリもあります。API のサンプルコードもあります。 私は PythonAPI ライブラリを使っています。 ただし、すべての API についてサンプルコードがあるわけではありません。 引数に何を入れればよいかわからない API に直面することもあります。 Stackoverflow を探せば API ライブラリを使うコードが出てくることがあります。 無ければライブラリのコードを読む必要があります。 これは Azure DevOps 特有の話ではないと思いますが、そういったプロセスに慣れていない方にとっては意外にしんどいものとなるでしょう。

docs.microsoft.com

github.com

github.com

stackoverflow.com

継続的なアップデート

3週間に1度というアップデート頻度は早く、自分でアップデートしなくてよい恩恵はとても大きいと感じています。 個別の OSS を組み合わせてセルフホストしなくてよかったと本当に思います。

以前に意外とこの機能がない、というものをまとめた記事を書きましたが、 この中にあるもので現在は実装されたものがいくつかあります。 masskaneko.hatenablog.com

とはいえ、自分達が欲しい機能からどんどん実装されるわけではありません。 Feature Timeline にはこれから実装予定の機能がまとめられています。ここにあればラッキー。 なければ Developer Community で訴えてゆくしかありません。 欲しい機能を検索し、あれば最低でも +1 を押し、できればなぜ欲しいかをコメントする積極性が必要だと思います。 本アドベントカレンダー4日目の記事(Azure DevOpsへ機能要望のTIPS)が参考になるでしょう。

docs.microsoft.com

https://developercommunity.visualstudio.com/spaces/21/index.htmldevelopercommunity.visualstudio.com

kkamegawa.hatenablog.jp

TFSUG に入って!

Azure DevOps (旧 Team Foundation Server を含む) のコミュニティとして TFSUG というものがあります。 私は同種のコミュニティとして Redmine Tokyo が思い浮かぶのですが、 比べると人数も勢いも TFSUG は小さいものです。だから使っている方々、興味ある方々、入って!そして私を助けて!(私も助けようとします) 一緒に楽しめる仲間が増えますように!以上で~す

Connpass や Slack のリンク、会則などもろもろは Azure DevOps のパブリックプロジェクトにあります。 https://dev.azure.com/tfsug/tfsuginfo