Zenn
🗃️

TypeScript 5.8、Terraform 1.11 リリースなど|Productivity Weekly(2025-03-05)

こんにちは。サイボウズ株式会社 生産性向上チームの佐藤(@defaultcf)です。

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

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

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

news 📺

Announcing TypeScript 5.8 - TypeScript

https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/

TypeScript 5.8 きました!! わいわい!!
以前 Productivity Weekly で紹介した 5.8 Beta から変更あります

5.8 Beta までは、返り値の型が条件型である場合の推論が賢くなる予定でしたが、これが差し戻されて 5.8 では超絶機能制限版が入ることになりました。超絶機能制限版では、条件式のブランチに any 型が含まれる場合のいい感じの型検査のみとなっています。

紹介記事のコードを一部変更した次のコードを例に説明します。TypeScript では、条件式(俗に三項演算子と呼ばれている、t1 ? t2 : t3 というやつ)の型は t2, t3 それぞれの型のユニオンとなるので、次の例では any | string となります。これまではこれが単に any 型に丸め込まれていたので、else 節で URL オブジェクトを作っていないのにも関わらず型検査が通っていました。5.8 からは、ユニオンの各要素が関数の返り値の型(今回は URL)と整合するか検査されるので、この種のバグを静的に検出できます。

declare const untypedCache: Map<any, any>;

function getUrlObject(urlString: string): URL {
    return untypedCache.has(urlString) ?
        untypedCache.get(urlString) : // any
        urlString; // string
}

条件型の賢い推論、5.9 では入ってくれると嬉しいですね!

本項の執筆者: @ajfAfg

Terraform 1.11がGAになりました | DevelopersIO

https://dev.classmethod.jp/articles/terraform-1-11-is-now-generally-available/

Terraform 1.11 きました!! わいわい!!2

生産性向上チーム的にクリティカルに効く変更は、tfstate の DynamoDB を用いたロックが deprecated になる点です。これからは S3 を用いたロックが GA になったので、これを利用せよとのことです。あと、ephemeral な attributes が利用可能になってたりします。

待望の S3 ロック GA です!! バンバンロックを取って最強のインフラを作り上げていきましょう。

本項の執筆者: @ajfAfg

Increased items in GitHub Projects now in public preview - GitHub Changelog

https://github.blog/changelog/2025-02-26-increased-items-in-github-projects-now-in-public-preview/

2025/3/5 頃より、GitHub Project のアイテム数の上限が 1,200 から 50,000 に増加する機能がパブリックプレビューになります。

プロジェクト管理ツールとしてより使いやすくなって嬉しいです!

本項の執筆者: @ajfAfg

Introducing GitHub Secret Protection and GitHub Code Security - GitHub Changelog

https://github.blog/changelog/2025-03-04-introducing-github-secret-protection-and-github-code-security/

GitHub Advanced Security がシークレット関係のプランとそれ以外(code scanning など)のプランの 2 つに分割されます。合計した料金は従来と同じです。新プランは 4/1 から始まります。また、GitHub Team プランでも契約できるようになります。

現在は GitHub Advanced Security ($49/active committer) というサービスとして契約する形でした。4/1 より GitHub Secret Protection ($19/active committer) というサービス、GitHub Code Security ($30/active committer) という 2 つのサービスに分かれ、それぞれ契約できる形になります。

GitHub Secret Protection はシークレット漏洩を未然に防ぐ、検知するサービスです。従来の push protection や secret scanning などの機能が含まれています。

GitHub Code Security はコードの脆弱性検出、修正をするサービスです。従来の code scanning や copilot autofix などの機能が含まれています。

サービスが 2 つに分かれたことにより、必要な機能を最小のプランで契約できるようになったので、ユーザからすると利用がしやすくなりましたね。例えば脆弱性対策は別のサービスやツールで行うため push protection、secret scanning のみほしいといった場合にこれまでは一人当たり $49 で割高感があったかもしれませんが、今後は一人当たり $19 で契約できるようになります。GitHub 側でシークレットっぽい文字列の push をブロックするなどは GitHub でしかできないことなので代替しづらいという背景もあるかもしれません。

また、これまでは GitHub Enterprise プランの顧客しか Advanced Security を契約できませんでしたが、4/1 からは GitHub Team プランの顧客も契約できるようになります。少人数の方が導入しやすいサービスではあるので Team プランの顧客からの需要は多そうですね。

これまでコスト面で契約を渋っていたり、一部の機能しか使えてなかったりする組織は新プランを真面目に検討しても良いと思います。
1 つの組織内で片方のみ適用・両方適用ということもできるかが個人的には気になってますね。2025/03/07 時点で pricing ページは古いままになってるっぽいのでもう少ししたら詳細がわかってくるかもしれません。早く知りたい人はサポートや営業に問い合わせましょう。

本項の執筆者: @korosuke613

Simplify policy adoption in Terraform with pre-written Sentinel policies for AWS

https://www.hashicorp.com/ja/blog/simplify-policy-adoption-in-terraform-with-pre-written-sentinel-policies-for-aws

HashiCorp と AWS による事前定義の Sentinel ポリシーが GA となりました。

AWS のベストプラクティスに沿っているかが、Sentinel ポリシーとして記述されており、ユーザーはこれを使用することで Terraform コードの変更がベストプラクティスに違反していないかを簡単にチェックできます。

Sentinel は HashiCorp が提供する Policy as Code を実現するためのフレームワークの 1 つです。
Terraform Cloud で使用すると、terraform plan 結果を検査し、その変更がポリシーを満たしているか検査してくれて、違反している場合は apply させない、といったことができます。

今回提供されるようになった Sentinel ポリシーは、CIS AWS Foundation Benchmarks v1.2, v1.4, v3.0 に準拠しています。

HashiCrop Terraform Registry で公開されており、すぐに導入できるようになっています。
https://registry.terraform.io/policies/hashicorp/CIS-Policy-Set-for-AWS-Terraform/1.0.0?product_intent=terraform

HashiCrop と AWS が公式で提供するポリシーということで、安心して取り込むことができるようになったのではないでしょうか。

本項の執筆者: @defaultcf

know-how 🎓

時間がかかっていた git status を Trace2 で計測しながら10倍速くした話 - Mirrativ Tech Blog

https://tech.mirrativ.stream/entry/2025/02/25/100000

ミラティブさんによる時間のかかる git status がどこで時間がかかっているか計測・改善して 10 倍早くした話です。

何もしない状態だと git status に 2 秒弱かかっていたため、Trace2 という git のパフォーマンス計測方法を使い、何に時間がかかっているかを調べ、ボトルネックを解消することを繰り返し、最終的に 1.941 秒を 0.173 秒にまで短縮しています。手法としては core.untrackedcache の有効化、file system monitor の有効化、サブモジュールの算出オフを紹介しています。Trace や各手法についてもわかりやすく概要を説明されていて良かったです。

僕も最近やけに大変大きいリポジトリを触っているおり、git status に 1 秒近くかかっていたため早速試してみました。非追跡ファイルが大量にあったので core.untrackedcache を有効化したところ、それだけで 0.1 秒以下まで git status を高速化できました。ディレクトリのタイムスタンプを見てキャッシュしているだけっぽいので開発中は 0.1 秒以下で安定することはないとは思いますが。
個人的には 0.1 秒以下で大満足なのでそれ以上の手法は試していませんが、file system monitor はデーモンを常駐させるっぽいので効果が大きく出そうなリポジトリで試したいですね。

git は知らない機能が本当にたくさんあるなという気持ちです。git の機能ノウハウを増やしていきたいですね。皆さんも動作に時間がかかるリポジトリがあれば計測して改善できないか試してみてください(そしてブログを書いてほしい)。

本項の執筆者: @korosuke613

GitHub Container registryのレート制限について - knqyf263's blog

https://knqyf263.hatenablog.com/entry/2025/02/28/210820

GitHub Container registry (GHCR) のレート制限が実は存在するという話です。また、回避策も書かれています。

GHCR は表向き rate limit が存在しません。しかし、著者の方が開発している OSS「Trivy[1]」においては rate limit に引っかかる報告が多数されており、問い合わせたところ実は rate limit が存在することが判明したとのことです。

気になる rate limit は Organization に対して 44000 req/minute[2] であり、利用者(ユーザ)側に課される制限値ではなく提供者(org)に課される制限値であるため OSS においては対策が難しくなっています。結局 rate limit の存在しない(?!)他のレジストリを使うようにして回避したとのことです。

全く知らない制限の話でした。一般人には滅多に引っかからない制限だとは思いますが、回避策含めて知見として知っておくとどこかで役に立てそうですね。

本項の執筆者: @korosuke613

read more 🍘

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

あとがき

サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック!
https://www.docswell.com/s/cybozu-tech/5R2X3N-engineering-productivity-team-recruitment-information


脚注
  1. 私も利用している OSS です。いつもお世話になっております。 ↩︎

  2. 正直この制限に到達する org がどれだけあるのか気になります。Trivy でしか見たことない。 ↩︎

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

Discussion

ログインするとコメントできます