SubversionリポジトリからPHPアプリケーションのデプロイを開始するにはどうすればよいですか？

https://stackoverflow.com/questions/800294

03-07-2019
|

質問

「アプリケーションのデプロイ」というフレーズを聞きました。個々の変更されたファイルをサーバーにアップロードするよりもはるかに良い/簡単/信頼できるように聞こえますが、どこから始めるべきかわかりません。

バージョン管理下にあるZend Frameworkアプリケーションがあります（Subversionリポジトリ内）。「展開」についてはどうすればよいですか。私のアプリケーション？「アップロード」がある場合はどうすればよいですか上書きしたくないディレクトリですか？

サードパーティを介してアプリケーションをホストしているため、FTP以外はあまり知りません。サーバーにログインする必要がある場合は、プロセスを説明してください。

解決

自動デプロイ+ステージングサーバーへのテストの実行は、継続的統合と呼ばれます。アイデアは、テストに違反する何かをチェックインすると、すぐに通知されるということです。 PHPの場合、 Xinc または phpUnderControl

通常、実稼働環境に自動的にデプロイすることはしません。通常は、タスクを自動化するスクリプトを記述しますが、手動で開始する必要があります。このために Phing または他のビルドツールなどのフレームワークを使用できます（一般的な選択肢は Capistrano ）、ただし、いくつかのシェルスクリプトを一緒に泡立てることもできます。個人的には後者を好む。

スクリプト自体は、アプリケーションと設定に応じて異なる処理を実行できますが、一般的なプロセスは次のとおりです。

本番サーバーへのssh。残りのコマンドは、sshを介して運用サーバーで実行されます。
実行 svn export svn：// path / to / repository / tags / RELEASE_VERSION / usr / local / application / releases / TIMESTAMP
サービスの停止（Apache、デーモン）
run unlink / usr / local / application / current＆amp;＆amp; ln -s / usr / local / application / releases / TIMESTAMP / usr / local / application / current
ln -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、アップロード、unzip、configureのように簡単で、最後の2つのステップは、実行する2つのbashコマンドをエイリアス化するだけです。次に、ルートアプリディレクトリを新しいものと交換し、古いものをバックアップとして保持します。これで問題ありません。

エラーが自動的に公開される前にキャッチできることに自信がある場合は、その手順の自動化を検討できます。それは私にジブリージブリーを与えます。

これは、Subversionを使用してWebプロジェクトを展開することに関する優れた記事です＆＃8212;あなたの質問の多くに答えます。

http://athleticsnyc.com/blog/entry/ on-using-subversion-for-web-projects

最近、webdev会社で、 Webistrano を使用し始めました。これは、人気のあるCapistranoのWeb GUIです。ツール。

一元化されたインターフェイス、説明責任（誰がどのバージョンを展開したか）、以前のバージョンへのロールバック、できれば無料の使いやすい高速展開ツールが必要でした。 Capistranoは、Ruby on Railsアプリケーションの展開ツールとしてよく知られていますが、主にRailsアプリを対象とした集中型ではありません。 Webistranoは、GUIと説明責任でそれを強化し、PHP展開の基本サポートを追加します（「純粋なファイル」プロジェクトタイプを使用します）。

Webistranoは、それ自体がRuby on Railsアプリであり、開発またはステージングサーバーにインストールします。 Webサイトごとにプロジェクトを追加します。各プロジェクトに、ProdやDevなどのステージを追加します。

各ステージには、デプロイするサーバーと設定が異なる場合があります。「レシピ」を作成（または変更）します。これは、カピストラーノに何をすべきかを伝えるルビースクリプトです。この場合、提供されたレシピを使用し、共有アップロードディレクトリへのシンボリックリンクを作成するコマンドを追加しました。あなたが言ったように。

[展開]をクリックすると、WebistranoはリモートサーバーにSSHで接続し、コードのsvnチェックアウト、およびデータベースの移行、以前のバージョンのシンボリックリンクまたはクリーンアップなどの必要なタスクを実行します。もちろん、これはすべて微調整することができます。結局のところ、単にスクリプト化されているだけです。

非常に満足していますが、特にRubyとRailsに慣れていなかったため、学習とセットアップに数日かかりました。それでも、非常に信頼性が高く、柔軟であることが実証されており、初期投資を何倍も節約できたため、中小企業での本番使用に強くお勧めできます。展開を高速化するだけでなく、ミスや事故を減らすこともできます。

この種のものは、「継続的統合」と呼ばれるものです。 Atlassian Bamboo（費用）、Sun Hudson（無料）、Cruise Control（無料）はすべて人気のあるオプションで（私の好みの順に）、PHPUnit出力の処理をサポートしています（PHPUnitはJUnit出力をサポートしているため）。

展開は、ビルド後トリガーで実行できます。このスレッドの他の人たちと同じように、チェックイン（およびテストの合格）で自動展開を行う前に、細心の注意を払っています。

フレディストラノを確認してください、それはカピストラーノのクローンですうまく動作します（インストールは少し混乱しますが、結局はうまく動作します）

http://code.google.com/p/fredistrano/

アップロードを処理するための古典的な解決策は、実際のディレクトリをメインWebスペースから移動し、新しいバージョンのみをチェックアウトするようにして（以下のスクリプトで行うように）、Apacheを使用して「エイリアス」にすることですウェブサイトの一部として元に戻します。

Alias /uploads /home/user/uploads/

サーバーをあまり制御できない場合は、選択肢が少なくなります。

特定のスクリプトをdev / liveサイトにデプロイするために使用するスクリプトがあります（両方とも同じサーバーで実行されます）。

#!/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は、専用の画像サーバーにシンボリックリンクされているため、画像のアクセス許可もOKです。

最後に起こることは、古いシンボリックリンク... / 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キャッシュは、サイトのいくつかのバージョンよりも好きではありません）。しかし、私にとっては、これは私自身の展開にとって非常に問題がないことがわかりました。

3年後、展開のベストプラクティスについて少し学びました。現在、セットアップと使用が簡単で、多くのデフォルトをうまく処理できるため、Capistranoというツールを使用しています。

自動展開プロセスの基本は次のようになります。

コードの生産準備が整っているため、リリースのバージョンv1.0.0でタグ付けされています
すでに展開スクリプトを構成していると仮定して、作成したタグを指定してスクリプトを実行します。

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

スクリプトは、現在の日時でリリースディレクトリに新しいディレクトリを作成します。そのディレクトリ内で、コードは指定したタグに更新されます。
次に、元のシンボリックリンクが削除され、最新のリリースを指す新しいシンボリックリンクが作成されます。

リリース間で保持する必要があるものは共有ディレクトリに格納され、これらの共有ディレクトリへのシンボリックリンクが作成されます。

アプリケーションとテストの堅牢性に依存します。

私が作業する場所はすべて、レビューのためにリポジトリにチェックインされ、リリースされます。

他の開発者が新しいバージョンを取得してそこに変更をマージできるようにチェックインするだけなので、リポジトリからの自動更新は賢明ではありません。

あなたが話していることを行うには、プライマリチェックインエリアでの開発者間のコラボレーションを可能にするために、何らかのセカンダリチェックインとアウトが必要になります。私はそれについて、またはそれが可能かどうかについては何も知りませんが。

また、処理が必要となるブランチやその他の同様の機能に関する問題もあります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow