3

次の問題に出くわしましたが、まともな解決策がわかりません。さまざまなクライアント向けに PHP で Web サイトを作成しています。すべてのクライアントと同様に、修正が必要なバグを見つける人もいれば、数か月後にライブ サイトの更新を要求する人もいれば、両方を行う人もいます。

クライアントの更新に取り組むときは、公開する前にクライアントにプレビューするのが好きです.

過去にいくつかの異なるソリューションを使用しましたが、満足できるものはありませんでした。私がこれまでに行ったこと：

  • インデックスにVERSIONs とを定義します。CURRENT_VERSION訪問者には、承認されたバージョンが表示されます。$_SESSION変数を設定する特定のリンクをクライアントに送信すると、クライアントは新しいバージョンを確認できます。コードでは、if とスイッチを使用して、に応じて新しいものを表示しCURRENT_VERSIONます。これは機能し、すべてのコードを 1 か所に保持し、バグ修正を容易にしますが、愚かなif(CURRENT_VERSION >= V2)ステートメントでコードをなぞります。これもCSSファイルでは使用できません。
  • すべてのファイルを「build1」フォルダーに入れます。プレビューが必要な大きな更新を開始するときは、すべてを「build2」フォルダーにコピーします。クライアント用の「build2」フォルダーをアップロードし、パスワードで保護します。これはうまく機能しますが、ビルド 2 の作業中にビルド 1 のバグを修正する必要がある場合は、修正をビルド 1 からビルド 2 にコピーする必要があります。
  • 開発サーバーを使用します (一部のクライアントはこれを提供できます)。これは、開発サーバーがライブ サイトから分離されているため、これまでのところ最適に機能します。これは、プロジェクトのコピーを作成する必要がある 2 番目の解決策とほとんど同じように機能しますが、私にはよりクリーンに感じられます。

ただし、おそらくGit/SVNを使用して、コードを管理するためのより良い方法を探していますが、これらが私を助けることができるかどうかについて十分に知りません.

4

2 に答える 2

1

最近のかなり典型的なパラダイムは、開発/ステージング/生産です。このアプローチでも開発サーバー全体は必要ありません。VirtualHosts/nginxと同等のもので十分です。

最初に行う必要があるのは、プロジェクトをGitに取り込むことです。これは、早いほど良いことです。

免責事項：これは私のワークフローです。これに似たものはたくさんありますが、これは私のものです。

これが私の現在のワークフローの例です。

GitHub

私が引き受けたプロジェクトごとに個別のリポジトリ

開発サーバー

ベアGitリポジトリ、GitHubを複製（これについては後で説明します）

/opt/git-bare

私のすべてのプロジェクトのVirtualHosts

/var/www/vhosts

ローカルマシン

必要に応じて、素早い編集とコミットのためにベアリポジトリのクローンを作成します。ファイルを前後にFTPで転送したり、マシンにローカルで何かをマウントしたりする必要はありません。これがプロジェクトに取り組むための最良の方法だと思います。開発サーバーでコードをチェックアウトする準備ができたら、作業をコミットしてベアリポジトリにプッシュします。ここに、開発VirtualHostに更新するように指示するポストフックがあります。

これは、ローカルマシンから作業をコミット/プッシュしてから数秒以内に、ブラウザを介して開発サーバーで作業を確認できることを意味します。

開発サーバーで見たものに満足したら、ベアリポジトリをGitHubにプッシュします。Gitは素晴らしいツールであり、私のローカルコミットはすべてGitHubのログ内でも利用できます。

演出

これは、GitHubのマスターブランチのGitHubからのクローンです。これは、クライアントに表示し、変更をサインオフするために使用するものです。

製造

私の本番サーバーはGitHubのタグのクローンです。マスターブランチ内で何をしても、本番環境に影響が及ぶことはなく、サーバーの1つで問題が発生した場合でも、このタグを簡単に再構築できます。

これについて質問がある場合は、ただ発砲してください。

于 2012-11-30T15:56:18.310 に答える
0

私の長い答えの前に：あなたのためにこれを行うようなホストを探しているなら、スタッカブルは複数の「環境」の概念をサポートしています。他のホスティング プラットフォームも、本質的に同じことを可能にする同様の機能を提供していると確信しています ( AWS Elastic Beanstalkなど)。注: 私は stackable とは何の関係もありません。私は顧客でもありません。

インデックスで VERSION と CURRENT_VERSION を定義します...しかし、ばかげた if(CURRENT_VERSION >= V2) ステートメントでコードをなぞります。これもCSSファイルでは使用できません。

私の記憶が正しければ、これは実際、Facebook が変更を展開する方法に似ています。その通りです。追加のロジックが追加されます。ただし、複数のユーザー (たとえば、管理者であるすべてのユーザー、または特定の地理的な場所にいるすべてのユーザー) に対して変更を「プレビュー」できるという利点があります。

そしてもちろん、プレビューでも同じデータが使用されます。つまり、サイトをプレビューしているユーザーは、(不自然なデータとの奇妙な相互作用ではなく) 通常のようにサイトを使用することになります。

欠点についてはあなたの言うとおりですが、これが新しい機能をテストするのに役立つ方法である場合があります。

プレビューが必要な大きな更新を開始するときは、すべてのファイルを「build1」フォルダーに入れます...ただし、build2 の作業中に build1 をバグ修正する必要がある場合は、build1 から build2 に修正をコピーする必要があります。

ここでは、基本的にプロジェクトの 2 つのバージョンを同じサーバーにデプロイしています。あなたが与える例では、2番目のコピーを元のWebルートの下に置いていますが、ホスティングによっては、サブドメインを割り当てて2つの異なるWebルートから作業することができます.

両方のインストールで同じデータを簡単に共有でき、すべてのリクエストがなんらかのフロント コントローラーを通過する場合、選択したユーザーの変更のみを表示するロジックを追加できます (または、何らかの基本認証を使用して、説明）。

この場合、プロジェクトをバージョン管理に入れることで (私が見ているように、これには SVG よりも git の方が優れているでしょう)、これがはるかに簡単になります。開発システムでは、ブランチを切り替えるだけで、既存のバージョンと新しいバージョンの間で機能します。

古いバージョンのバグを修正した場合、いくつかのコマンドを使用して、その修正を新しいバージョンに簡単に (または現在のワークフローよりも簡単に) マージできるはずです。古いバージョンにもあったバグを新しいバージョンで修正した場合、cherry-pick を実行すると、その 1 つの変更を古いバージョンにマージすることができます。

コードのデプロイは、Web サーバーにログインして git pull を実行するのと同じくらい基本的なものにすることも、ツールを使用してデプロイを自動化することもできます。基本的に、古いバージョンのデプロイはリポジトリの「マスター」ブランチ (またはそれに類似したもの) に基づいており、新しいバージョンはそのブランチと呼ばれるものに基づいています。

開発サーバーを使用します (一部のクライアントはこれを提供できます)。これは、開発サーバーがライブ サイトから分離されているため、これまでのところ最適に機能します。これは、プロジェクトのコピーを作成する必要がある 2 番目の解決策とほとんど同じように機能しますが、私にはよりクリーンに感じられます。

これは 2 番目の方法と非常に似ているため、バージョン管理を追加すると、これも簡単になります。

さまざまなバージョン管理システムからさまざまなホスティング プラットフォームに展開する方法を説明するリソースはたくさんありますが、うまくいけば、これは、それがあなたがすでに行っていることにどのように適合し、物事をより簡単にするかを示しています.

于 2012-11-30T16:09:26.600 に答える