fabric使ってインシデント一次対応の自動化をすることになった
pythonあんまり良くわかんないけど
目的
- オペレーション手順をプロダクト単位に管理していく上でメンテコスト（現行は手順書ドキュメント管理）が肥大化し続けることが課題となっている
方針
- メンテナンス性重視。出来うる限りDRYな状態が保ち続けられるような設計
- プロダクトを横断して使うのでプロダクトそれぞれの価値観によって同じ手順の亜種が大量にできてしまいうる
基本的には「標準処理」で対応可能なミドルウェアのみ処理対象としておきたい、が - 【？】最終的なゴールとして自動オペレーションの対象とする要求はどこまでを許容範囲とするか。（いちばん細い単位まで自動化対象とするとすると結局、メンテコストが大きくなってしまう状況が避けえないのじゃないか）
pythonとfabricについて
fabricタスクをデコレートして異なるミドルウェア同士のクラスを抽象クラスで定義できる。構造化というよりはfactoryMethodに近い
fabricの中でも多少の構造化する仕組みがある。タスク定義するfabfileが、普通に書いてると1ファイルの中にタスクがたくさんできてってしまうが、__init__使うことでネームスペースを区切る程度のことはできる
が、これだけだとやはり結合を疎に保ち続けるのはなかなか厳しい
デザインパターン使ってやりたい。最初に挙げたfactoryMethodがなかなかいいかな、と感じているがそれでもまあまあ苦しいはず
Jenkinsについて
本当はbuildPipeLineとかでビジュアル的に作業手順を処理としてまとめて管理していく方がメンテコストを低く保ち続けやすいんじゃないだろうか
確か、自分が参画する前のツール選定で弾かれてたきがする
勉強しなあかん
pythonとfabricについて
Python 言語リファレンス — Python 3.5.1 ドキュメント
Welcome to Fabric’s documentation! — Fabric ドキュメント
ドキュメンテーションついて
doxygenで生成してgithub-pagesで公開できる。pj上にドキュメントを展開できるから全部そこに集まるし便利
ドキュメンテーションはどうするか迷うな、しかし
メンテナンス性とか考えるとDoxygen + Graphiz がいいと思うけど、せっかくpythonだしSphinx使って綺麗に書けるといい。でもconfuluence使える環境があるので、わざわざSphinx使うくらいならそっちかなー、とも思う。けど、Sphinx + blockdiag 使えるとか図があるかどうかで結構差が出る。confuluenceはエディタが本当に素晴らしいけど結局、デベロッパーとして本気出そうとするとUMLとかもっと導入しやすくないとなあ
こうやってDoxygenとblockdiag組み合わせるとかもありかも
http://qiita.com/umiyosh/items/d73f1e507aa8018b5cf2
pythonのコーディング規約やドキュメントやデザインパターンなど
https://myekps1te.wordpress.com/2014/08/15/大規模なプログラムをpythonで始めるときに知ってお/
