ちなみに

火曜日の空は僕を押しつぶした。

「レガシーシステム洗い出し大作戦」というタイトルで発表しました #kyotoasterisk

speakerdeck.com

(横長の資料が切れてしまっているので、リンク先から読んでいただけると :pray: )

Kyoto.なんか #4 で、レガシーシステムの移行でやった洗い出しについて紹介してきました。 Kyoto.なんかでの発表は第一回の Atomの話 以来。いまはEmacsです。

質問

Q. 経緯を残せということだけれど、今はどうやって残しているのか

  • 残念ながらベストな回答はなくて、現在でも努力によって運用されています。
  • 知見あるかたと情報交換したいです。
  • 少なくともいまのチームでは以下のようなことを気をつけています。
    • Issueに出来るだけの情報を書く(書きすぎても読みにくくなるので難しいですね)
    • 情報を辿れるように関連情報へのリンク、またはPRなどからのバックリンクを貼る
    • 複雑な場合にはコードからも辿れるように、関連するURLをコメントしておく

Q. 特定のコミットがいつマージされたのか調べる方法はないか

  • 現代ではGitHubやGHEがあるので特定のコミットが属するPRを知ることがは容易でmoznionさんが書いてくれている。 moznion.hatenadiary.com
  • UIからは特定コミットのパーマリンク開いて、こういうところを見ると良さそうです。
    • f:id:Sixeight:20180822145327p:plain
  • それ以前の時代のコミットについてはどのブランチに属するか調べて、そのブランチのマージのタイミングを探るしかなさそう。(そんな時代にブランチ切っているとは思えないけど)

Q. 何か問題が起きた時に気づける仕組みはあるのか

  • 事前に確認していてもどうしても漏れるところが出てくるのが前提で、どうやって気づけるようにしているのかという話。
  • エンドポイント単位では、レスポンスのステータスコードを関ししていて、200以外が急増すると気づけるようにしています。
  • またデータのオンラインマイグレーションに失敗した場合は一件毎にSlackに通知がくるようになっていてこっちらも気づけるようになっています。
  • 内部的な機能については、現時点ではシステム的な解決策はなく、リリースする前後のタイミングでエラーログを眺めたり、ワーカーのジョブが詰まっていないかを確認するというフローを入れて、人力で拾うということをしています。