こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2024-04-03 単独号です。
今回が第 148 回目です。過去の記事はこちら。
news 📺
Bringing enterprise-level security and even more power to GitHub-hosted runners
GitHub-hosted なランナーに関して一気に複数のアップデートが行われたようで、それぞれの新機能に関する紹介記事です。changelog の方でも同じ内容がよりコンパクトにまとまっている記事が上がっています。
1. Azure private network との統合が GA
GitHub-hosted なランナーが Azure private network と接続できるようになる機能が去年の後半から Public Beta として提供されていましたが、今回 GA となりました。
この機能に関してはエーピーコミュニケーションズさんの記事が詳しいです。
Public Beta からの差分として、今までの GitHub Enterprise Cloud プランに加え、GitHub Team プランでも利用が可能になったことと、利用可能な Azure のリージョンが追加されたようです。
2. macOS 14 のランナーが GA、 macos-latest ラベルのランナーは macOS 14 ランナー（M1）に切り替わる予定
今まで macos-latest は macOS 12（Intel）でしたが、GA に伴って今後は macOS 14（M1）に切り替わっていくようです。また、macOS の Larger runner である macos-latest-xlarge や macos-latest-large にも同様の変更が行われるとのことです。
これらの記事では紹介されていないですが、標準ランナーと Larger runner のページもこのタイミングで更新されており、それによると macos-latest または macos-14 は public リポジトリでも利用可能なようです。つまり、OSS 向けにもついに M1 の macOS ランナーが利用可能になったということですね！
macOS のランナーに関しては現状だと Large は Intel、XLarge は M1 であったりと大変ややこしいので、ランナーの種類とスペック一覧のページを確認することをおすすめします。
3. Larger runner のスペックに 2vCPU Linux と 4vCPU Windows が追加
Larger runner という名前に反して標準ランナーの v4 CPU より小さい Linux ランナーが追加されました。用途としては先ほど紹介した Azure private network との統合やAndroid向けのハードウェア仮想化機能など Larger runner にしか提供されていない機能を利用しつつも、スペック自体は v2 CPU で十分なユースケースを想定しているのだと思われます。
4. GPU 付きの Linux と Windows ランナーの提供が public beta で開始
GPU 付きのランナーは今までprivate betaでしたが、public beta として利用可能になったようです。
アップデートは以上です。GitHub-hosted なランナーも様々な種類が増えてきており、用途に応じた OS やスペックを選択可能になってきましたね。macOS ランナーのラベルは非常にややこしいのが残念ですが、Intel から M1 のマシンに切り替わる移行期が終われば使いやすいラベルになることを期待しています。
本項の執筆者: @Kesin11
Actions Usage Metrics public beta - The GitHub Blog
GitHub Actions において、ワークフローやジョブが Organization 内のどこでどれだけ実行されているかを知れるダッシュボード Actions Usage Metrics が public beta としてリリースされました。GitHub Enterprise Cloud 利用者のみが利用可能です。
ワークフローやジョブ、リポジトリや OS ごとにメトリクスを出すことが可能で、課金対象時間（total minutes）や実行回数などのメトリクスが確認できます。
この機能を使うことで、Organization 内でのワークフローの利用状況を把握し、リソースの最適化などに役立てることができます。
閲覧するためには Organization の Owner 権限、または Custom organization roles の View organization Actions usage metrics 権限が必要になります。Owner 以外も見られるのは嬉しいですね（メンバーならみんな見られてほしい気もするけど）。
僕もさっそく自身が管理する Org で試してみましたが、意外なワークフローが total minutes 上位に来ていていい発見が得られました。全体の実行時間を削減してコスト節約したい場合に、メスを入れるワークフローやジョブの優先度をつけやすくていいですね。
本項の執筆者: @korosuke613
Code security configurations let organizations easily roll out GitHub security products at scale - The GitHub Blog
GitHub において、セキュリティに関するデフォルトの設定プリセットを作成、リポジトリの可視性ごとに適用できる機能がリリースされました（public beta）。
設定できる項目は、Dependabot Security updates や Secret scanning、Code scanning などのセキュリティ機能です。適用対象は、「全てのリポジトリ」、「Public のみ」、「Private または Internal のみ」を選ぶことができます。なので、例えば Internal リポジトリは Secret scanning を有効にしないけど、Public リポジトリは有効にする、といった設定が可能です。
プリセット設定画面では、どの機能が GitHub Advanced Security を必要とするかもわかるようになっているので、誤って GHAS のライセンスを消費してしまう恐れも減ります。
また、プリセット一覧画面ではどのリポジトリにどのプリセットが当たっているかや、リポジトリごとに必要な GHAS ライセンス数が確認できます。
あくまでデフォルト設定なので、リポジトリごとに設定を変更したり、適用プリセットを変更したりすることも可能です。
リポジトリの可視性でデフォルトプリセットを変えられるのが特に嬉しいですね。これを機にセキュリティ設定を見直していきましょう。
本項の執筆者: @korosuke613
Style Guide - Configuration Language | Terraform | HashiCorp Developer
Terraform がスタイルガイドを公開しました。スタイルガイドは 2 つのセクションに分かれています。
最初のセクションでは、書式やリソースの構成などコードのスタイルに関する推奨事項が扱われています。
例えば、リソースの命名規則、定義の順序、コメントの書き方などが解説されています。
2 つ目のセクションでは、ライフサイクル管理、バージョン管理、機密データ管理など、運用とワークフローに関する推奨事項が扱われています。
例えば、プロバイダ・モジュールのバージョンを固定することやシークレットの管理方法などが解説されています。
v1.6 から導入された terraform test における Unit Test にも触れられています。
全体として、違和感がある内容は無く、リソース定義の順序や description と validation はちゃんと書かねば…という気持ちになりました。
これまで、有力な Terraform のスタイルガイドは Google Cloud が公開しているものしかありませんでした。
公式でスタイルガイドが公開されたことでクラウドベンダーに依らないスタイルが統一されそうでいいですね。
次の記事では日本語で要約を書いてくださっているので、英語がつらい場合はこちらを見るとよさそうです。
本項の執筆者: @r4mimu
デジタル社会推進標準ガイドラインに CI／CDパイプラインにおけるセキュリティの留意点に関する技術レポートが追加されました
デジタル庁から CI/CD パイプラインにおけるセキュリティの留意点に関する技術レポートが公開されています。
近年のアジャイル的な開発手法の普及により、迅速な変更要求に応えて効率的に変更差分をリリースできる体制が求められ、それに伴い CI/CD パイプラインの重要性が高まっています。
CI/CD パイプラインは高い権限を持つため、セキュリティの観点からも注意が必要です。そこで、本レポートではローカル作業フェーズ、ビルドフェーズ、デリバリフェーズの 3 つのフェーズに分けて、それぞれのフェーズでのセキュリティの留意点を解説しています。
最小権限の原則やトークンの管理とローテーションなど基本的なセキュリティ対策から、OpenID Connect を用いるべきといった具体的なアドバイスまで幅広くカバーしています。
CI/CD パイプラインを構築する人は必読の内容です。
本項の執筆者: @r4mimu
Linux Foundation Launches Open Source Valkey Community
背景として、NoSQL として広く知られ使われている Redis は、現在 Redis Ltd によってホストされ、マネタイズされています。
Redis Ltd の 3 月のこのブログ記事によって、Redis のライセンスが BSD License 2.0 から RSALv2（Redis Source Available License）と SSPLv1（Server Side Public License）のデュアルライセンスに変更されることが発表され、大きな話題を呼んだことは記憶に新しいですね。
Redis を使った商用サービスを提供している大手クラウドベンダーらは Redis Ltd と別途契約を結ぶ必要があるとのことです。
Microsoft は先のブログ記事中で Redis Ltd と協力していく旨コメントしていますが、AWS や GCP は特にコメントが無く、今後どのように Redis を使っているサービスが提供されるのか注目されていました。
今回 Linux Foundation が Redis のライセンス変更前である 7.2.4 の時点からフォークし、Valkey の名でオープンソースとして開発を継続し提供していくことを発表しました。
発表の記事中で AWS や GCP（の中にいる元 Redis コントリビューター）などがコメントを寄せており、これらクラウドベンダーが提供する Redis を使っているサービスが今後 Valkey に置き換わっていくことが想定されます。
あの Linux Foundation がフォークするとのことで、今後も安定して続いていきそうな安心感がありますね。
本項の執筆者: @defaultcf
know-how 🎓
The Wrong Way to Use DORA Metrics - The New Stack
近年、組織の開発生産性指標としてよく使われる DORA Metrics(Four Keys) が定着してきました。
Four Keys に基づいて組織の課題を把握したり、改善活動を行うことがあると思います。
その際に気をつけるべき誤用やメトリクスハック・キャンベルの法則などについて、具体例を交えて解説されており、分かりやすかったです。
パフォーマンスが良い組織は Four Keys 指標が高くても、逆に Four Keys 指標が高いからといってパフォーマンスが良いわけでは無かったり、Four Keys 指標が悪くてもビジネス的価値を生み出している場合もあるということには注意しておきたいですね。
本項の執筆者: @r4mimu
一日30回リリースを可能にするpixiv開発 - Speaker Deck
pixiv さんによる、一日 30 回リリースを可能にする開発手法についてのスライドです。
pixiv というサービスは長い歴史がある、かつ、大規模なプロダクトらしく、タイトルにある一日 30 回もリリースしているというのはとても驚きます。
スライドでは、一日 30 回リリースを実現するために必要な考え方や取り決め、そしてさまざまな自動化やデプロイの容易性（切り戻し含めた）を高めるテクニックなどが書かれています。
スライドを読むと、pixiv ほどのプロダクトが高頻度でリリースできていることの現実味を感じられます。リリース頻度を上げることを課題に感じている方には参考になる内容かと思います。
文量はそこまで多くなく、大切なポイントが簡潔にまとまっていて読みやすいので、気になる方はぜひ読んでみてください。
本項の執筆者: @korosuke613
どのようにして Findy Team+フロントエンドチームは高速な開発をしているか 〜開発フロー編〜 - Findy Tech Blog
開発生産性の可視化・分析をサポートする Findy Team+の開発チームにおける CI 高速化、レビューへの反応速度、プルリクエストの分類、デプロイ前の確認項目のテンプレート化など、開発フローを改善した事例が紹介されています。
個人的には、クラウド上のキャッシュを利用して依存関係から不要なテストをスキップさせるNxというビルドシステムを活用とした結果として、CI の待ちの時間を最小化してすぐにレビュー依頼を出せるように プルリクエストをなるべく小さくする という力学が働くようになったという点が面白かったです。
本項の執筆者: @Kesin11
Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog
Fargate Spot は Amazon ECS で選べるプロバイダの 1 つで、Fargate とは違って予備のコンピュートキャパシティで動作し、安く使用できますが AWS の都合でタスクの中断が発生し得ます。
この記事では、いかにして Spot のタスクの使用率や中断率をモニタリングできるようにしたかが詳しく書かれています。
個人的には、ECS タスクの停止理由を CloudWatch Logs に保存し、そこから Fargate Spot の中断を検出するのが面白いと思いました。
個人のプライベートプロジェクトで運用している ECS でも、この記事を参考にさらなる監視を導入してみます。
本項の執筆者: @defaultcf
read more 🍘
Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。
-
news 📺
-
Dependabot grouped security updates generally available - The GitHub Blog
- 去年の 7 月に Dependabot がセキュリティアップデートをグループ化する機能を public beta としてリリースしていましたが、とうとう GA になりました
- 細かく制御もできるので、Dependabot 使いの皆さんはぜひ確認してみてください
-
GitHub Copilot Enterprise - March 2024 update - The GitHub Blog
- GitHub Copilot Enterprise 3 月の更新内容です。細かい改善が多いです
- モデル変更によるコンテンツ検索の強化
- プログラミング言語の認識
- プルリクエストで diff のファイルや行を絞り込んで質問可能に
- メッセージ生成中に次の質問作成が可能に
- キーボードの上下矢印で過去のメッセージを表示可能に
- 日本語や中国語で変換時のエンターキー押下でメッセージが送られないように
- 開発リソースを enterprise に集中してる感ありますね
- GitHub Copilot Enterprise 3 月の更新内容です。細かい改善が多いです
-
脆弱性の検出から修正提案まで：GitHub CopilotとCodeQLを利用したCode Scanningの自動修正機能 - GitHubブログ
- GitHub Advanced Security 利用者向けに Code Scanning の自動修正機能がパブリックベータとしてリリースされました
- 脆弱性のあるコードを GitHub Copilot と CodeQL を使って修正提案してくれる機能です
- 以前も修正を提案してくれる機能はあったと思うのですが、Copilot も協力してくれるのが変更点でしょうか
-
Dependabot grouped security updates generally available - The GitHub Blog
本項の執筆者: @korosuke613
あとがき
遅くなりましたが今週号でした。最近締め切りのあるタスクが多くて頭を悩ませています。こういう時に限って関係ないことやりたくなるよね。
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
Discussion