サーバーにMercurialをインストールし、hg pullを展開することをお勧めしますか？

私はこの1か月間に新しい仕事に着手しましたが、コードのソース管理がないようです。彼らは、ホスティングプロバイダーがバックアップを使用していることに依存しています。

少し話した後、私は間違いなくソース管理を使うべきだと上司に確信させ、それについて短いセミナーを行った後、チーム全体が参加しています。彼らはMercurialが大好きでした。

だから今、これが私たちの仕事のやり方です：

º----------BitBucket
º---------/
º--------/

私自身とhg pullBitBucketの他の3人の開発者が変更を加えてから、BitBucketに変更hg pushを加えます。

展開のために、誰かが最新のファイルを実稼働サーバーにFTPで送信する必要があります。

サーバーにMercurialをインストールし、hg clone（その後hg pull）を使用して実稼働時にバージョンを最新に保つことを考えていました。

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

これはいいアイデアですか？目に見えない潜在的な落とし穴はありますか？ここで誰かが似たようなことをしましたか？大規模なPHPフレームワークアプリケーションをどのようにデプロイしますか（Moodleを使用しています）？

これは確かに良いアイデアであり、展開に使用する一般的な方法です。安定したブランチを実稼働環境にデプロイする前にテストできるように、継続的な開発のためにトランクを維持しながら、デプロイメント目的で安定したブランチを使用することができます。

唯一の問題は、サードパーティのサーバー（この場合はBitbucketの場合）にアップロードしたくない機密情報（APIキーなど）がコードベースにある場合に発生する可能性があります。この場合、適切な場所に機密データを復元するためにリポジトリからデータを取得した後に実行される単純なスクリプトは、その問題を解決します。

この展開戦略はアトミックではないことに注意してください。アプリケーションがヒットしている間、一部のファイルは既に更新されている一方で、他のファイルはまだ古い状態にある可能性があります。これにより、予期しない副作用が発生する可能性があります。

アトミック展開を行う方法は、シンボリックリンクを使用することです。新しいファイルを含むディレクトリを作成します。すべての準備ができたら、使用するディレクトリのシンボリックリンクを変更します。古いバージョンを保持している場合は、簡単にロールバックすることもできます。

別の（私の意見では）可能性：ビルドサーバー/継続的統合サーバーを使用します。

短い簡単な説明：これは、リポジトリを監視するために設定するサーバー（社内にあることができ、インターネット上にある必要はありません）であり、リポジトリに新しい変更セットがあるたびに、サーバーはコードを構築します（私の知る限り、これはPHPでは必要ありません）、ユニットテストを実行し、Webサーバーにコードをデプロイします。

詳細については、次のリンクを確認してください。

• CIに関するウィキペディアの記事
• スタックオーバーフローの質問：「ビルドサーバー」のポイントは何ですか？

CIにはさまざまな製品がありますが、これまで使用したのはTeamCityだけです。設定が非常に簡単です...実際、これは私が最初に試したもので、とても気に入ったので、それを使い続けました。

代替の安価なソリューション：

ビルドサーバーのセットアップに手間がかかる場合、またはサイトを正確に展開するタイミングをより詳細に制御したい場合は、スクリプトファイル（Windowsのバッチ/ Powershell、またはLinux / Macの類似物）を設定して、リポジトリから最新バージョンを取得し、本番サーバーでFTPします。

基本的には、ビルドサーバーと同じで、より単純です。

最終的にどれだけ正確に解決しても...どうにかしてそれを自動化してください！

ワンクリックで/単一のコマンドを入力することで展開できるようにしたいので、すべての人が特別なことを何も知らずに、ミスを犯さずに-災害やストレスの場合でもそれを行うことができます。

これ、またはこれに類似したことを行います。非アトミックな@johannesは角度が1つの問題であると述べていますが、現実的な用語では非常に高速に発生するので問題ありません。

この非原子性よりもおそらく重要なのは、「データベーススキーマの更新をどのように管理するか」です。この方法で不良コードをデプロイすると、修正が容易になります。大きな問題は、ロールバックするデータベースを変更する更新プログラムを展開する場合です。または、不適切な更新を行ってデータを破損している場合。

（SVNを使用するのとは対照的に）DCVSツールで発生した他の問題は、攻撃者が入手する可能性のあるマシン上のコードベース全体のコピーを手に入れたことです。また、そのDCVSコードベースはサイズ的にかなり重いことがあります。これは、ストレージやバックアップにお金を払う場合に問題になる可能性があります。これらの理由から、最終的な展開にはSVNを使用しています。

これは素晴らしいアイデアですが、次のことに留意してください。

• サーバーでコミットしないようにしてください（プラグインのインストールやコンテンツ資産の追加など、まれにこれを行うのが理にかなっていますが）
• テストにステージングサーバーまたはセカンダリリポジトリの展開を使用する
• hg update -C生産に影響を与えないように常に注意してください（つまり、重要なファイルを削除してください）
• 運用ブランチと開発ブランチがあり、運用ブランチのみを展開する
• アセットをバックアップ（コンテンツの画像など）として扱い、ユーザーデータ（添付ファイル/アップロード、キャッシュなど）を無視します
• hg statusサーバー上で常にクリーンな出力が得られます（これにより、キャッシュとしてのものを無視していることを確認できます）
• Webフォルダーにリポジトリーをデプロイしないでください。パブリックスペースの外部からのシンボリックリンクを使用します（例：ln -s / myrepo / src / web / public_html / myapp）
• 構成ファイルをバージョン管理しないように注意してください（特にデータベースパスワードなどを使用）
• 本番バックアップの代わりに使用しないでください、これは本番データではなく、本番コードの開発バックアップです

最後に、DVCSを展開プロセスに追加するための最も重要なことは、これにより展開にセキュリティが追加され、ハッカーが悪意のあるコードをユーザーに挿入することがあり、バージョン管理などの手段がなければ簡単にそれを検出する手段がないことです（ VCSへの分散された側面により、ファイルの整合性を簡単に確認できるため、特別に分散されています。

私は得ていくつかのサイトは、Mercurialは私が助けた、数回ハッキング持っていたlitterallyだけ発行することで、このハックを元に戻すhg update -C（もちろん、あなたがしたいかもしれませんサーバーでhg status、後の分析のために、影響を受けるファイルを取得します）。