社内SEの徒然なる日記

ソースに修正履歴を残したくないのだが Part2 ソフト変更

■ サーバリプレース

そんな感じ(ソースに修正履歴を残したくないのだが Part1 状況)で、バージョン管理システムが崩壊の危機を迎えていました。

残念ながら、私はの○太ではないので、ド○えもんも助けてくれないので、自力で何とかしないといけません。
とはいえ、ここまで来ると、適当なパソコンとかに環境を移行するしか策が思いつきません(予算があれば別ですが)。

ちなみに、こんな状態まで放置したのは、移行作業自体にも手間とリスクがあったからで、例えば、バージョン管理システムから本番環境へのリリース手順の修正(ドキュメントとツール)とか、私にバージョン管理システムの移行ノウハウがないとか、そもそもインストールメディアが見当たらないので発掘しないといけないとかです。

覚悟を決め始めたのですが、考えてみると基幹システムのサーバリプレースが近かったので、そこでサーバを新設して移行してやることにしました。

ここまでの経緯で、大声を上げて騒ぎ続けていたので、今回は誰も意義を唱えませんでした。
...まぁ、頭抱えながら「うぐぉぉぉぉ!助けてド○えもん!」とか叫んでるのを見られたので、(いろんな意味で)恐ろしくて、誰も関わりたくなかったのかも知れませんけどね。

■ ソフトが無い?

本音では専用サーバが欲しかったのですが、別の用途で導入するサーバに相乗りさせることにしました。管理者としては、サーバ台数も増やしたくないですしね。

当然OSのバージョンとかも変わってくるので、バージョン管理システムの最新版を手に入れようとしたのですが、衝撃の生産中止!

...そう来たか。

しかし、無い物は仕方ありません。
しょうがないので、オープンソースのバージョン管理システムを用意して使う事にしました。

移行は成功、しかし...

詳細は省きますが、最終的には新しいバージョン管理システムへの移行は成功。
それに合わせて、リリース用のツールとかも最適化して、これまでよりもずっと使いやすく、管理もしやすい環境が手に入りました。

しかし、失ったものもあります。

移行できたのは、資産の最新の状態だけで、修正履歴の移行までは出来ず、それまでの修正履歴の全てを失ってしまいました。
まぁ、ソフトが違う上に、旧システムの方は触れば止まるって状態だったので、いずれにしても無理だったでしょうけどね。

■ 履歴をどう残す

こういう経緯があったため、システム上には修正履歴が残っていないのですが、ソース上にはコメントとして修正履歴が残っています。

滅多に使わないのですが、特定の障害発生時に頼りになるのは、今となってはこいつだけです。

もちろん、他にも方法はあったとは思います。
例えば、仮想OS上で旧バージョン管理システムを動作させて、そこにリポジトリを移行するとか。

しかし、そのためのコストとか、環境を誰が作るのか(というか、作れるのか)ってことを考えていくと、私の技術力では難しいです。

私の本業は、あくまでも社内SEなんですからね。

次回は、ここまでの経緯を踏まえた上での、ソース上での履歴の残し方について書いていきます。

前回:ソースに修正履歴を残したくないのだが Part1 状況
次回:ソースに修正履歴を残したくないのだが Part3 修正履歴
投稿記事の一覧:目次

--- blog end --- スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する