✏️

2023年のエンジニア活動の振り返り & OSSへの寄付

2023/12/30に公開

GitHub Actions

idea

今までこの手の振り返り記事を年末に書いていなかったのですが、親しい友人の振り返り記事を読むのは結構面白かったり、特に今年は自分のエンジニア人生においてちょっと変化があった年なので書いてみることにしました。

登壇

毎年1-2つはCfPありのカンファレンスで採択されることを目標としています。今年の回数はあまり多くなかったのですが、一方で自分が目標にしていた大舞台に立つことができたので思い出深い年になりました。

DeNA TechCon 2023

ここ数年は大規模なゲーム開発のビルドやJenkinsを支援するというのがメインの仕事だったのですが、一区切りが付いて次の仕込みを始めていた時期でした。DeNAのTechConは自前開催のカンファレンスでありながら規模はかなり大きく、コロナ禍ではオンライン開催に加えてDiscordを併用した新しい体験の提供にチャレンジするなど毎年変化があるので自分も楽しみにしており、オフライン開催されていた時代からスタッフとして色々と関わらせて頂きました。

また社内といえども基本的に公募制となっており、CfPに提出して採択されないと発表の機会を得ることはできません。実は自分が社内異動でSWETグループに行きたいと思ったきっかけも2016年のTechConでのSWETの発表だったので、いつかは自分もという密かな思いを抱いていたのですがそれが叶いました。共にJenkinsの次としてGitHub Actionsの活用を進め、別の部署でありながら快く共同発表にしてくれた同僚にはとても感謝しています。

CI/CD Test Night #6

Jenkinsの次としてGitHub ActionsをCI/CDの基盤として考えていたのですが、社内ではほとんどのプロジェクトが github.com(GHEC) ではなくGitHub Enterprise Server（GHES）であることからセルフホストランナーのインフラ基盤を自前で構築する必要がありました。

自分も最高のインフラ基盤を設計するため、既に同様の基盤を構築した各社のブログが出るたびに読み込んでおり、経験者にぜひ直接話しを聞いてみたいと思っていました。そこで自分が読んだセルフホストランナーの記事の中で特に気になった3社の著者に直接お声がけし、セルフホストランナーのインフラ基盤設計という超ニッチなテーマの勉強会を開催しました。

自分は主催者であることと、当時は自分たちのインフラ設計が未だに形になっていなかったため、前座としてセルフホストランナーのインフラ設計において難しい点や各社のアプローチの違いなどを解説する発表をさせて頂きました。

他の登壇者の方とはその後もTwitterで繋がったり、カンファレンスで再会したり、新しい同僚となったりと交流が続いているので、このCI/CD Test Nightは開催して本当に良かったなと思っています。

GitHub dockyardコミュニティ竣工イベント！

転職（後述）直後にGitHub Actionsについて登壇の依頼を頂いたので、2023年のGitHub Actionsの半年分のアップデートのサマリーの内容で登壇させて頂きました。ちょうど高スペックなLarger RunnerがGAしたタイミングだったこともあり、そのあたりを熱く語らせてもらいました。アーカイブ動画を見ていただくと、このあたりからギアが切り替わった様子をお楽しみ頂けると思います。

今までは勉強会やカンファレンスは全て自分から応募して発表の機会を頂く形だったので、社外の方から依頼されるのは初めての経験で嬉しかったです。

GitHub Universe後の11月に予定されていた#2が延期となってしまったことは残念でしたが、また次回の開催を楽しみにしています。

転職

DeNAは5月末で最終出社となり、6月はまるまる有給を消化して7月からサイボウズ株式会社に転職して生産性開発チームに入りました。生産性開発チームはサイボウズのエンジニアの生産性を上げるための色々なツールや基盤の開発・運用などを行っているのですが、自分はその中でも特にGitHub Actionsのセルフホストランナー基盤をメインにしています。会社は変わりましたが、今までの経験をフルに活かせる仕事内容なので新しい環境に馴染むのは早かったと思います。

サイボウズのセルフホストランナーは既に多くのチームが利用していることからインフラの規模がかなり大きく、おそらくはGitHubやAWSのAPIリミットに起因する謎エラーや、AWSの費用面など大規模に運用されているからこその問題が発生しており、毎日飽きることはないです。

2ヶ月ほどで生産性向上チーム仕事に完全に慣れたので、チーム外の方にも顔を覚えてもらうために社内SNSでGitHub Actionsについて困っている方たちを見つけては会話スレッドに横から失礼して勝手に対応策を提案したり、GitHubの公式ドキュメントを案内したりを始めました。やはり業務のプロジェクトというものは巨大かつ複雑な事情を抱えていることが多いのできれいに解決できない場合も多かったのですが、この活動のおかげか12月頃には社内のオンライン・オフラインの両方で自分の顔を覚えていてくれた方がいらっしゃいました。ありがたいことです。

あとは自分のライフワークとして毎朝の朝刊代わりにGitHubのアップデートが全て集まる github.blog/changelog を読んでいるのですが、特に面白いアップデートはProductivity Weeklyでも紹介しています。Productivity Weeklyは転職前からずっとファンだったので、その執筆に自分も携わることができてこれも感慨深かったです。

OSSへの寄付

今年は3つの出来事から自分の中で寄付についての考え方が変わった年でもありました。

１つ目はポイントによる寄付です。日々使っているクレジットカードやSuicaのJREポイントは今まで残高のチャージやギフト券に引き換えていたのですが、交換先のリストを見ていくと慈善団体への寄付も行えることに気が付きました。その中には自分が毎年楽しみにしている RTA in Japan で知った国境なき医師団の名前もありました。自分はポイ活に力を入れていないのでポイントはあぶく銭として考えており、ポイント分であれば気軽に寄付してもいいかなと思うようになりました。

２つ目は地元のカフェへの寄付です。最近は毎朝コーヒー豆を手挽きしてドリップするぐらいにはコーヒーが好きになりました。地元にとても美味しいコーヒーを出してくれるカフェができたので実家に帰る際は立ち寄っていたのですが、そのカフェが不幸な事故で大変困った状況になってしまいクラウドファンディングを募集していることを知りました。完全なる寄付ではなく多少の見返りはあったものの、今までの人生の中で1つの団体に対しての最高額の寄付をしたと思います。

3つ目は転職先のサイボウズがOSSへ寄付していることです。最近ではOSSのサプライチェーン問題がたびたび話題になっており、これには色々な要因があるもののどこの国であろうとOSS開発している方にも生活がある以上は金銭的な問題が一定存在してそうです。サイボウズでは社内で利用しているOSSに会社の収益の一部を寄付する取り組みを行っています。利用しているOSSの開発が安定することは回り回って自社開発におけるリスクを減らすことに繋がるので、内部の社員から見てもとてもありがたいことです。

これらの経験から、まずクレカなどのポイント分は全て寄付してもいいなと思いました。さらに、どうせ寄付するなら自分が深く関わっていて社会的に意義がある領域、OSSそのものもしくはコミッターに寄付をしたいと思うようになりました。慈善団体として有名な赤十字や国境なき医師団などは自分以外にも大勢の方が寄付をしていると思われる一方、OSSへの寄付はまだエンジニアの一部にしか認知されていないと思います。どうせ寄付をするなら自分が寄付することに意義を見いだせる団体に対して寄付をしたいです。

OSSへの寄付やGitHub Sponsorについてはazuさんの記事が詳しいです。自分はGitHub SponsorとOpenCollectiveで自分がよく使うjs/ts関連を中心に寄付しました。

ただ、これらにクレカなどのポイントから直接寄付する方法は残念ながら存在しないため、ポイントは以前同様に商品券などとして受け取った後にそれと同額を寄付するという形にしています。回りくどくはありますが、ポイントと同額分を寄付するという当初の目的を果たせました。

現在のOSSと金銭の問題を状況を考えると、単発の寄付も良いですがおそらくそれ以上に継続的な寄付の方が望まれているとも思いました。来年はazuさんの記事にもあるように自分の所得の1%を寄付のためのバジェットとして最初から確保しておき、大部分は継続型の寄付に回すことを予定しています。

もしこのエントリを読んでOSSへの寄付やGitHub Sponsorについて興味が出た方は、ぜひazuさんの記事も読んでみてください。

OSS

最後に今年のOSSの活動を振り返っておきます。自分の場合は著名なOSSにissue報告したりpull-reqを送るよりは、大半が自分自身欲しいものをOSSとして実装している時間になります。

2023_github

転職前の休暇期間だった6月から芝がだいぶ増えました。転職後は業務のコードがGHECのリポジトリで管理されているのでそのコミット分が上乗せされているというのが大きな要因ではありますが、転職直後ゆえのモチベの高さからプライベートの開発も以前よりアクティブになったと思います。

今年にリリースしたリポジトリ

DeNA/setup-job-workspace-action

実は初コミットは2022年ですが、DeNA TechConの登壇に合わせて2023/01にDeNAのOrganizationに移管しました。このactionはセルフホストランナーを利用している場合に1リポジトリ1ワークスペース（ディレクトリ）の制約をちょっとしたhackで突破するものです。ゲーム開発における大規模リポジトリのCIをJenkinsからGitHub Actionsに移行する際の課題を解決するために作成しました。

詳しくはTechConの発表前にブログを書いていたのでこちらを御覧ください

Kesin11/github_actions_otel_trace

GitHub Actionsのジョブにかかっている時間のステップ毎の内訳をいい感じに可視化するため、APIから取得したジョブのデータをOpenTelemetryのTracing形式に変換するTypeScript製のサーバーです。多分可能だろうと考えていたアイディアが実際に可能であることを実証するPoC的なレベルの実装のため、npmにはpublishしてなくてGitHub Packagesに一応publishしてるところ止まりです。

一応現在でもライブラリのアップデートなどは続けており、自分のCloud Run上で動かしていてCloud Traceにデータを送っています。来年は仕事でも本格的にObservabilityをキャッチアップすることになりそうなので、そうなったら開発を再開するかもしれません。

Kesin11/junit2json-rs

RustとWASMの練習として、以前にTypeScriptで作成した https://github.com/Kesin11/ts-junit2json をRustで再実装 + WASI対応をしたものです。

再実装なので簡単かと思いきや、Rustでのserialize/deserializeの定番であるserdeに苦戦したり、実装していく中で実はts-junit2jsonのXML → JSON変換ロジックの一部に一貫性が無い（言ってしまえばバグってる）ことが判明してしまったりと色々とありました。

CI/CDを主戦場としている身としていわゆるsingle executableなツールに憧れを抱きつつもgolangに馴染めなかったため、そのあたりもRustに期待していました。ですが、実際にやってみたらクロスコンパイルがgolangほど簡単ではなかったり、Linuxに限定しても実行環境のglibcのバージョンに注意が必要だったりと思ったほど簡単ではないということが分かり、Rustによるsingle executableに対する幻想は打ち砕かれてしまいました。

作りきった後に新機能の追加などは全然していませんが、CIとRenovateはバッチリ整えたので依存ライブラリのバージョンアップはほぼ全自動で続いています。

Kesin11/actions-timeline

GitHub Actionsのジョブのステップごとの内訳をサマリー画面に描画してくれるActionです。github_actions_otel_traceのライト版という感じで、OpenTelemetryへ送る代わりにトレーシングの可視化をMarmeidのガントチャートで無理やり表現しています。

転職後のモチベが高い時期に以前からやってみたいと思っていたアイディアを一気に形にしました。前前作のCIAnalyzer、前作のgithub_actions_otel_traceに対してユーザーからの使いやすさに特化したツールを目指して作成しており、どう違うのかをzennに書きました。

やはりGitHub Actionsだけで完結する使い勝手の良さがウケたのか、リポジトリのスター数は自分が今まで作ってきたOSSの中でトップとなり、zennの記事も近年稀に見るクリーンヒットとなりました。

Kesin11/gh-setup-release-drafter

完全に自分用のgh extensionです。新しいOSSを作るたびにrelease-drafterのセットアップとissueのラベルをデフォルトから変更するのが面倒になってきたので自動化して gh setup-release-drafter と実行するだけで完了するようにしました。

Kesin11/deno-action-template

actions-timelineはDenoでjsのActionsを作成する実験も兼ねていたのですが、上手くいったのでDenoでjsのActionsを作成する部分だけを切り出してテンプレートリポジトリにしました。DenoはデフォルトでTypeScriptを扱えることや lint や fmt が内蔵されていることでNode.jsよりも手軽にプロジェクトを始められる点が非常に気に入っており、Actionsのような小規模なプロジェクトには特に向いていると思っています。

テンプレートの構成について詳しくはzennに書いたので興味がある方は見てみてください。

それ以外

Kesin11/CIAnalyzer
Kesin11/ts-junit2json

どちらも今年は新規実装をほぼしていないのですが、CIとRenovateは完備しているので依存ライブラリはほぼ全自動でアップデートされています。リリース作業もrelease-drafterによってGitHubからリリースジョブを開始するワンポチで済むようにしているためほぼ工数ゼロです。1-2ヶ月ごとに気が向いたときにパッチバージョンをリリースするか、Dependabotが脆弱性を報告してくれたときに臨時セキュリアップデートとしてリリースをするようにしています。

今年新たに作成したOSSも基本的に同じセットを完備しているため、依存ライブラリのアップデートとリリース作業はほぼ工数ゼロです。よっぽどアップデート対応の面倒なBREAKING CHANGESが来てかつ自分が興味を失っていない限りはそのOSSのメンテは続けるでしょう。

登壇

DeNA TechCon 2023

転職

OSSへの寄付

OSS

今年にリリースしたリポジトリ

それ以外

Discussion