4

運用サーバー上に約 15,000 個のファイルを含む Web サイトがあります。現在、リモートの開発者がサイトで大部分の作業を行っていますが、編集も必要になる場合があります。バージョン管理が必要なのは明らかなので、git をセットアップしようとしています。

セットアップをシンプルかつ簡単に保ちたいと思います。変更を確認するためのインテグレータは必要ありません。両方とも、変更を本番サイトにプッシュすることについて完全に信頼されています。また、変更をライブにする前にステージング サーバーにプッシュする必要もないと思います。ローカル マシンでテストできないものはステージング サーバーでテストできないからです。私は基本的に、お互いのファイルを壊さないようにする何かが欲しいだけです。これが私が念頭に置いているシナリオです：

          Production Server
              ↗↙ ↖↘          
Developer1(LAMP)  Developer2(WAMP)

質問:

  1. このワークフローは 2 人の開発者のチーム (そのうちの 1 人は不定期にしか編集しない) にとって理にかなっていますか、それとももっと良いワークフローがありますか?

  2. 開発者と実動サーバーの間にステージング・サーバーを追加する利点はありますか?

  3. 運用サーバーは、webroot フォルダーを指す post-receive フックを備えたベア リポジトリである必要があり、各開発者のマシンにコピーを複製してから、git commit / git push を実行して変更を運用に戻す必要があると思いますか?

  4. 運用サーバー上にベア リポジトリを作成し、サイトの既存の 15,000 ファイルを追加する簡単な方法はありますか? それとも、ローカル ワークステーションのクローン リポジトリにダウンロードしてから、git add / commit / push を実行して本番サーバー リポジトリにロードする必要がありますか? (アップロードには約 13 時間かかる場合があります。)

ありがとう！

4

1 に答える 1

3

ワークフロー自体に問題はありません。ただし、通常、「正規の」リポジトリは別のものであり、rsync などの他のメカニズムを使用して手動で本番サーバーにデプロイします。こちらです：

  1. 運用サーバーの更新は、開発ワークフローに関連付けられていません。コードの変更後に実稼働サーバーで何らかの作業 (Web サーバーの再起動、キャッシュのフラッシュ、スキーマの変更など) が必要な場合、突然、実稼働システムの問題がコードを更新する能力を妨げてしまいます。

  2. .git誤ってディレクトリへのアクセスが漏洩して、すべてのソース コードと開発履歴が公開されることを心配する必要はありません。

  3. サイトを破壊するには、たった 1 回 (ルイン マスター) ではなく 2 回 (ルイン マスターとデプロイ) のアクシデントが必要です。

  4. 2 人だけの問題ではないかもしれませんが、「サイトを更新する」ボタンに「コードを更新する」ボタンとは異なる権限を持たせると便利です。

ステージング サーバーは、本番環境と同様に存在しますが、壊れやすいものです。開発者は 2 人しかいませんが、すでにまったく異なるオペレーティング システムを使用しています。少なくとも1 人は、本番環境と同じ開発環境を使用していないと確信しています。:)

いいえ、裸のリポジトリにファイルを追加することはできません。作業ツリーで何かを行うには、作業コピーが必要です。

于 2013-01-24T07:34:30.153 に答える