updateするタイミングと共有についての考察

 

昨今,超高速開発なんて言葉(※1)もありますが、MobileアプリやWebサービスで生計を立てている組織では、頻繁にデプロイをかけていると思います.

デプロイするタイミングやフローはそれぞれの組織で異なるのはまぁよいとして,自分が気をつけている点を備忘録代わりにまとめておきます.

緊急性が高い場合

セキュリティupdateや,基地の脆弱性対応,致命的なバグfixが当たるかと.さっさと対応するのが良いと思います.

ユーザや関係者への報告は,必ず行います.もしかすると事後になるかもしれませんが.

影響範囲が広い場合

影響を受けるユーザ数や,メンテナンス時間が長い場合が該当します.

具体的には,DBの移行や入れ替え,サーバーの切り替えなどでしょうか.デプロイをするタイミングでシステムダウンするようであればユーザが少ない時間帯(例えば深夜)に対応する等が良いと思います.

比較的,デプロイまでに時間があることが多いので,ユーザーへの周知はしっかり行っておくのが良いでしょう.

社内システムであれば,DBに触る作業を一次中断してもらうよう事前に周知しておきつつ,当日にも連絡をいれるのが良いと思います..

影響範囲が狭い場合

このあたりは,組織や個人によって異なるかもしれません.

個人的には,デプロイ+確認作業を後に残しつつ,別の作業を行うのはめんどくさいと感じてしまうので,さっさと本番デプロイしてしまうようにしています(もちろん,レビューを通した上で).

連絡は,変更があったところで誰も困らないと想定し,事後共有になると思います.

 

※12014年か2015年くらいかな.はじめに聞いたときはネーミングがギャグかとおもった…

  • このエントリーをはてなブックマークに追加
  • Pocket

この記事へのコメントはこちら

メールアドレスは公開されませんのでご安心ください。
また、* が付いている欄は必須項目となりますので、必ずご記入をお願いします。

内容に問題なければ、下記の「コメント送信」ボタンを押してください。