🧑‍⚖️

Productivity Weekly (2023-04-05号)

Futa Hirakoba

2023/04/11に公開

ProductivityWeekly

生産性向上

idea

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

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

2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2023-03-29, 2023-04-05 合併号です。

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

news 📺

GitHub Actions: Visual Studio Code Extension is now in public beta | GitHub Changelog

VSCode の GitHub Actions 拡張機能が登場しました(public beta)^[1]。

主な機能としては次があります。

ワークフローのワークフローランの管理
- 一覧の表示
- ページへのリンク
- 履歴の表示
- ログの表示
ワークフローの作成支援
- 式や構文の強調表示
- ホバー時のドキュメント表示
- 式や構文の validation
- 式や構文の自動補完

個人的にはワークフロー一覧の表示とかよりも、式や構文の validation や自動補完が嬉しいです。
特に、3rd party アクションに関する支援（リンクの表示や with の検証）がとても便利です。

大変便利なので、GitHub Action ユーザはぜひ使ってみてください。
個人的には JetBrains IDE を好んで使うため、そっちにも公式で拡張機能を出してほしい気はします。

Introducing GitHub Copilot X

去年、コーディング時に AI に次のコードをサジェストしてもらうサービス、GitHub Copilot がリリースされましたが、今回、新たに GitHub Copilot X が登場しました。

GitHub Copilot X は 1 つの機能・サービスというわけでなく、AI による新たな開発者体験を実現する実験的なサービス群を指します。
GitHub の中の人によると、Copilot に関する各名称は次を表すようです。

GitHub Copilot 👉 プロダクト
GitHub Copilot for Business / Individual 👉 提供形態
GitHub Copilot X 👉 ビジョン
https://twitter.com/yuhattor/status/1640344136787034113

ビジョンと言われるとわかりやすいですね。

実際には次の機能が Copilot X の一部として紹介されています。

GitHub Copilot chat
- ChatGPT のような体験をエディタで
Copilot for Docs
- プログラミングに関するドキュメントに詳しい Chat
Copilot for Pull Requests
- プルリクエストの説明をしてくれる
Copilot for CLI
- 質問すると CLI のコマンドを提示してくれる。解説もしてくれる^[2]

また、上記ブログ記事に載ってないようなプロジェクトも GitHub NEXT で始動しており、クラメソさんが最近まとめてくれていました。

【GitHub Copilotは序章に過ぎない!?】GitHub Next、次世代の開発エクスペリエンスを実現する圧倒的なプロジェクト群 | DevelopersIO

GitHub Copilot for Your Codebase や GitHub Copilot Radar もまだ WIP 段階となっていますが、WAITLIST 段階になると X に含まれるのかもしれませんね。

Copilot X についてですが、あくまでビジョンを表すものであり、ここのサービスは実験段階とのことです。
既存の Copilot のプランに含まれるかどうかやそもそも提供されるかどうかも現時点では決まってなさそうです。

GitHub Copilot X is currently a representation of GitHub’s vision for the future rather than an available product offering of GitHub Copilot. As we continue to design, test, and build features that fall into the GitHub Copilot X vision, we are also taking the time to determine the best way to provide them to our customers.
https://github.com/features/preview/copilot-x

GitHub Copilot を契約している方であれば、各 Waitlist に参加し、待てば実際に触ることができます。気になる機能があれば触ったりフィードバックを送ったりしてみましょう。

個人的にはプルリクエストの説明をしてくれるやつがとても便利そうで興味があります。
ソフトウェア開発がますます加速しそうですね。楽しみです。

know-how 🎓

【Copilot はじめました】GitHub Copilot 導入におけるハードルの整理 - M&Aクラウド開発者ブログ

M&A クラウドさんによる GitHub Copilot 導入話です。導入する上で避けられない、セキュリティ・ライセンス周りの懸念点・リスクをどう扱うかがの事例が書かれています。

GitHub Copilot では利用者が書いているコードの続きを Copilot が提案してくれますが、提案を受け取るためにはコードの一部を GitHub が管理するサーバに送る必要があります。そのため、GitHub に送られたコードがどう扱われるかは知っておく必要があります。この記事では、送信されたコードがそれぞれのプラン(for Individuals, for Business)でどう扱われるのか、プライバシーポリシーはどうなっているのかをまとめてくれています。

他にも GitHub Copilot が提案するコードを採用することで他の OSS のライセンスを侵害してしまう可能性があるというリスクが存在します。この記事では、そのリスクをどう抑えるか^[3]、リスクをどう評価するかが書かれています。また、ライセンス侵害による訴訟が発生した場合の防御措置についても触れています。

GitHub Copilot を扱う上でのリスクに対してどう判断したかの詳細が載っているのは、現在導入を検討している企業にとっては大変参考になるのではないかと思います。
個人的にはリスクを 0 にすることはできないと思っているので、最小限化した上で Copilot 利用していけるといいのかなと思っています。

GitHub Appsトークン解体新書：GitHub ActionsからPATを駆逐する技術

GitHub Actions でよりセキュアに権限を行使するために GitHub Apps トークンを使うという記事です。

GitHub Actions で使える GITHUB_TOKEN の権限が足りなかった際に、Personal Access Token(Classic) を使いがち^[4]ですが、PAT はリポジトリを絞り込めなかったり、長期間トークンを生存させなければならず流出時が怖かったりと、基本的に使いたくないです。

そのため、この記事ではよりセキュアにある程度使いやすい方法として GitHub Apps のトークンを紹介しています。GitHub Apps だと発行したトークンは短命だったり、リポジトリを制限できたり、ユーザに紐づかなかったり^[5]と色々と利点があります。

この記事では、なぜ GitHub Apps か、Apps のセットアップ、3rd party アクションによるトークン生成方法＆3rd party アクションをおすすめしない理由^[6]、自前実装によるトークン生成方法＆さらなるセキュリティ強化などが書かれています。

特に自前実装によるトークン生成の項目では、ただ完成形を提示するのではなく、1 つ 1 つの処理で何をやっているかを説明しており、GitHub Apps のトークン発行の仕組みを知りつつ実装していけます。

GitHub Apps のトークン発行についてこれだけわかりやすく説明してくれている記事は初めてみました。Apps の管理やトークン発行までがちょっと面倒かもしれませんが、記事を読めればトークン発行までの道はそんなに苦ではないと思う（実際自分の中でもハードルが下がった）ので、今後は PAT をどんどん App に置き換えていきたいですね。

モノレポでの GitHub Actions CI の泥臭い高速化

アセンドさんによる開発が活発なモノレポでの GitHub Actions 高速化の話です。

パッケージごとに成果物の有無をキャッシュし、ビルドが不必要であれば（キャッシュが存在すれば）ジョブをスキップするという方法が細かく紹介されています。

また、GitHub Actions 特有の問題（ジョブの立ち上げオーバーヘッドや 1min 切上げの課金など）を回避するためのテクニックや、キャッシュキー生成のメンテナンス性改善などの工夫も書かれています。

あくまでアセンドさんのモノレポ構成が前提としてあるため、キャッシュキーの計算方法が Node.js 特有であるなど、細かいところまでは自身の環境に最適化する必要がありますが、大まかな考え方はだいたいどの構成にも効果的であり、CI 高速化をしたい場合にとても参考になると思います。

ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す - Google Slides

廃墟（＝動いているけどメンテできない、されてないもの）との付き合っていく方法についての発表スライドです。

廃墟を直すか、廃墟から出るか、廃墟を壊すか、廃墟に住み続けるのか...という廃墟への対応をパターン別に紹介しており、また、そもそも廃墟を作らないためにはという内容も載っています。

廃墟という言葉にとてもしっくりきました。技術的負債と言わず廃墟と言った方がいいパターンは決して少なくなさそうです。

僕も廃墟に当たりそうなシステムを少なからず見てきました。特に僕のいるチームではメンテコストが高すぎるものや手をつけられる状態にないシステム^[7]を破壊（移行）する方針であるため、いろいろなステークホルダに破壊のための説明をすることが多いです。

廃墟とあい見えることが多いからこそこのスライドの内容は参考になるなと思いました。色々な人に読んでもらって廃墟という言葉が共通言語になれば廃墟を作らない・廃墟に住み続けないことがやりやすくなりそうだと思いました。

あとがき

なかなか余裕がなくて read more 🍘 多めになってしまいすみません。

先日、映画 Winny を見てきました。絶対暗くなるよな〜と思いつつ見に行って案の定悲しい気持ちになって帰ったのですが、1 人の開発者としてあの大事件を映像で見ることができたのは良かったです。
金子さんが長い間開発できないのに裁判で戦いぬいたのは本当にすごいと思います。敬意を評したいです。

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

脚注

ちなみに僕は存在すら知りませんでした。 ↩︎
前試した時の様子 https://twitter.com/Shitimi_613/status/1632941034140471296 ↩︎
GitHub の機能（Suggestions matching public code）で少し安全側に倒せる。 ↩︎
よりセキュアな fine-grained な PAT も存在しますが、こちらは定期的に手動でトークンのローテーションが必要となってしまって現状使いづらいです。 ↩︎
Organization で App を作る場合の話。 ↩︎
個人的には 3rd party アクションは中身を精査（変なことしてないかや依存の依存が固定されているかなど）した上でハッシュ固定で使えばいいって思っちゃうタイプ。とはいえ認証に関わる大事な部分なので自前で用意するに越したことはないと思う。 ↩︎
自分らで作ったものもあれば、人からもらったものもある。 ↩︎

GitHubで編集を提案

サイボウズ生産性向上チーム 💪Publication

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