さて、２日目についてのメモです。
☆楽天でのDevOps実践事例とAzureベストプラクティス
前半はEnterprise AgileやDevOpsをどうやって全社に広めるか、後半はAzureでの実装実例でした。
今日の定義：アジャイル開発手法をチームを超えて適用する取り組みの総称
各チームに部分的にアジャイルを適用→組織全体をアジャイルに
変化に強い
課題：チーム運営／チーム外との調整／組織全体
チーム解散→ノウハウ／暗黙知が失われる「記憶喪失」
SmallTeamの維持／勉強会・コミュニティ／自動化・リポジトリ
チームの熟成不足：ビルディングに時間がかかる／計画制度が悪くなる→研修／スキル分析／定期的な計画と振り返り
・スキルとプロセス合意の不足：
自動テストが書けないなど
研修／テストコーディングの研修／勉強会
・チーム外
・職能別組織：開発チームとの協働のために時間がかかる
事業別組織：情報共有が起こりにくい→調査などの予算や教育が部門ごとに分かれているので
明確なPO／関係者への成果物のデモとFB
・承認プロセス
事前チェックで速度が落ちる
POをチームの中に置く／マネージメントからの支援／関係者への成果物のデモとFB
・What’s Devps?
Faster Feedback for Business
・Why DevOps
どうやって勝つか？
引継ぎをやめる、SmallTeam、Automation
Cross Functional Cover All Skillsets
・Team Tools Services Data Analysis Process
・Delevlopers QA Devps Product Manager Project Manager
・Real time Reporting
・4拠点に分散
・コードレビューも自動化
・SonarQube StyleCop PatchCOnfig
・TeamCity
・Blue/Green -> Rollback
・Performance Test
・Application Insightsで監視→エラーがあれば一旦エラーテーブルに格納して対応／対応が終わったらエラー情報のクリーニング
・自動実行部分はAzure Functionを使用
・AWSのログによく似ている←エラーテーブル
・これらの確認が完了したサイトをAutoSwapでリリース
・Traffic ManagerでStagingとProductの割り振りを制御
・EFを使っていないものもある
・DBSchemaを変えると他の処理でエラーになる→Microservice
・週1回エラー内容のレビューを行い、問題と思われるものについては改善を行う
☆赤間さん：拝啓「変わらない開発現場」を嘆く皆様へ
キャッチーなタイトルです。社内でも議論になったようです。
聴講対象は「Excel設計書・打鍵フルパステストに親近感がある方」だそうですww
・いろいろなデバイスに対するUXの追及
・MSのアナウンスに響くのは技術者（協力会社）まで。アーキテクト以上のプロパーには響きにくい
○SI開発手法の変化←10年間で大きく進化した
・Agility→軽量化
・課題が多くあるにも関わらず、やり方そのものの改善が進んでいない
・開発文化が違う→良いところを取り入れる。全部を輸入するのは難しい
・決定的に異なるポイント：無駄なことを徹底的にそぎ落とす
日本の「良き文化」「美徳」が悪い方法に作用している可能性がある
→設計作業の最適化／テストの最適化／開発状況の見える化／近代的なプロマネ技術の会得
・無駄な設計書を書かない／手戻りを減らす
当たり前のことを書かない：ex.キャンセルボタンを押すと処理がキャンセルされる
コードで自明なことは書かない
内部設計作業の先取りをしない：コントロール名・イベントハンドラのつづりの一覧
→現在の開発技術は開発生産性が高い→設計書でワンクッションを置く必要がない
・外部設計書：誰が。いつどんなときに、何のために使うのか
・Excelで最初から描くのは「手戻り」を考えていない→100%の設計書を1回で作成するのは無理
・後工程を完全に想像するのはできない→プロトタイプを作成する／設計の意図を共有する
→タブレット／スマホアプリでは、すべての操作を描き切れない
・プロパー～協力会社間で「きれいな境界線」
協力会社のリーダーに「意図の共有」「実装可否の確認」「プロトタイピング」
・技術が進化→プロセスも改善しないと対応できない
・テストの効率化<>テストの自動化
・テストの自動化はコストメリットが出にくい：5～15倍程度
ソフトウェアベンダーがテストの自動化を行っている理由：構成テストの必要性／長期サポートの必要性
・テスト設計の効率化
テストケース設計の良しあしで大きく左右される
・UT:モジュール単位、IT:業務シナリオベースの機能テスト
ST:非機能要件の品質特性に対するテスト ※日本ではシステム間の連動テストを指すことがある
・STは後付けで実施するものではない
設計段階からの実施が必要
・UT/ITに非効率なテスト重複が多い
協力会社から納品されたアプリをどこまで再検査すればよいか？
・プログラム構造を考える(MVVMなど）で、テストパターンを減らす／一部を自動テストに回す
「ユーザがやりそうなこと」をITで確認
・UT:入力パターン網羅／IT:UT完了を前提としたシナリオ網羅
・MSでITである一定のUT不良が発生したら差し戻し
・DevとTesterを分けない←効率が良い
昔に戻るんじゃ？→UT/iTの作りこみを最適化するには変更が必要
・濃淡をつけずにテストを実施→効率が悪い
「バグの抽出」が目標→バグのありそうな場所を重点的にテスト
・テストケースの排除の判断は、過去の経験からしか推測できない
→テストインフラを使用して、データの管理と蓄積、分析が重量
→Excelでは分析が難しくなる
・テストの実施効率化は、結果的にWaaS(Windows as a Service)になる
○まとめ
・作れなくてもよいが勘所は知らないといけない
・設計やテストにも技術が存在する
・基礎理論をおろそかにしない
・ツールや手法の背後に存在する「意図」を理解する
・最初からパッチ当てを考えない→最終的にどこを目指すか
・「根拠のある作業」「根拠のあるSI」
・木こりのジレンマ
「刃を研ぐ時間なんてないよ」
時間は有限→自分たちを改善（斧→チェーンソー）
・日々の作業を見直し「やり方」を改善
・最新技術の背後にある「意図」をくみ、現場に取り込む
・魔法の杖はない
☆Jenkins 川口さん：Dockerコンテナによる継続的デリバリのおすすめと新機能の紹介
ちょうとJenkins2.0が出たばかりだったので聞いてみました。
前説がなんとJavaエバの寺田さんでした。寺田さんのリクエストに快諾してくれたとのこと。
○Jenkinsがミッションクリティカルか？→2015年度は92%
○ビルドの自動化→テストの自動化→デプロイスクリプトの共有→継続的デリバリ
○継続的デリバリ 素直で単純な反復可能なプロセスが欠かせない
○デプロイの現実：手順書、深夜作業、２週間に１回 ← 嫌ですよねw
○継続的デリバリへの道のり：自動化、エラーに耐えるアーキテクチャ、エラーを検知するパイプライン・エラーを許容するインフラ
全体の底上げが必要
○フィーチャーフラグ・ダークラウンチ・マイクロサービス
○エラー検知パイプライン：ブランチごとで検知 Dev→QA→Production
○コードレビューの自動検査、信頼できるテスト・ブランチの活用・複数の検問（例：ブランチ毎にテスト実施）
○テストのサイズ、内容が適切なところで実施されているか
○インフラ：Bule/Green Deploy、カナリアリリース、不死鳥サーバ(0から構築しなおし)、Immutableインフラ → クラウドだと簡単にできる
○共通する目標を設定することが重要
○現状、３割はどこかで手動が入るデプロイ、１割は完全自動デプロイ
○Jenkinsをコンテナ上で→アップデート、将来の引っ越しが簡単
○Azure Slaveプラグイン：負荷に応じて自動伸縮、いつも新築、Win/Linuxの両方
○Labelを使ってビルド環境の対応付け、Init Scriptで初期設定を実施←時間がかからない程度であれば
Init Scriptで時間がかかるのなら、イメージから展開
○30～60分のRetention Timeを設定する
○Dockerプラグイン(with Docker swarm)
利点：ビルド環境の作成・管理・利用が簡単、いつも新築
欠点：ワークスペースの再利用なし、AutoScaleNG、Docker in Docker
○Pipeline as Code：Jenkinsfileに記述、ソースリポジトリに保存できる、パイプライン実行中にJenkinsを再起動できる、とか
○Jenkinsfileを拡張してDRYにできる
○Organization Follder：プロセステンプレートの事前登録、自動適用？
・利点：設定は１度だけ、Jenkinsfileをコミットするだけ、ブランチ別のビルド履歴、プルリクの自動ビルドと履歴
・使うツールの依存関係までは自動解決しない（Jenkinsufile内で「～がなければインストール」と記述。
そのツールの前提となるソフトも全て記述）
○Jenkins管理者に個々のツールまで管理させたくない
○チームから全社へ／一家に一台Jenkins→中央集権化
○運用の効率化、ベストプラクティスの開発と普及、計算機資源のプール
○Private SaaS Edition(PSE)で、開発者にサービスとしてJenkinsに必要なものを提供
チームごとに「Jenkinsが欲しい」と言われたらサービスとして提供。器（ハード）はさっきの中央集権で集約
自動的なフェイルオーバー、マルチテナント、個々のマスター配置に悩まない
☆マグナムさん：Azure Resource Managerを利用したIaC
ちょうとAzure上に確認環境が欲しくて、テンプレートから生成するところまでやってみたいと思ってたところでした。
○３００個を超えるARMテンプレートがあるので、自分で１から作成する必要はない
○ポータルサイトで自分が作成したリソースのテンプレート出力が可能
○azuredeploy.json内のparametersの設定内容はazuredeploy.parameters.jsonのparametersから取得する
○variableは同一テンプレート内で利用する変数を定義
○Windows以外だとAzure CLIでデプロイ可能
○最低限覚えておいた方がいいもの
文字列連結:concat
リソースID取得;resourceId→dependsOnとの併用で多用
ロケーション指定:resourceGroup().location()
ループ関連（複数のVMを作成するときとか）:copy, copyindex()
○AzureRmResourceGroupDeployment でテンプレートチェックができる、-Debugで結果を出力してくれる
○定義ファイルを編集したときは、キャッシュがきいてるので、編集した直後は反映されないときがある
○管理ポータルの監査ログでもエラー内容を確認できる
☆Chef社James Casey氏：Powering High Verocity Development for your Infrastructure
ここの前説は牛尾さんでした。（DevOps系セッションは前説デフォルト？）
ここでも「Chef!」コール発動w
内容は自社(Chef社)での事例、設計思想っぽいものとかでした。
○7割はリモートで作業
○インフラとアプリを同等に扱う
○「安全に」スピードを持って→Cloud, Automation, Culture
○早くインフラが使用可能になると、いろんな実験ができるようになる
○手作業では無理（時間がかかる）→自動化。今までのやり方を巻き込む（バージョン管理、CI/CDとか）
○ミスが起こっても前に進む。
○ミスの分析→より早く動ける
○広めるために：事実と数字。美地熱的な数字につながってる
○ツールとしてのChef, ワークフローとしてのChef Delivery、DevのためのChef DevelopmentKit、コンプライアンスのためのChef Compliance(テスト)
○MS Ecosystemとの統合:ハイブリッド（クラウドとオンプレミス）への対応
○ChefはAzureポータルから導入可能、PowerShellにも対応
○LinuxもWindowsもフルサポート
ここからはChef社が他社にコンサル／サポートした事例
○買収などで複数企業のシステムを稼働させる→サイロ化→DevOpsでの最適化
○いくつかの企業で使ってたChefのベストプラクティスを他の企業にも展開
○opensshのパッチ適用対応：1person・15minと156persons・9day
ここからはDevOpsの進め方とか
○データの可視化が重要
○インフラ構築でもTDDを採用する
○TDDでスピードと品質に対応する
○Rubocop：Static Code Analyzer
○FoodCritic：CookBookのスタイルチェック
スタイルチェックは「わかりやすさ」優先
○ChefSpec:ローカルでのテスト
○Test Kitchen:テスト環境を設定し、実際にテストを実行
○たくさんのCookBookが公開されてるので、それを使うこと
○Chef Complianceから作成した環境のテストを実施、結果をComplianceで確認
○PowerShellをCookBookの中に入れることが出来る
長くなったので、全体的な感想は次に書きますw