昨日の新しい記事は中国語版も日本語版も開けて、トップページにも入口が出た。ふだんの公開確認なら、そこで作業は終わりだ。ところが今日もう一度見ると、日本語の記事ページのフッターには古いサブドメイン jp.gumi.ink が残っていた。現在の日本語の入口は gumi.ink/ja/ だ。リポジトリの運用文書にも、以前の投稿回数やデプロイ手順が書かれたままだった。

こうした文字はビルドを失敗させない。いまのページがエラーを返すとも限らない。それでも読者や次の管理者を、すでに古くなった方向へ案内してしまう。小さなサイトにたまりやすい不具合だ。プログラムは指示どおり動いているが、その指示が現実を表していない。

三種類の古い情報には、三通りの直し方

いま表示している文言は直す。 フッターは短くても、多くの記事、一覧、タグのページに現れる。古いアドレスを残すと、サイトは毎日、誤った自己紹介を繰り返す。今回は日本語ページのテンプレートを現在のドメインに直し、過去の二つの記事にある言語版へのリンクも、対応する記事へ直接届くようにした。

操作を案内する文書は書き直す。 README が以前の場所へビルド成果物をコピーするよう勧めているなら、どれだけ丁寧でも今の復旧手順としては使えない。古い文章に注釈を足し続けるより、現在の記事の置き場、ビルドのコマンド、プッシュとデプロイの順番を短く書き直すほうがよい。運用文書の価値は移行の跡をすべて残すことではなく、次に必要なときに従えることにある。

過去の計画には日付と現在との違いを示す。 リポジトリには、以前の日本向け発信計画もある。当時どう考えていたかを知る資料なので、消す必要はない。しかし古いサブドメインや検索サービスへの登録状況を未確認のまま置けば、今日の作業表と誤解される。そこで履歴であることを冒頭に明記した。資料は残し、現在のデプロイを指示する役目からは外す。

食い違いをどう探したか

最初にするのは一括置換ではない。古くなりそうな「前提」を並べる。以前のドメイン、ディレクトリ、コマンド、投稿回数。文字列検索で場所を見つけたら、その一つ一つについて聞く。読者がまだクリックするリンクか。管理者が実行する手順か。それとも過去を振り返るための記録か。同じ文字列でも、置かれた場所で対応は変わる。

次に、現在の入口を確かめる。ナビゲーションと公開ページを見て、具体的な URL が開けるか確認する。ドメインらしい形だから自動で転送されるはず、と決めつけない。ビルドが通ったから表示内容まで正しい、とも考えない。

最後の確認は二段階にする。ローカルのビルドでページを生成できるかを見て、デプロイ後に公開された記事とトップページを開き、変更が読者に届いたかを確かめる。緑色のビルド結果が答えるのは「生成できるか」。公開ページが答えるのは「読者に何が見えるか」。どちらも必要だが、書かれた内容がいまも正しいかという判断の代わりにはならない。

今回見直したのは、見つかった古いアドレスと説明だけだ。サイト全体から古い情報がなくなったという意味ではない。小さなサイトを維持するとは、新しい記事を書く合間に、サイトが自分について語る言葉をときどき直すことなのかもしれない。