【勉強会メモ】Osaka Venture Today Meetup #4 - 開発生産性アップの秘訣
- 日時：2018/10/26(金) 18:30 〜 21:00
- 場所：サイボウズ大阪オフィス
MonotaROさん、サイボウズさん、freeeさんによる三社合同の勉強会。今回のテーマは「開発生産性アップの秘訣」でした。
遅刻してMonotaROさんの発表はまるごと聞き逃してしまいました。大変残念です。かわりに現地で頂いたMonotaROまんじゅうの画像をお楽しみください。。
さらに残念なことにPCを持っていくのを忘れてしまい、スマホで撮った写真とフリック入力で必死に追いかけたやや雑なメモになっておりますがご了承ください。
小さなサービスも契約する時代 〜マイクロサービスのテストをすばやく回しデプロイを安全にやるよい方法〜
小さなサービスも契約する時代 from RyoMitoma
www.slideshare.net
マイクロサービス
- 技術的異質性
- サービスごとに別の技術を使える
- 回復性
- スケーリング
- デプロイ容易性
- 組織面の一致
- チームとサービスを一致させる
- チーム間の折衝が減らせる
- 合成可能性
- 交換可能にするための最適化
テストにおける課題
- 全体を結合したテストが大変
- どのバージョンでテストするか判断ができない
- 誰がAPIを利用しているかわからない
どうすればいいのか？
- クライアントライブラリは自動生成
- 互換性の崩れた古いクライアントライブラリを意図せず使い続けられたら困る
- モノリポジトリの採用
- 全部のコードを1つのリポジトリに入れる
- モノリシックと変わらない
- 不充分なテストで本番に突っ込んで異常検知したら取り下げる
コンシューマ駆動契約
- 契約をもとに独立してテスト
- 提供側が守るべき契約をDBに問い合わせできる
- 利用側が起点となって提供側と契約するのがコンシューマ駆動契約
CDCは何を解決しないか
- 契約していないサービスの互換性保証
- 契約が壊れたときのチーム間のコミュニケーション
- APIの実際の動作保証
- サービス間の実際の疎通
サイボウズの事例
課題
※参考
Freee流DevOps Dailyリリースを支える技術と、データ可視化の先
増田茂樹さん@freee
- デプロイは毎日
- 年間135件の機能リリース
なぜ頻繁にデプロイできないのか？
- タスクの粒度が大きい
- デプロイまでのプロセスが多い
タスクの粒度
- 1スプリント2週間
- スプリント単位ではなくモノができたら毎日リリース
- 細かく分解
- 1機能で45タスクぐらい
- 数時間から1日で終わる範囲
- コード量は1タスク50行ほど
- 効果
- レビューしやすい
- 進捗管理しやすい
※50行を超えているとBotが「文化的ですか？」と聞いてくる
ブランチ戦略
- developに取り込まれると
staging→masterに自動で流れる
リリースフラグ
- システム全体、事業単位で設定できるフラグ
- 開発中
- ボタンや機能の制御
- 開発中継
- QAチームへの開放
- 運用
- ABテスト
- 障害の切り戻し
リリースフラグはフィーチャートグルとも言われる手法ですね https://t.co/lsOQ7YjGSW #ovento
— radiocat (@radiocatz) 2018年10月26日
デプロイプロセス
- ChatBotでデプロイ
- Chatで「デブデブしたい」と投稿すると自動でデプロイ
- おみくじでプルリクエスト
余談ですが、遅れて行ったら同じテーブルに元同僚が座っていました。その場ではあまり話が出来なかったので終わってから2人で飲みに行きました。一生のうち1回ぐらいは達成したい事リストのタスクを1つ消化した気分で帰宅しました。
勉強会に遅れて行ったら偶然にも同じテーブルに元同僚がいて終わってから2人で飲みに行くという一生のうちに1回達成したいタスクを1つ消化した。
— radiocat (@radiocatz) 2018年10月26日
