「DevOps」やってみた。そして、気づいたこと、陥ること、見直すところ。
DevOpsは特定の規格ではないので、その解釈、やり方、売り方、向かう所など、皆同じではありません。とは言え、それぞれが何かの課題を解決しよう、開発と運用の現場をより良くしようという「思い」から始まっているのは同じではないでしょうか。本セッションでは、そんな思いからそれぞれが考えたDevOpsを「やってみた」現場から、特に多くの方が初めに取り組むことが多い「リリースとデプロイメント」の自動化を中心に「気づいたこと」や「陥ってしまったこと」を振り返ると共に「見直すべきポイント」をIBM DevOps ソリューションを切り口に解説します。
DevOpsとは
- 創り続けること、生かし続けること
- 使い続けてもらえるモノを提供
- 創り生かし続けられる仕組み
- 何を目指している(た)のか？
- 創り届ける距離/時間の短縮
- やったメニュー
- 小さなチームの小さな改革
- CIを進めてみたはいいが...
- Opsから変えてみたら...
小さなチームの小さな改革
- きっかけはビジネスの拡大/拡張
- 無秩序な環境からの脱却
- そのためにDevOps
- 最初にやったこと
- 自動化の検討
- テスト自動化
- デプロイ自動化など
- 自動化の検討
- 早めに気付けたこと
- 部分最適ではなく全体最適
- やるべき2つを選択
- デプロイのしくみを再構築
- 将来を見据えた構成の見直し
- 次にやったこと
- デプロイのしくみを再構築
- オンプレ→クラウド
- 標準化と自動化
- 将来を見据えた構成の見直し
- デプロイの再構築
- IBM UrbanCode
- IBM Rational Team Concert
- デプロイのしくみを再構築
- 陥ったこと
- コスト、期間が想定上にかかった
- 「やる」は人数や規模に正比例しない
- 思った以上に「やる」ことが多い
- 小さくても「やる」範囲は広い
- コスト、期間が想定上にかかった
CIを進めてみたはいいが...
- 標準化部門の施策としてDevOpsを推進
- 生産性上げるにはCIでしょ！
- やったこと
- ソース管理サーバの用意
- 共通ビルドサーバの用意
- 気づいたこと
- ソース管理がバラバラで共通ビルドサーバに乗せられない
- 陥ったこと
- ビルド用サーバのばらまき
- 見直すべきところ
- コスト以外も気にする
- 最終的なビルドを意識した構成管理
Opsから変えてみたら...
- ビジネスの改革
- コスト削減
- リリース時期の死守
- やったこと
- 自動化、運用絡みでデプロイの自動化
- 運用人員"0"を目指す
- 自動化でリリース作業のスピードアップ
- 自動化、運用絡みでデプロイの自動化
- 気づいたこと
- アプリ、チームごとのデプロイ手順が別々で標準化/パターン化しにくい
- 開発と運用のギャップ
- 運用側の開発スキル不足
- コードは読めるが、開発経験が少ない
- 運用人員"0"は無理
- デプロイ以外にも作業があった
- 陥ったこと
- 6ヶ月の予定が1年
- 要員を追加しコスト3倍
- 誰が「やるか」
- 部署/部門/個人の得意/不得意を見極める
- だれでもコードが書けるわけではない
- 部署/部門/個人の得意/不得意を見極める
- 何から進めるか
- 自動化対象の優先付け
- 効果のある作業を選択
- 80:20の法則
- 自動化での効果の8割は2割の置き換えでできることが多い
- 急がば廻れ
- 自動化対象の優先付け
さらに...
- IBM DevOps Solution
- Mobile
- Cloud
- その他
- Shift Left
- benefits of shifting left
- 早い時期（より左）から統合テストを繰り返す
- リリース管理におけるリスク計算
- 数が多くなればなるほどトラブルが起きやすい
- 早めに小さく統合しておく