やりたいこと 単体テストだけではなくDB接続を含んだ結合テストの環境をGitLab CIに組み込みたい 結合環境なのでコンテナ仮想化ではなく完全仮想化または準仮想化環境で行いたい（根拠が薄い） 環境の手動セットアップはダサい やること 結合テスト環境用のVagrant導入済みマシンを構築 Vagrantfileに環境をコード化 GitLab Pipeline にvagrant upを組み込み、テストが通ることを確認する 用意したこと openSUSE Tumbleweed sudo zypper in virtualbox vagrant sudo usermod -aG vboxusers xxx sudo usermod -aG libvirt xxx 必要なパッケージ類 postgres (エンジン、クライアント) rust sdk、ランタイム プロビジョン用コマンド これが後述のVagrantfileで指定するtest_integration.

設計・実装を進めていると「ここはこうしたほうが後々便利かも」と思うことはよくある。

今回は現在開発しているシステムのドメインモデルのうち、一つの概念が複数の型とふるまいをとるクラスを設計していた。インターフェイスや継承などでよく実装されるパターンで、ドメインの表現的にも明確に分類すべきものだった。そこで自分は教科書通り継承を使った実装をした。

DDD的にも教科書通りであり、ある程度正しいコードだと思っていた。そんなつもりで残したコードをレビューで「継承はなくし、単一のクラスで表現したほうが良いのではないか」という指摘をもらった。

どういうことだろうと思い、自分の胸中をそのまま言葉にしてみた。

「自分は拡張性を見込める場合は実装に落とし込んでしまいがちだが、今回のように、やめておいたほうがいいのではないかという指摘を受けることがままある。教科書的にも正しく、後々便利なはずなのに、なぜなのか？」

TL;DR

RancherOS の役目は BurmillaOS に引き継がれたようです。

背景

もともと Longhorn を試すためにある程度まともな k8s クラスターを構築しようとしていたのが事の発端。最初は openSUSE を Node ホストマシンとして頑張ろうとしていたがうまくいかず、 RancherOS なら間違いないやろ！と試したところ…

Vue 3 で導入された公式ツール Vite で作ったプロジェクトを簡単にPWA化できる vite-plugin-pwa というものがあり、とても便利。

ただし manifest にちょっと手を加えることで動きます（5/23時点）。