2

職場では、SCM なしから Mercurial に移行しています。少し習得に時間がかかりますが、2 日間いじった後は、より快適に操作できるようになりました。

とはいえ、まだ未解決の大きな疑問が 1 つあります。コードが完成したら、実際の展開をどのように処理すればよいのでしょうか?

Mercurial のコピーを本番 (ライブ) サーバーで実行する必要がありますか? それとも、リポジトリから Web ディレクトリに同期するように rsync などを設定する必要がありますか? ここでのベストプラクティスは何ですか?

hg updateapache をレポに向けるだけの場合、別の安定していないブランチに注意している限り、これで問題ないと思いますか? それはまだ私には少し危険に思えます。特定のビルドにのみ切り替えるように強制する方法はありますか?

それとも、レポにApacheを向けるのはひどい考えであり、代わりに何か他のことをする必要がありますか?

関連するトピックとして、アップグレード スクリプト (MySQL のスキーマ変更など) をバージョン管理下に置いて、バージョンがデプロイされたときに実行できるようにするという話も耳にしました。しかし、それがワークフローの一部としてどのように機能するのでしょうか? これは一時的な 1 回限りのスクリプトなので、他のすべてのものと一緒に保持したくありません...

皆さんのアドバイスに感謝します。

4

2 に答える 2

1

私は最近hg archiveコマンドを発見したので、代わりにこれで行くと思います。「プロダクション」ブランチの先頭に変更し、それを所定の宛先にアーカイブするbashスクリプトを作成しました。うまくいくようです。

これが良いアイデアかどうかについて、皆さんからのフィードバックをお待ちしております。

于 2012-07-12T19:24:37.930 に答える
0

apache をレポに向けるのは間違いなく悪い考えだと思います。開発ファイルのスナップショットを取得するだけであれば、hg アーカイブは問題ありません。

通常、開発ソース ファイルとデプロイされたアプリケーション (コンパイルを必要としない Web アプリの場合でも) は大きく異なり、後者は前者のサブセットから派生したものです。

私はシェル スクリプトや Makefile を使用して、開発ディレクトリのサブディレクトリにデプロイされたアプリケーションを "ビルド" する傾向があります。これには、ディレクトリ ツリーを作成して必要なファイルをコピーするだけの場合や、スクリプトの圧縮などが含まれる場合があります。

このようにして、デプロイされたバージョンにファイルを含めるかどうかを意識的に決定する必要があります。これにより、セキュリティ リスクを引き起こす可能性のある開発ユーティリティ ファイルをオンライン アプリケーションに誤って残すことを防ぐことができます。

Mercurial が果たす唯一の部分は、メジャー リリース用に新しい名前付きブランチ (例: 1.5) を作成し、開発はデフォルト ブランチで続行することです。その後のバグ修正またはパッチは、必要に応じてリリース ブランチに移植できます。バグ修正リリースが作成された場合は、リリース ブランチに新しいバージョン (例: 1.5.1) のタグを付けます。

于 2012-07-13T05:06:39.020 に答える