Productivity Weekly (2022-07-20号)
こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
今回が第 83 回目です。過去の記事はこちら。
news 📺
Carbon, a new programming language from Google, aims to be C++ successor
Google が C++ の後継者とするための新しいプログラミング言語 Carbon を発表しました（experimental）。
Rust が C++の後継者であるという考え方もありますが、その実 Java や kotlin のような双方向の相互運用性が無いため、実際に C++プロジェクトを移行することは困難であると記事で提唱されています。Carbon は既存の C++コードと完全に相互運用可能であり、C++から Carbon への移行をできるだけ簡単にすることを目標としています。
Carbon は OSS プロジェクトとして GitHub にて公開されており、広く Issue やプルリクエストを受け付けています。
Carbon のゴールは goals.md にまとめられており、ロードマップは roadmap.md にまとめられています。ロードマップによると、2024〜2025 年に Version 1.0 をリリースしようとしているようです。
既に実際に動かしてみた方もいます。
まだまだ正式リリースは先になるのでなんとも言えませんが、C++ と相互運用可能となったら古い C++ プロジェクトを簡単に移行していけそうですね。続報を待ちたいです。
Differentiating triggering actor from executing actor | GitHub Changelog
GitHub Actions において、ワークフローを再実行する際、最初に実行したアクター（ユーザや GitHub Apps など）の権限が使われるようになりました。これまでは再実行したアクターの権限が使われていました。これにより、再実行時に権限の差異による問題が発生しなくなります。また、意図せぬ権限昇格によるセキュリティ上の懸念も減ります。
ワークフローからは、github.triggering_actor で再実行したアクターの情報を取得できるとあります[1]。
「Starting next week」と書いており、この記事は 2022/07/19 に投稿されているのでおそらく既に施行されています。挙動が変わって驚かないように覚えておきたいですね。
sider.reviewサービス終了のお知らせ
自動コードレビューサービスの sider.review が 2022 年いっぱいでサービスを終了します。
sider.review はさまざまな言語やフレームワークに対応しており、脆弱性のあるコードやよろしくない書き方のコードを指摘してくれます。また、secret が含まれているかどうかのチェックや misspell のチェックも行ってくれます（設定で柔軟に変更できます）。GitHub でログインするだけで利用でき、設定もわかりやすかったので使いやすそうでした。
安定的にサービスを提供する事が難しくなったことがサービス終了の理由と説明されています。サービス終了までのスケジュールによると 2022 年 12 月 31 日に全てのサービスと技術サポートが終了する予定です。2014 年頃に前身である SideCI のベータ版がリリースされ、今年で 9 年目でした。
試しに Zenn の記事を管理しているリポジトリを解析してもらったところ、ミススペルが見つかりました
ちなみに Sider 社は Sider Scan というユーザがホスティングする（各種 CI サービスで実行可能）バグ検知ツールも提供しています。こちらはバグ検知に特化したプロダクトのようです。
こういった長く生きたサービスが終了するのは悲しいものがありますね。最近だと CI サービスで実行できる静的解析ツールで間に合ってるとかそういう背景があったりするんですかね。
know-how 🎓
6 strategic ways to level up your CI/CD pipeline
GitHub による CI/CD パイプラインをレベルアップさせる 6 つの戦術です。
次の先述が詳しく説明されています。
- CI/CD パイプラインにパフォーマンステスト、デバイス互換性のテスト、ビジュアルリグレッションテスト、アクセシビリティテストを追加しよう
- CI/CD パイプラインに自動のセキュリティテストを取り入れよう
- 段階的なテストを構築しよう
- ブルー・グリーンデプロイメントで簡単にロールアウトできるようにしよう
- IaC を導入しよう
- 自動ロールバックの仕組みをいれよう
CI/CD パイプラインを適当に作るのではなく、こういったことを意識して構築していきたいですね。
CircleCI の設定ファイルを分割して CUE で合成してみたら割と簡単で便利そう - Mitsuyuki.Shiiba
分割した CircleCI の設定ファイルを CUE 言語の CLI ツールを使って合成する方法について説明した記事です。
CircleCI の設定ファイルである config.yaml は原則として単一のファイルでなければなりません。複数ファイルに分けて管理したい場合は Dynamic Config を利用したり（参考）事前にマージするなどの対応が必要です。
CUE 言語は yaml や json のようなデータ記述言語の一種です。この記事では、CUE 言語を処理する CLI に分割した yaml を渡して合成し yaml でエクスポートするというアプローチを紹介しています。また、実際に CircleCI 上で利用するための Dynamic Config の設定方法も載っています。
実は CircleCI CLI にも circleci config pack というコンフィグを合成する機能があります。記事で書かれているサンプルのコンフィグを合成するように試してみたところなぜかうまく行きませんでした（指定方法が間違ってるかも？）。
`circleci config pack` vs `cue export`
jobs:
say-hello3:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
command: echo Hello, World3!
name: Say hello3
version: 2.1
workflows:
say-hello-workflow2:
jobs:
- say-hello
- say-hello2:
requires:
- say-hello
version: 2.1
jobs:
say-hello:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: Say hello
command: echo Hello, World!
say-hello2:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: Say hello2
command: echo Hello, World2!
say-hello3:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: Say hello3
command: echo Hello, World3!
workflows:
say-hello-workflow3:
jobs:
- say-hello
- say-hello2:
requires:
- say-hello
- say-hello3:
requires:
- say-hello
say-hello-workflow:
jobs:
- say-hello
say-hello-workflow2:
jobs:
- say-hello
- say-hello2:
requires:
- say-hello
❯ circleci config pack . | circleci config validate -
Error: Error calling workflow: 'say-hello-workflow2'
Cannot find a definition for job named say-hello
❯ cue export *.yaml --out yaml | circleci config validate -
Config input is valid.
なかなか面白いアプローチだと思いました。yaml で受け取って yaml でエクスポートするというのは逆転の発想感があります。CUE は一度決定した値に上書きできないという特性もあるため、意図せぬ値の上書きが起こらないことを保証できるのは嬉しいかもしれません（yq の場合は上書きされる）。便利ですね。
リリースノート管理術
CHANGELOG.md にバージョン差分を書いていく方法をやめて GitHub Releases を使うようになり、関連する色々な Tips を紹介してくれている記事です。
リリースノート自動生成時にどこのセクションにどのプルリクエストを載せるかをラベルで管理できることは知りませんでした。ラベルを各リポジトリで設定するための actions も紹介されており、リリースノートをいい感じに楽に自動生成したい際に参考になりそうと思いました。
Linting Markdown And Documentation - Earthly Blog
英文用のフォーマッターやリンターの紹介記事です。全部で 7 つのツールが紹介されており、Formatting や Spelling といったカテゴリごとに著者の方が点数をつけています。
思ったよりもこういうツールがたくさんあることに驚きました。textlint しか知らなかったので他のツールも触ってみたいです。ただ、日本語を書く場合はどこまで使えるのか怪しいので、個人的にはあくまで README.md を書く際などに使いそうです。
tool 🔨
Python コードでアーキテクチャ図を生成できる Diagrams がめっちゃ便利！
AWS とか GCP のアーキテクチャ図を書くときにコードで書けるツール Diagrams の紹介です。
アーキテクチャ図を記述できるツールはたくさんありますが、Diagrams は AWS や GCP などのアイコンが最初から用意されているのが嬉しい部分です。また、Python で記述するため、プログラマブルに記述できるのも特徴です。
とにかくアイコンが用意されているのが嬉しいですね。個人的には Python はあまり使いたくないのでなんとも微妙ですけど、アーキテクチャ図を作る際に覚えておきたいです。
koneta 🍘
Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。
-
know-how 🎓
-
GitHub Actionsでワークフローは使いまわしたいけど環境別に変数切り替えしたい場合
- Environments 機能を使わずに GitHub Actions で環境別で変数を切り替える方法の紹介
-
「PHP 8.0でエグ目のブレーキングチェンジがあったんですが、 PHP 7.4のバイナリに手を入れて、PHP 8.0の挙動を模倣して、挙動が変わっていたらログに出力する、というアクロバット対応で、無事事前に問題箇所の炙り出しができました。 弊社のスーパーエンジニアの初登壇なので、応援お願いします😌」 / Twitter
- PHP 7.4 のバイナリに手を入れて PHP 8.0 の機能の一部を盛り込んで PHP 8.0 へのアップデートを比較的安全に行うというセッションが PHP カンファレンス 2022 であります
- すごいですね。PHPer の方は見に行ってみましょう
-
GitHub Actionsでワークフローは使いまわしたいけど環境別に変数切り替えしたい場合
あとがき
デブサミ 2022 サマーの発表が終わって、反動で遊びまくってたら Weekly が遅れてしまってます。すみません...
最近遊びすぎなのでちょっとゆとりある時間を確保しようと思ってます。
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
-
しかし、ドキュメントにはまだ記載されていません。Issue に書いておきました。https://github.com/github/docs/issues/19307 ↩︎
Discussion