« 2016年3月 | トップページ | 2016年6月 »

2016年5月

2016年5月26日 (木)

de:code 2016に行ってきました:感想

感想ですが、
・DevOps関連としては最強(過去のMSイベント/OSS系イベントと比較して)
 これだけ有名な方々が勢ぞろいしてセッションを行ってくれるのは記憶にありません。
 人数制限で入れなかったのですが、25日の最終セッションで「DevOps 第一人者のガチトークバトル」もあり、
 そちらには日本トップのスクラムコーチである@ryuzeeこと吉羽さんやMS高添さんなども交えたセッションもありました。
・DevOpsとは
 よく「1日10回デプロイすればDevOps」「テストやデプロイを自動化すればDevOps」とか聞きますが、今回のイベントでは「文化」「継続」「計測可能」というキーワードがよく出てました。
 「スピードを出すための自動化」ではなく、「やったことを(ビジネス価値として)計測して、それに基づいて改善するプロセスを継続して実施する文化」ができないとDevOpsではないということかと。
・最近のMSはいい方向に進んでる(気がする)
 自分ごときが言える立場ではないですが、スタンスが昔の「MSテクノロジーだけで」から「いいものは他社のものでも使って。でもMSもいいものあるでしょ」に変わってます。
 MSのテクノロジーもOSS化されているものも多々あるので、本当の意味でオープンになってきているなと感じます。
 DevとOpsの両方をサポートできるMSなので、プラットフォーム/開発の両方を高い融合レベルで使えるメリットは高いと思います。
・セッション大杉
 たくさんセッションがありすぎて、同一時間帯で聞きたいセッションが被ることがありました。
 首都圏の会社なら複数人で手分けして聞けるのでしょうが、地方からではその手は使えないので。
・会場(動線)悪すぎ
 昨年からも言われてますが、会場独特の通路(コの字)とキャパシティの小ささが相まって、セッション間の移動がカオスです。
 中々大箱がないのと、大箱は年単位で予約されているのでなんともし難いのも分かるのですが・・・。

まぁ、生存確認できた方もいらっしゃいましたし、全体的には楽しいイベントでした。
イベント関係者の方々お疲れ様でした。

de:code 2016に行ってきました:Day2

さて、2日目についてのメモです。

☆楽天での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%
 ○ビルドの自動化→テストの自動化→デプロイスクリプトの共有→継続的デリバリ
 ○継続的デリバリ 素直で単純な反復可能なプロセスが欠かせない
 ○デプロイの現実:手順書、深夜作業、2週間に1回 ← 嫌ですよねw
 ○継続的デリバリへの道のり:自動化、エラーに耐えるアーキテクチャ、エラーを検知するパイプライン・エラーを許容するインフラ
  全体の底上げが必要
 ○フィーチャーフラグ・ダークラウンチ・マイクロサービス
 ○エラー検知パイプライン:ブランチごとで検知 Dev→QA→Production
 ○コードレビューの自動検査、信頼できるテスト・ブランチの活用・複数の検問(例:ブランチ毎にテスト実施)
 ○テストのサイズ、内容が適切なところで実施されているか
 ○インフラ:Bule/Green Deploy、カナリアリリース、不死鳥サーバ(0から構築しなおし)、Immutableインフラ → クラウドだと簡単にできる
 ○共通する目標を設定することが重要
 ○現状、3割はどこかで手動が入るデプロイ、1割は完全自動デプロイ
 ○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:プロセステンプレートの事前登録、自動適用?
  ・利点:設定は1度だけ、Jenkinsfileをコミットするだけ、ブランチ別のビルド履歴、プルリクの自動ビルドと履歴
  ・使うツールの依存関係までは自動解決しない(Jenkinsufile内で「~がなければインストール」と記述。
   そのツールの前提となるソフトも全て記述)
 ○Jenkins管理者に個々のツールまで管理させたくない
 ○チームから全社へ/一家に一台Jenkins→中央集権化
 ○運用の効率化、ベストプラクティスの開発と普及、計算機資源のプール
 ○Private SaaS Edition(PSE)で、開発者にサービスとしてJenkinsに必要なものを提供
  チームごとに「Jenkinsが欲しい」と言われたらサービスとして提供。器(ハード)はさっきの中央集権で集約
  自動的なフェイルオーバー、マルチテナント、個々のマスター配置に悩まない

☆マグナムさん:Azure Resource Managerを利用したIaC
ちょうとAzure上に確認環境が欲しくて、テンプレートから生成するところまでやってみたいと思ってたところでした。
 ○300個を超えるARMテンプレートがあるので、自分で1から作成する必要はない
 ○ポータルサイトで自分が作成したリソースのテンプレート出力が可能
 ○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

de:code 2016に行ってきました:Day1

今年もde:codeに行くことができました。
早速ですが、自分が聞けたものについて残したメモを簡単にまとめたいと思います。

☆Keynode
なんかいろいろあった気がしますw
非常にOpenになった、and今年はかつらさんのお話しにもありましたがグローバルレベルでのスピーカー陣だなと思います。
(ナデラのスピーチを筆頭に。まぁ、壇上で踊ったり「DevOps」Jenkins」「HashiCorp」「Chef」「Mesosphere」とかのCall&Responce求めたりする方もいらっしゃいましたが)
とりあえず、(アンチMSであっても)今のMSが提供する技術・情報を拒絶する必要は全くないなと感じました。
個人的には非常にワクワクするものばかりです。
(また、自分がTFSでJavaやってるのもありますが)

☆世界DevOpsトップ企業×MSによるトークセッション
スピーカーが強力すぎます!!これほどのスピーカーがそろうことはOSS系のイベントでも中々ないのでは?
 MS:Sam Guckenheimer, 牛尾さん
 HashiCorp:Michell Hashimoto
 Chef:James Casey
 Mesosphere:Aaron Williams
 クリエーションライン:鈴木逸平氏
英語だったので綺麗には聞けてないのですが、概要/出てくる単語はこんな感じです。
○DevOpsのキーワード:Cloud、Automation、Culture
○Agileの導入しずらさ ワースト1は日本w
 https://t.co/18jZhbOAFs ← 牛尾さんのTweetで、「文化の違いによるAgile導入難度」のスライド
○黒船とか鎖国とかちょんまげ(ウォーターフォールと形が似てる)とか・・・w
○ScrumのDone:出荷可能
 DevOpsのDone:出荷可能ではないが展開可能+測定可能←評価可能
○継続的にデリバリー可能+計測可能 継続的なフィードバック
○ソフトウェア駆動型企業に代わるための活動
○組織変革
○どこにどのような問題点があるのか/本当に変わろうとする意識があるのか
○経験を大事に
○DemoDays
 カイゼンの進捗を見せれば、他の人も変わりたいと思う
 CI, 見える化, Release Automation
 許可を求めるな、後で謝れw
 Value Stream Mapping
 利害関係者を巻き込め
○この製品が面白いと思ってもらって、サポートや拡張機能が欲しいと思ってもらうことが重要

☆安納さん:ハイブリッドなAD設計 Windows Server 2016版
安定の安納さんです。立ち見でした。
○認証は「生産性向上」のため。安全性を確保する条件。→できないことはさせない
○利用者/デバイス/アプリに対する認証
○IdPは統一しないといびつな作りになり、セキュリティホールを生む元にもなる
○パスワード:サーバに渡す(ネットワークを流れる)
 PIN:ネットワークに流れない、PC内にある
 スマートカード証明書:展開が面倒
 PINの代わりとしてWindows Helloが使える
○.NET PASSPORTはユーザとデバイスの組み合わせが正しいことを証明
 ※デバイスに秘密鍵
○PASSPORTのリモートアンロック ※Preview
 PCとスマホをBlueToothで接続し認証。PCにプロファイルを残さない?
○PASSPORT for Work
○AADに組織アカウントを登録することでAAD用PRTを取得(Windows 10でAD用PRTと併存可)
○Azure AD Connect
○Windows Server 2012 R2だとKerberosを使えばAAD連携可能

☆高添さん&小塚さん:Windows系インフラエンジニアのためのDevOps
どうも、Dev系と仲が悪いそうですw(パフォーマンスですよw
○Containerの分離レベル ← Docker
 Windows Container:Registty/Files/Apps
 Hyper-V Container:Windows Container+Process
 ※一旦停止する必要があるが、相互に切り替え可能
○特権アクセス管理
 ・特定の時間帯のみ特定の処理を実現
○通常SSDとNVMe SSDも認識して記憶域の管理を行える
 CPUボトルネックが出始めている
○25Gbpsネットワーク市販開始

☆SysinternalsやOS標準ツールの徹底活用術
ちょっとしたおすすめツールの紹介です。目指せ脱初心者!
○イベントファイル形式と、その他の形式の2種類でイベントログは取得する
 evtx形式は、メッセージ内容をDLLから取得している
○パフォーマンスモニタで複数のマシンをまとめて監視
○ベースライン取得のためなら、取得間隔は10~15分、取得対象:Processor, Memory, Disk, Network
○ProcessExplorer:SpaceとF5でプロセスの増減を簡単に確認できる(色がつく)
○NotMyFault←自分の好きな色に設定できる
○Symbolファイルも入れておく(オフライン用にDL可能)
○WinDBGで、「! Analyze -v」で簡易解析

セッションの後に参加者パーティがあったのですが、人が多すぎて途中で帰りましたw
セッション間も入室待ちや移動で人が集中するので大変でした。

一日目はこんな感じで。

« 2016年3月 | トップページ | 2016年6月 »

無料ブログはココログ