読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

When Database Source Control Goes Bad 翻訳 Part4

システム開発

「The Catch」の後半部分です。記事全体からするとそろそろ折り返し地点?いやあ長いですね〜。


Anyhow, during the next deployment to QA, someone needs to remember that these specific changes need to get deployed. Since there is no defined strategy for tying database changes to code changes, every time code is deployed there is a little bit of confusion around


それでもQAに向けた開発の最中は誰かがこうした特定の変更を忘れずにデプロイしなければならない。データベースの変更とコードの変更を同期させる明確な戦略を持っていないため、コードがデプロイされると毎回次のような混乱が発生する。

  • exactly which database changes need to be released
  • どのデータベース変更をリリースすべきか確信が持てない
  • which changes were already released
  • どの変更がすでにリリースされているのかわからない
  • the order the scripts need to be run in.
  • どの順番でスクリプトを実行させればいいのかわからない


Jimmy is getting upset.
ジミーはだんだんうろたえるようになる。


Another darker possibility is that instead Jimmy needs to submit his changes to the database review board, a collection of detached idealists, college professors without the college, who will criticize every aspect of the scripts in order to justify their existence, but will not really offer any true value because they don’t understand the business problem that needs to be solved, nor do they appreciate the application considerations beyond the database that need to be satisfied.


また、次のような暗い問題が持ち上がる可能性がある。ジミーは変更点をデータベースのレビュー委員会に提出する必要があるが、学識ぶった委員会の連中はそれが自分たちの存在意義だと言わんばかりにスクリプトのあらゆる点を批判してくる。しかし本当に価値のある指摘はしてこない。なぜなら彼らは解決すべきビジネス上の問題を理解していないし、データベースが満たさなくてはならないアプリケーション上の考慮点も理解していないからだ。


One of the long term impacts of this is that Jimmy will look for any possible way to accomplish what he is trying to do without making database changes, because it is too much trouble. If he does indeed need to change the database, he’ll try to accomplish it just by changing stored procedures, because changing table schemas are even worse. In the end, he’s definitely not trying to find the appropriate solution to the problem; instead he backed into a situation of finding a “good-enough” solution that will just minimize his hassle, regardless of the downstream impacts.


こうした状況が招く長期的な問題の一つは以下のようなものだ。ジミーはデータベースの変更なしにやろうとしていることを実現させる抜け道を探しはじめる。なぜならデータベースの変更は非常に面倒だからだ。もしジミーが本当にデータベースを変更しなければならないのであれば、彼はストアドプロシージャの変更だけで完了させようとする。なぜならテーブルのスキーマ変更はさらに面倒なことになるからだ。最終的にジミーは問題を解決するための適切な解決策を検討しなくなる。下流工程への悪影響などは無視して自分の仕事を最小限に抑える「まあまあ十分な」解決策を模索するようになってしまうのだ。


From now on, he’ll look for any way he can accomplish it by only changing stored procedures and not changing the underlying schema. If he’s lucky (sort of), he’ll find a way that he can just kludge the stored procedures to work around the problem for now, and let it be someone else’s problem to solve later. He has long since given up trying to find the “right” solution, because it is so exhausting the current state of things is so busted up that it’s not even worth trying anymore.


これ以降、ジミーはスキーマを変更するのではなく、ストアドプロシージャの変更だけで完了させる方法を検討し始める。幸運な場合は(ある意味ね)、あとで解決しなければならない誰かの問題はほっといて、ストアドプロシージャをちょっといじるだけで一時的に問題を回避できる方法を見つけられるかもしれない。ジミーはそれからずっと「正しい」解決策を探そうとはしなくなる。なぜなら現状はすでに破綻し尽くしており、これ以上頑張る価値はないからだ。


Further complicating the issue, some developers and DBAs make one-off changes in the QA and production environments without going through source-control. Either they need to make an emergency fix in one of the environments and forget to go back and add the scripts to source-control, or worse they just don’t believe that databases should be under source-control at all. I’ve seen this attitude far too often from some DBAs, because they can’t stand the idea of being forced to use a source-control system managed by some other developers, just so that they can make changes to their own database. Pretty soon, every environment is a perverted branch of the one true database, and trying to identify why a test works in one environment and fails in another quickly becomes a nightmare.


さらに複雑な問題は、開発者とDBAがソース管理を使うことなしにQA環境と本番環境に一度きりの変更を加えてしまうことだ。彼らは緊急対応を片方の環境に実施してソース管理にスクリプトを登録するのを忘れるか、ひどいことにデータベースはソース管理する必要はないと考えているかのいずれかだ。私はこうした姿勢をDBAの方に多く見てきた。なぜなら彼らは開発者たちが管理しているソース管理システムに縛られることに耐えられず、単純に自分たちのデータベースに変更を適用したいからだ。そうしてまもなく、どの環境も本来のデータベース構成とはかけ離れたブランチ環境となってしまう。そして、ある環境でパスするテストが別の環境ではパスしないようになり、その原因を調査することが途端に困難になってしまうのだ。