5

次の要件を備えた専門的な開発セットアップがどのように見えるかについて、いくつかの意見が欲しいです。

  • 数人の PHP 開発者 (PHP など)
  • 各開発者は 1 つのグループに属します
  • 各グループには、タスクを委任するチーム リーダーが 1 人います。
  • 各開発者は 1 台の Windows 7 マシンで作業します
  • NetBeans または Eclipse で開発
  • 各開発者は、コードを実行できる 1 つの仮想テスト サーバーを「所有」します。
  • 使用中の VCS は SVN です
  • 製品がリリース/デプロイされる前に最終的にテストされるステージング サーバーがあります。

抽象的になりすぎないように特定のテクノロジーをいくつか挙げました。また、プラグインなどの具体的な提案にも興味があります。

そのセットアップで私の頭に浮かぶいくつかの質問があります。

1) したがって、すべての開発者は個人のブランチで作業します。

2) このブランチは作業コピーでチェックアウトされます。

今...この作業コピーは、開発者のIDEを使用してPC上でローカルに編集され、サーバー上で実行/テストされます。

その場合、それを行う最善の/通常の方法は何でしょうか? つまり、オーバーヘッドをあまり発生させずに、編集したコードをサーバーに取得するにはどうすればよいでしょうか?

開発者は自分のローカル ディスクにコードを持っているでしょうか? それとも、トンネルまたは特定のプロトコルを介してリモート仮想サーバーに IDE で書き込みを行う方がよいでしょうか?

3) 開発者は毎日、中央リポジトリにある自分の個人用ブランチに自分の作業をコミットします。

リポジトリの配置場所に関するベスト プラクティスはありますか? 別サーバー？

4) 次に、開発者がタスクを完了した後、開発者またはチームリーダーが新しいコードをそれぞれのメインブランチまたはトランクにマージします。

一番ややこしいのは、2)と3)の間に書いたことについてです。これまでのところ、私はローカルサーバーでしか作業していませんでした. たとえば、共有フォルダーにあるコードを実行するサーバーを備えた VM を直接編集できるようにします。サーバーが実際にリモートになったときに、ギャップを効率的に埋める方法がわかりません。効率的とは、たとえば FTP 経由で手動でアップロードする必要がないことを意味します。

また、外部ソースや書籍の推奨事項も歓迎します。

編集

私の質問は、準標準/ベストプラクティスを目指しています。これはほとんど標準的な開発シナリオだと思うので、「通常の」解決策が必要です。

編集 2

わかりました...画像で試してみましょう： セットアップ

V は、1 人以上の開発者 D の仮想テスト サーバーです。C と C' は、2 つのコード バージョンです。それらは可能な限り同一に保つ必要があります。

2つの解決策が思い浮かびます：

1 : C を編集して C' にアップロードし、C' を実行してから C をコミットします。

2 : C は存在しません。いくつかのトンネル技術を介して編集され、実行され、コミットされたJust C'。

私の直感では、どちらのソリューションも準最適であると言えます。では、「プロフェッショナル」/最も効率的/最速/最も便利/最も摩擦が少ない/エラーが発生しにくい/ベストプラクティス/業界標準とは何でしょうか?

質問は？

4

4 に答える 4

3

あまり役に立たないかもしれませんが、GIT は問題にぴったりのように思えます。GIT の機能を確認することをお勧めします。時間があれば、Linus Torvalds が GIT について独り言を言っています。http://www.youtube.com/watch?v=4XpnKHJAok8

于 2011-04-08T14:25:40.187 に答える
2

私は個人の支店で働くのが好きではありません。私はClearCaseを15年近く使用しましたが、ClearCaseはおそらく個人の分岐をほとんどの場合よりもうまく処理しますが、それでも大きな苦痛でした。さらに悪いことに、個人の支店は、最後の最後まで、通常はメジャーリリースの1〜2日前まで仕事をコミットしないように人々に勧めています。

そのため、開発者が互いに順調に進むように、できるだけ1つのブランチ（またはトランク）で全員が協力することを強くお勧めします。私は開発者に、変更を加えるときに少しずつ噛むように言い続けています。

必要と思われるのは、展開を自動化する方法です。つまり、ローカルマシンで変更を加え、1つのコマンドで、サーバーにコードの複製コピーがあることを確認します。また、展開を効率的にする必要があります。2ギガバイトの10,000ファイル展開の単一の2キロバイトファイルを変更する場合、10,000ギガバイトではなく、その1つのファイルのみをコピーする必要があります。そのためには、Antでデプロイメントスクリプトを作成することをお勧めします。

開発者はファイルを変更し、Antスクリプトを介してそれらのファイルをデプロイできます。Antが自動的に処理するため、開発者は更新したファイルを覚えておく必要はありません。実際、Antはファイルを変更して、コピー時に適切な環境情報が含まれていることを確認することもできます。もちろん、サーバーでの設定がソースリポジトリでの設定と異なる場合、Antはファイルを再配置できます。また、NetbeansとEclipseはどちらも、IDEでAntスクリプトを実行できます。

それで：

  • 開発者にローカルマシンのコードを変更してもらいます。
  • Antスクリプトを実行して、サーバーとローカルマシンが同期していることを確認します。
  • サーバーでテストします。
  • 次に、サーバーでの結果に満足したら、変更をチェックインします。

誰かがJenkinsのような継続的ビルドシステムについて言及しました。それがこの特定の問題を解決しないとしても、それはとにかく実際には良い考えでしょう。Jenkinsは独自のサーバーとデータベースを持つことができます。次に、コードをコミットすると、Jenkinsはサーバーを更新し、自動テストを実行します。その後、Jenkinsはレポートを作成できます。それはすべてジェンキンのウェブページに表示されます。さらに、Jenkinsでデプロイをアーカイブできるため、誰かに「ビルド＃20」をテストするように指示すると、簡単に見つけられるJenkinsからデプロイを引き出すことができます。

于 2011-04-15T18:49:34.917 に答える
2

あなたが説明する標準的な手順は、多かれ少なかれ同じです。私はまた、私のチームにこのアプローチを適用します。段階的なアプリケーション開発とも言えます。

これが私がやっている方法です。リモート SVN ホスト (例: assembla.com、unfuddle.com) を使用して、すべてのコードを保存します。私のチーム メンバーは、これらのリモート svn サーバーに情報を保存します。VPS を購入してそこで SVN をセットアップし、同じアプローチを使用することもできます。

ベスト プラクティスは、ローカルでテストし、できる限り何度もコミットしてコミットすることですが、すべてのコミットで問題を解決するか、新しい機能を追加する重要なセグメントを含める必要があります。

全員によるコミットが完了すると、主任開発者は PuTTY などのツールを使用して SSH 経由でステージング サーバーにログインできます。最初に、主任開発者は、コードが配置されるフォルダーにコードをチェックアウトする必要があります。この段階で、複数の開発者がファイルの同じセグメントを編集すると、ファイルの競合が発生する可能性があります。主任開発者は、最初にコードを解決してから、チェックアウトに進む必要があります。チェックアウトが完了すると、主任開発者はステージング サーバーで svn update を実行してコードを最新の状態にするだけで済みます。

基本的な考え方は、コードをローカル セットアップで動作させてから、シミュレートされたシナリオでアプリケーションをテストするためにステージングをコミットおよび更新してから、ライブ サイトにコミットすることです。

多くの if と but がありますが、ここには章を書く必要があります :) が、要するにこれが熱意です。

ツール (この設定で作業するために使用できます): - Tortoise SVN Manager - PuTTy - NetBeans

それが役に立てば幸い ：）

于 2011-04-12T04:23:11.110 に答える
1

やり方は人それぞれだと思いますが、私の考えをまとめてみました。

「ベスト プラクティス」はおそらく「継続的統合」です。つまり、各開発者は独自のブランチを持たず、共通の開発ブランチにチェックインします。これにより、競合を処理し、早い段階で相互に調整する必要があり、多くの場合、主任開発者が後で大規模な列車事故のマージを管理することを回避できます。本当にそのルートに行きたい場合は、クルーズコントロールを見てください。

最善の方法は、ローカルの Apache Web サーバーと完全な php スタックがある場合です。Zend_Server コミュニティ エディションを使用すると、Windows をすばやく起動して実行できます。ほとんどの標準的な php コードは、Windows と Linux の両方で問題なく動作しますが、多くのファイル操作、cron ジョブ、cli などを実行している場合、または memecache が必要な場合などは、互換性の問題が発生します。その場合、Linux のみが問題になる場合は、VMWARE または VirtualBox を使用してローカルの Linux インスタンスを実行し、それらの中に IDE をインストールして、それに対処するための RAM が大量にあることを確認します。

各開発者は、Eclipse 内で syncronize (基本的には svn の更新) を実行し、その場で他の開発者との競合に対処し、ローカル テストを行い、変更をコミットする必要があります。

svn サーバーでpost_commit フックをセットアップし、Web サーバーで /autobuild.php を呼び出します。autobuild.php は svn update を実行し、最新のコード変更を取得するだけでなく、chown または chmod ファイルのアクセス許可を実行し、サーバー固有の構成ファイル config.php をリセットします。Apache ユーザーが svn update を実行できるように設定するのは少し難しいですが、一度実行すると、ベータ/テスト サーバーには常に最新のコミットされたコードが含まれます。CruseControl、および他のいくつかは、この種のことを実行したり、単体テストを追加したりするのにも役立ちます。

あなたの主任開発者は、開発ブランチを本番ブランチにマージし、開発サーバーでテストし、他の人のコミットを確認し、リリースをプッシュする方法と時期を決定する仕事をまだ持っていますが、あなたは負担をかけません。すべての競合を解決し、すべての変更をマージする彼。

開発者は、ファイルをftpingしたり、サーバーに ssh リモート処理したりするのではなく、IDEでローカルに作業し、svn (および電子メール、電話、チャットなど) を介して相互にやり取りして、新しいコードを取得し、作業が完了したらコミットします。

SVN を使用している開発者ごとに個別のブランチを用意しても、良い結果が得られるとは思えません。これらのブランチのマージは Git では機能するかもしれませんが、SVN を使用すると、リード開発者はそのタイプのセットアップですぐに生活を嫌うでしょう。

于 2011-04-13T21:43:28.923 に答える