私は常に非常にシンプルなbashスクリプトを使用してコードをデプロイしてきました。 SubversionをMercurialに使用するのをやめようとしていますが、展開にはリビジョン管理ソフトウェアが重要だとは思いません。
これを行ういくつかのより良い方法は何ですか?
#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
すべてを管理するためのMercurial を使用します(静的HTMLページを含む)。それは私にとって人生を本当に簡単にします。
利点が含まれます
免責事項、私はチュートリアルを書きました。はい、使用するVCSの種類はある程度重要です。たとえば、このシナリオでは、ローカルでコミットして1つの大きなプッシュ/更新を行うことができないものは使用しません。そのため、問題となる可能性のある変更が1つのコミットメントにまとめられます。
IcouldSubversionでそれを行うと、SVNをまったくノックしません。 Mercurialは、あなたが解決しようとしている問題に対してはるかに優れたツールだと思います。
他に選択肢がない限り、ツールを「回避」する必要はないという私の意見です。そうすることはそれらを持っている目的を打ち負かし、あなたには選択肢があります:)
他の回答の優れた提案に加えて、アトミック更新を行うことが重要かどうかを検討することもできます。
私のFreeBSDサーバーでは、2つのメカニズムでこれを実現しています。
すべての静的リソースのバージョン管理。 (例:http://static.example.com/images/logo.1.png
またはhttp://static.example.com/style/main.3.css
)。これにより、ユーザーが古いページに新しいファイルを表示することを心配することなく、動的サイトを更新する直前に静的サイトをsvn update
することができます。
動的Webサイト全体のバージョン管理。私の場合、シンボリックリンクを指すドキュメントルートがあります。私の戦略は、新しいバージョンのプロダクションを導入し、1つのコマンドで「Push it live」にすることです。 .g。このようなもの:
cp -Rp www.site1.com.1 www.site1.com.2
(またはsvn checkout
)
svn update site1.com.2
(最初にsvn switch
が必要になる場合があります)
ln -sf site1.com.2 www.site1.com
(変更を実稼働に原子的に移動)
これにより、ユーザーの誰もが中途半端なページを見ることがなくなります。まだキャッシュにある場合は古いバージョンが表示され、新しいバージョンは表示されます。
この戦略は、ユーザーがアップロードしたコンテンツを動的サイトと混在させていない場合にのみ有効です。
Antの scp task と、 modified selector を使用します。つまり、前回のアップロード以降に変更されたファイルを更新するだけです。残念ながら、変更されたセレクタは、チームメンバーと共有するのではなく、個人使用のみを目的として設計されているようです。 cache.properties
ファイルには、ユーザーの作業ディレクトリへのパス名が含まれています。 cache.properties
ファイルを開発者間で共有できる形式にマッサージした後、antが必要とする形式にマッサージするために、多数のantターゲットを作成しました。形式は、Windows環境とGNU/Linux環境の間でも異なります。
バージョン管理を使用することの全体のポイントは、更新プログラムをプッシュする前にサイトをバックアップすることを心配する必要がないということではありませんか?
正しく行われた場合、svn update
(または同等のもの)で十分であり、それが間違いである場合、前のコミットにロールバックしますか?それはとにかくやることです。すべての変更をコミットします。svn update
ステージングサーバー。すべてが問題なければsvn update
ライブサーバー。