Azure

DevOps at Microsoft

内製化の準備できていますか？Microsoft Azureを活用したソフトウェア開発徹底解説！

https://alterbooth.connpass.com/event/178424/

日本マイクロソフト 平岡一成

Microsoft における DevOps への道のり

2020/07/03

15 min

平岡一成 ひらおかいっせい日本マイクロソフト株式会社

パートナー事業本部、パートナー技術統括本部

クラウドソリューションアーキテクト

担当領域

Azure Apps (Application Development)

Web, API, PaaS, Serverless, OSS, Container, DevOps

経歴• 2004年より、エンジニアとしてWebアプリケーション開発・運用プロジェクトに従事。

• 2012年に国内最大手EC事業会社に入社。サービスを支えるバックエンドAPIの開発・運用を行うグループマネー

ジャを担当。大規模＆高負荷システムの構築を得意とする。

• 2017年３月より現職。Azureパートナー向けの技術支援やPoC支援などを担当し、現在に至る。

@hoisjp

hoisjp自己紹介

これまでに Microsoft が学んだ5つの習慣

課題を解決していくストーリーたち

全てをご紹介できないので、5つのうち、なんとかひとつを抜粋

クオリティのシフトレフト

どのように品質を作りこむか

最後に少しだけ、”私が” 感じているギャップ

なぜ、そんなに急ぐのか

アジェンダ

ご紹介 (1)：読み物がこちらにたくさんhttps://docs.microsoft.com/ja-jp/azure/devops/learn/

• Learn DevOps

• Learn Git

• Learn Agile

• DevOps at Microsoft

• DevOps Events and Talks

• DevOps Self-Assessment

ご紹介 (2)：日本語で解説したブログ記事https://link.medium.com/VLgaGkThx7

これまでにMicrosoft が学んだ5つの習慣

カスタマーフォーカス

プロダクション・ファースト マインドセット

チームの自律とアラインメント

クオリティのシフトレフト

柔軟なリソースとしてのインフラ

Shift Left Qualityいかに 早い段階で問題を見つけて解決するか

これまでにMicrosoft が学んだ5つの習慣

カスタマーフォーカス

プロダクション・ファースト マインドセット

チームの自律とアラインメント

クオリティのシフトレフト

柔軟なリソースとしてのインフラ

パイプラインの管理

速くするかどのように

そして、いかに

破壊しないか

シフトレフトいかに、早い段階で、前の工程で、問題を見つけて解決するか

チームのエンジニア数#

負債をためないたまった負債は、速度低下につながる

私たちは「バグキャップ」と呼ばれる単純なルールに従います。

5 ?x =

See also: Agile principles in practice

https://docs.microsoft.com/ja-jp/azure/devops/learn/devops-at-microsoft/agile-principles-in-practice

プルリクエスト

PRはコードレビュー際に

マージの前に実行される L0 + L1 テスト

コミット前にテスト済みのセキュリティ

結果:

マージ前のテスト

1/5 のプルリクエストが失敗する

CIビルドの失敗

1/100 のCIビルドが失敗する

内側と外側のループを加速する

プルリクエストに対するテスト数分でのフィードバック、PRの承認前

緑は成功、赤は失敗を意味する完全にグリーンなビルドのみがリリースされる

• Tests that anyone can run anywhere (inc production)

• Shifted to unit tests from automated functional tests

• Core tests run before pull request

• Fast and 100% reliable build and test is critical

• Rolling tests run after commit

テスト：統合からユニットへのシフトレフトL0 – ビルドされたバイナリのみが必要で、

依存関係はない

L1 – SQLおよびファイルシステムを使用する機能を追加。

プルリクエストビルドでL0とL1を実行する

L2 – REST APIを介してサービスをテストする

L3 – エンドツーエンドをテストするための完全な環境

いかなる目標も完璧ではない

そのため、暴風域を制御する 1

段階的な展開

一度に1つのステージ展開

リリースゲートが進行を制御

現在のリングを確認する自動（L3）テスト

明示的な承認で速度が低下する可能性

結果

すべての展開の影響に対する可視性

横断のデプロイ

カナリアリリース

ユーザー数の少ないデータセンターへの対応

ユーザー数の多いデータセンターへの対応

低いのレイテンシー

”私が” 感じているギャップなぜ そんなに急ぐのか

DevOps 文脈でよく見る図とにかく ぐるぐる回っている

あふれるキーワードたち：

“カイゼン”、”アジャイル”、“どのように速くするか、いかに破壊しないか”

視点が だんだんと 内向的になりがち

ContinuousDelivery

プラン +

トラック

モニター + 学習

リリース開発 + テスト

なぜ そんなに急ぐのかメンバーそれぞれ筋力をつけ、自動化をして、密なコミュニケーションをとり、・・・

Photo: Wikimedia Commons https://commons.wikimedia.org/wiki/File:Flickr_cc_runner_wisconsin_u.jpg

プレイヤーは組織の外、すぐそこにいます組織の内側に向きがちな視点をいちど外側に向けてみる

Photo: Wikimedia Commons

https://commons.wikimedia.org/wiki/File:Off_they_go._There_had_been_a_false_start_and_the_runner

_was_shown_a_great_big_red_card_then_marched_off._So_mean._(7745214550).jpg

多くの場合、

解決する課題は同じ

• “あなたのアイデアは他の誰かが最初に

思いついている”

• 目のつけどころレースというよりは、

より早く形にするレースになっている

中ではなく隣を見てみる

• 先にゴールされると、”くやしい”

• 煮詰まったら、競合調査も効果的

他者を圧倒してゴールする瞬間を想像する取り組むべき課題の優先度が、少し変わって見えるかもしれません

Photo: Wikimedia Commons https://commons.wikimedia.org/wiki/File:Usain_Bolt_winning-cropped.jpg

© Copyright Microsoft Corporation. All rights reserved.

Thank you!

http://aka.ms/devops