Zenn
サイボウズ 生産性向上チーム 💪Publicationへの投稿
🏪

Productivity Weekly (2023-07-26号)

Futa Hirakoba
2023/08/04に公開
ProductivityWeekly
生産性向上
idea

こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。

僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。

2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2023-07-26 号です。

今回が第 119 回目です。過去の記事はこちら。

news 📺

GitHub Actions: Update on save-state and set-output commands - The GitHub Blog

https://github.blog/changelog/2023-07-24-github-actions-update-on-save-state-and-set-output-commands/

GitHub Actions 初期の頃から存在する save-state, set-output というコマンドは既に2022/10に Deprecated アナウンスが行われて廃止時期 2023/05/31 と名言もされていたのですが、今回延期が決定したようです。さらに今回のアナウンスでは延期後の次の廃止時期について明記されませんでした。

save-state, set-output を使っているワークフローは warning のアノテーションが出るものの引き続き利用できるとのことです。ただ、この 2 つの古い方法は既にドキュメントからも削除されています。過去にこれらを使用したワークフローや actions を作成していた場合は GITHUB_STATE, GITHUB_OUTPUT の環境変数を使用する新しい方式に移行しましょう。移行の具体的な方法は前回のアナウンスが参考になるはずです。

本項の執筆者: @kesin11

GitHub Copilot Chat ベータ版がすべての組織で利用可能に - GitHubブログ

https://github.blog/jp/2023-07-24-github-copilot-chat-beta-now-available-for-every-organization/

GitHub において、GitHub Copilot Chat が GitHub Copilot for Business を契約している Organization で使えるようになりました（パブリックベータ）。

利用するには GitHub Copilot for Business を契約している Organization である必要があり、管理者による Chat の有効化が必要です。
また、Copilot Chat の利用をポリシーで制限することも可能です。

GitHub Copilot Chat は僕もクローズドベータの頃から使っていましたが、軽い質問はもちろん、コードの説明やテストケースの生成にも使えてとても便利です。
GitHub Copilot for Business を契約している組織管理者はぜひ有効化を検討してください。

本項の執筆者: @korosuke613

know-how 🎓

GitHub の merge queue で 「マージ待ち」を解消した話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)

https://hackerslab.aktsk.jp/2023/07/20/183510

アカツキさんによる、7/12 に GA となったばかりの GitHub における merge queue の活用事例です。
merge queue があることで何が嬉しいのか、使ってみて出てきた問題とワークアラウンドなどが載っています。

アカツキさんのあるリポジトリには同時実行できず時間のかかる E2E テストが存在するため、マージするまでに待ち時間が発生してしまうという問題がありましたが、merge queue を使うことでその問題を解消できたとのことです。
同時実行できないテストがある際は、どうしてもマージ待ち行列ができてしまうと思うので、merge queue は効果的でしょうね。

merge queue は僕も以前探求したのですが、仕様がちょっと複雑で、慣れるまで手こずりました。記事内でも仕様について触れられており、普通に使うと「merge queue の為のジョブを 2 回実行しなければいけない問題」の話も書かれています。
僕もダミーのワークフロー・ジョブを用意することで回避したのですが、やっぱりこの方法しかワークアラウンドは無さそうですね...

merge queue 導入のメリットだけでなく、誰もがぶつかりそうな壁についての話も入っており、merge queue をまだゴリゴリに使ってない人には特に参考になると思いました。「マージ待ち」で困っている方は、ぜひ一度読んでみてください。

本項の執筆者: @korosuke613

Github Merge Queueの何が嬉しいのか - ymtdzzz.dev

https://ymtdzzz.dev/post/merit-of-github-merge-queue/

こちらも GitHub における　merge queue の事例記事です。

先の紹介記事では、時間がかかって同時実行できないテストがある場合に効果的という話でしたが、こちらの記事では、デフォルトブランチの変更によりトピックブランチのテストが落ちるようになっても、rebase せずテスト失敗に気づけるという merge queue 活用話が書かれています。
丁寧に一作業ずつ説明されており、merge queue の上記のユースケースがわかりやすいです。

正直全く予想していなかった merge queue の使い方でした。最小プルリク数（Minimum pull requests to merge）を 1 にする理由が思い浮かんでなかったのですが、なるほどこういう時は便利ですね。
rebase の回数を減らせるのは楽で良いです（branch protection で Require branches to be up to date before merging を設定すればいいだけかもしれませんが、だとしても自動で rebase はしてくれないので便利だと思います）。

本項の執筆者: @korosuke613

Git履歴をgit resetとgit rebaseで管理する（翻訳）｜TechRacho by BPS株式会社

https://techracho.bpsinc.jp/hachi8833/2023_07_24/131590
原文: https://binarysolo.chapter24.blog/how-i-manage-my-git-history/

squash & merge だと巨大なコミットができてしまうので、reset & rebase を使って綺麗なコミットにすると良いでしょう、という記事です。

まず初めに git reset --mixed の説明があり、手元でガンガンコミットしてちょっと汚くなってしまったログをキレイに整える話が出てきます。
git reset --mixed main のように実行し、手元のファイルはそのままにコミットだけを取り消します。
そして改めてキレイにコミットしていくというものです。

そして、複数のコミットを修正するために git rebase -i を使います。
git rebase -i では、コミットを時系列（上から下へ、旧から新の順に並びます）で眺めながら、各コミットをどう処理するか指定できます。

記事の例では lint の修正を後からコミットして、それを前のコミットにまとめることが書かれています。
lint の修正コミットの行を、まとめたい先のコミットの行の直後に移動させ、修正コミットの処理には squash を指定してエディタを閉じます。
すると squash が行われ、コミットがまとめられます。非常に直感的で簡単ですね。

また git rebase -i では過去のコミットの削除（drop）や、コミットメッセージの修正（reword）など、他にもいろんなことができます。
reset と rebase は破壊的なイメージがあるから使わない人もいると聞きますが、上手く使うとこのように非常に便利です。
是非お試しください。

本項の執筆者: @defaultcf

AWS コストの最適化を検討する時、最初にチェックしたい定番の項目をまとめてみた（2023年夏版） | DevelopersIO

https://dev.classmethod.jp/articles/aws-cost-optimize-cheat-sheet-202307/

クラスメソッドさんが、AWS のコスト最適化を検討する際にチェックしたい項目をまとめています。
主要サービスごとにチェックリストがあり、それぞれのチェック項目に対して、どのように検討・対応すればいいか、推奨度合い、関連リンクが載っています。

例えば、以下のようなチェック項目があります。（これらは一例であり、多くの項目があります。）

  • Amazon EC2: 停止または削除可能（利用頻度が低い・用途不明・代替可能）なリソースの有無
  • Amazon S3: 不完全なマルチパートアップロードをクリーンアップ
  • Amazon CloudWatch: Amazon CloudWatch Logs の利用状況（保存期間、利用状況、不要なログ）
  • ...

どのように検討・対応すればよいかも箇条書きで簡潔に書かれており、とてもわかりやすいです。
サービスごとにまとまっているため、Cost Explorer などでコスト配分の大きいサービスから確認していくと良いかもしれませんね。

みなさんも AWS のコスト最適化、やっていきましょう。

本項の執筆者: @korosuke613

tool 🔨

Metrics for issues, pull requests, and discussions - The GitHub Blog

https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/

GitHub リポジトリの issue やプルリクエストの time to first response、time to close などのメトリクス集計ができる GitHub Actions のアクションが GitHub によってリリースされました。

https://github.com/github/issue-metrics

どれだけ早く issue やプルリクエストのに反応できてるかみたいな指標を GitHub Actions でお手軽に集計できます。
記事には使い方だけでなく、いろんな立場の人のためのユースケースも載っています。

僕の管理してるリポジトリに issue が活発なものはなかったので、プルリクエストを対象に実際に試してみました。

全体の time to first response や time to close ももちろんのこと、どのプルリクエストに時間がかかったのかなどもわかり、なかなかおもしろいです。クエリを工夫して柔軟に集計できるのも良いですね。
ただ、得られたデータをどう活用するかは利用者の手にかかっているので、そこはがんばらないといけません。

OSS だけじゃなく、プライベートな製品リポジトリでも活用できそうです。

本項の執筆者: @korosuke613

read more 🍘

Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。

本項の執筆者: @korosuke613

あとがき

今週号でした。最近遅めだったけどちょっと早く出せたぞ（ホンマか？）

最近日光に初めて行ったのですが、車でドライブで行くのにちょうど良い距離でなかなかよかったですね。
でっかい滝[3]がでっかくて今でも頭の中で水飛沫を感じられます。
時間の都合で日光東照宮には行けなかったので、リベンジ日光マッチをしたいですね。

サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
https://note.com/cybozu_dev/n/n1c1b44bf72f6

【現地orオンライン(予定)】GitHub dockyardコミュニティ 竣工イベント！ - connpass

https://github-dockyard.connpass.com/event/289714/

2023/08/05（土）に「GitHub dockyard コミュニティ竣工イベント！」というイベントが開催されます。

銀座にある GINZA SCRATCH で開催予定です。（オンライン配信も予定されています）
茅場町のコワーキングスペース茅場町 Co-Edo で開催予定です。（オンライン配信も予定されています）

GitHub の開発者向けコミュニティイベントとのことで、GitHub 製品に精通している方々によるセッションがいくつかあります。
生産性向上チームからも登壇者がいます。楽しみですね。

個人的には GitHub Project をあまり追っかけられていないので、「自称日本一 GitHub Projects を使っているので魅力を伝えたい！」が気になりますね。
とはいえ残念ながら僕はイベントを知る前から先約が入っていたため、参加できません。残念 🥲

気になる方はぜひ参加してみてください！

脚注

  1. セキュリティに関する施作を開発の早い段階で組み込むこと。参考: シフトレフトとは - 意味をわかりやすく - IT用語辞典 e-Words ↩︎

  2. PaaS は Platform as a Service の略です。Integration PaaS は各プラットフォームを組み合わせられるサービスを指すらしいです。 ↩︎

  3. 華厳滝（けごんのたき）というらしいです。詳しくはググってください。 ↩︎

GitHubで編集を提案
サイボウズ 生産性向上チーム 💪
サイボウズ 生産性向上チーム 💪Publication

サイボウズ株式会社 開発本部 生産性向上チームです。 サイボウズエンジニアの生産性を上げるために日々活動しています 💪

Discussion