3

これは、セキュリティに関する質問hereに多少関連しています。ライブ Web サイトに hg / mercurial リポジトリを使用するのは悪い考えですか? もしそうなら、なぜですか？

さらに、dev.example.com、test.example.com、www.example.com. ライブ/本番 Web サイトにリポジトリを使用するのが悪い考えである場合、開発およびテスト サイトに hg リポジトリを使用しても問題ありませんか?

導入のしやすさも気になります。サイトで作業する技術者と技術的でない同僚がいます。技術者 (ソフトウェア エンジニア) は、コマンド ラインまたは TortoiseHG で問題なく作業できます。あまり技術的でない人々 (Web デザイナー) の方が心配です。彼らはコマンドラインでの作業に慣れておらず、TortoiseHG が気が遠くなるかもしれません。これらの同僚は、主に.cssファイルと画像をサーバーにアップロードします。これらのファイル (少なくとも.cssファイル) をバージョン管理下に置きたいと思っていますが、技術チーム以外のメンバーに対して可能な限り透明性を確保したいと考えています。

これを達成するための最良の方法は何ですか？

編集: 私たちの「サイト」は、実際には、メイン リポジトリといくつかのサブリポジトリを備えたマルチサイト CMS セットアップです。リポジトリ構造のモックアップ:

/root [main repository containing core files and subrepositories]
    /modules [modules subrepository]
    /sites/global [subrepository for global .css and .php files]
    /sites/site1 [site1 subrepository]
    ...
    /sites/siteN [siteN subrepository]

ソフトウェア エンジニアは、リポジトリroot、modulesおよびsites/globalリポジトリで作業します。あまり技術的でない人 (Web デザイナー) はsite1...siteNサブリポジトリでのみ作業します。

4

4 に答える 4

4

はい、それは悪い考えです。

リポジトリを Web サイトとして使用しないでください。これは、チェックインされているが機能していないものがすぐに利用可能になることを意味します。そして、偶発的なチェックイン (たまたま) もライブで反映されることを意味します (つまり、そこに属さないドキュメントなど)。

ただし、実際には、この「概念」(展開としてのソース管理) に、私が作成したツールを使用して対処しています (他のいくつかの企業も現在このトピックに取り組んでいるので、後で詳しく説明します)。私のは（現時点では）SVN用であるため、特に関連性はありません。以前にこれを検討したことを示すためだけに言及します（ただし、リポジトリではありません。作業コピー、そのシナリオでは答えは同じです：バージョン管理されていない「無料」をWebサイトディレクトリとして持つ方が良いです。そのディレクトリへの「バージョン管理された」データのコピーを（ユーザーアクションを介して）自動化します）。

于 2010-03-02T08:29:50.243 に答える
4

多くの人が自分のサイトをリポジトリに保管していますが、ライブ サイトをライブ編集している人がいなければ問題ありません。非リビジョン管理者が変更を行うステージング/開発領域を用意し、RCS に適した人に定期的にコミット、プル、マージ、プッシュのサイクルを実行してもらいます。

staging-area -> production-repo push を行う審査員の意識的な行動である限り、問題ありません。本番クローン内の作業ディレクトリの「hg update」を自動的に実行するフックを本番クローンに配置することもできるため、「プッシュ」だけでデプロイできます。

そうは言っても、あなたは Web チームまたは tortoiseHg を過小評価していると思います。彼らはこれを得ることができます。

于 2010-03-02T14:55:54.687 に答える
2

私は個人的に (私は 1 人のチームです)、ライブ Web サイトとして src コントロールを使用するというアイデアが非常に気に入っています。hg、svn の場合はなおさらです。

私の見方では、単一のコマンドでサイト全体をロード（ファイルの追加/削除）することができます。

apache (おそらく iis も) を使用している場合は、すべての .hg ファイル (svn を使用している場合は .svn) をブロックする単純な .htaccess ファイルを作成できます。

私の好みの構造は、開発サイトがリポジトリから直接実行されているローカル マシン上にあることです (ここではセキュリティは実際には必要ありません。必要に応じて好きなことをコミットしてください)。

ステージング/テスト マシンは、ライブ データベースの最新のコピーを実行する別のボックスまたは VM です (コミットされた変更をステージング サーバーにプッシュしてテストを実行するスクリプトがあります)。

ライブ マシン (ssh 接続を開き、変更をライブ サーバーにプッシュし、再度テストします。すべてのスクリプトはかなり簡単に記述できます。例としては Google を使用)

hg のプッシュ/プルの性質により、壊れたビルドをライブ Web サイトにプッシュする危険を冒さずに、変更をコミットしてテストできることを意味します。あなたがコメントで言っているように、特定の人だけがライブ サイトにバージョンをプッシュする権限を持つべきです。(失敗した場合は、src コントロールを介して以前のバージョンに簡単に戻すことができるはずです)

于 2010-04-12T07:49:16.743 に答える
0

リポジトリをアクティブな Web サーバー (とにかく開発またはテスト/QA 環境用) にしないのはなぜですか?

これが私が実装しようとしているものです：

  • 開発者には、コードをビルドおよびテストできるローカル テスト環境があります。
  • 開発者は、ローカルの開発マシンで開発環境のクローンを作成します
  • 開発者はローカル リポジトリに好きなだけコミットします
  • 作業のチャンクが完了してテストされると、開発者は作業中の変更セットを開発リポジトリにプッシュします

変更は Dev でマージおよびテストされ、次に Test/QA にプッシュされます。

ところで、Mercurial を使用しています。このモデルは、分散ソース コード管理ツールを使用した場合にのみ機能すると思います。

于 2010-12-10T16:55:45.150 に答える