本番サーバーでの開発
今日、本番サーバーでアプリケーションを開発することに怒鳴られました。 「本番サーバーでの開発は受け入れられません-これまで！」
これが状況です。
- 開発インスタンスをセットアップしました：
http://example.com:3000 - 本番インスタンスは
http://example.comです。 - 私はすべての開発作業を
http://example.com:3000で完了し、クライアントが変更に満足したら、http://example.comに移動します。
私が使用しているアプリケーションは古い Ruby on Rails アプリケーションであり、最初に開発環境をローカルでセットアップしようとしましたが、実行できませんでした。しばらく試してみて、あきらめて本番サーバーで開発することにしました。
繰り返しますが、私はばかですか？おそらくそうですが、私はここ数年ウェブ開発を行っており、このような状況に遭遇したことはありません。誰が正しいのか、そしてその理由は？
他の人が述べたように、PROD環境でのコーディングはユーザーをバグにさらします。別のインスタンスを起動した場合でも、共有ハードウェアリソースがあり、本番ファイルとデータベースにアクセスできます。そして、コメントのいくつかが指摘しているように、Devインスタンスがハッキングされた場合（たとえば、ワイプを忘れ、誰かがRailsで大規模なセキュリティエクスプロイトを発見したため）、これで、一般公開されているマシンにyourアプリがゲートウェイとして機能します。 これは...残念ですが
これに対するビジネスの反応は異なりますが、一般的には次のように分類できます。
- ねじ込みは発生しましたか？
- 変更を元に戻すのにどのくらいの時間がかかりますか（私は主にC++で作業するため、バイナリのロールバックには、Rubyよりも大幅に長くかかる可能性があります。特に、古いバイナリを「失った」場合、再コンパイル）
- 変更の影響（大まかなガイド：格納されたデータを台無しにすることはsoデータを格納または表示しないよりもはるかに悪い、つまりページをまったく表示しないよりも悪い）
- あなたが失敗してドアから出た場合、誰かがあなたがしたことを知っていますか？
- 影響が出る前にねじ込みを防止/最小化/検出する別の展開オプションはありましたか？
これにより、最終的な計算が得られます。
- この完全に防止可能なねじ込みにより、ビジネスにどれほどの費用がかかりますか？
これは、予算の決定を下す人にとって、はるかに少ない全体の管理構造に相当する価値です。したがって、叫びます。
会社の「会社概要」ページで作業しているときに、自分の名前をLと入力すると、「神のような」トーマス、ニックネームの恥ずかしい問題が発生します。ビジネスクリティカルな購入アプリで作業していて、誤ってクレジットカードの詳細をホームページにデバッグしてプレーンテキストでデバッグしてしまう場合...訴訟の問題。これらの両極端の間には、過充電、生産性の低下など、顧客を遠ざける可能性のあるすべてのものがあります。
「About Us」ページでも許可しない理由は、本番環境で直接コーディングするのは中毒性があるためです。あなたは、未成年者のためだけにそれから始めることから始めます、しかし、時間が経つにつれて、DEV環境をスクラッチにする必要がないために、それはとても速くなります。
それ以上に、ビジネスの規模は大きな影響を与える可能性があります。 2人組のチームでは、何か問題が発生した場合、肩に寄りかかり、「大井、ジャッカス、元に戻す」を行います。 300人の会社では、それが無能か悪意かを心配する必要があります。マネージャは、自分が制御できなかったものについて責任を負うことになります。
一日の終わりに、あなたが手順に従って失敗した場合、彼らは手順の何が問題かをチェックします。手順を踏みにじってねじ込みを犯した場合、たとえ非難が少し広がったとしても、それはあなたの責任です。サイコロを振るかどうかはあなた次第です。
ローカルで開発環境をセットアップしようとしましたが、実行できませんでした。しばらく試してみて、あきらめて本番サーバーで開発することにしました。
私はステートメントto AVOID開発を運用サーバーでサポートします。それが構成ファイルのタイプミス修正であり、マネージャーによって主張されている場合にのみ、GUNの下で行うことが正当化される場合があります。
WHY NOT?-後で危険にさらされて習慣になるになると、あなたはひどく追いつくでしょう。致命的な生産エラー/失敗はあなたの仕事から解雇されるの費用がかかるかもしれないからです。
もう一度繰り返しますが、productionサーバーでタイプミスを修正するように要求した場合でも、firstStagingで修正します。または言い換えると、変更をテストしてテストし、本番環境に配置する前にもう一度テストします。
これは、「do it quick and dirty」の文化が当たり前のように思われる場所でよく起こることです。
編集：別の環境としても本番サーバーで開発受け入れ不可。作業中に発生した問題は、運用サーバーを停止させ、運用アプリケーションのパフォーマンスに影響を与えるになる可能性があります。例として、以前の同僚が開発目的で運用サーバーWinServer 2003を使用しようとしたときに、セキュリティホールがあった場合を思い出します。
これは実際にはプロトコルの問題です。一般的に、これはあなたがやりたいことではありません。生産機械をそのままにしておきたい。それらには機密データが含まれている可能性があり、本番環境に対応していないコードで本番サイトのパフォーマンスや安定性を損なうことは望ましくありません。
とはいえ、これが一般的に行われる場合があります。低トラフィックのブリュシュアウェアまたは単純なCMSサイトを汲み上げる位置にいる場合、これはおそらく問題の少ないものになります。しかし、機密データや「ビジネスクリティカルな」プロセスで何かに取り組んでいる場合、同じマシン上に開発コードを置くリスクを冒すべきではありません。
本番環境で直接開発しないことのもう1つの重要な理由は、開発インスタンスは通常、詳細なエラーとスタックトレースを生成して表示することです。あなたに決してそれをユーザーに公開したくない。
はい、クライアントに表示する代わりにログに記録できますが、これによりデバッグの面白さが以前よりも少なくなります。
追加開発インスタンスで問題が発生するという副次的な問題への対処： VirtualBox -basedのデプロイに大成功しましたVMこれは、実稼働環境（もちろんハードウェアを除く）を buntu Server で複製します。
私は常に他の開発者に、特定の会社の手順について尋ねます。一般的にはい、常に次のことを行う必要があります。
- ローカルでビルドします。
- それをできる限り生産を模倣するあるタイプのボックスにプッシュして、そこでニースが再生されるかどうかを確認します。
- おそらくそれをQAまたは認定インスタンスにプッシュして、クライアント/ QAチームに渡して変更を確認します。
- 本番環境に移行します。
Capistrano レシピと GitHub を組み合わせて使用すると、このすべてを処理できます。毎回手動でこれを行う必要がある場合は、古くなります。
最も重要な理由について誰も言及していませんが、実稼働サーバーでの開発が絶対に禁止されている理由にはまったく驚いています。
簡単に発生する可能性がある本番データをいじらないでください
1か所での小さなエラーは、他の計算で大きな問題を引き起こし、翌日、すべてのデータはゴミであり、顧客は腹を立てます。これは、UIのバグやあちこちでの小さなクラッシュよりもはるかに悪いです。
ほとんどのアプリケーションでは、値はルーチンではなくデータにあります。
Prodでの開発に関するもう1つの問題は、ソース管理でこれらのことが見落とされ、将来のリリースでクイックフィックスの変更が取り消される可能性があることです。
米国の株式公開企業に所属している場合は、規制上の理由で製品にアクセスすることはできません。一般的に、開発者が（すべての回答で述べられた理由と考えられる法的理由のために）製品アクセスを行うべきではないので、上司もそのサーバーへの権限を許可するのが間違っています。
「常に」または「決して」を使用するルールは、通常、正しく定義されていません。ベストプラクティスを破ることが正当化されるEdgeのケースがあります。より良いアドバイスは、「非常に正当な理由がない限り、運用サーバーに触れないこと」です。
私のキャリアの中で、本番サーバーのコードを変更する理由は2つしか見つかりませんでした。
そこだけで発生し、開発環境で再現できないバグまたは動作。これらはまれですが、非常に煩わしく、見つけるのが難しい場合があります。
数分以上かかる場合、通常の展開プロセスを通過するのを待つだけの余裕のない重大なバグを直接修正します。この後、管理者によりクリアされました。あなたが運が良ければ、あなたのキャリア全体のためにそれらのいくつかだけを持っているべきです。
どちらも、システムを熟知している上級開発者に任せるのが最善です。