When Database Source Control Goes Bad 翻訳 Part1

「When Database Source Control Goes Bad」という興味深いブログがあったので、ちょっと日本語に翻訳してみようと思いました。
今回はとりあえず途中経過を報告する意味でPart1です。あと6倍ぐらいの長さがあるのですが、果たして最後まで翻訳できるでしょうか・・・？
なお、訳はところどころ意訳しています。一字一句を日本語に直そうとはしていません。あしからず。

原文
http://www.simple-talk.com/sql/t-sql-programming/when-database-source-control-goes-bad/

When Database Source Control Goes Bad

データベースのソース管理が悪化するとき

It is a question every development manager dreads; “So how does your company handle database changes?”. The reply usually masks a multitude of sins against all the canons of version control. Mike has seen most of these sins and, like the ancient mariner, is keen to give you the awful warning, 'Neglect database source control at your peril'.

すべての開発マネージャーを怖がらせる質問がある。「あなたの会社ではデータベースの変更をどのように管理していますか？」開発マネージャーはたいてい罪の意識を隠すような回答になることが多い。マイクはこうした罪の意識を数多く見てきた。「データベースのソース管理をないがしろにするなら危険を覚悟すべきだ」マイクはこのように警告している。

How should we do change-control when developing database applications? In order to prevent chaos, I believe that we need to follow these general requirements:

データベースアプリケーションを開発するときにはどのように変更管理をすべきか？混沌とした状況を避けるために以下のような一般的な要求事項に従うべきだ。

The database must be versioned, so that it is easier to tell which changes have been applied, and when they were applied.
データベースはバージョン付けされなければならない。これによりどんな変更が行われ、いつ適用されたのかを容易に判断できるようになる。

All database changes must be checked into source-control.
あらゆるデータベースの変更をソース管理へチェックインしなければならない。

Every database developer should work on their own version of the database.
すべての開発者は専用のデータベースを使って開発すべきだ。

It should be possible to tie database changes to the code changes that they affect, ideally checked into source-control as a part of the same changeset transaction.
データベースの変更とコードの変更を関連づけられるよう、同じタイミングでソース管理へチェックインされるべきだ。

The database changes should be built along with the code changes.
データベースの変更はコードの変更にあわせてビルドされるべきだ。

The database changes should be deployed along with the code changes.
データベースの変更はコードの変更にあわせてデプロイされるべきだ。

The continuous-integration server must be able to build and update its own copy of the database, so that it can run automated tests of code and scripts that are checked in at the same time.
継続的マイグレーションサーバーは専用のコピーをビルドし、更新できなければならない。これにより同じタイミングでチェックインされたコードのテストを自動化できる。

You should be able to keep scripts local, with big fat lines between your environments, and handle promotion of database scripts even more thoroughly than your application code. Ensure that you can recreate any database anywhere, anytime. Clearly define your ground rules for how developers are going to merge your changes together. Lean heavily on your build server to enforce as much of this as possible, because a process that is enforced manually is a process that will never be followed.

スクリプトはローカルに保持し、アプリケーションコードよりもずっと厳密にデータベーススクリプトの適用を管理すべきだ。いつでもどこでもどんなデータベースでも再作成できるようにしなければならない。開発者はどのように変更をマージするのかを明確にルール化しなければならない。こうしたことを実現するためにビルドサーバーを徹底活用すべきだ。なぜなら手作業のプロセスは結局誰も従わなくなってしまうからだ。

In this article, I’ll be describing the problems that happen when these guidelines aren’t followed.

この記事では上記のようなガイドラインが守られなかった場合に発生する問題について記述する。

The Problem

問題点

I’m a pathological job-hopper who is sick of seeing one company after another wasting hidden hours and days on insufficient database change control strategies.

私は非効率なデータベースの変更管理をしている会社をたくさん見てきた。

“So how does your company handle database changes?”

「では、あなたの会社ではデータベースの変更をどのように管理していますか？」

I’ve asked this of potential employers many times, and I usually just get blank stares, or a vague answer along the line of “uh… with scripts?” Sometimes, if they are honest, they just reply “poorly.” There’s not even an explicit Joel Test for it. Considering how bad the situation is at most companies, the real test is not whether their database change management is any good, but just whether they are willing to recognize how problematic it really is.

私はこのような質問を何度もしてきた。するとたいてい目をそらされたり、あいまいな返事が返ってきた。「ああ・・・スクリプトを使ってるかな？」中には「ダメダメです」と正直に回答する人もいた。この分野における明確なジョエルテスト*1はない。多くの会社がひどい状況にあることを考えると、データベースの変更管理がうまく行われているかということより、現状の問題点を認識できているかどうかということの方がテストとしては適切だろう。

Given how much thought and effort goes into source-code control and change-management at many of these same companies, it is odd that so much less progress has been made on the database change management front. Many developers can give you a 15 minute explanation of their source-code strategy, why they are doing certain things and referencing books and blog posts to support their approach, but when it comes to database changes it is usually just an ad-hoc system that has evolved over time and everyone is a little bit ashamed of it. The vast majority of companies I’ve seen were not even in the ball park.

ソースコード管理と変更管理がこうした会社の多くで熱心に行われているにも関わらず、データベースの変更管理についてはほとんど向上していなというのは奇妙な話だ。多くの開発者はソースコード管理については熱く語ることができるのに、データベースの変更管理の話となると、小っ恥ずかしいその場しのぎのやり方しか持っていないことがほとんどだ。私が見てきた会社の大多数は全く論外だった。

I’ve seen some companies that have had home-grown utilities that come close to a satisfactory solution, but in the end they all fell just a little bit short of what’s needed.

いくつかの会社では完璧なソリューションに限りなく近い自作のユーティリティを持っていた。しかしそうしたツールも結局必要とされる機能がわずかに足りなかった。

Some of you are probably asking, “Doesn’t Visual Studio Team System” do this? Yeah, I think so. Probably, but who knows. Honestly I tried working with it a few times, and it caused me nothing but problems. Sure, I could spend a lot of time mastering all the quirks, but I’m looking for something a little bit more accessible here. The underlying concepts are hard enough; we need an approach that simplifies it, and I just don’t think that VSTS accomplishes that. More importantly, and also along the lines of accessibility, VSTS costs a fortune, and so most developers will never have access to it, so it is no good for the other 95% of developers out there that are stuck with having to use reasonably-priced tools.

Visual Studio Team System(VSTS)は使えないのかと尋ねる読者もいるかもしれない。うん、使えると思う。たぶんね。でもどれくらいの人が使いこなせるんだろうか？私は何度か使ってみたが、私にとっては害にしかならなかった。私は長い時間をかけてVSTSの癖のある仕様をマスターしようとした。しかし、私はもうちょっと簡単に使えるツールが欲しい。VSTSのコンセプトは非常に難解だ。我々が望むのは簡単に実現可能なアプローチだ。VSTSではそれが実現されているとは思えない。簡単に使えるという点でもっと重要なことはVSTSには莫大なお金がかかりすぎるということだ。大半の開発者は触れる機会もないだろう。だから手頃な価格のツールしか使えない95%の開発者に取ってはVSTSの話をしても役に立たない。

*1:訳注 http://japanese.joelonsoftware.com/Articles/TheJoelTest.html