DevOps Days Tokyo 2019 DAY2 参加レポート と まとめ

DAY1からの続き

Report

Five Development Practices for Agile DevOps

Speaker: David Bernstein
Slide:

4つしかメモれなかった。がそもそも9つあるなかからの抜粋
Practice 1: Say What, Why, and for Whom Before How excerpt
Practice 2: Build in Small Batches
Practice 3: Integrate Continuously
Practice 4: Collaborate
Practice 5: Create CLEAN Code
Practice 6: Write the Test First
Practice 7: Specify Behaviors with Tests
Practice 8: Implement the Design Last
Practice 9: Refactor Legacy Code excerpt

詳しくはBeyond Legacy Code参照

TDD難しいけどいいよ。と言っていたのが印象的

Memo:

1. Integrate Continuously
   継続的に統合することは最も重要である
   最高のフィードバックは素晴らしいビルドシステム

2. Create CLEAN Code

   • Quality Code is Cohesive
   • Quality Code is Loosely Coupled
   • Quality Code is Encapsulated
   • Quality Code is Assertive
   • Quality Code is Non-Redundant
   • Code Qualities Guide Us

3. Write the Test First

   • TDD
   • QA
   • Write Good Tests
   • 単体テストのUnitとは、コードをテストしているのではない、振る舞いをテストしている
   • TDD は迅速にフィードバックを行う
   • TDD はリファクタリングを助ける
   • Write Testable Code
   • But TDD Can Fail
     • しかしTDDは失敗する可能性がある
   • Become 'Test Infected"
     • テストに熱中する

4. Refactor Legacy Code

   • 新しいfeatureは生まれないが、今後より容易く価値を届けられるようになる
   • 技術的負債はすぐに返す
     • すぐに返せば返すほど、安くつく
   • コードを綺麗にしてから変更を追加する

---

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

Speaker: 池田 秀弥
Slide: https://www.slideshare.net/slideshow/embed_code/key/DvhB5fUUbdUpPq?feature=oembed

SIerでもDevOpsプラクティスを取り込むことによって少し幸せになれる
SIerのやっているのは真のDevOpsではない。ゴールが違う

Memo:

• SIビジネス縮小の危機感

  • Agile/DevOps技術者を増やさないと！

• SIerのビジネスゴール

  • 見積 - コスト
  • SIerがリスクを負って攻めのリリースをする理由はない

• 忖度部分を自動化

  • 構成管理
  • パイプライン制御(CI/CD)
  • チケット管理
  • テスト自動化
  • モニタリング
  • インシデント管理
  • コラボレーション

• まずは推奨ツールを定めて広くばらまいてみる

  • コアツール

    1. GitLab
    2. Mattermost(Slackクローンみたいなもの)
       オンプレの要件にマッチしたため使用する
       有料ツールはハードルが高い(価値が認知されるまでは)

  • 標準化
    言語・アーキテクチャ別のパイプラインをテンプレート公開

• SIプロジェクトにDevOpsしましょう！と言っても響かない

  • DevOpsの世界観とSIのギャップ

    • 開発手法
    • 人数
    • 環境
    • 契約

  • SIプロジェクトの具体的な課題解決にフォーカス

  1. 製造終盤に問題発覚し炎上

     • CI
       → Step1 ソースコードを共有する
       → Step2 ナイトリービルドする
       できればソースコード静的解析
       指摘0件をキープする。100件が101件になったところで誰も気に留めない

  2. 構成管理はExcel, 手順書地獄

     • CD
       → GitLabを使いこなせば解決
       Issue, branch, 自動ビルド、デプロイ

  3. 気持ちが伝わらず孤独

     • Culture
       → Mattermost(SlackクローンのOSS)
       効果的な使い方：プロジェクトメンバー全員が同じ空間
       基本的に会話はオープンに
       分報を推奨: 自分用のチャンネルにつぶやき続ける

     → 重要な連絡事項をチャットで流し、メールは補助とする
     例) メール本文：詳細はチャットに書いたのでそちらで議論しましょう

     → 絵文字リアクションを推奨する

• まとめ

  • SIerのビジネスのゴールは見積 - コストにあるため
    自動化、コラボレーションなどの狭義のDevOps

---

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

Speaker: Genki Sato
Slide: https://speakerdeck.com/genkist/devopsdays-tokyo

日々の運用の中で変更が発生するものはアプリのリポジトリに同梱する

Memo:

• うまくいったポイント

  • 設計段階からエンジニア全員で勉強しつつ進めた
    • 選定基準はあえてゆるめに
    • DDD勉強会
  • チーム全員で集中してプロジェクトに取り組む体制

• 開発サイクル

  1. 何を作るか
  2. どう作るか
     • 実装
       • Lintチェック
  3. どう品質を担保するか
     • QA
       • 単体検証
       • 全体検証
     • ブランチと環境を1:1にしている
  4. リリース
  5. インフラ構成管理
  6. 計測監視

• デリバリー高速化への取り組み

---

Data-Driven x DevOps

Speaker: Masato Ishigaki
Slide:

DevOpsツールチェーンのMONITORは全関係者がクエリを打って計測(KGI,CSF,KPI)できるようにする。

Memo:

• プロダクトをグロースさせる文化を作る

  1. 仮説
  2. 開発→リリース
  3. 効果検証

• デプロイ回数UP＝ビジネス価値UPではない

• Product → Measure(DWH構築)

• Measuer → Data(優れたデータを可視化)

• Data → Learn(どう学習するか)

• Learn → Idea(効果的な施策立案)

---

Terraform で自社サービスを便利に! Custom Provider開発におけるDevOpsへの取り組みのご紹介 かゆいところに手を届かせたい人へ

Speaker: Hikita Keiichi
Slide: https://docs.google.com/presentation/d/1A_e5QJZLX6TvWUHwz77gVOElimjBy64oyBF56ewlu48/edit

あった方が良い機能は作らない。結局作らないほうが幸せになれる。。。

Memo:

Terraformプラグイン開発を通じたDevOpsの活用事例
その過程で出た課題/Tips

• TerraformのCustom Provider(=プラグイン)により対応

• IaCツール検討にむけて

  • 自社で作らない

• Custom Provider開発におけるDevOps

  • BizDevOpsの11フェーズ
  • Bizフェーズ
    • 要件と計画を作成する
    • やることを決める。やらないことも決める。
  • Devフェーズ
    • GitHub Flowに基づき進行
  • Opsフェーズ
    • Configure
    • Monitoring 効果測定
      • お客様からのTerraform利用要望数

• Custom Provider開発におけるTIPS

  • ForceNewによる予期せぬ変更
    • IDを検証する
  • 操作時間が長いor枯渇しやすいリソースへの試験
    • Golangはmockが作りづらい
    • テストダブル

• 最後に

  • あった方が良い機能は作らない
  • 全体最適を取った上でHW, SWを選ぶ
  • 技術に乗っかってもサービスにはならない。ビジョンが大事
  • 小さくていい

---

AWSを活用した少人数チームためのコンテナデプロイ戦略

Speaker: Katsunori Kanda
Slide:

CodePipeline内の定義でCodeBuildのartifactIdなど参照できるので楽ですよと。
Dockerfileのレビューもすること。

Memo:

• AWS FargateとCodePipelineのお話

1. 組織としての学習効率を重視する
2. 解く知恵の技術に集中する
3. 運用コストをかけない
   ↓
   AWSとコンテナを開発の中心に据える

• AWSでコンテナを使う

  • EKS or ECS(EC2) or ECS(Fargate) どれを使う？
  • Fargateを選択
  • ポータビリティ低い
  • オペレーションコストが低いのを重視した。

• AWS CodePipelineを使ってつなぎ合わせる

  1. コンテナを作る
     • CodeBuild
  2. コンテナを保存する
     • ECR
  3. コンテナを配る
     • ECS
  4. コンテナを動かす
     • Farate

• AWS CodePipeline

  • 良い点：
    • インフラ管理が不要
    • セキュリティ(クレデンシャル不要、IAMロールで管理できる)
  • 悪い点：
    • 初期構築に手間がかかる
    • ロールの作成や権限設定
    • CircleCIは設定ファイルを置くだけ

• 1つのプロジェクトは1つのリポジトリ

• インフラ関連(tf)もまとめる

• プロジェクトの標準構成を決めることで、ベストプラクティスの横展開をしやすく

• コンテナの品質が書き手によって異なる

  • Dockerfileもレビューしよう

• ALBとAWS Fargateの連携について

  • 変更が多発する部分は自動化している、あまり変更が発生しない部分については手動という割り切り

---

DevOpsに関わるPO(プロダクトオーナー)として大切なこと

Speaker: Seiji Kawakami
Slide:

いろんな人を巻きこもう

Memo:

• 社内の業務改善プロジェクト

• DevOps導入がうまくいかない

  • 手段が目的になってしまった
  • 目的に準ずる

• プロジェクト体制の変化

  • 「使う側」から「作る側」に巻き込む

    • 使う側にヒアリングする以上の効果が発生

  • 「作る側」も「考える側」に巻き込む

    • 言葉が通じるようになった

---

まとめ

1. ベストセッション
   DAY1のService Operation Centered Development - サービス運用をまんなかにおいた開発
   実践出来るプラクティスに加え、そもそも皆幸せになるためにやっているんだ！
   というのが伝わってきてほっこりしたセッションだった。
   仕事もできて、人格者なんてズルいよ！

2. 印象に残ったセッション
   DAY1のDevOps導入支援、始めました
   16:25開始、皆疲れてきて集中力が落ちる時間帯での劇薬投下
   2日通してこのセッションだけ異彩を放っていた。
   完全に覚醒を与えてくれるため、来年は是非DAY1, DAY2ともに
   集中力が途切れそうな時間帯に登場していただけることを望む。

3. わかったこと
   VSM!VSM!!
   VSMする → 改善点を出す → 改善する → 効果測定を行う → VSMする
   のループを行うこと。

4. 最後に
   堅苦しくなく、皆楽しもう、楽しんでもらおうという雰囲気が伝わる いいカンファレンスでした。
   来年も同じ日同じ場所でやるそうなので、参加したいなと思います。

---

その他

• 水・お茶・コーヒー(タリーズ）があった!
  

• お弁当(今半)が出た!
  

• 電源は無い

• 名刺はメッチャ消費するので沢山持って行ったほうが良い

Datadog

ブースでデモを見たらTシャツがもらえました！かっこいい！ありがとうございます！