1

バージョン管理システムを決定しました - Mercurial クライアントと Bitbucket をリポジトリに使用します。しかし、考えもしなかった問題があることに気がつきました。

内部開発用の LAMP サーバー (Ubuntu) があり、すべての開発者がそこに保存されている Web サイトで作業しています。つまり、すべての開発者が単一のファイル ソースを共有し、それを基に作業しています。2 人の異なる開発者が同じサイトで同時に作業することはめったにありませんが、ときどき発生します。これは、2 人の開発者が同じファイルで同時に作業している場合、互いの作業を簡単に上書きできることを意味します。

私の質問は次のとおりです。この問題の最善の解決策は何ですか? 内部でサイトをデモできるように単一の内部サーバーの利便性が気に入っており、ファイルとデータベースをバックアップするための cron ジョブも実行されています。

各開発者は、個々のワークステーションで独自の LAMP (または WAMP) サーバーを実行し、コミットして、bitbucket リポジトリにプッシュする必要があると思います。もちろん、別のサイトで作業するときはいつでも、プルを実行して、通常どおり相違点を解決してください。これはもちろん、他のチーム メンバー (非開発者) が 192.168.0.100 (LAMP サーバーの IP アドレス) を参照して Web サイトの進行状況を確認できる利便性を奪います。言うまでもなく、一部のクライアントも同じサーバーにアクセスできます。外部から（ポート転送を設定し、IPアドレスに制限しました）、Webサイトの進行状況も確認します.

どんなアドバイスでも大歓迎です。

前もって感謝します。

4

2 に答える 2

1

LAMP-per-dev は、サイトをその場で編集するよりもわずかに優れているだけなので、使用するワークフローについて真剣に再考する必要があると思います

  • 本格的な企業開発において Bitbucket の居場所が見当たらない - 社内リソースは少なくともより管理しやすい
  • Staging Mercurial-server (pseudo-central) を Staging internal LAMP-server (現在使用している) と一緒に使用しない理由がわかりません

少なくとも 2 つの可能な選択肢 (高速、ダーティ、ドラフト アイデア、すぐに使用できるソリューションではない) を想像できます。どちらもフックベースです。

管理が難しく、実装が速い

すべての開発者は独自のローカル リポジトリ フックを持っており、(それぞれ?) コミット後に彼のヒントをエクスポートし、コピーを関連するサイト スペースにエクスポートします。ワークフロー: コミット - 内部サイトで結果をテスト

利点：実装が簡単、迅速

短所: 他の開発者のコ​​ードによるテスト済みコードの上書きを (分散型の性質により) 防ぐことはできません。

管理しやすい展開、実装と管理が難しい

LAMP サーバーは Mercurial サーバーにもなり、すべてのサイト リポジトリの「中央」クローンをホストし、開発者のローカル リポジトリからのみプッシュによって更新されます。このサーバー上の各レポは、2 つのフックを取得する必要があります。

  • 「プッシュ前」チェック、今すぐプッシュが許可されているか、以前の開発者によってサイトが「ロック」されているか
  • 受信したデータをエクスポートコピーし、フック1の制御機能も実行する「ポストプッシュ」：条件に基づいて（議論の対象）リポジトリへのプッシュのロック/ロック解除

ワークフロー: コミット - プッシュ - テスト結果 - 特別な (移動された) タグで WC にタグを付ける - タグをコミットする - アンロック変更セットをレポにプッシュする

利点: 管理しやすいシングルポイント テスト

短所: プッシュワークフローとプッシュのブロックによる遅延の可能性。追加のサーバーをインストール、構成、サポートする必要があります。changegroup および pretxnchangegroup フックの複雑さ

解決策 2 の最終的な注意事項とヒント: (テストされていません) 、特別なタグ (チェンジセット間を移動するための -f 付き) をロック解除記号として使用できると思います (ブックマークは「手で移動」という条件を満たさないでしょう) 。つまり、開発者はタグの付いていない変更セットをコミット (およびプッシュ) し、タグ (fe) "Passed" は古い変更セットをマークします。ステージング サーバーでのテスト結果が完了したら、開発者は上記のタグで WC をタグ付けし、タグをコミットして中央リポジトリにプッシュします。changegroup フックは、.hgtag のプッシュを検出し、(何らかの方法で) 将来のデータ プッシュを許可する必要があります (コントロール プッシュは常に許可する必要があります)。

于 2012-11-27T03:29:56.460 に答える
0

はい、おそらくより良い解決策は、各開発者にローカル サーバーを設定することです。サーバーの共有に慣れているように見えるため、不便に思えるかもしれませんが、次のことを考慮してください。

  1. 単一のサーバーをデモ サーバーとして使用することに本当に関心がある場合は、その時点で開発に積極的に取り組んでいない方がよいでしょう。彼らはそのように物を壊すことができました！また、開発者は、開発中に何かを壊すことを心配する必要はありません。開発とは、多くの場合、実験を意味します。
  2. 各開発者が独自のサーバーを実行することで、たとえばオフラインで作業する柔軟性が得られます。分散バージョン管理システム (mercurial) を使用していますが、開発プロセスは高度に集中化されています。人々がリモートで作業することを望んでいない場合でも、単一のサーバーがダウンすると、全員がダウンすることを認識してください。
  3. 開発者がそれらのコミットをコミットしてプッシュするたびに、デモ サイトへのデプロイを直接自動化できます。そうすれば、デモ サーバー上に最新のソースがまだ残っています。

TL;DR: デモ サーバーはそのままにしておきますが、開発者は各自のサーバーで作業してください。

于 2012-11-27T01:38:15.093 に答える