The Impedance Mismatch
インピーダンス・ミスマッチ(開発者とDBAの違い)
Why aren’t Database DML and DDL subject to the same level of source-control as the application? Why don’t developers think about databases the same way that they think about source-code?
どうしてデータベースのDMLとDDLはアプリケーションと同じレベルのソース管理下に置かれないのか？どうして開発者はソースコードと同じようにデータベースのことを考えないのだろうか？
The most obvious reason is that database changes are fundamentally different in many ways. While source-code is usually just a collection of files that are recompiled, versioned, and released at any given time, databases are much more temperamental. They have existing data, and they have history. Sure, source-code has history, which you can review for reference purposes, but in databases the historical lineage of a table is actually very important. In C#, if you added a field to a class, and then a week later someone else changed the type, and then a month later someone else changed the name, it usually doesn’t really matter too much when or in what order those changes happened, all that matters is the current state of the code and that everything builds together and works in its latest state. However, if you were to do the same thing to a new field in a table, it definitely makes a difference, because there are data implications at every step of the way. This alone scares a lot of developers away from maintaining the database.
データベースの変更は様々な面で全く異なるからだ、というのが最も明白な理由になるだろう。ソースコードはふつうファイルの集まりであり、いつでも再コンパイルされ、バージョン付けされ、リリースされる。一方、データベースはずっとややこしい。データベースにはデータがあり、履歴を持っている。もちろん、ソースコードも履歴を持っており、開発者はそれを参照できる。しかしデータベースの場合、テーブルの変更履歴は非常に重要だ。C#であればあなたがクラスにフィールドを追加し、一週間後に誰かが型を変え、一ヶ月後に誰かが名前を変えたとしても、変更が発生した時間や順番は大して問題にならない。重要なのはコードの現在の状態であり、最新の状態ですべてがビルド可能で動作さえすれば良いのである。しかし、もしも同じことをテーブルのフィールドに対して行おうとすると、話が全く変わってくる。なぜならすべての作業においてデータの密接な関係を意識しなければならないからだ。これだけでも多くの開発者はデータベースの保守を嫌がるようになる。
To many developers, there is something fundamentally uncontrollable about databases. They don’t fit into the safe model that we’re use to. Managing those changes is definitely introduces new challenge, and many developers just don’t want to be bothered. Another major reason for the difference is just cultural. Developers want the database to work well, and they may even like tinkering around with some stored procedures from time to time, but at the end of the day they like to be able to wash their hands of anything that slightly resembles being a “DBA”.
多くの開発者にとってデータベースに関しては根本的に制御できないことがある。データベースは我々が使い慣れた安全策を適用しにくい。データベースの変更を管理することは新しい課題を作り出すことであり、多くの開発者はそんな面倒なことを避けたがるのだ。違いを生み出すもう一つの大きな理由は単に文化的なものである。開発者はデータベースが正常に動作することを期待する。彼らはストアドプロシージャを時々書き直すことは好きかもしれないが、いわゆる「DBA」的な仕事はやりたくないのだ。
Developers often see themselves as the general of a utilitarian army of code that they build and train and then order off to carry out their mission, and they usually won’t hesitate to trash it all and replace it if it proves itself unable to complete the mission. DBAs on the other hand are used to dealing with a gentle lion that could easily lose it temper and kill everyone in the room if it’s not treated with kindness and respect. Developers often have the option to wipe the slate clean and start over, and usually want to, especially when they are dealing with someone else’s code. DBAs however are stuck with the original version and they need to keep it alive and make it work until the point that the data can be migrated to a better system, and we all secretly know that is never going to happen.
開発者は自分たちの任務を遂行するためであれば、役に立たないコードはすべて捨ててしまうことも厭わない。一方、DBAは丁寧に扱わないとすぐにキレてしまう紳士的なライオンを扱うのに慣れている。開発者はしばしば今までのコードを捨ててゼロから書き直すことを考える。他人のコードを扱うときは特にそうだ。しかしDBAはそのデータがより改善されたシステムへ移行するまで(まあ絶対にないことだが)、オリジナルバージョンを保守し続けなければならない。
Silently Killing Software Quality
ソフトウェア品質の密かな低下
Let’s take a fictitious example: At some internal IT department, a group of developers is toiling away on a set of dull yet fabulously ‘enterprise-y’ software that no more than five people will ever use. Jimmy checks his code changes into his company’s version-control system of choice, where it is automatically held at the gates until it is code-reviewed by a senior developer, and then it is checked into the team’s current release branch. Meanwhile the continuous-integration build server will download, compile, package, and unit-test the code to make sure that Jimmy hasn’t broken anything, and that nobody else’s changes broke Jimmy. The package code is then migrated through an integration environment, QA environment, UAT environment, and staging environment on its way to production. All the while, as the changes are validated from one environment to another, version numbers are automatically assigned to allow anyone to trace back the exact revision for a given build, and the corresponding code changes slowly work their way towards the code-release Promised Land, the Main Trunk. Those branches can get pretty damned complicated, even when everything is going smoothly, which it never does.
ここで架空の例を取り上げてみる。とある社内情報システム部において、とある開発者たちが「エンタープライズY」というイケてないソフトウェアを保守している(ちなみにユーザーは5人以下)。その会社のバージョン管理システムを使う場合、現行のリリースブランチへコードをチェックインするためには上級開発者のコードレビューが必要になる。ジミーはそこへ変更したコードをチェックインする。一方、継続的インテグレーションサーバーはジミーのコードが壊れていないか、また他の開発者の変更がジミーのコードに悪影響を及ぼしていないかを確認するため、ユニットテストを実行する。それからそのコードはプロダクション環境へ移行するまでに、統合テスト環境やQA(品質保証)環境、UAT(ユーザー受入テスト)環境、ステージング環境を通過する。ある環境で変更内容が検証され、次の環境へ移行する間は絶えずバージョン番号が自動的に付けられる。これはどのリビジョンがビルドに使われたのかを正確にトレースできるようにするためである。こうして変更されたコードはリリース用のメイントランクへとゆっくり進んでいく。このようなコードブランチは極めて複雑であり、物事はなかなかスムーズに進まない。
Hopefully this is a process that Jimmy’s company evolved out of mixture of necessity and forethought over the years. The other, less attractive, and far more common scenario is that the company hired an astronaut trapped in a developer’s body, bored with his work and not bound by any sense of urgency, who assured the company that he was going to implement a lot of big complicated processes because that’s just want professional companies do.
これはおそらくジミーの会社が長年時間をかけて必然性と用心深さの混合物を発展させた末に出来上がったプロセスである。一方、魅力的ではないがよくありふれたもうひとつのシナリオは、専門家を雇い入れ、プロフェッショナルはそうあるべきだという理由から巨大で複雑なプロセスを作らせるというものである。
In the end, a whole lot of people are paying a whole lot of attention to managing the source code. Hopefully at your company, you are paying attention to this to.
結局のところ、多くの人々はソースコードを管理することに多くの注意を払うのである。それはあなたの会社においてもたぶん同じだろう。
