集中開発サーバーではなく、ローカル マシンで Web 開発を行うことの長所と短所は何ですか? ローカル マシンで開発を行う場合、複数の開発者が関与している場合、ローカル開発用に更新されたデータベース アーキテクチャを維持するにはどうすればよいでしょうか?
特に、私は現在 XAMPP for PHP を試していて、他の開発者がデータ/データベース構造を定期的に変更しているときに、ローカル マシン上の MySQL DB インスタンスをどのように同期させているのか知りたいと思っていました。
ローカル開発は、単独で作業する場合にのみ実用的ですか?
誰もが開発に使用する 1 つの中央サーバーを好む人がたくさんいるようです。変更を加える人が開発プロセスを中断できる共有環境にいることを好む理由がよくわかりません。
私のショップでは、誰もが独自の開発 Web サーバーと独自の開発データベースを持っています (多くの場合、同じデータベースサーバー上に配置されていますが、独自のデータベースです)。そうすれば、他の開発者から完全に隔離され、互いに干渉することはありません。
機能を実装したり、バグを修正したりするときは、コードと一致するデータベース スキーマをチェックインして、他の開発者が完全なユニットとして利用できるようにします。テスト サーバーまたは展開サーバーへのリリースは、ソース コード リポジトリ内のラベル付きバージョンから行われます。
安定して元気！開発サーバーが無料であるのに、他の方法でそれを行う理由がわかりません!
他の開発者による変更が自分の変更に干渉しないようにするために、開発中に完全に制御できるローカル セットアップを用意するのが最善だと思います。開発環境とテスト環境をローカルにセットアップしているので、他の開発者を考慮する必要なく両方のタスクを実行できます。autotest を使用してコーディングしながらテストを継続的に実行します。つまり、コードが正しく、正しい仕様を満たしていることを確認できます。
コード ベースが整ったら、ステージング サーバー (本番環境にできるだけ近い環境) にデプロイし、テストを再実行します。また、ステージを使用して負荷テストを実行し、ユーザー テストを実行します。
他の人が編集しているときにDBを「同期」しておく限り。これを回避する 1 つの方法は、DB スキーマをバージョン管理下に置くことです。これは、ソース コードをバージョン管理下に置くほど単純ではなく、さまざまな処理方法があります。
コーディングホラーに関するこの記事を読んでください:
https://blog.codinghorror.com/get-your-database-under-version-control/
投稿そのものではなく、彼がリンクしている K. Scott Allen の 6 つの記事です。
基本的に、これらの記事で説明されているのは、データベース スキーマのベースラインを作成し、そのベースラインの .sql ファイルをチェックインし、そこから、スキーマを変更するたびにインクリメンタルな .sql "変更スクリプト" を記述する方法です。これで、開発者が作業コピーをチェックアウトまたは更新するたびに、未処理の変更スクリプトが実行されます。これを行うフレームワークを使用しない限り、自分でそれを行うには、いくつかのスクリプト/ツールをセットアップする必要があります。
リモート DB を使用してローカル Web サーバーを実行するのが最適であることがわかりました。DB のレプリケーション/同期は面倒なので、本当に必要な場合にのみローカル DB で作業します。
ただし、ローカル Web サーバーを使用すると、変更の間にページ/コードをアップロードする煩わしさと遅さがすべてなくなります。
ローカルの長所:
ローカルへの短所:
中央の長所：
中央への短所：
他にもあると思いますが、すぐに思いつくのはこれらです。
ローカル マシンでの開発と「テスト」は問題ありませんが、品質テストはターゲット環境を反映するシステムで実行する必要があります。つまり、すべての開発ツールなどがインストールされていません。
これにより、「自分のマシンでは問題なく動作する」という状況を回避できます。
参考までに、私たちのセットアップは Matt 氏が説明したようなものです。各開発者は、独自の Web サーバーと DB を使用して、独自のサンドボックスを操作できます。リリースが近づくと、バージョン管理されたコードがスナップショット/分岐され、実際のライブ環境を可能な限り模倣するステージング サーバーに移動されます。テストが続き、その後、本番環境へのリリースが行われます。
私自身の個人的な (仕事に関係のない) プロジェクトでは、ローカルで開発してから、ライブにプッシュします。1 つまたは 2 つのプロジェクトには、開発とパブリック/ライブの間に中間テスト サーバー/環境がある場合があります。
ローカルで作業するもう 1 つの理由は、すべてがより高速に実行されることです。これは、より迅速な開発につながります。ネットワークラグは生産性を損なう可能性があります!
私は一人の店です。リモートサーバーとローカルサーバーの両方があります。
私はローカルサーバーを使用して、ラピッドプロトタイピングと、多くの変更を加えてそれらを迅速にテストする必要がある初期開発サイクルを行っています。ほぼアルファ段階になったら、プロジェクトのカスタムサブホストを設定し、サーバーにデプロイします。ローカルでテストできない特定の機能（つまり、電子メールベースのユーザー登録）があるため、これらの機能はリモートサーバーで開発されます。これはMINEであり、実際のデプロイメントではないため、ほとんどラグがありません。私はVPSを持っているので、両方のマシンの開発環境を完全に制御できます。
現在のポジションでは、自分のマシンで開発しています。小規模なプロジェクトでは、Visual Studio に同梱されている軽量の Web サーバーを使用します。また、開発と初期テストの目的で、自分のマシンに SQL Server 2005 と 2008 をセットアップしました。
これは全体的にうまくいきました。私が遭遇した 1 つの問題は (他の人が指摘しているように) データベースの同期を維持するのが面倒なことです。私は最近、ローカル/ステージング/uat/運用データベースの同期を維持するために、 migrator dot net (基本的には Ruby on Rails の移行を .NET で採用したもの) に移行しました。このようなツールを使用すると、チーム環境でデータベースを操作しやすくなりますが、一貫して使用するには十分な訓練が必要です。
ここでの経験から、ある種のデータベース変更管理プロセス、継続的インテグレーション サーバー、マージをサポートする優れたバージョン管理システム (TFS を使用) を組み合わせたローカル開発が最善の方法であると確信しました。これにより、誰もが他の人を踏むことなく自分のことを行うことができますが、変更が適切にマージされることも保証されます.
私の以前の仕事では、PC で IIS を専用の開発データベースと組み合わせて使用していましたが、これはちょっとした PITA でした。他の開発者や IMO に影響を与える可能性があり、そもそも開発用 DB を持つという目的を打ち負かすことになります。
両方。開発サーバー (理想的には、ライブ サーバーと可能な限り同じにする必要がありますが、ローカル) でいくつかの統合と単体テストを行い、QA 環境でいくつかの受け入れテストを行います。QA 環境は、ライブ サーバーと同じマシンである必要があります。サーバー、またはまったく同じセットアップ (ハードウェア、ソフトウェアなど) であり、リモートである必要があります。
質問のデータベース部分に関しては、次のいずれかを実行できます。
localhost でテストする際の問題の 1 つは、ブラウザーからアクセスできるものではなく、ローカル ファイルへのリンクであるものを見逃す可能性があることです。父はいつもカメラ クラブの Web サイトに「a href="C:\My Documents\Camera Club\Photos...」のようなリンクを張っていました。 、彼は「それは私のために働いた」と言うでしょう。同様に、プロの環境では、ソース コード管理にチェックインするのを忘れたものがあり、実際のサーバーに展開されないことがあります。
妥協案の 1 つは、VirtualBox、VMWare、または Parallels のいずれかの VM を用意して、Solaris、Windows、Mac、Linux の仮想ボックスを起動してテストできるようにすることです。これにより、デフォルトのブラウザでサイトがどのように表示されるかがわかります。さらに、非ローカル接続を介して実際に動作することを確認できます。さらに良いのは、デプロイ先の VM を用意し、それをテスト用の Web サーバーとして使用することです。
ベース OS が OpenSolaris の場合、各テストの実行後に VM をベース状態にロールバックするために、ZFS とスナップショットを使用することもできます。
私は Ruby on Rails でサイトを構築しており、開発はローカルで行っていますが、できる限り頻繁にリモート マシンにデプロイしています。Rails を使用したアジャイル Web 開発の記事で、デプロイの練習をすればするほどうまくいくと読んだことがあります。
そのような状況では、私は常に開発サーバーでそれを行ってきました。再コンパイルがないため。毎日新しい DB スナップショットを取得し、マシンにダウンさせることができます。または、Web サーバーをローカルにして、DB を開発ボックスに向けます。
ソース管理を使用してローカル マシンでコードを開発し、集中型の開発 DB にアクセスすると、うまくいくことがわかりました。複数の DB の同期を維持することは困難であることが判明しました。
通常、全員が共有するローカル開発サーバーがあります。