3

コンピューターと ssh を使用する Web サーバーに Web アプリがあります。問題は、自分のコンピューターでローカルにアプリを開発していて、ftp 経由でファイルをコピーするのではなく、サーバーと同期したいことです。他に方法はありますか？ギット？

4

5 に答える 5

8

どの OS や言語が関与しているかを特定しないため、特定するのが難しくなります。

Git (および SVN や Mercurial など) はバージョン管理に最適ですが、システムの同期を維持するにはバージョン管理以上のものが必要になることがよくあります。あなたが Python タイプの人なら、Tools of the Modern Python Hacker: Virtualenv, Fabric and Pipを読むのが楽しいかもしれません。これは、コードだけでなく、環境全体を同期させることについて語っています。

2 つのシステムのファイルを単純に同期させるには、rsyncをお勧めします。私はこれをあらゆる種類のタスクに使用しています。単一のマシン上でも、マシン間でディレクトリをバックアップ/同期する場合でもです。SoCal には、5 テラバイトを超えるデータの 3 レベルのバックアップ戦略 (オンサイトに 2 つ、オフサイトに 1 つ) を行っている顧客がいます。その中心は rsync とrsnapshotです。

コメントの更新:

サイトがどのように記述されているかは問題ではありませんが、すべての変更が本番環境に反映されていることを確認する必要があります。多くの場合、これは複数のステップからなるプロセスです。Fabric は、これらの手順をカプセル化し、単一のコマンドに減らすように特別に設計されています。Pip と virtualenv は、追加のライブラリの変更などをキャプチャする点でより Python 固有ですが、Ruby/Rails にはおそらく同等のものがあります。目標は、開発からステージングに移行するために必要なすべてを 1 つのコマンドで実行し、ステージングから本番環境に移行するために別の 1 つのコマンドを使用することです。

注意:開発マシンから本番ディレクトリに直接自動同期しないでください。必ず、最初に本番マシンの中間ステージング ディレクトリに移動してください。2 つのマシンが 100% 同一の環境を持っているわけではなく、dev で機能するものが実稼働マシンではまったく機能しない可能性があることはほぼ確実です。実稼働サイト全体で 500 エラーが発生するよりも、ステージングでのテストに余分に 1 ～ 2 分かかる方がよいでしょう。

于 2009-12-20T19:17:53.887 に答える
3

開発ビルドと本番ビルドの両方で、ソースコードリポジトリからの自動ビルドが必要です。

また、開発環境と本番環境にデプロイするための自動スクリプトも必要です。

次に、本番環境にデプロイするには、開発コードをチェックインし、ビルドスクリプトを実行してから、本番環境のデプロイスクリプトを実行するだけです。

これは、使用しているソフトウェア/環境/ツールに関係なく当てはまります。

于 2009-12-20T19:53:45.630 に答える
3

通常git、開発環境用に保持することを期待しています。

tar.gzビルドは、ビルド対象のタグを指定することにより (ビルドが監査され、繰り返し可能になるように)展開可能なもの (おそらく . ) を構築し、それをssh/を使用してサーバーにコピーしますscp。

開発環境から同期するだけではありません。開発中のもの、実験中のもの、サポートするツールやファイルなどにそれが必要です.

于 2009-12-20T19:15:48.297 に答える
2

特に Rails アプリケーションをデプロイするために最初に構築されたCapistranoは、その後、あらゆる種類の Web アプリケーションをデプロイできるように拡張されました ( rails-less deploymentと呼ばれます)。

設定が完了すると、ワークフローは次のようになります。

  1. プログラムのソースを編集します。
  2. 変更をチェックインし、中央リポジトリ (git/mercurial/svn/whatever) にプッシュします。
  3. プログラムで実行cap deployします。

ステップ 3 で魔法が起こります。これが Capistrano の目的です。Capistrano はリポジトリからコードの新しいコピーをチェックアウトし、そのコードを新しい「リリース」ディレクトリ (タイムスタンプのような名前) にコピーし、最後にそのディレクトリを最新のコピー20091028230834にリンクします。current移行が存在する場合は、途中で移行を実行することがあります。次のようなディレクトリ設定が残っています。

...deploy-to-path/current  ->  ./releases/20091028230834
...deploy-to-path/releases/
    20091028230834/
    20091028225623/
    ...    # You can configure the number of releases kept after deployment.
...deploy-to-path/shared/
    cached-copy/  # A cached copy of your repository, which Capistrano updates
    ...           # Any shared data, like file uploads, for your application.

Capistrano のドキュメントは良くありません。彼らは本当に誰かが来て、それをまとめて書く必要があります. ただし、基本的にはdeploy.rb、次の情報を含むファイル ( ) を作成しています。

  • サーバーはどこですか？(例: www.example.com)
  • あなたのssh資格情報は何ですか? （利用者パスワード）
  • コードはどこに保存されていますか? (リポジトリの URL)
  • サーバー上のどこにコードが必要ですか?

capify開始するには、アプリケーションで実行し (既定のファイルを用意)、テスト サーバー (またはサーバー上のテスト ディレクトリ) で実行して、その動作を確認することをお勧めします。何かをデプロイしたら、それをカスタマイズして、追加の移動/シンボリックリンクを実行できます。

于 2009-12-20T19:47:06.007 に答える
0

また、どのようにリリースしたいかについても検討する必要があります...変更を継続的に本番環境にプッシュすると、問題が発生したときに追跡するのが非常に難しくなる可能性があります。

他の人が言及したように、git を使用して同期してコードを管理できます。準備ができていると思われる新しい変更セットがある場合、それらをブランチに入れるか、少なくともタグを付けて、どの変更セットが一緒に出されたかを知ることができます。

次に、これらの変更をステージング ディレクトリに同期し、シンがそこで検証されたらスイッチを切り替えることができます。

于 2009-12-21T03:13:42.703 に答える