🛞

compose watchがフロントエンド開発に便利そう、他に改善話など｜Productivity Weekly(2024-02-21号)

Futa Hirakoba

2024/03/06に公開

ProductivityWeekly

生産性向上

idea

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

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

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

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

news 📺

Announcing end-of-support for AWS SDK for Go (v1) effective July 31, 2025 | AWS Developer Tools Blog

AWS SDK for Go の v1 が 2024 年 7 月 31 日にからメンテナンスモードに入り、一年後の 2025 年 7 月 31 日にサポートが終了することが発表されました。

メンテナンスモードでは、重大なバグ修正とセキュリティ対応のみが行われるようになり、サポート終了後は全くアップデートされなくなります。

移行先としては、SDK v2 があります。移行ガイドもちゃんと用意されています。

Migrating to the AWS SDK for Go V2 | AWS SDK for Go V2

サポート終了まではまだ期間がありますが、移行は決して簡単ではないかもしれないので、早めに v2 へ移行していきましょう。

本項の執筆者: @korosuke613

Scaling Docker Compose Up | Docker

日本語版記事

Docker Compose v2.22 から利用可能になった docker compose watch の紹介とバックエンド、フロントエンド開発における具体例が Docker の公式ブログから紹介されています。

compose.yml に watch を追加することで、ファイルの変更を検知して自動でコンテナの再ビルド（rebuild）やコンテナへのファイル同期（sync）が可能になりました。記事中ではフロントエンドは package.json が更新されたときには rebuild で RUN npm install をやり直し、 src/ 次のファイルが更新されたときは sync でファイルの同期だけを行っていました。

このように rebuild と sync を使い分ける理由は、パッケージの再インストールが必要になった場合はコンテナ内で行うことが望ましいので rebuild でパッケージの再インストールを含めコンテナを作り直し、src/ ファイルの更新であれば sync でコンテナ内に同期だけを行うことで、フロントエンド開発において主流となっている Hot Module Reload（HMR）による開発体験を損なわないようにするためだそうです。

従来では開発環境に Docker Compose を利用する際にはローカルでのファイル修正をコンテナ側に反映させるためにバインドマウントを利用することが一般的でしたが、watch コマンドはマウントではなく変更があったファイルをコンテナ内にコピーする手法のようです。Docker Composeのドキュメントにはこのあたりの違いの説明も書かれていたので、気になる方はそちらも参照してみてください。

ちなみに、Docker Compose v2.22.0は 2023/09/22 リリースと比較的新しいため、コマンドが使えなかった場合は手元で docker compose version を実行してバージョンを確認してみましょう。

本項の執筆者: @Kesin11

AWS Control Tower introduces APIs to register Organizational Units

AWS の Control Tower で OU まわりの API のエンドポイントが増えました。
今まで AWS コンソールからしかできなかった OU のベースライン有効化などが API 経由で可能となり、IaC で管理できる範囲が増えたと言えるでしょう。

Terraform の AWS プロバイダーである terraform-provider-aws v5.39.0 では、執筆時点でこの API に対応するリソースはまだ無いようです。
今後対応リソースが増えると管理がより楽になるかもしれません。

本項の執筆者: @defaultcf

aws_ecs_task_definition に CI/CD との競合を防ぐ track_latest 引数がリリースされました | DevelopersIO

Terraform で ECS を管理していて、別途 CI/CD などでタスク定義のリビジョンを追加、過去のリビジョンを削除するとします。その後、terraform apply を叩くと、リビジョン追加ではなく新しくタスク定義自体を作り直そうとする挙動がありました。
Terraform の state が古いものを参照していて、その実態が削除されると Terraform としては新たに作るしかなくなるからですね。

今回追加された track_latest を有効化することで、Terraform は常に最新のタスク定義を見るようになります。
これによりタスク定義を作り直すことなく、リビジョンを追加するだけになります。

...個人的にはタスク定義は常に Terraform で更新するようにしたいかな、と思っています。今回の track_latest が入ったところで、結局 Terraform 側の定義も更新する必要があるからです。
Renovate を上手く設定すると Terraform の定義中のイメージを更新できるので、CI/CD で terraform apply まで実行すればよりスムーズに運用できるんじゃないか、と思います。

本項の執筆者: @defaultcf

know-how 🎓

Renovateを使ってフロントエンドのバージョンアップを改善した話 | PR TIMES 開発者ブログ

Renovate でパッケージの自動アップデートを実現された事例で、Renovate の設定や運用方法をかなり詳細に紹介されています。

Renovate の設定ファイル（renovate.json）で設定できるオプションは豊富^[1]でかなり細かい挙動まで変更できるのですが、もはやどういうオプションが存在するのかを把握するのも難しいため、実践されている方の設定ファイルを見るだけでもきっと発見があると思います。それぞれのオプションについてコメントも書かれていて分かりやすいです。

個人的には記事中でも紹介されているこちらの偶数バージョンのみをアップデートするという allowedVersions の例が目からウロコでした。Node.js のようにバージョンの奇数偶数で安定版と開発版を分けているプロジェクトだと Renovate が採用したくないバージョンも自動で pull-request を作ってしまうので毎回手動でクローズする手間が面倒なこともあったのですが、この設定を参考にすればそのような場合も柔軟に対応できそうです。

{
    {
      "matchPackageNames": ["node"],
      "matchManagers": ["dockerfile"],
      // Node.jsは偶数バージョンのみアップデートする
      "allowedVersions": "/^[0-9]*[02468]([.-].*)?$/"
    },
}

本項の執筆者: @Kesin11

フロントエンドのGitHub Actions実行時間を削減するために取り組んだこと | PR TIMES 開発者ブログ

PR TIMES さんによる、フロントエンドの GitHub Actions 実行時間削減事例です。

今回は、実行時間は実行時間でも、billable time という GitHub Actions の課金単位を削減することが目的となっています。billable time は、純粋な実行時間と異なります（例えば、平均 45 秒で終わるジョブを平均 15 秒で終わるようにしても、課金時間はどちらも 1 分となる。）。

GitHub Actions の各種調査から始まり、調査結果を元にいくつかの対応を行なっています。

調査: billable time が長いワークフロー洗い出し、削減可能かどうかを調査、不要なワークフローを調査、など
対応: 並列実行ジョブを直列化、lint や test を差分のみに行う、キャッシュの無駄な保存を減らす、Renovate 見直し、concurrency 設定、など

その結果、全体として 25,000 分の billable time 削減ができたとのことです。なかなか劇的に効果が表れていてすごいです。

純粋な実行時間を減らしたければ、1 つのジョブを並列化する例をよく見ますが、今回は billable time 削減に着目しているため、むしろ直列化しています。ワークフロー/ジョブの純粋な実行時間を減らすことを主題に置いた記事は多いですが、billable time を削減することを主題にした記事はあまり見かけないので、面白かったです。

また、ジョブで時間がかかっている箇所の調査には、我が生産性向上チームの kesin11 さんが作った Kesin11/actions-timeline が使われています。便利ですので、Actions の実行時間に関する調査の際は使ってみてください。

GitHub Actionsのワークフローを可視化するactions-timelineを作った

本項の執筆者: @korosuke613

あとがき

今週号でした。春一番が吹き荒れてますね。吹き飛ばされそうです。

宣伝です。4/9（火）に大阪で Engineering Productivity Meetup #2 を開催します。
開発生産性を向上させる知見や技術をネタに開発者と交流する会です。
なんと LT 枠が埋まっていません（血涙）。応募待ってます。

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

脚注

利用可能な設定の一覧ページはかなりすごいことになっています。Configuration Options | Renovate Docs ↩︎

GitHubで編集を提案

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

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