aretan.jp

Welcome to DevOpsDays 2019¶

DevOpsの原則を実行していくことで、変化は自然と起こっていく
セキュリティ パフォーマンス 安定運用
この3つが三つ巴になっている。全てを抑えるのが難しい

Lessons Learned Since The Phoenix Project¶

1999から成果の高い組織を研究している
Gene KimさんLeanとDevOpsの科学 Accelerateの著者
Phoenix Projectという有名な本を書いた人
1960年にLEANでディストラプトされた
今ではDevOpsが今とても熱い
Definition of DevOps
1Architecture, technical practices, cultural norms
2Better, Faster, Safer, Happier
もうこれが科学的に正しいという事が分かっている
そして今、Unicorn Projectという本を書いている
技術的負債、次に変更しなければならない事
色々な悪いことが蓄積してしまっている
マニュアルのデプロイ、コンフィグ、手動のテスト
時間とともにどんどんと悪化してしまう
デプロイに6週間かかった、1300のステップ
年間に2回のデプロイ、300人がかりで練習もする
DevOpsはみんなに影響する。DevOpsの原則をする
DevOpsのビジネスバリューが本当にすごい
Development Frequency 46x
Deployment Lead Time 2555x
Deploy Success Rate 7x
Mean Time to Restore 2604x
By Google 2018 State of DevOps Report
組織目標についても2倍の速さ
Net Promoter Scoreも2倍高い
Code Deployment Lead Timeが最も戦略的メトリクス
Deploys per day、LEANならlead time
Product Design and Developmentは発想的な仕事
Product Deliveryはビルド、テスト、繰り返しの作業
Deploymentsに対する恐怖心の7段階のスケール
Conwayの法則がどのような影響を与えるのか
2008 Devs and DBAs 2チームが協力していた
2009 追加でSprouter teamを作った
デプロイのリードタイムは短くなったけど悪くなった
2010 Devsだけにした 何もかもが良くなった
Lesson: 組織の箱がたくさんある、再編成よりコミュニケーション
チームがばらばらに働けるアーキテクチャが無い
アーキテクチャがチームをEnableする
アーキテクトは絵を1枚送ってくるだけ
Puppet 2017 State of Devops
The Value of Platform
Enable Developer Productivity
→Self-service, On-demand, Immediacy and fast feedback
DevopsはUnicornsだけのものだけなのか？
Horsesにも必要だと6年の研究でわかった
2018年 DevOps Enterprise Summit
とても古い企業たちがDevOpsで成功していた
TEP and LARB annihilation
これらを壊したという功績
まずTEPを書く、そしてLARBでピッチをする
100人のエンジニアはこんな事を経験させてはいけない
これから1000人のエンジニアに経験させてはいけない
Leadershipというのはとても重要だとわかった
ハイパフォーマーはLeadershipが居るところに多かった
しかしこのGreatnessは無料じゃない
技術的負債を払わなければならない
Microsoft 2002 Bill Gates memo, Security standdown
INSPIREDという本、POの本、20％をTechDebtに当てろ
The five ideals
1 Locality in our code and organizations
2 focus, flow and joy in our daily work
3 enablement of improvement and achievement
4 a culture of psychological safety
5 a ruthless and relentless focus on our customer
Andonはtoyotaでは毎日どれぐらいひかれるのか
3500回も毎日引かれている事がわかった
Google Dev and ops 2013
Typology of organizational culture 2004
病院の心理的安全性の研究、低いと隠蔽してしまう
Realgenekim@sendyourslides.com
Subject: devops
これでスライドを送るからメールしてください

技術的負債を返す時間で市場から置いていかれるのでは？
3年がかりで返すとなったら大丈夫なのか？
EbayやGoogleやFacebookはそういう決断をした
もうやるしかなかった、その選択しかなかったからやった

How we moved 7500 microsofties to DevOps in the Cloud, Microsoft¶

Team Fundation Serverを販売していた。DCにインストールして使う。
今でいうとDevOpsのソフトのようなもの。
数年おきにバージョンアップをしていた。
コードをチェックインしてから2年かかっていた。
MicrosoftにはDevOpsの定義は一つしかない
人、プロセス、プロダクト、で協力して、
継続的に価値を提供する。
DevOpsを適用する事で、非常にデリバリーができる組織になる。
成果に基づいた企業の方が、人に会社を勧める。
それぞれのチームが別々のツールを使っていた。
One Engineering System - Satya Nadela
Azure DevOpsは自分たちでも使う
Azure Boards, Pipelines, Repos, Test Plans, Artifacts
Microsoftの10万人がAzure DevOpsを使っている
82000 Deployments per day
1Qに1回リリースすることにした
そして今はWeb Applicationにした
ブランチ戦略はコンウェイの法則になる
チーム間の分断が速度を遅くする
チームルームを作った1.0-12people
Clear charter and goals
リードDeveloperは5つまでの技術的負債を持てない

BDD in DevOps CI&T¶

BDD in Development Phase
Communication between tech and non-tech teams
The requirements are written in a format that is understandable
誤解の予防やテスト自動化に役立つ
Gherkin language
Given, When, Thenで表現する
-> User Story
As a store owner
In order to keep track of stock
I want to add items back to....
-> Gherkin Language
Given: that a customer previously bought a black sweater from me
And: I have three black sweaters in stock.
When: they return the black sweater for a refund
Then: I should ...
BDD Tools
Cucumber, be hat, specflow
cucumberが一番有名
SolutionとしてBehatを使うことにした
そしてRegression TestにBDDを使った
CMSをきちんと使ってないと問題が起こってしまう
本場環境で問題がでてきた
だから、本番環境でもモニタリングしなきゃいけない
1データは変えない
2彼らのニーズに合わせた観点でテストする
3翻訳の問題も見る
4クライアントより早くJITで見つける
3分で12のウェブサイトを24時間7日でテストする

Openning¶

2017 Two DevOps Principles
チームをまたいだコラボレーション
できる限りすべてを自動化する

2018 DevOps in Japan
エンプラ系企業が興味を示している
SI系企業はDevOpsを検討している

2019 DevOps is for Everyone
あらゆる組織で実現は可能 巨大なエンタープライズでさえも
特殊な誰かのためだけのものではない
エンジニアやTechサイドの人間だけでは実現できない

Agile Japan Community
アジャイルは日本に深く根付きつつある
実行委員の多くが初めてDODaysに参加した
貴重な情報交換をすることができた
Agile isn’t enough, you need DevOps

Five Development Practices for Agile DevOps¶

Tobeagile.com David Bernstein
エドワードデミング博士が師匠
アメリカではそれほど有名じゃない
Agileを生み出した父だと思っている
スクラムはアジャイルの最初のステップ
素晴らしい開発者がどういうことをやっているのか
生産性の高い開発者は何が違うのか
そういう人たちのスキルを学べばそうなれる
18個のプラクティスと12個の・・・
プログラミングはコミュニケーションの方法
レガシーコードを超えて という本を書いた
xpみたいなテクニカルなプラクティス
CI, TDD, Refactoring, Pairing
アジャイルマニフェストを書いたのは開発者
開発者のために書いた
アジャイルがビジネスになってしまった
アジャイルを取り戻したい
スクラムのようなミーティングだけでなく
質のいいソフトウェアを開発したい
Agile Software Development with Scrum
This book shows readers how to use Scrum,
An agile software development process, to quickly
And seamlessly implement XP in their shop-while still
Producing actual software.
プラクティス3 継続的に統合する
インテグレーションは痛みを伴う
3つのDone
Doneは開発がおわった
Done-Doneはインテグレーションまで終わった
Done-Done-Doneはコードがクリーンになっている
Continuous Deployability
なぜテストを2回やったんだ
だって気持ちいいじゃないか グリーンのバーが出るの
最初の一歩を踏み出す
継続的インテグレーションを始めよう
Enterprise software development is a social activity
ペアプログラミングはほんとやるのは大変
一人でこの机を動かそうというのは難しい
ソフトウェアの場合はどうだろうか？
数時間ペアリングしたら、とても疲れる
それが難しかったらバディプログラミング
今日なにをビルドしたか、夕方に確認する
モブプログラミング
今まで全く開発できなかったけど、集まったらできた
それから毎日やるようになった。どんどん進むようになった
Spiking, Swarming, Mobbing
常に誰かにメンターしなさい、そして誰かにメンターされなさい
プラクティス5 クリーンなコードを書く
Cohesive, Loosely Coupled, Encapsulated, Assertive, Nonredundant
良いコードはこういう5つの性質を持っている
Cohesive 凝縮度が高い
Assertive 他のオブジェクトを持ってこなくてもいい
Encapsulated 他のところを壊さずに変更できる
Nonredundant 冗長ではない
コード品質は私たちを導く
プラクティス6 先にテストを書く
TDDはもうデッドムーブメントと言われている
テストを書きすぎる 実装に依存しているテストを書く
だからBehaviorをテストする、BDDやATDDをする
Acceptance testsはcustomer tests、これはコミュニケーション
Unit testsはdeveloper tests開発者を助ける
Other testsはassurance testsソフトウェアにバグがない
TDD doesn’t replace QA but it can help
QAは作った後に検査するという機能を持っている
ペースメーカーにバグがあってはいけない
良いテストの書き方分かっている開発者は少ない
コードをテストしない、振る舞いをテストする
台所が汚れいているのに、料理をはじめませんよね？
まずはキッチンを掃除する、フライパンを洗う
テスト可能なコードを書く
TDDは失敗する可能性があります
Use TDD to specify behaviors, not to test implementation
開発者にTDDを押し付けることはできない
TDDをやる経験をさせることはできる
テスト熱中症になる TDDが大好きになっちゃう
プラクティス9 レガシーコードをリファクタする
コードの振る舞いは変えずにコードの構造だけ変える
以下の4つのコストを削減することができる
Understanding the code later
Adding unit tests
Accommodating new features
Doing further refactoring
投資する？借金する？Investment or Debt?
毎月1回払いしか使わない人がいる Deadbeatと呼ばれる
開発者はDeadbeatになれ
Refactoring legacy code, use the simple refactoring
Refactor to the Open-Closed
オープンで拡張できるコードを書く
まずキッチンを綺麗にしてから料理をしましょう
Do it Right the Second Time
二度目に正しくやる、一度目に正しくやるのは難しい
Our highest priority is to satisfy the customer through
early and CD of valuable software
ジュニアのプログラマからも学べることはある

富士通のSIプロジェクトがどのようにDevOpsに取り組んでいるか¶

DevOps標準化活動
4万人のSE, 年間2000プロジェクト (売り上げ3000万以上)
Agile/DevOps技術者を増やしていかないといけない
売り上げを伸ばすために攻めのリリースをする
（あえて変化を起こしてフィードバックを得る）
SIからすると、見積もりからコストを引いたものがゴール
だから、リスクを負って攻めのリリースをする理由がない
推奨ツールを決めてばら撒くことにした
SIプロジェクトにDevOpsしようといっても響かない
SIプロジェクトの具体的な課題解決にフォーカス
・製造終盤に問題発覚し炎上
いろいろなちーむの成果物を結合する作業が大変
→チームリポジトリに1日1回はコミットしよう
→リーダーはセントラルリポジトリに週一でマージ
→ナイトリービルド：自動ビルドする
ーソース共有、自動ビルド、静的解析、ユニットテスト
・構成管理はExcelと手順書地獄
資産凍結をブランチのProtectで代用する
障害はIssue登録とする
修正はブランチでマージリクエスト
・気持ちが伝わらず孤独
MattermostというSlackみたいなのを導入
分報を推奨した
会議での会話をチャット流す
CI やばい状態にはやくきづける
CD 精神を病む単純作業が減る
Culture メンバー同士が仲良く助け合える

開発効率を最大化するデプロイメントパイプライン¶

6年で技術的負債がどんどん溜まっていっていた
事業を伸ばしてくれたことに感謝しつつリプレース
・組織の拡大についていけそうなもの
・簡単すぎず難しすぎない
・つぎにくる技術トレンド
2週間に1日は改善しかしない日
ProtocolBuffersを採用していてAPIのレビューを実装より先に実施
Uber/prototoolでチェック、フォーマットでPR見やすい
Lint, 単体, 結合などしてきていた
個人フォークして通知がやべー問題に対応

DevOpsっていってないDevOpsの話¶

きれいなヴァル研究所じゃなくて、実際の本体の話
適応しただけでは上滑りしてしまう
自分たちの状況に照らし合わせてみることが必要
上滑りの文明開化：夏目漱石
涙をのんで上滑りに滑っていかなければならない
同時多発的にいっぱいの問題がおこっていく
鳥の雛が卵から出ようと鳴く声と母鳥のつつくのが同時
社外から輸入して熟成していった結果
チームの秘密基地を作っていく
8名の会社と400名の会社が同じ生産性だった
アリスターコバーン：メールより電話よりホワイトボード
メラビアンの法則：視覚情報が55％
人間は33msで相手の感情を読むことができる
マンネリ化は暗黙知化した証拠？
競争に勝ち発展しようと思うなら知識を内部に入れるフローを作る
おもしろきこともなき世をおもしろく
ヒーローを待っていても会社は変わらない
偉大さを決定づけるのは環境ではなく何にも増して
自分自身の意思と規律できまる。
個人から出発すると心が折れる
しかしその行動が次の進展を作る。
足りないピースだったから勝手に個人で舵を切った。
この会社の現象はなに？アジャイル？DevOps？改善？
結果的にこういう状態になっているということ