「本番作業に強いプロダクト」を作る

やっているところは当然こんなことやっているんだろうなぁ、、、　というようなことですが。

私が所属するチームでは昨年は、jUnitのユニットテストのカバレッジをあげることを中心に、「変更に強く、長く使われるプロダクト」をテーマに新プロダクトを開発してきました。
（明確にそういう話をメンバーとさせてもらったわけではないんですが、そういう思いでした）

年が変わり、次のステップを考えたときに思いついたのが、リリース作業などの本番作業への「強さ」でした。
今の私にとって、”本番作業に強いプロダクト”とは以下のような特徴を持っています。
（つまり、この逆の状態が今の環境です）
・リリースの準備、作業、確認、事後監視に割く労力が小さい。また、時間もあまり必要としない。
・作業前後で不具合が発生する可能性が低い。副作用なく、予定通りの変更のみ達成される
・他プロダクトとの関係が疎であり、他プロダクトやチームとお互い意識することなく変更が可能。
・小さな変更は小さな労力・時間で実行可能。
・作業中の、システムへの影響が無もしくは小さい。（無停止）
・以上の理由から、積極的な本番リリースが可能であり、価値を提供するまでのリードタイムを短くできる。


この、強さを手に入れるために、オペレーションによる改善と、システムによる改善の両面のアプローチがあると考えました。

【オペレーションによる改善】
・準備、作業、確認、事後監視の方法が定型化されており、通常の作業においては検討する必要がない。
　既に決められているフローに則れば、小さなコストで本番作業を終えることができる。
・リリース直前での準備に時間をあまり必要としない。
　必要なソースコードや（もちろん自動の）テストケースは開発中のプロセスで既に用意されている。
・作業を行うことのできるメンバーが複数いて、特定の人物に負荷が集中しない。
・小さなコストで関連チームへの連絡が可能。

【システム、アーキテクチャによる改善】
・ソースコードのマージに割く労力・時間が小さいソースコード管理システムを使用する。
　⇒Stashに全面移行

・作業、確認、事後監視が極力自動化されており、手動作業に割く労力・時間が小さい。
　さらに、確認・事後監視での不具合発見精度が十分であり、不具合時の復旧も小さな労力・時間で可能。
　⇒リリース作業のスクリプト化。1回のエンターで全サーバへのデプロイが完了するのが理想
　⇒確認テストの自動化。以下が自動ですぐ実行できる状態で用意されている。
　　　－リリースのたびにメンテナンスされる既存チェック
　　　－リリースされたソース群に必要な修正が確かに含まれていることを確認できる修正チェック
・プロダクトのクライアントに影響のない状態でバージョンアップが可能。
　⇒別コンテキストとしてリリース。クライアントは任意のタイミングで接続先を新バージョン版に変更可能。
・プロダクト内からコールする、APIの新バージョンに対応していることがSTG以前の環境で確認が取れている。
　⇒プロダクト内でのAPIコールまで含めた自動テストがSTG環境で動作する。
・各サーバごとに安全なS-outが可能


このレベルではまだ抽象的な、夢物語ですが、少しでもこの「強い」状態に近づけていくことが、今期の課題の一つになりそうです。