要約

  • Codespacesの保存期間は作成時に割り当てられる。組織が後からポリシーを変更・削除しても、既存の環境の期限は変わらない。
  • 停止中もストレージ使用量は積み上がる。自動削除は未プッシュの変更を待たないため、環境を減らす作業には成果物の持ち出し確認が必要になる。

経費削減の会議では、数字を小さくした画面がよく働く。保存期間を三十日から七日に変更した、と示せば、古い開発環境も早く片付くように見える。

GitHub Codespacesでは、この仮の設定変更を受け取るのは新しく作る環境だ。組織の保存期間に関する公式文書によると、期限は作成時に決まり、その後にポリシーを書き換えても既存の環境には反映されない。ポリシーを削除しても、割り当て済みの期限は残る。

節約令の掲示板は新しくなった。古参の作業机は、元の条件で場所を借り続ける。この仕組みを知らずに削減効果を約束すると、設定の変更より後の説明が忙しくなる。

電源を切っても、机は返していない

Codespacesの便利さは、クラウド上の開発環境に戻って作業を続けられることにある。停止前に保存したファイルが残り、作業場を丸ごと作り直す手間を省ける。

ライフサイクルの説明では、実行中の計算使用量と、停止後にも続くストレージ使用量が分けられている。後者が止まるのは削除時だ。削除しても、その月にすでに積み上がった使用量は消えない。ブラウザーのタブを閉じるだけでは、遠隔の環境自体も停止しない。

このため、費用管理では画面を閉じた人、環境を停止した人、環境を削除した人を同じ成果として数えられない。それぞれの操作の後に、残っているものが違う。

適用対象も支払いで決まる。組織のポリシーが対象とするのは、組織が費用を負担する環境だ。組織所有のリポジトリから作ったものでも、個人が支払う環境はそれだけで対象にはならない。作成時には、組織、リポジトリ、個人の設定など、適用される期限のうち最も短いものが使われる。

管理者に必要なのは、現在のポリシーだけでなく、環境ごとの支払主体と割り当て済みの期限である。公開文書には個別企業の環境一覧、期限、未プッシュの作業、請求額がなく、実際の削減額や損失額はそれらの確認が必要だ。

保存ボタンには引っ越し機能がない

ファイルを保存したという報告は、作業がリモートリポジトリに届いたという報告とは別の情報だ。保存先は仮想マシンであり、変更をコミットしてプッシュする工程がまだ残り得る。

GitHubの自動削除の説明は、この残り作業に容赦しない。プッシュされていない変更があっても、削除は実行される。人間にとって大事な書きかけを、期限管理が自動で見分けてくれるわけではない。

既定では、停止して使用されない状態が三十日続くと削除される。再接続すると期間はリセットされ、停止後に数え直す。個人設定の範囲は零日から三十日で、零日なら停止時に削除される。アイドル時間の超過による停止も含まれる。

つまり、古い環境ほど先に消えるとは限らない。時々使われる旧環境が残る一方、新しく短い期限を与えられた環境が先に消える場合がある。一定の個人用環境には手動削除まで保持する選択肢もあるが、その間はストレージを使い続ける。組織の保存ポリシーが適用される組織所有の環境では、この保持を選べない。

短い期限を採用するとき、企業は容量だけでなく、「明日また同じ机に戻る」という便利さにも値段を付けている。

出口の幅を先に測る

GitHubには、環境を起動せずに変更をブランチへエクスポートする機能がある。支出制限などで環境を再開できないときには助けになる。

ただし対象は、現在チェックアウトされているブランチだ。他のブランチまでまとめて持ち出す機能ではなく、100 MiBを超えるファイルは該当するプッシュとエクスポートを妨げる。完了表示を見た後にも、移動先に必要な変更があるか、別のブランチに固有の作業が残っていないかを確かめる仕事がある。

その確認ができて初めて、環境を残す価値と、削除して解放する資源を比較できる。コードの持ち出しと、開発環境全体を再利用可能な状態で保つことは、異なる便益だからだ。

新しい期限は今後の増え方を変える。すでに借りている机の返却は、個別の判断と作業で進める。その二つを別々に数えれば、設定変更だけが先に成功して費用が置いていかれる事態を説明できる。