エコシステムにビルドツールがたくさんあるのは悪いことではない - Kengo's blog
JavaやNodeJSには多数のビルドツールがあります。ものによってはビルドツールではなくタスクランナーとかワークフローとか名前が付いてるかもしれませんが些細なことです、ここでは以下のようなツールのことをまとめてビルドツールと呼びます： Apache Ant Apache Maven Gradle Bazel yarn pnpm 一方で言語公式のビルドツールを用意している言語もあります。これによってプロジェクトごとに異なる技術を学ぶ必要性が減りますし、一貫性のある開発体験を得ることができます。javac javadoc のような単純なコマンドしか提供しないJavaとは異なる方針を言語として持っていることは明らかでしょう。 では言語のエコシステムにビルドツールがたくさんあることはモダンではなく不便なのでしょうか？そんなことはないだろうというのが自分の考えです。もちろん欠点がないとは言いません
Gradle用のGitHub Actions勘どころ（2023年夏） - Kengo's blog
前回書いたのがもう4年前でビビったのと、最近いろいろ進展があったのでまとめてみます。 actions/setup-java の依存キャッシュを使わない これ自分が実装した機能なのでホント申し訳ないんですけど、今なら gradle/gradle-build-action を使ったほうが良いです。 利点は公式が説明しているので読んどいてください。 github.com spotlessApplyして差分が出たらSuggest Changeする reviewdogが action-suggester という素敵なアクションを提供しています。GitHub Actionsでフォーマッタを実行して差分ができた状態でこのアクションを実行すると、GitHub Pull RequestのSuggest Change機能を使ってフォーマットを提案してくれます。 github.com フォーマット適用箇所が多い
医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ
こんにちは、ヘンリーの SRE の戸田と Wildcard Engineer の岩永です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 前編の Henry のバックエンドをモノレポ化した戦略やプロセスに続いて、後編のこちらの記事ではモノレポ化の技術的手法を解説します。 dev.henry.jp 実際のモノレポ化の流れに沿って、ポイントを3点説明します。 2つの git リポジトリのマージ アプリケーション・ワークフローのモノレポ対応 モノレポへの切り替え当日に向けた手順書の作成 1. 2つの git リポジトリのマージ 今回のモノレポ化においては、もともと存在していた henry-general-api と henry-receipt-api という2つのマイクロサービスのリポジトリを、1つのリポジトリにマージし、それぞれのマイクロサービスがサブディレ
2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
Gradleのjvm-test-suiteプラグインがテスト周りの定型コードを排除するのに便利そう - Kengo's blog
Gradle v7.5の時点ではまだIncubating段階の機能ではあるのですが、Gradleの新しいプラグイン jvm-test-suite がいい感じなので紹介します。 docs.gradle.org 解きたい課題：サブモジュールや統合テストが出てくるととたんに面倒になるビルドスクリプト Gradleは設定をDSLで記述するので基本的には何でもありなのですが、やはり定形コード（boilerplate）は少ないほうがビルドスクリプトの見通しも良くなります。もちろんGradleは「設定より規約（Convention over Configuration）」の考えを持っているため、ある程度は空気を読んでSourceSetやTaskを自動的に生成してくれます。しかしテスト周りにおいてはこうした自動生成は十分ではなく、次に挙げるような課題がありました： サブプロジェクト全てに対して実行したタス
Gradle/Kotlinで開発する私的ベストプラクティス2022 - Kengo's blog
こちらのエントリーが素敵だなと思ったので、最近書いてるKotlinプロジェクトのベストプラクティスをまとめてみます。一部はJavaプロジェクトにおいても利用できるはずです。 zenn.dev 基本方針 参加障壁を下げる。OSSプロジェクトでもプロプライエタリ・ソフトウェアプロジェクトでも、新しい開発者が参加するコストを下げることには大きな意義がある。 環境差異を吸収する。javaにPATHが通ってさえいればOSに関係なくビルドが通るようにする。 プロジェクト固有ルールを作らない。Conventional CommitsやKeep a changelogなど、ひろく世に使われているルールを採用する。 Gradleを設定する Spotlessを使う コードのフォーマットはformatterに任せて人間は細かいことを考えない、というのが不特定多数が参加するソフトウェアプロジェクトのあるべき姿だと
Gradleプラグインのメジャーアップデートにおいて、古いGradleへのサポートをいかにして切るか - Kengo's blog
spotbugs-gradle-plugin v5をリリースしました。beta1のリリースから約3ヶ月間かかっています。 github.com Gradleプラグイン開発はややマイナーな取り組みだと思うので、Gradleプラグイン開発のメジャーアップデートがどういうものだったのかをちょっと紹介します。 なぜ後方互換を壊す必要があったのか spotbugsプラグイン固有の理由はもちろんあります。デフォルトの設定がうまくなかった、リソースリークの解消にはデフォルトの動作モードを変える必要があった、などです。これに加えてGradleプラグインならではの理由があります。 古いGradleへのサポートを切るため Gradle 7をサポートするには、Gradle 7で削除されたGradle APIへの依存を切る必要があります。この場合、移行先Gradle APIが存在するGradleのバージョンが最低
GradleのbuildSrcとどう付き合うべきか - Kengo's blog
Gradleで複数サブプロジェクトをもつプロジェクトを作成する - kdnakt blog を見て、buildSrcディレクトリ周りで混乱した記憶が蘇ってきました。 gradle initでサブプロジェクトを持つプロジェクトを作るとbuildSrcを使ったプロジェクトが生成されるらしい。知らんかった。buildSrcまわりはドキュメントわかりにくいので、実コード読めるのは助かる。 Gradleで複数サブプロジェクトをもつプロジェクトを作成するhttps://t.co/XVozfs9Zqu— 書けない猫はただの猫さ (@Kengo_TODA) July 7, 2021 書く場所がbuildSrcとbuild.gradleの2つに増えるので、何をどこに書けばいいのかよくわかんないんだよね。Gradleはこういう悩みが多い、最近ではbaseプラグインに書くべき処理とそうでないconvention
「ドメイン駆動設計入門」付録のGradle向け解釈 - Kengo's blog
ITエンジニア本大賞2021で紹介されていた「ドメイン駆動設計入門」（以下、本書と呼ぶ）が、DDDを学ぶ上でわかりやすかったです。一応他のDDD本も数冊読んではいたのですが、どうしてもユビキタス言語や境界づけられたコンテキストなど”場合による”ものが頻出してしまい、結局どうすればいいんだ……となって手が動きにくかったのです。よくわからない概念の上にさらにわからない概念を積み重ねるので、どんどん混乱する感覚がありました。 定期的にDDD勉強しなきゃ……ってなるんだけどやらない（やれ）— 正月と正月のあいだ (@Kengo_TODA) September 5, 2019 反面、本書では副題の通りボトムアップ形式を採っているため、実際にどう手を動かせば良いのか細かく確認できました。また不明点を最小化しながら進むだけでなく、その概念を導入することでどんな問題が解決されるのかが実例をもって明示されて
Javaライブラリを配布する際のログ周りにおける配慮と実践 2020 - Kengo's blog
この記事は、2013年に書いた記事を現状に合わせてアップデートするものです。結論から言うと、当時から id:miyakawa_taku さんがおっしゃっていた「APIは依存に含めて良い」を支持するものです。あるいは無難にバージョン 1.7.30 を使っておきましょう。 blog.kengo-toda.jp slf4j-apiに1.7, 1.8, 2.0の3バージョンが生まれた 現在slf4j-apiには3つのバージョンが存在します。現在のSLF4Jエコシステムを考える上では、これらの違いを抑える必要があります： 1.7.x Java 1.5から利用できるバージョンです。安定版にこだわるなら未だこのバージョンを使う必要があります。 1.8.x JPMS（a.k.a. jigsaw）を採用しServiceLoaderを使ってBindingを呼び出すようになったバージョンです。Java 1.6が
Javaプロジェクトにおけるリリース周りの手法あれこれ - Kengo's blog
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
Gradle用のGitHub Actions勘どころ - Kengo's blog
GitHub Actions のベータ版が個人リポジトリの方に来ているので、色々と試しています。使っているテンプレートプロジェクトと実アプリケーションプロジェクトから、いくつか事例を紹介します。 なお各種単語の定義が公式サイトにあるので、いちど目を通すことをおすすめします。 テストレポートをworkflow runに添付する upload-artifact actionを使うことで、テストレポートをworkflow runに対して添付することができます。 - name: Build with Gradle run: ./gradlew build - name: Upload Test Report uses: actions/upload-artifact@v1 if: always() with: name: test results path: build/test-results/
Kotlin DSL を考慮した Gradle Plugin を記述するために必要だったこと - おでーぶでおでーぶ
とある Gradle Plugin を 2.0.0 に移行する際、v1 から Kotlin DSL を使っていた人の環境でちょっと問題が発生したというツイートを見たので、Kotlin DSL がどうやって DSL Marker なしに lambda で書けるようにしてるのかちょっと調べてみた。ここで記述している問題は 2.0.1 では修正されていて、また Kotlin DSL での移行ステップも README に追記しておきました。 github.com TL;DR 外に見せる境界で def を使うのは避けておいた方が無難 Kotlin DSL は拡張関数で delegate してて、見るべきメソッドが違うかもしれないから気をつけよう Kotlin と Gradle の言語仕様の違いに気をつけよう kotlin-dsl を apply して開発しないと Groovy と Kotlin DS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gradle用のGitHub Actions勘どころ（2024年夏） - Kengo's blog
spotbugs-gradle-plugin v6の安定版をリリースしました - Kengo's blog
spotbugs-gradle-plugin v6のリリース候補版（RC版）をお試しください - Kengo's blog
WIP: Gradleの機能でどこまでビルド性能が改善するのか - Kengo's blog
Gradleのbaseプラグインに書くべきでないconventionとは何か - Kengo's blog
技術書「JavaのビルドとCIのキホン」を公開しました - Kengo's blog
Guide to build Gradle Plugin for efficient development
