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

give IT a try

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

When Database Source Control Goes Bad 翻訳 Part5

Developing Application code Locally

ローカル環境でアプリケーションコードを開発する


These days, most every application programmer develops their code locally. That’s just what you do. Many developers have learned the hard way that this is important, and won’t tolerate any divergence. And for the less experienced developers who are doing it just because they are told to, eventually they will make the same mistakes and learn from them too. This is such an easy lesson to learn that you don’t see too many people violate it intentionally.


最近ではどのアプリケーションプログラマもたいていローカル環境でコードを開発する。あなたもまさにそうだろう。多くの開発者はこのことが重要で、意見が分かれることはないと考えている。そうしろと言われたからという理由でそのようにしている経験の浅い開発者も同じ間違いを犯して、そこから学ぶ。これは簡単に学習できる教訓であり、わざわざこの教訓を破る人はほとんどいない。


Even if you are obliged to develop on a server environment, you’ll probably at least find a way to isolate yourself. For example, SharePoint developers tend to avoid installing the SharePoint platform on their local machines, mostly because it requires a server OS, but also because SharePoint is pure, unadulterated evil that will steal the very soul of any machine it comes into contact with. Nonetheless, in those cases where a local machine is not practical, the developer will install the SharePoint software onto a virtual machine so that they can still work in isolation.


もしあなたがサーバー環境上で開発を強いられたとしても、おそらく自分用の環境を確保できるような方法を見つけるだろう。たとえばSharePoint開発者はSharePoint環境をローカルマシンにインストールすることを避ける。SharePointはサーバーOSを必要とするというのが大きな理由だが、それだけではなく、SharePointをインストールするとマシンが使い物にならなくなってしまう。ローカルマシンは実用的でなかったとしても、隔離された環境で作業ができるよう、開発者はバーチャルマシンにSharePointをインストールしようとする。


This local development approach is critically important to any form of version-control or change management. For all practical purposes, developers must have a workable environment that they can fully control and work in peace. From there, developers check their code into source-control, and hopefully it gets built from source-control before being deployed to another server. This gives each developer a degree of control over how much the other developers can screw them up, and more importantly it ensures that every change is traceable back to a date and time and person responsible.


ローカル環境で開発することはバージョン管理や変更管理の決まりとしても非常に重要である。実用性を考えれば、開発者は自分で完全に管理でき、なおかつ一カ所にまとまっている開発環境を所有しなければならない。開発者はそこから自分たちのコードをソース管理へチェックインし、別のサーバーへデプロイされる前にソース管理からビルドされることになる。これによって他の開発者がどれだけヘマをやらかしても開発者個人は状況を多少制御できるようになる。また、さらに重要な点はあらゆる変更がいつ誰によってなされたのかを追跡できるということだ。


This approach is so ingrained in so many developers, that often we take it for granted. Just try to remind yourself regularly how awful it was that time that everyone was working directly on the same developer server, and nobody can keep track of who changed what when. Or better yet, how fired up everyone got the last time somebody sneaked directly into the production server and started mucking around.


このアプローチは多くの開発者に深く根付いており、それゆえ我々はこのことを当然だと思い込んでいる。全員が同じ開発サーバー上で作業し、いつ誰が何を変更したのか分からない状況がいかに恐ろしいことか、思い起こしてみるといい。さらに、誰がこっそりと本番環境サーバに忍び込んで、うろうろしているような場合でも誰もが憤慨するだろう。


Surprisingly, developers go to such trouble to isolate their local application development environment, and then point their local application code to a shared development database server that the whole team is working on.


驚くことに、開発者はアプリケーション用のローカル開発環境を隔離し、自分たちのアプリケーションコードをチーム全員が共有するデータベースサーバー上で動作させることで、このようなトラブルを引き起こしているのだ。


If you never need to make database changes, and nobody on your team needs to make database changes, this can certainly work. In that case, the database behaves like a third party service, rather than an actively developed part of the system.


もしあなたが決してデータベースに変更を加える必要がなく、さらにチームの誰一人としてデータベースに変更を加える必要がないのであれば、このやり方はきっとうまくいくだろう。そのような場合、データベースはシステムの一部として活発に開発されるものではなく、むしろサードパーティ製のサービスのように振る舞うことになる。


However, if you are ever making database changes, you need to isolate your database for the exact same reasons that you need to isolate your application code.


だがしかし、もしあなたがデータベースの変更を行うつもりなら、アプリケーションコードを隔離するのと全く同じ理由でデータベース環境も隔離する必要がある。