みんなは、どうやってOracleDataaccessを筆頭に、複数バージョンが入り乱れるDLLを管理してるのか教えてください。
マジで。
恐怖のエラー報告
事の発端は、先月、担当しているお客さんからのエラー報告でした。
経験ある人は多いんじゃないでしょうか・・・
お客さんからの、怒ったような、諦めたようなトーンの電話越しの声。
「先日更新してもらったところで、エラーになるんです」って。
ただ、確認するも、自分の開発環境ではどうにも再現しない・・・
再現方法の調査から始まるので、原因を探るには、非常に効率が悪くなります。
色々悩んだり、ググッたりしたけど、なかなかコレっていう解決法がヒットしない。
・・・。
ということで、別の環境を用意し、実行してみると、エラー再現。
すかさず、対処を行い、再度確認するも、エラー・・・
今までは、画面単独のDLLのみの更新で大丈夫だったけど、念のためということで、プロジェクト単位でのビルド時に一緒に作成される他のDLLも一緒に上書きしてみると、あっさりエラーが消えたわけです。
地獄に踏み出す、安易なDLL更新
ということで、ここから泥沼化してきます。
先のテストで問題なかったDLL群を客先環境で更新！
画面も動いてるみたいだし、一件落着！！
とは、行きません。
そうは問屋がおろしません・・・
20時過ぎにメール。
確認すると、画像が添付されており、エラーダイアログが・・・
そうです、更新したDLLを参照している別の画面とかと整合性が取れなくなって、エラーが別の複数の画面にまで波及していました。
もうここから死にたくなるぐらいにお客さんとやり取りして、怒られて、飽きられて・・・
再現しないエラーで、客先環境との差異を検討することに
ここまで来てやっと、客先環境と自分の開発環境との差異を探すことになりました。
といっても、全然情報がなくて、手探り・・・
OSの違い
まずは、OSの違いを疑いました。
が、可能性は低い・・・
確かに、WIndows Server なので、違うのですが、こちらもWin7 64bitなので、大きな影響は考えにくい。
というのも、先日リリースした別の画面は正常に稼動していたから。
OSの違いが影響するなら、多分、その時点でトラブルになってます・・・
OracleDataaccessが原因？
結論から言うと、これが原因でした。
でも、原因と断定するには、状況が微妙だったんですよね。
有識者からしたら、すぐに原因にたどり着けたのかもしれませんが、自分は有識者でもないし、連絡取れる人もいないし・・・な状況w
お客さんからもらったエラー報告には、複数のエラーが載せてあって、全部OracleDataaccessに関連していたなんて、その時点では思わないわけですよ・・・
色々あって、客先環境を使わせてもらって、1個ずつDLLの更新を検証した時に、特定のDLLでエラーが発生するようになるところまでは探りました。
でも、それはOracleDataaccessじゃなかった。
でも一番怪しいのは、Oracledataaccess.Dllだった
エラーが発生し始めた頃にOracleDataaccess.dllがらみのエラーは確かに発生してたんですよね。
でも、バージョンが複数混在できるとか、知らなかったんですよ(汗
今、3つぐらいのプロジェクトの開発を同時に担当している状況で、開発環境に必要なDLLとかが複数バージョン混在してるんですよね・・・
ということで、先輩からGACとか調べて来い！とアドバイスをもらったので、調べてみると、確かに違う・・・
自分とお客さんの環境では、バージョンが違ったんですよ。
末尾が。
GACなんて、正直良く分からないまま使ってるところもあったし、開発してて、それが致命傷になる状況も経験してなかったので、そこまで考えが回りませんでした。
バージョン変えたけど改善しない
ということで、開発環境のDLL参照先を全部変更したんですが、OracleDataaccess.dll関連のエラーは止まらないｗ
正確には、動く画面と動かない画面に分かれてました。
違いはこうです。
-
-
- 動く画面
-
OracleDataaccess.dllを参照していない
-
-
- 動かない画面
-
OracleDataaccess.dllを参照しているか、OracleDataaccess.dllを参照しているDLLを参照している
どうあれ、OracleDataaccess.dllが影響してたんですね。
とりあえず、復旧して地獄から出れた？
ということで、参照するDLLを全て客先環境のものに合わせ直したところ、正しく動作する状態のビルドになりましたとさ。
めでたしめでたし〜
じゃない。
今回のトラブルは、ただの地雷だった
遅かれ早かれ起こってました。
ただ、タイミングが今回だっただけです。
はい。
・・・・・・。
このプロジェクトを他の仕事優先な状態で、1ヶ月で引継ぎました。
正味、1ヶ月もありません。
前担当者とまともにやりとりしたのは、１週間もありません。
引継ぎ資料もロクにもらってません。
っていう、最初、正しくビルドできるまでに1週間かかったからね。
マジで。
前担当に聞いても、「問題ないはずですけどね〜」としか返ってこないw
そんな状態で、まともな引継ぎ出来てなかったし、OracleDataaccess.dllの重要性とか言われて無いし。
引き継いだ時点で、既に正しくないバージョンのOracleDataaccess.dllを使用してシステム開発を行ってたわけですよ。
引継ぎ後の数回のシステム更新では、たまたまOracleaccess.dllが参照されない画面だったから上手く行ってただけで、ずっと地雷原を歩いてたようなもんでした。
まとめ：引継ぎは、必要以上に時間かけてでもやったほうがいい
今回、まともな引継ぎが出来なかったのが、一番の問題だった。
引継ぎは、必要以上に刷り合わせをやったほうがいいし、やるべき。
引継ぎ後、開発まで担当するなら、環境整備は必須。
可能であれば、客先のテスト環境を用意してもらって、そこで確実に稼動するビルドを作成できるところまで確認するとなおよし。
- 十分な時間がない
- 引継ぎ資料も揃ってない
- 有識者が去る(いなくなる)
- 保守ではなく、開発も引き継ぐ
こんな状況で引継ぎをしちゃいけないって事が分かったので、教訓にしたい。
しかし、開発も継続しながらの状態なのに、保守として引継ぎって無理があるよなぁ・・・
っていうか、開発も継続するので、保守ですらない。
