システム開発■ サーバリプレース
そんな感じ（ソースに修正履歴を残したくないのだが Part1 状況）で、バージョン管理システムが崩壊の危機を迎えていました。
残念ながら、私はの○太ではないので、ド○えもんも助けてくれないので、自力で何とかしないといけません。
とはいえ、ここまで来ると、適当なパソコンとかに環境を移行するしか策が思いつきません（予算があれば別ですが）。
ちなみに、こんな状態まで放置したのは、移行作業自体にも手間とリスクがあったからで、例えば、バージョン管理システムから本番環境へのリリース手順の修正（ドキュメントとツール）とか、私にバージョン管理システムの移行ノウハウがないとか、そもそもインストールメディアが見当たらないので発掘しないといけないとかです。
覚悟を決め始めたのですが、考えてみると基幹システムのサーバリプレースが近かったので、そこでサーバを新設して移行してやることにしました。
ここまでの経緯で、大声を上げて騒ぎ続けていたので、今回は誰も意義を唱えませんでした。
．．．まぁ、頭抱えながら「うぐぉぉぉぉ！助けてド○えもん！」とか叫んでるのを見られたので、（いろんな意味で）恐ろしくて、誰も関わりたくなかったのかも知れませんけどね。
■ ソフトが無い？
本音では専用サーバが欲しかったのですが、別の用途で導入するサーバに相乗りさせることにしました。管理者としては、サーバ台数も増やしたくないですしね。
当然ＯＳのバージョンとかも変わってくるので、バージョン管理システムの最新版を手に入れようとしたのですが、衝撃の生産中止！
．．．そう来たか。
しかし、無い物は仕方ありません。
しょうがないので、オープンソースのバージョン管理システムを用意して使う事にしました。
移行は成功、しかし．．．
詳細は省きますが、最終的には新しいバージョン管理システムへの移行は成功。
それに合わせて、リリース用のツールとかも最適化して、これまでよりもずっと使いやすく、管理もしやすい環境が手に入りました。
しかし、失ったものもあります。
移行できたのは、資産の最新の状態だけで、修正履歴の移行までは出来ず、それまでの修正履歴の全てを失ってしまいました。
まぁ、ソフトが違う上に、旧システムの方は触れば止まるって状態だったので、いずれにしても無理だったでしょうけどね。
■ 履歴をどう残す
こういう経緯があったため、システム上には修正履歴が残っていないのですが、ソース上にはコメントとして修正履歴が残っています。
滅多に使わないのですが、特定の障害発生時に頼りになるのは、今となってはこいつだけです。
もちろん、他にも方法はあったとは思います。
例えば、仮想ＯＳ上で旧バージョン管理システムを動作させて、そこにリポジトリを移行するとか。
しかし、そのためのコストとか、環境を誰が作るのか（というか、作れるのか）ってことを考えていくと、私の技術力では難しいです。
私の本業は、あくまでも社内SEなんですからね。
次回は、ここまでの経緯を踏まえた上での、ソース上での履歴の残し方について書いていきます。
前回：ソースに修正履歴を残したくないのだが Part1 状況
次回：ソースに修正履歴を残したくないのだが Part3 修正履歴
投稿記事の一覧：目次
--- blog end ---
スポンサードリンク
0
0
