新しいサーバーのDzhangまたはRailsにプロジェクトをデプロイするには、 5〜10個のコマンドを実行する必要があります。 開発者がデータベーススキーマを修正した場合、いくつかのコマンドを実行してサーバーを再起動する必要があります。 サードパーティのパッケージのリストを変更する場合は、さらに2つのコマンドを再構築して再起動する必要があります。 翻訳を変更しました-さらに2つ。 また、データベースと翻訳の2つのことをすぐに変更した場合はどうなりますか？ または3？ エラーが発生する可能性があることを確認してください。 しかし、私たちはコンピューターを使用しています！ 彼は何を更新すべきかを理解できるほど頭がいい。 ドライバーを作ることができず、ドライバーで作業することができなかったドリル工場を想像してください。 愚かでしょ？
ジェフ・アトウッド、またはポール・グラハムのいずれかは、プログラマーは自分でツールを開発するのにより多くの時間を費やすべきだと書いていました。 繰り返しを減らすためにコードの抽象化（関数、モジュール）を書くので、繰り返し作業が少なくなるようにツールを扱う必要もあります。
このようになりましょう：上記の場合に何が必要ですか？ （インストール、更新。）サーバーは何をするようにインストールしますか？ 稼いだ。 パッケージを更新し、何が欲しいですか？ そのため、何かが変更され、サーバーが再び動作を開始します。 最も重要なこと-速く、つまり、超過分が更新されないようにする方法は気にしません。
もちろん、これらすべての場合にスクリプトを書くことができますが、やはり、どのスクリプトが何のためにあるかを覚えておく必要があります。 あなたは間違ったものを実行します-そして時間が無駄になります。
記事の冒頭の図には、 fastdev-djangoプロジェクトで実行する必要があるアクションがあります。 最近まで、私は実際、このスキームの類似体を頭の中に保持しなければならず、毎回何をすべきかを覚えていなければなりませんでした。 ただし、スキームの最終目標は黄色で強調表示されているもののみです。 残りのアクションは中間停止であり、優れたシステムはそれらを思い出さないようにする必要があります。
解決策
Makeユーティリティは非常に柔軟であり、すべてを更新し、同時に再コンパイルしすぎないように、再構築する必要があるものを正確に追跡できます。 Djangoサーバーに必要なMakefileのルールは次のとおりです。
.PHONY：実行 実行：bin / django syncdb bin / sass compile_trans ./bin/django runserver 0.0.0.0:8000 .PHONY：shell_plus shell_plus：bin / django syncdb bin / sass ./bin/django shell_plus bin / django：bin / buildout buildout.cfg ./bin/buildout ビン/ビルドアウト： python bootstrap.py --distribute syncdb：bin / django ./bin/django syncdb ＃タイムスタンプファイルをタッチして、再同期を回避 syncdbをタッチします make_trans：bin / django ./bin/django makemessages -a -e 'py、html、haml' ビン/サス： gem install sass --bindir bin ＃buildout.cfgを見る buildout.cfg： compile_trans： ロケールを作成する/ * / LC_MESSAGES / django.mo ロケール/％/ LC_MESSAGES / django.mo：ロケール/％/ LC_MESSAGES / django.po ./bin/django compilemessages -l $（word 2、$（subst / ,, $ @）） ロケール/ * / LC_MESSAGES / django.po：
（ ファイルの全文 ）
そのようなファイルがある場合、ジョブはより簡単になります。
1.翻訳を変更しました-表示する必要がある場合は、コンソールに移動してmake runを記述してください。 また、すぐに見る必要がない場合は、翻訳を編集するだけです。 もう一度更新されます。
2.依存するパッケージを追加-make runまたはmake shell_plusのコンソールからサーバーを再起動するだけです。
ここでは、Makefileの作成方法については説明しません。Webにはこれについて十分な資料があります。O'Reillyの本 （英語）、 ロシア語のマニュアル、 GNU Makeの有効な使用です 。
翻訳（特定のファイルではない）がコンパイルされるようにファイルを構成しましたが、更新のみを行いました。
データベースの移行を自動化できませんでした。 もちろん、データベースを削除して再作成するコマンドを作成できますが、これは運用サーバーにとって危険です。 より良いツールSouthがありますが、今のところ（バージョン0.7.3）自動的に呼び出さない方が良いです。 データベース内のすべての変更を移行に記録する場合（デルタとテーブルの完全な状態の両方を記録する）、これが発生します。フィールドを追加すると、移行が表示されます。 その後、私は働きましたが、まだ何もコミットしていませんが、このフィールドは削除しました。 別の移行がディスクに表示されました。 SUVにファイルを保存し、他の開発者に送信しました。 不要な移行を開始する必要があり、リポジトリは不要なファイルで膨らみます。
リスト：移行フォルダー内のファイル。 0002はフィールドを作成し、0003はそれを削除します。 それぞれのサイズは17キロバイトです！
29K 2011-10-13 12:33 0001_initial.py 17K 2011-11-13 02:07 0002_auto__add_field_address_test_field.py 17K 2011-11-13 02:07 0003_auto__del_field_address_test_field.py
Southの自動起動をオフにした場合、データベースにどのような変更が発生したかを覚えておく必要があります。 そして、ここで記事の冒頭に戻ります。コンピューターが記憶できることを覚えておく必要があります。
仕事文化
この議論を聞いたら、「開発者に覚えておいてください。 すべてを覚えて再確認することは、働く文化の問題です。「私は自分でCとPHPでプログラミングを行っていましたが、注意して、たとえばプロジェクトWikiに行ってライブラリのドキュメントを維持する必要があると考えました。 Pythonにはdocstringがあり、モジュール、クラス、またはメソッドの説明はコードの横にあります。 同じ結果が少ない労力で達成され、エラーの発生頻度も少なくなります。コードを調べて、ドキュメントが古くなっているかどうかを確認できます。
技術的なソリューションがより複雑で高価な他の業界でも、同じことが行われます。 飛行機のパイロットがどんなに慎重であっても、それは間違っている可能性があります。そのため、例えば、着陸装置の昇降機構は、車輪が高速で誤って解放されたり、地面に立っている間に車輪が外れたりしないように自動的にロックされます。
シャーシAn-124、 Airliners.net
したがって、逆に作業文化は、メモリの負荷を減らして作業を簡素化し、人々の時間を節約すること（もちろん、節約に値する場合）と、必要に応じてツールを修復できるように労働者を教育することだと思います。
次は何ですか
1.翻訳を更新するときにサーバーを再起動することも、特に自動再起動がある場合は時間の無駄です。 django.utils.autoreloadにパッチを適用して、ロードされたモジュールだけでなく、テキストおよびコンパイルされた翻訳も監視するようにします。
2. Make構文には、変数、関数、遅延計算が含まれます。 これは、覚えておくべきもう1つのマークアップ言語です。 同じことを書いてもいいのですが、Pythonで？ 試してみる価値はあります。 ただし、すべてのシステムにあるわけではなく、MakeはLinuxとMacの両方にあります。
文学
- GNU Make 、O'Reilly、2003
- GNU Makeガイド
- GNU Makeの効果的な使用 、Vladimir Ignatov、2000
- PythonのMakefile 、Ian Bicking
- Setuptoolsのドキュメント
補遺：コメントで、 artifexはFabricシステムのスクリプトにPythonのMakeに似ていると伝えています。 私の意見では、提案の中で最も便利です。