実動サーバーでの開発

今日、私は本番サーバーでアプリケーションを開発することで怒鳴られました。「実稼働サーバーでの開発は受け入れられません-これまでに！」

これが状況です。

1. 開発インスタンスをセットアップしました。 http://example.com:3000
2. 実稼働インスタンスは次のとおりです。 http://example.com
3. すべての開発作業を完了し、http://example.com:3000クライアントが変更に満足したら、それらをに移動しますhttp://example.com。

私が使用しているアプリケーションは古いRuby on Railsアプリケーションです。最初は開発環境をローカルに設定しようとしましたが、実行することはできませんでした。しばらく試した後、私はあきらめ、本番サーバーで開発することにしました。

繰り返しますが、私はばかですか？おそらくそうですが、私はここ数年、Web開発を行ってきましたが、このような状況に遭遇したことはありません。誰が正しいのか？

実稼働サーバーでの開発に使用していました。正常に機能しますが、少なくとも2つの理由からお勧めできません。

1. 開発コードは、無限ループ、メモリリーク、またはCPUをロックしたり、すべてのメモリを使い果たしたり、または本番コードに影響を与える方法でサーバーに影響を与える他の問題を引き起こす可能性があります。
2. RubyやMySQLのバージョンなど、開発作業の一環としてサーバー環境のコンポーネントを変更する必要がある場合は、バインドされます。

他の人が述べたように、PROD環境でコーディングすると、ユーザーがバグにさらされます。別のインスタンスを起動した場合でも、ハードウェアリソースは共有されており、運用ファイルやデータベースにアクセスできます。また、コメントの一部が指摘しているように、Devインスタンスがハッキングされた場合（たとえば、消去するのを忘れて、誰かがRailsで大規模なセキュリティエクスプロイトを発見した場合）、アプリが動作する公開アクセス可能なマシンがありますゲートウェイとして。それは...不運です。

さまざまな企業がこれに対して異なる反応を示しますが、一般的には次のように分類できます。

• ねじ込みは発生しましたか？
• 変更を元に戻すのにどれくらい時間がかかりますか（主にC ++で作業しているため、特に古いバイナリを「失って」再コンパイルしなければならない場合、バイナリのロールバックにはRubyよりもかなり長い時間がかかります）
• どのような変更の影響（目安：保存されたデータを台無しがあるので、順番にすべてのページが表示されないよりも悪いである、はるかに悪いデータを保存するか、表示しないより）
• あなたが台無しにした後、ドアから出て行った場合、誰もあなたがしたことを知っていますか？
• 影響を受ける前にねじ込みを防止/最小化/検出した別の展開オプションがありましたか？

これにより、最終的な計算が行われます。

• この完全に防止可能なねじ込みは、ビジネスにどの程度の費用がかかりますか？

これは、予算決定を行う人にとって、管理構造全体がどれほど価値がないかです。したがって、大声で。

会社の社内の「About Us」ページで作業しているときに、自分の名前をL.「God-like」Thomasのように入力すると、恥ずかしいニックネームの問題が発生します。ビジネスに不可欠な購入アプリで作業していて、クレジットカードの詳細をホームページに誤ってプレーンテキストでデバッグしてしまった場合...訴訟の問題。これらの極端な点の間には、不正請求、生産性の低下、および顧客を追い払う可能性のあるすべてのものがあります。

「About Us」ページでも許可しない理由は、プロダクションで直接コーディングするのは中毒性があるためです。あなたは未成年者のためだけにそれを行うことから始めますが、時間が経つにつれて、DEV envをスクラッチする必要がないように、ずっと速くなります。

さらに、ビジネスの規模が大きな影響を与える可能性があります。二人組のチームでは、何かがしゃがむと、肩に寄りかかって「大井、ジャッカス、元に戻して」行きます。300人の会社では、それが無能であるか悪意であるかを心配し始めなければなりません。管理者は自分がコントロールできないものなどに対して責任を負うことができます。

一日の終わりに、あなたが手順を踏んで失敗した場合、彼らは手順の何が悪いのかをチェックします。あなたが手順とねじ込みを回避する場合、責任が少し広がったとしても、それはあなただけの責任です。サイコロを転がすかどうかはあなた次第です。

開発環境をローカルにセットアップしようとしましたが、実行することはできませんでした。しばらく試した後、私はあきらめ、本番サーバーで開発することにしました。

実稼働サーバーでの開発を避けるためのステートメントをサポートします。GUNの下で行うことを正当化できるのは、それが設定ファイルのタイプミスであり、マネージャーによって主張されている場合だけです。

WHY NOT?-なぜなら、非常に危険であり、後で習慣になることはあなたをひどく追いつくだろうからです。なぜなら、致命的な生産エラー/失敗は、仕事から解雇されるのに費用がかかる可能性があるからです。

productionサーバーでタイプミスの修正を要求した場合でも、最初にそれを繰り返しますが、もう一度繰り返してみましょうStaging。または、言い換えると、変更をテストし、テストし、実稼働に移す前に再度テストします。

これは、「早くて汚い」という文化が当たり前のように思える場所でよく起こることです。

編集：独立した環境も本番サーバーで開発することはできません。作業で発生した問題は、運用サーバーを単純に停止させ、運用アプリケーションのパフォーマンスに影響を与える可能性があります。例として、以前の同僚が開発目的で運用サーバーWinServer 2003を使用しようとしたときに、セキュリティホールがあったケースを覚えています。

これは本当にプロトコルの問題です。一般的に、これはあなたがやりたいことではありません。生産マシンはそのままにしておきます。それらには機密データが含まれている可能性があり、非実動準備コードで実動サイトのパフォーマンスや安定性を損なうことは望ましくありません。

そうは言っても、これがよく行われることもあります。交通量の少ないブローシュアウェアや単純なCMSサイトを送り出す立場にある場合、これはおそらく問題ではありません。しかし、機密データや「ビジネスクリティカル」なプロセスを扱う作業をしているのであれば、同じマシン上に開発コードを置くことを恐れてはいけません。

本番環境で直接開発しないもう1つの重要な理由は、開発インスタンスが通常、詳細なエラーとスタックトレースを生成して表示することです。それを決してユーザーに公開したくありません。

はい、クライアントに表示する代わりにログに記録することができますが、これによりデバッグが以前よりもはるかに面白くなくなります。

追加開発インスタンスで問題が発生するという副次的な問題への対処：実稼働環境（もちろんハードウェアを除く）とUbuntu Serverを複製するVirtualBoxベースのVMの展開に大成功しました。

最も重要な理由について誰も言及していないのに、実稼働サーバーでの開発が絶対に禁止されている理由には驚いています。

実稼働データを混乱させないでください。

ある場所で小さなエラーが発生すると、他の計算で大きな問題が発生し、翌日にはすべてのデータがゴミになり、顧客は腹を立てます。これは、UIのバグやあちこちで少しクラッシュするよりもはるかに悪いです。

ほとんどのアプリケーションでは、値はルーチンではなくデータにあります。

私はいつも、他の開発者に特定の会社の手順を尋ねてみます。一般的にはい、あなたは常にする必要があります：

1. ローカルでビルドします。
2. 生産を可能な限り模倣する何らかのタイプのボックスに押し込み、そこで再生されるかどうかを確認します。
3. おそらくそれをQAまたは認証インスタンスにプッシュして、クライアント/ QAチームに渡して変更を確認します。
4. 本番にプッシュします。

GistHubと組み合わせたCapistranoレシピを使用して、これらすべてを処理できます。毎回これを手作業で行わなければならない場合、早く老化する可能性があります。

prodでの開発に関するもう1つの問題は、これらのことがソース管理で見落とされ、将来のリリースでクイックフィックスの変更が取り消される可能性があることです。

米国の株式公開会社にいる場合は、規制上の理由からprodにアクセスすることさえできません。一般に、どの会社でも開発者がprodアクセスを行うべきではありません（すべての回答に記載されている理由と考えられる法的理由のため）。そのため、マネージャーはそのサーバーへの権限を許可することも間違っています。

「常に」または「決して」を使用するルールは、通常、不適切に定義されています。ベストプラクティスを破ることが正当化されるエッジケースがあります。より良いアドバイスは、「非常に正当な理由がない限り、実稼働サーバーに手を触れないでください」です。

私のキャリアの中で、本番サーバーのコードを変更する理由は2つだけです。

1. そこだけで発生し、開発環境で再現できないバグまたは動作。これらはまれですが、非常に迷惑で、見つけるのが難しい場合があります。

2. 数分以上かかる場合、通常の展開プロセスを通過するのを待つ余裕がないという重大なバグを直接修正します。これが管理者によってクリアされた後。運がよければ、あなたのキャリア全体でそれらのうちのわずかしか持ってはいけません。

両方とも、システムを熟知している上級開発者に任せるのが最善です。