コード見てもわからない情報（その変更が必要となった背景や、数ある実現方法の中からどうしてその方針で変更したのかなど）がコミットメッセージにもJIRAのチケットにも書いてなくて、当時居た人をなんとか探して聞きまわる、そして大概は昔のことなので忘れている…といった状況が当たり前だったのが一年半くらい前。最近はチームメンバが積極的にJIRA のチケットに要件確認のやりとりや、調査のメモなど、どんどん情報を残してくれるようになり、新しめのコードについては人の記憶に頼らなくても情報収集できるようになってきた。
次に課題として出てきたのが、チケット見てもコメントがたくさんありすぎて、要点を抽出するのが大変という問題。チケットクローズするときに最後のコメントとしてサマリを残してますーという声は一部からあったけど、まわりを見渡すと、最後にやったことの記録があればまだ良くて、スプリントの終わりに閉じ忘れてたチケットを急いで閉じる時とか、何も書かずに閉じちゃってることもしばしば。
通常の導線上でサマリを残す一手間をゆるく強制できないかなと思っていて、こないだの上司との 1 on 1 で相談してみたら、少し前にレビューの効率悪いのをどうにかしようという文脈でプルリクエストにサマリを書くという話をしていたのを思い出した。プルリクエスト出すときにやったことの要点と関連情報をちゃんと整理して書き、レビューアに十分な情報を出した上でレビュー依頼することで、より深いレビューをしようという話だった。リリースのために必要な一つのステップとして自然に開発フローに組み込めるのでこれはよい。
コミットメッセージにはチケット番号を入れるというルールにしてるので、次の開発や不具合調査のときに git blame すれば、過去にそのコードを変更したチケットを開くのは簡単にできて、さらにJIRAとBitbucketを連携させているから自動的にチケットからプルリクエストへのリンクも張られていて、プルリクエストに書かれたサマリに到達できる…。待てよ、毎度毎度リンクを辿るというのは面倒だな。GitHub の pull request 開くやり方は見たことあるし、自分たちが使っている Bitbucket でも同じようにできるよねと思って、元ネタ
を見直してみると、マージコミットを取ってくる所までは流用できるけどその先を hub に任せてるのでそちらは何とかする必要があることがわかった。
ここで先日 OSS Gate というイベントに参加して刺激をもらっていたのが効いた。
やってみたらよいということで実装してみて期待した動作になったので、初めて PyPI へ登録するところまで勢いでやった。
以下は開発の流れのメモ。こういう水面下でばたばたした情報も残しておくと後で何かの役に立つかもというのを OSS Gate に参加して思い出すことができた。
- BitbucketでもGitHubと同様に、マージボタンのコミットメッセージにプルリクエストの番号が定形で入るのは知ってた。
- それとリモートURLをパースしたものと合わせれば、プルリクエストの URL は生成できる！いけそうだ。
- 外部コマンド実行して出力取るの、commands で簡単にできる。(deprecated と書いてあるのこの時点では見落としてた)
- ブラウザを開くのどうしよう。macOS でも Windows でも Linux でも使えるといいんだけど。
- open, start, xdg-open を叩くようなの書けばいけそうだけど面倒だなー。
- webbrowser 使えばいけるやん。
- 引数もかっこよく処理したいなー。 argparse 使っちゃお。
- 説明読んでも add_argument の使い方分からないので試行錯誤して何とか解決 (わかりやすい チュートリアル へのリンクがあったのは後で気付いた)
- commands は python3 だとなくなってる。subprocess で書き直そう
- せっかくだし、PyPI にも登録しておこうか。
- https://pypi.python.org/pypi の Register からユーザ登録と、Package Submission から PKG-INFO の登録を試みる。
- エラーページに飛ばされる。pypi の調子が悪い？何度かやったらうまくいった。
- Package Submission のページからリンクされていた、twine を使ってアップロード
- pip install openpr でインストールできるようになった！
