個々の変更されたファイルをサーバーにアップロードするよりもはるかに優れた/簡単な/信頼性の高い「アプリケーションの展開」というフレーズを聞いたことがありますが、どこから始めればよいかわかりません。
バージョン管理下にある Zend Framework アプリケーションがあります (Subversion リポジトリ内)。アプリケーションを「デプロイ」するにはどうすればよいですか? 上書きしたくない「アップロード」ディレクトリがある場合はどうすればよいですか?
私はサードパーティを通じてアプリケーションをホストしているため、FTP 以外のことはあまり知りません。これに私のサーバーへのログインが含まれる場合は、そのプロセスを説明してください。
ステージング サーバーへの自動展開とテストの実行は、継続的インテグレーションと呼ばれます。テストに違反するものをチェックインすると、すぐに通知されるという考えです。PHP の場合は、XincまたはphpUnderControlを調べてください。
ただし、通常、本番環境に自動的にデプロイすることは望ましくありません。通常は、タスクを自動化するスクリプトをいくつか作成しますが、それでも手動で開始する必要があります。これにはPhingやその他のビルドツールなどのフレームワークを使用できます(人気のある選択肢はCapistranoです) が、いくつかのシェルスクリプトを一緒に泡立てることもできます。個人的には後者の方が好きです。
スクリプト自体は、アプリケーションとセットアップに応じてさまざまなことを実行できますが、一般的なプロセスは次のとおりです。
svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMPunlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/currentln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var/usr/local/application/current/scripts/migrate.php(アプリケーションが にあると仮定します/usr/local/application/current)
自動更新はお勧めしません。単体テストに合格したからといって、アプリケーションが 100% 機能しているとは限りません。誰かが新しい単体テストなしでランダムに新しい機能をチェックインし、その機能が機能しない場合はどうなりますか? 既存の単体テストはパスするかもしれませんが、いずれにしても機能が壊れる可能性があります。ユーザーには、中途半端なものが表示される場合があります。チェックインからの自動デプロイでは、あるべきではないものがライブになった場合、数時間気付かないことがあります。
いずれにせよ、あなたが本当に望むのであれば、自動展開を開始することはそれほど難しくありません. チェックイン後のフックが必要です。実際の手順は次のとおりです。
1) 最新のチェックインからエクスポートを実行する 2) エクスポートを本番サーバーにアップロードする 3) 新しくアップロードされたエクスポートをアンパック/構成する
私は常に最後のステップを手動で実行してきました。一般的には、SVN エクスポート、zip、アップロード、解凍、構成と同じくらい簡単です。最後の 2 つの手順では、いくつかの bash コマンドを一緒にエイリアスして実行します。次に、ルート アプリ ディレクトリを新しいディレクトリと交換し、古いディレクトリをバックアップとして保持するようにします。これで問題ありません。
エラーが自動的に有効になる前にエラーを検出できる自信がある場合は、その手順の自動化を検討できます。しかし、それは私にジブリージブリーを与えます。
私の webdev 会社では最近、人気のある Capistrano ツールの Web GUI であるWebistranoの使用を開始しました。
私たちは、一元化されたインターフェース、説明責任 (誰がどのバージョンをデプロイしたか)、以前のバージョンへのロールバック、できれば無料の、使いやすく高速なデプロイ ツールを求めていました。Capistrano は、Ruby on Rails アプリケーションのデプロイ ツールとしてよく知られていますが、一元化されておらず、主に Rails アプリを対象としています。Webistrano は、GUI、アカウンタビリティでそれを強化し、PHP 展開の基本的なサポートを追加します (「純粋なファイル」プロジェクト タイプを使用します)。
Webistrano 自体は、開発サーバーまたはステージング サーバーにインストールする Ruby on Rails アプリです。Web サイトごとにプロジェクトを追加します。各プロジェクトに、Prod や Dev などのステージを追加します。
各ステージには、デプロイ先の異なるサーバーと異なる設定を含めることができます。カピストラーノに何をすべきかを伝える ruby スクリプトである「レシピ」を作成 (または変更) します。私たちの場合、提供されたレシピを使用して、共有アップロード ディレクトリへのシンボリック リンクを作成するコマンドを追加しました。
[デプロイ] をクリックすると、Webistrano はリモート サーバーに SSH 接続し、コードの svn チェックアウト、およびデータベースの移行、シンボリック リンク、以前のバージョンのクリーンアップなど、必要なその他のタスクを実行します。もちろん、これはすべて微調整できます。結局のところ、単純にスクリプト化されているだけです。
とても満足していますが、特に Ruby と Rails に慣れていなかったので、学習とセットアップに数日かかりました。それでも、非常に信頼性が高く、柔軟性があり、初期投資を何倍も節約できることが証明されているため、中小企業での本番環境での使用には強くお勧めできます。展開をスピードアップするだけでなく、間違いや事故を減らすことによっても。
この種のことは、「継続的統合」と呼ばれるものです。Atlassian Bamboo (有料)、Sun Hudson (無料)、Cruise Control (無料) はすべて (私の好みの順で) 一般的なオプションであり、PHPUnit 出力の処理をサポートしています (PHPUnit は JUnit 出力をサポートしているため)。
デプロイは、ビルド後のトリガーで実行できます。このスレッドの他の一部の人々と同様に、チェックイン (およびテスト パス) で自動展開を行う前に、細心の注意を払う必要があります。
アップロードを処理するための古典的な解決策は、実際のディレクトリをメインの Web スペースから移動し、新しいバージョンをチェックアウトするためだけに残して (以下のスクリプトで行っているように)、Apache を使用して「エイリアス」に戻すことです。ウェブサイトの一部として配置します。
Alias /uploads /home/user/uploads/
ただし、サーバーを十分に制御できない場合は、選択肢が少なくなります。
特定のスクリプトを開発/ライブ サイトにデプロイするために使用するスクリプトがあります (両方とも同じサーバーで実行されます)。
#!/bin/sh
REV=2410
REVDIR=$REV.20090602-1027
REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk
IMAGES=$REVDIR/php/i
STATIC1=$REVDIR/anothersite.co.uk
svn export --revision $REV $REPOSITORY $REVDIR
mkdir -p $REVDIR/tmp/templates_c
chown -R username: $REVDIR
chmod -R 777 $REVDIR/tmp $REVDIR/php/cache/
chown -R nobody: $REVDIR/tmp $REVDIR/php/cache/ $IMAGES
dos2unix $REVDIR/bin/*sh $REVDIR/bin/*php
chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php
# chmod -x all the non-directories in images
find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x
find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x
ls -l $IMAGES/* | grep -- "-x"
rm dev && ln -s $REVDIR dev
リビジョン番号と、チェックアウトしたディレクトリ名に使用される日付/時刻を入れます。中央の chmod は、専用のイメージ サーバーにもシンボリック リンクされているため、イメージのパーミッションが問題ないようにします。
最後に、古いシンボリック リンク .../website/dev/ が新しくチェックアウトされたディレクトリに再リンクされます。Apache 構成には、.../website/dev/htdocs/ の doc-root があります。
一致する .../website/live/htdocs/ docroot もあり、「live」は別のシンボリック リンクです。これは、ライブ シンボリック リンクを削除し、dev が指すものに置き換える私の他のスクリプトです。
#!/bin/sh
# remove live, and copy the dir pointed to by dev, to be the live symlink
rm live && cp -d dev live
私はサイトの新しいバージョンを数日ごとにプッシュしているだけなので、これを 1 日に数回使用したくないかもしれません (私の APC キャッシュは、サイトのいくつかのバージョン以上を好まないでしょう)、しかし私にとっては、これは私自身の展開では非常に問題がないことがわかりました。
fredistrano を確認してください。これは capistrano のクローンであり、うまく機能します (インストールは少し混乱しますが、結局はうまく動作します)。
3 年後、展開のベスト プラクティスについて少し学びました。私は現在 Capistrano というツールを使用しています。セットアップと使用が簡単で、多くのデフォルトを適切に処理できるからです。
自動展開プロセスの基本は次のようになります。
スクリプトは、次のディレクトリ構造を持つ運用サーバーに SSH 接続します。
/your-application
/shared/
/logs
/uploads
/releases/
/20120917120000
/20120918120000 <-- latest release of your app
/app
/config
/public
...etc
/current --> symlink to latest release
Your Apache document root should be set to /your-application/current/public
このスクリプトは、releases ディレクトリに現在の日時で新しいディレクトリを作成します。そのディレクトリ内で、コードは指定したタグに更新されます。
リリース間で保持する必要があるものは共有ディレクトリに移動し、それらの共有ディレクトリへのシンボリック リンクが作成されます。
それは、アプリケーションとテストの堅実性によって異なります。
私が働いている場所では、すべてがレビューのためにリポジトリにチェックインされ、その後リリースされます。
他の開発者が新しいバージョンをプルしてそこに変更をマージできるようにチェックインするだけなので、リポジトリからの自動更新は賢明ではありません。
あなたが話していることを行うには、一次チェックイン領域で開発者間のコラボレーションを可能にするために、ある種の二次チェックインとチェックアウトが必要になります。私はそれについて何も知りませんが、それが可能かどうかさえ知りません。
処理が必要な分岐やその他の同様の機能にも問題があります。