$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

「ピープルウェア 第3版」読んだ

昔読んだけど、プロジェクトマネジメントや組織マネジメントをしてきた今だからこそもう一度読みたいなと思い、読んだ。

久々に読むとまた別のところに面白さを感じてよかった。特に「根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く」「早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない」「エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である」「誰とチームを組んでいるか、が生産性向上の要因になっている」あたりが面白かった。

読書ノート

以下読書ノート。(「知的戦闘力を高める独学の技法」という本で気づきも合わせてメモすると良いと書いてあったのでやってみた)

  • 根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く 469
    • 気づき: 制度設計や形骸化したミーティングでも同じ。インクリメンタルに改善していると局所最適で無駄が多くなってしまう。一回捨てることで全体最適が出来る
  • 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 706
    • 気づき: スケジュールは意欲の湧くものにする。
    • 気づき: 最終締め切りと、目標は別でも良い
  • エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である 770
    • 長い目で見れば、市場が必要としている程度に品質水準を合わせるとコストが増える
    • 開発者自身が満足する品質基準を決めることが生産性の向上につながり、品質を上げるためのコストを補って余りある 790
    • 気づき: リーンとDevOpsの科学でも、結局変更失敗率と変更速度は逆相関の関係では無かったと言っていたので、開発速度と品質がトレードオフという考えは直感では正しそうだけどそうでもないのだろう
  • 誰とチームを組んでいるか、が生産性向上の要因になっている 1248
    • パートナーの成績が良ければもう片方も成績が良く、そうでなければ逆の結果に
    • 気づき: デッドラインでも、別プロジェクトでチームとなっていた人をそのチームのまま他の部署にと書いてあったので、近いことを言ってそう
  • 仕事に取り組んだ時間の測り方を、フロー状態の時間をベースにしたものにする 1600
    • 連続して中断が入らなかったhour数で計測
    • E係数 = 中断なしの時間 / 机の前に座っていた時間で計測すると、最高0.38、最低0.10と大きな開きがあった
  • リーダーシップ:不言実行 2321
    • 気づき:経験則だが、とにかく言う前にやっていくというのは本当に大事
  • 人が入れ替わる際の全コストは、結局5ヶ月分の人件費ほどにもなる 2594

参考

昔読んだときの感想 「ピープルウェア」を読んだ - $shibayu36->blog;

Renovateを使ってライブラリアップデートの自動マージ

利用しているライブラリのアップデートは常に行いたいが、中々コストの掛かる作業でもある。その時にテストが通ったらOK・型検証が通ったらOKみたいなライブラリ(例: TypeScriptなら @types/系やjestなど)なら人間の目を通さずに自動でPullRequestをマージしてくれたら、その分コストが減り、人間の目が必要な作業を行う時間が増える。

そこでRenovateを使って上記のようなことをやってみたのでメモしておく。

出来たもの

https://github.com/shibayu36/typescript-cli-project/pull/10 のように、Renovateのbotが勝手にPRを作り、勝手にApproveし、テストが通ったら(GitHubのchecksが通ったら)勝手にマージしてくれるようになった。

実現するためにやること

  • Renovateを有効にして、自動マージできるように設定ファイルを作る
  • renovate-approveを有効にして、レビューが必須でも勝手にApproveしてくれるようにする

の2つだけしたら良い。

Renovateを有効にして、自動マージできるように設定ファイルを作る

https://github.com/apps/renovate を入れたいレポジトリに設定すれば良い。するとConfigure Renovateというissue( https://github.com/shibayu36/typescript-cli-project/pull/6 )が作られるので、それを見ながら設定する。

自動マージを実現するために以下のようにrenovate.jsonを設定した。

{
  // VSCodeで補完が効くようになって便利
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  // 一般的な設定を有効にし、timezoneも設定する
  "extends": [
    "config:base",
    ":timezone(Asia/Tokyo)"
  ],
  // ラベル付ける
  "labels": ["dependencies", "renovate"],
  // CIを阻害しないように、夜や週末に実行する
  "schedule": ["after 10pm and before 5am every weekday", "every weekend"],
  // これを設定しておくと https://github.com/shibayu36/typescript-cli-project/issues/17 みたいなのが作られて便利
  "dependencyDashboard": true,
  // pinのPRは自動マージ
  "pin": {
    "automerge": true
  },
  // npmではrangeのバージョンを使う
  "npm": {
    "rangeStrategy": "bump"
  },
  // @types/系はmajorが変更される以外は自動マージ
  "packageRules": [
    {
      "packagePatterns": ["^@types/"],
      "automerge": true,
      "major": {
        "automerge": false
      }
    },
    // jestはまとめる(一旦自動マージしない)
    {
      "groupName": "jest",
      "sourceUrlPrefixes": [
        "https://github.com/facebook/jest",
        "https://github.com/kulshekhar/ts-jest"
      ]
    },
    // linter系はまとめる(一旦自動マージしない)
    {
      "groupName": "linters",
      "extends": ["packages:linters"],
      "packageNames": ["prettier"],
      "packagePatterns": ["^@typescript-eslint/"]
    }
  ]
}

必要があればjestの自動マージやlinterの自動マージを設定すると良いだろう。

renovate-approveを有効にして、レビューが必須でも勝手にApproveしてくれるようにする

基本は上記設定でも問題ない。しかしGitHubのBranch protection rulesの設定でRequire pull request reviews before mergingを有効にしている場合、ReviewsのApproveがないことで自動マージが出来ないという問題がある。

この場合の解決策もRenovateは用意してくれていて、https://github.com/apps/renovate-approve を入れるだけで済む。とりあえず入れておくと良いだろう。

まとめ

今回はRenovateで自動マージを実現する方法を調べたのでメモしておいた。今回は調査のために1から設定したが、とにかく素早く使いたいなら下のような設定を使うのも良いだろうと思う。

developer.hatenastaff.com

GitHub Actionsでeslintを動かすだけでFiles changedにlint errorが表示されて便利

GitHub Actionsでeslintを動かすだけでFiles changedにlint errorが表示されるのが便利すぎたので紹介。

様子

f:id:shiba_yu36:20201106221356p:plain https://github.com/shibayu36/typescript-cli-project/pull/7/files

やり方

GitHub Actionsでsetup-nodeを使った上でeslintを動かすだけ。

これだけで上で紹介したようにlintのエラーがFiles changedに出てくる。便利。

仕組み

Problem Matchersという仕組みを使っているみたい。例えばsetup-nodeだと

のようになっているので、setup-nodeをするだけでeslintの出力をparseしてくれるようになるようだ。

このような仕組みを使えば、自分で便利なProblem Matchersを作れそうだ。

まとめ

今回は、GitHub Actionsでeslintを動かすだけでFiles changedにlint errorが出て便利という紹介と、その仕組みについて軽く調べたのでブログに書いておいた。便利そうなProblem Matchersを思いついたら自分で書いてみようと思う。