サーバーで直接コーディングする代わりに？
PHP Linux上のApacheで実行されている大規模なWebサイトがあります。プログラマーや技術者でないユーザーが毎日Webサイトを変更しており、テストサーバーで直接実行しています。
サーバー上でファイルを直接変更する方法はありますか？
確かに、プログラマはすべて自分のマシンにApacheインスタンスをセットアップして管理できますが、PHPに新しい拡張機能を追加したり、Apacheの設定を変更したりするため、誰もが必要とすることになります。また、技術者以外のユーザーが独自のApacheインスタンスを管理することを期待するのは現実的ではありません。
もう1つの問題は、私たち全員がWindowsコンピューターを使用していることですが、WebサイトはLinuxで実行されます。コードはWindowsと互換性がないため、別の問題です。 Linuxに完全に切り替えることも選択肢ではありません。他のタスクのためにWindowsでのみ実行される多くのプログラムを使用しているため、デュアルブートまたはVMである必要があります。
サーバーで直接作業するのは奇妙に感じられますが、私たちの場合はそれが最善の方法ですか？
アプリケーションを変更するすべての人がソース管理でそれを行う必要があり、ソース管理からテストサーバーに特定のバージョンをデプロイするための自動化プロセスが必要です。非技術者がソース管理を使用するように説得する必要があるかもしれませんが、彼らは本当におもちゃ以外のシステムを確実に実行し続けることに代わるものではありません。コードをチェックインしてデプロイするステップが十分に単純であれば、サーバーで直接作業している人がいないことは問題になりません。 gitは高速で、優れたエンドユーザーツールのエコシステムを開発しているため、人々はこれにgitを使用することを好みます。人々がサーバーで直接作業することは、災害のレシピです。
Vagrantを使用して、サーバーの設定を反映する環境をセットアップし、そこで再生できるようにします。
物事をサーバーに戻す方法、それはデプロイメントについてです、その部分は@antlersoftによってうまく答えられますが、警告があります：非技術的なユーザーにソース管理を使用するように説得することはできません（そしてgitは難しいものの1つです）もの）。技術者以外のユーザーがWebを変更する必要がある場合は、時間とお金をかけて適切なCMSを見つけて使用してください。
ホスト上の一連の仮想マシン。すべてのユーザーが独自のインスタンスを操作し、そこからメインリポジトリにプッシュして、そこから実際のテストサーバーを更新します。
技術に詳しくないユーザーにgitを紹介しようとしないでください。ある日、頭蓋骨に斧ができる可能性があります。 :-)毎日それを使用する開発者にパワーを与えても、それは彼らが失敗するほどの高いレベルの複雑さを追加します。 SourceTreeのようなツールはすばらしいですが、それでも、混乱を防ぐことはできません。
これまでに経験した最もユーザーフレンドリーなバージョン管理はTortoiseSVNです。技術に詳しくないユーザーでも、きれいなグラフィカルインターフェイスで表示されるsvn upコマンドとsvn commitコマンドを理解しています。
あなたの問題に対する答えは2つあります。
TL; DR：DTAPを使用してVCSを実装します。
まず、エンタープライズ環境では、決してサーバー上で直接コーディングしたくない。ライブ環境ではない場合でも、同じ環境で複数の人がファイルを編集すると、変更が競合する可能性が非常に高くなり、予期しない結果が発生します。 DTAPを完全に実装すると、この問題の解決に役立ちます。
DTAPは「開発、テスト、受け入れ、生産」の略で、コードを配置できる4つの別々の場所があるシステムを表すために使用されます。分離は、可能な限り多くの問題からプロダクションを保護するように設計されています。
最初に、コードが開発で実行およびテストされます（これは別のマシンにすることもできますが、多くの場合単に開発者自身のPCです）。開発者が自分の作業に満足した場合、コードはテスト環境に移ります。そこで、他の誰か（理想的には専用のテスターですが、別の開発者が作業できます）がコードを試します。テストのこのフェーズで問題が見つからない場合、コードはAcceptanceに移動し、そこで企業の "ビジネス"側がコードをテストします。これは、会社が別のパーティーのために製品を製造する場合の顧客になる可能性があります。または、エンドカスタマーのニーズに合わせるために製品が何をすべきかを連絡する別の部門になる可能性があります。それらがacceptである場合にのみ、コードはライブ環境である本番環境に移動します。
次に、変更を追跡し、複数の人が同時にコードの同じ領域を変更したときに発生する問題を回避するには、すべての変更を追跡するVCS（バージョン管理システム）を組織に実装する必要があります。すべてのファイル（例はSVN、Git、Mercurial）。これらのシステムでは、間違いがあった場合に変更をロールバックすることもできます。人生を楽にするために、 Bitbucket のようなサービスのアカウントで選択したシステムを使用すると、開発者の作業を別の開発者の作業と組み合わせるプロセスにインターフェースを使用できるようになります。すべての開発者は、コードを開発から次の環境に移行する状態にマージするために使用する特定の戦略に同意する必要がありますが、私はそれで私の答えを過負荷にすることはしません。
非技術者がテスト環境を変更していると言うとき、実際のファイルではなく、構成やコンテンツに変更を加えたことを意味します。技術者ではない人は、決してWebサイトのコードに触れないでください。結局、彼らが何をしているかわからない場合、誤って何かを壊してしまう可能性があります。
互換性の問題と、技術者ではない人が独自のApacheサーバーを維持することは期待できないという声明に関して、私が見ることができるいくつかのオプションがあります。 1つのオプションは、関係者全員に対してこれらのサーバーのインストールを1人で管理することですが、これはフルタイムの仕事になる可能性があり、組織にそのような人がいない場合があります。別の方法は、VagrantやDockerなどの使用可能なツールの1つを使用することです。これにより、1人の技術者が作業環境（通常はLinuxベース）を持つ「イメージ」を作成し、そのイメージをすべての開発者が自分のマシンで実行できるようにします。アーキテクチャの更新が必要な場合、この担当者はイメージを更新し、それを開発者に再配布します。
個人的な意見：元の投稿から、私はあなたの会社が「とにかく2人しかサイトで作業していないため、サイトで作業していない状態」を過ぎていると推測します何をすべきか」私が提案するこれらの概念は、良い説明として広く受け入れられています。私の説明からわかるように、プロセスに比較的わずかな追加の複雑さを導入することのトレードオフで、製品の品質の追加チェックの多くを得ることができます。 GitやMercurialのようなバージョン管理システムは恐ろしいように思えるかもしれませんが、私の意見では、ある程度のトレーニングがあれば、文字通り誰でも適切に操作する方法を学ぶことができます。必要なのは、システムを敵のように見るのではなく学ぶ意欲の態度であり、それによって仕事を終わらせることができなくなります。後者は残念なことに一般的です。ツールを適切に使用する方法を学ぶことで、間違いを修正し、複数の人の作業をコードに組み合わせる方法を手動で整理するために費やす時間を節約できます。
まず、バージョン管理は必須です。ただし、コミットする前に変更をテストする必要があります。これらの変更については、各ユーザーが独自のテスト環境を必要とします。したがって、theサーバーで直接コーディングすることはお勧めできません。
各ユーザーのテスト環境をどの程度分離する必要があるかは、特定のニーズによって異なります。一部の単純なタスクでは、共有テストサーバーでユーザーごとに仮想ホストを実行することで、十分な分離を実現できます。さらに分離が必要な場合は、ユーザーごとにVPSを構成できます。
最も要求の厳しいタスクでは、ユーザーごとに専用の物理マシンが必要になる場合があります。そのため、一部のユーザー用に別の物理マシンを購入する必要がある場合、他のマシンをユーザーのデスクに配置するか、サーバーラックに配置するかを決定する必要があります。
これまでに使用したすべてのバージョン管理システムで、ユーザーがコミットを台無しにするのを見てきました。バージョン管理システムを正しく操作する方法を学べる人もいれば、そうでない人もいます。一部のコードベースを変更する必要があるが、バージョン管理の使用方法を学ぶことができない技術者以外の人がいる場合は、検討する価値のある別のオプションがあります。
開発者が技術者以外の人のテストマシンに（シェルログインとして、またはネットワークファイルシステムを介して）アクセスできるようにして、変更の準備ができたら、技術者以外の人が開発者に変更のコミットを依頼できるようにすることができます。