2016年現在確立した定義はないが、自分の理解を列挙してみる。
- Dev(開発)とOps(運用)の協力体制をより密にすること。
- これまでは、開発の立場としては、開発したプロダクトをより早く本番環境に載せたい。
- 一方運用側は、安定稼働を望むため変化を好まない。
- そのような利害関係があるので、企業体として求められる「早くサービスを提供すること」に対応しきれない部分があった。※上記の書き方だと運用側が抵抗勢力のように読めてしまうが、低品質のプロダクトをもってくる開発側にも問題がある。あと本番環境と開発環境の差異などで障害は発生しがちである。なのでコンテナ技術が発達してきたのかな?
- そのための考え方がDevOpsという言葉に集約される。
- より密に協力していこうという考え方の背景は、ITをコストカットのためのツールとしてではなく、ITを使って競争に打ち勝つという考え方がある。そのためより便利で安定性のあるソフトウエアプロダクトが求められている。
- また協力の考え方だけでなく、それを実現するためのツール群も近年現れてきた。
- ツール群によるプロダクト開発(と投入)のレベルに段階があるので少し解説する。さっき覚えた(笑
- 第1段階 バージョン管理(本番のソースコードと開発中のソースコードの差異管理。)
- 第2段階 継続的インテグレーション(テストとOKであれば開発系ソースコードへのコミットの自動化)
- 第3段階 継続的デプロイ(第2段階の結果、問題がなければプロダクトのビルドと本番環境への適用の自動化)
- 第4段階 継続的デリバリ(本番環境へのデプロイタイミングをビジネス要求に沿って決定する。※第3段階までくるといつでも本番環境にプロダクトを投入できる状態になる)
- 上記の段階を実現するための便利なツール群が近年登場してきた。
- 欧米ではここ7,8年前ぐらいからこの考え方はあって、日本では自分の見聞きする限りせいぜい第2段階どまり。(スマホゲームだと第4段階まで行っていないとだめだろうけども、毎日のように何かイベントがあるから)
一番重要なのは6.の考え方だと思う、その方法としてDevOpsという考え方が生まれてきたのだと考える。
0 件のコメント:
コメントを投稿