複数の環境を用意する理由としては、単純な理由
私の経歴を通して、私はさまざまな目的のためにさまざまな環境のコレクションを持つ企業で働いていました。私たちは常にデスクトップ環境、テスト環境、QA環境、ステージング環境、および運用環境を多かれ少なかれ持っていました。これは、サーバー/アプリケーションと、使用していたデータソースの両方に当てはまります。
現在の会社で仕事を始めたとき、90％のアプリが、実稼働データソースに対するデスクトップ環境で開発されているか、プラットフォームに応じて実稼働サーバーで直接開発されていることに気付きました。これは特に驚くべきことではありませんでした。面接のプロセスから明らかなように、開発チームの機能を改善するために一部変更を加えるために雇われたためです。私たちはゆっくりと哲学を変え始め、ほとんどすぐに、ほとんどのアプリはデスクトップ、テスト、または本番環境のいずれかで実行できました。そのステージングがやって来てからそれほど長くはありません。
現在、ほとんどの開発者がこの方法論の利点を理解し、慎重に防御しています。ただし、移行されていないレガシーアプリが多数あります。また、これを時間の無駄だと考える多くのレガシープログラマもいます。残念ながら、リップサービスは受けましたが、経営陣から完全な賛同を得ることはできませんでした。約1年前にこれに大幅に投資するというコミットメントだと思いましたが、かなりの計画を立てたにもかかわらず、何も実現しませんでした。今、私たちはますます多くの環境が必要であることを発見しています。セットアップにはサーバー/ネットワーク管理チームの支援が必要であり、リリースサイクルをサポートするには、ビジネス関係者の参加が必要です。私たちは今、プロジェクトに適切な人がいて、適切な環境をセットアップする時間がなければ、合理的な開発者が「通常」と考えることをプロジェクトが機能できる場所にいます。
完全な議論を提示したいのですが、重大な問題が発生するまで、経営陣は実際に私に連絡する時間も関心もありません。それが常に私にとって第二の性質であるように思われただけで、私は本当に利点を明確に述べることはできません。 開発の経験が不足しているマネージャーがこのアイデアをサポートするために環境を分離するための良い、シンプル、反駁できない理由があるか？と思いました。このトピックに関する優れたリソース/文献はありますか？
答え：Money
実際の理由は何でも構いません。特に管理を扱う場合、お金はすべての推論の根本にある必要があります。
両方が2時間部屋に座っていた場合、複数の環境を用意した方がよい理由として数十が考えられます。
ここに問題があります：理由がお金に基づいていない場合、どれも重要ではないです。
プログラマーは賢く雇われていません。彼らは創造的であるために雇われていません。彼らは収入を増やす-お金を稼ぐか、お金を節約するかのどちらかに雇われています。これらのどちらも行わない場合は、履歴書をまとめておくとよいでしょう。
その観点から見ると、答えは簡単です。
環境が1つしかないと、ダウンタイムが増加し、収益が失われます。複数の環境により、ユーザーと同様に信頼性と信頼性の高いフロントエンドをユーザーに提供することで、利益を保護できます。
毎日繰り返します。
この回答にいくつかの真の価値を加えるいくつかの素晴らしいコメントがありますので、私はそれらについて言及します：
カールビーレフェルトは、コスト/利益分析が重要な要素であると述べたときに素晴らしい点を示しました。経済学者はそれを複数の環境を追求する機会費用と呼ぶかもしれません。意外と聞こえるかもしれませんが、複数の環境では答えにならない可能性があります！御社のWebサイトがごくわずかな追加である場合、予期しないダウンタイムの方が実際に費用対効果の高い方法である可能性がありますビジネスを行うことの。これはあなたがいる立場のようには聞こえませんが、言及する価値があります。
BlairHippoは、それを大惨事のように見せることを自由に感じられるべきである（そして、あなたがデータを失った場合、それはそうなのです！）良い点を持っています。責任はマネージャーを説得するための優れたツールですが、それでも同じ理由で訴訟は高価です。それらを避けることはお金を節約します。
補遺として、私は この記事 が非常に良いことを発見しました。それはあなたの質問に直接答えることはしませんが、プログラマーが経営陣に対してどのように見られているかを認識することができ、それが今度はこの答えにつながります。よく読みました。
単一障害点
開発環境やステージング環境がないことで、これらのレガシーアプリケーションに単一障害点が発生します。これらの用語でレガシーアプリケーションについて説明すると、経営陣があなたに耳を傾けるでしょう。
あなたは彼らに意味のあるサウンドバイトでメッセージを売り込むことができる必要があります。 "Programmer Speak"をディスカッションから外し、 "Manager Speak"に置き換えます。また、30秒のエレベーターに乗って、目的を達成したとしましょう。
私の上司が歩兵海兵隊だった状況がありました。私は、生産性を高めるために海兵隊員のためにソフトウェアツールとコンピュータートレーニングが必要だと彼に言い続けました。彼はそれを理解できませんでした。とうとう私はついに彼のオフィスに入り、問題が起きたことを彼に伝えました。
その影響について何か言った...「もし私が戦争を戦っているなら、私は棒、岩、木の枝を使うことになるだろう。必要なのは手榴弾、バズーカ、そして機関銃だ」彼はメッセージを受け取りました。
それは実際に重要ですか？
別々の環境を使いたいという欲求を理解できます。非自明な質問は：
レガシーシステムを移行することは実際に重要ですか？
私は、ほとんどの技術を重視する人は、どちらの方法が優れているかという学問的な問題に焦点を合わせる傾向があると思います。しかし、ビジネスでは常に勝つとは限りません。私はこれが否定的だと言ったり、炎上戦争を始めたりしているのではありません。私は、数年間ソフトウェアビジネスに携わってきた私たちにとって明白な、または明白なはずのことを述べています。
通常、すべてのビジネス上の決定は、認識されたコスト/利益に基づいて行われます。したがって、企業がおそらく求めている質問は次のとおりです。
レガシーアプリケーションへの追加のシステムと開発投資のコストは、同じ投資を別のプロジェクト/製品に投入するよりもメリットがありますか？
ソフトウェアの移行/書き換えだけでなく、日々の決定においてリードが通常関与する決定を行うために、定期的に費用便益分析を行っています。寿命が限られていたため、私は古いソフトウェアの書き換え/移行に合格しました。したがって価値。
環境の分離
環境を分離するbusiness理由。
- リリースにおけるリスクの軽減、およびバグ修正。 数字で証明してください。不適切なリリース/バグが原因で製品が失敗し、顧客の収益を犠牲にした回数
- 開発のリスクが少ない。 誤って開発データベースを吹き飛ばすことは、本番データベースを誤って吹き飛ばすこととは異なります
- 役割とアクセスを明確に分離する機能。より良いセキュリティ。 生産パイの指の数を制限することは良いことです
- 環境を分離する機能、およびこのスタイルの開発に伴うプラクティスと手順により、クラウドシステムへの将来の構築が可能になります。
- 環境を分離すると、複製環境で効率が向上するはずです。これは、スケジュールされたスケーリングと動的スケーリングで役立ちます。
すべての「正しい」議論がすでに整っているようです。代わりに、あなたがそうするなら、あなたは「赤目」を経験しています。または、「ニンジンを追いかけて」
重大な問題が発生するまで、経営陣は本当に私に意見を聞くことに時間と関心がありません。
それが本当の問題だと私は考えています。私の経験では、あなたが説明するほど劣る開発慣行が会社にある場合。それは単に「私たちはそれ以上知りませんでした」という問題ではありません。むしろ、それが提示する問題について知らない（気にする？）上層部の経営陣によって引き起こされる技術的な負債の集まりです。
そのような場合、良いpep-talkは突然物事をあなたの方向に振ることはありません。多分深刻なトラウマ（クライアントに見える製品の失敗であり、悪い習慣に直接結びついている）かもしれませんが、あなたが話をする前に、私はきちんとした精通した技術者であると確信しています。
私の提案は、それを吸い取って、彼らが何であるかのために物事をとるか、または新しいポジションを探すことです。
一度に何人のグループがアプリで作業する予定ですか？通常、私は人々のグループごとに1つの環境を見てきました。これは、開発者（DEV環境とDEV統合環境を取得します-100％必要ではないと言う人もいますが、プロジェクトによって異なります）、2つのテスト環境（非常に詳細なテストを行うテスターのグループ、その他のグループ）ハイレベルのQAテスター-通常、彼らは実際のビジネスユーザーであり、トレーニングを受けたテスターではありません）。通常、分離されたパフォーマンステスト環境もあります（大量のデータをテストしたり、大量のユーザーをシミュレートしたりできるためです... g）。
なぜこれらすべての環境なのか？したがって、さまざまなグループがお互いのつま先を踏まずにさまざまな機能をテストできます。開発者とテスターが同じ環境で作業する場合、それは悪夢です。テスターは、開発者によって毎分積極的に変更されている機能の欠陥を開くことができます。 2つのレベルのテストがある場合、それらは異なるアクティビティに焦点を合わせることができ、互いのデータを台無しにする心配はありません。分離されたパフォーマンス環境があると、マシンをハングさせる可能性のあるテストを実行できますが、それが分離されている場合、他のテスターは影響を受けません。
同じ環境で非常に多くの人がさまざまなことを実行しようとすると、あるグループが別のグループのテストが完了するのを待って、それらのグループがテストを実行できるようになるので、多くの無駄な時間がかかります。そしてそれは時間を浪費し、無駄な時間は無駄なお金につながる可能性があり、それは Stargazer712が指摘した が最強の兵器になる可能性がある。
別の理由（あまり一般的ではありません）はデータです。アプリケーションに機密の個人データまたはクレジットカードデータがある場合、通常、それをテスト環境に入れることはできません。通常、QAおよび本番環境以外のすべてにマスキング要件があります。
あなたは職場に文化的変化をもたらすために多大な努力を払ってきたようです。変化は最高の状態では難しいため、これは素晴らしい成果です。文化の変化は、単に人々の心を変えることではなく、習慣を変えること、偏見を打破すること、そして最終的には潜在的に閉じた心をより大きな可能性に向けて開くことです。したがって、この時点で自問する質問は、「見逃したことは何か」です。簡単な答えは、管理に完全に従事していない可能性があるということです。
経営陣から賛同を得ることは簡単ですが、受け入れがさらに難しくなっています。お金についての議論に関係なく、現実には、経営者の優先順位の考え方に影響を与えることができる必要があります。上司は予算を持ち、予算が慎重に適用され、会社の価値観と優先事項に沿って適用されていることを示す必要があります。これらの優先事項のいくつかは財政的ですが、他の優先事項は他のニーズに対応することです。場合によっては、これは上司が常に望んでいた昇進を得るために、他のマネージャーの手のひらに油を注ぐことを意味する場合があります。ただし、ほとんどの場合、ビジネスを拡大したり、パートナーや顧客との関係を改善したりする方法を見つけることになります。あなたがこれらの言葉であなたの主張をすることができないならば、あなたが行き詰まりに気づく前にあなたはこれまでに行くことができるだけでしょう。
私の提案は、他の人が示唆したように、生産性とこれが予算にどのように影響するかについて主張することを試みることですが、会社の優先順位と生産性が他の会社との会社の関係に直接影響を与える方法についても主張することです。
1つは、テスト容易性です。
テスト環境を用意することで、運用環境での実行は推奨されないデータベースでのテストを自由に実行できます。
組織がソフトウェアを開発する方法を変更したいですか？ 「違うことをする」「理由」を気にすることを忘れましょう。人間は合理的な議論のために行動を変えません。彼らは習慣への心理的影響のために変化します。
それで、これはどこに行くのですか？
ときどき議論を通じて組織の振る舞いを正常に変更することができますが、より効果的な他の戦術があります。これらには以下が含まれます：
草の根のサポート：あなたに挑戦してくれる他の「レガシー」開発者を1人見つけてください。彼と協力して、物事の仕組みを変えてください。変更を発表しないでください。変更を加えてください。誰かがあなたにそれについて尋ねた場合は、「ああそうです、それが私たちが今やっていることです」と言ってください。
責任を引き継ぎます。従来の人々のデプロイメントを処理するボランティア。好きなように振る舞います。彼らはその責任を放棄して喜んでいるかもしれません。次に、希望どおりに実行します。
適切な人たちの過ちを責めなさい。石器時代の展開メカニズムのために、次にレガシーアプリのバグが本番環境に導入されたときは、指摘してください。微妙にやってください...メールではありません。次にマネージャーとのミーティングに参加するときは、展開に問題があった理由の例をさりげなく述べてください。 「ああ、ボブが本番にチェックインしたフーのバグが原因で、先週の金曜日にスクランブルをかけたことを覚えていますか？ええ、それは多くの無駄な努力でした！」
より良い方法で簡単に実行できます。たとえば、iPhoneを見てください。その上に一つのボタンがあります。 （まあ、2つ）。電源を入れるのはとても簡単です。複数の環境への展開を、ばかげた愚かさを簡単にします。すべてのマネージャーが実行できるように簡単にしてください！
相互接続されたシステムまたはレガシーシステム、ビジネスが機能していて正確であるために依存しているシステムの処理を開始するときの問題の詳細。ステージ間に分離が必要なため、これは重要です。PRODでDEVを実行しない理由は、失われた時間内に数百万ドル相当の損傷を引き起こす可能性があるであるためです。
常にDEV-> QA-> PRODを実行します（場合によっては、これらのステップが同じハードウェアで分割されます）。現在の本番データは常にPRODからQA、DEVにプッシュされます。
DEV：開発サンドボックスであることが意図されており、この環境であらゆるデータに対して試行、反復、打撃が行われることは絶対に信頼すべきではなく、問題を解決する方法を見つけるだけの開発者によって定期的に破棄されます。
QA：開発者がユニットテストに満足したら、テストグループが注目する時間です。彼らはテストケース、パフォーマンステストを実行し、バグを見つけます。それらのバグ/エンハンスメントはDEVにフィードバックされ、サイクルは全員が満足するまで続きます。
PROD：この段階に到達したら、コードが現在のデータと連動して機能し、QAグループ/ビジネスユーザーが実装に満足していることを確認する必要があります。すべてを正しく行った場合は、コードを更新してそれで完了できるはずです。
同様に、テストされていない製品を顧客にリリースすることは決してなく、テストされていないコードを本番環境にリリースすることはできません。
会社が適切にそれを行うために時間を費やすことを望んでいない場合、彼らは緊急メンテナンスとエラーの10倍の費用を払い戻します。
小さな例として、本番のレポートを自分で変更することにした会社が1社ありました。 1年か2年後にさまざまな問題に取り組むために私たちが来るまで、誰もそれが変わったことを知りませんでした。
レポートの不規則性を指摘したところ、CFOの顔は真っ白になり、誰かが迅速に変更したために四半期ごとに約250,000ドルを失っていたことがわかりました。
あなたが考えるより頻繁に起こる、あなたが適切にそれをする余裕がないならそれをしないでください。
管理は、これらの環境を生成する必要があったソフトウェア会社とソフトウェア製品の成功の背後に大きな部分を持っています。プロジェクトの例を見てみましょう。ソフトウェアが大規模に開発されている場合、プロジェクトの要件、プロセス制御、テストビルドなどを管理しないと、失敗する可能性があります。プロジェクト管理が存在するように。
@ Stargazer712についていくらか同意しますが、あなたの声明はMoneyの問題を指摘しているものですが、ソフトウェア開発に関するMarc Hamiltonの本：Building Reliable Systems（Prentice Hall PTR、1999、ISBN 0-13-081246- 3）。これらすべての要因を調べた後、あなたの質問についての私の意見は、単一環境はあなたに節約を与えないということです、それはプロジェクト/ソフトウェアを完了するための長期的なプロセスを作るでしょう。分散環境を使用すると、キャリアを開始したスタートアップソフトウェア会社で何が起こったかを知り、経験から見て、時間と収益を節約できます。
成功のために何が重要かを示す記事はたくさんあります。これをチェックしてください 成功するソフトウェア開発のための組織化
組織内の各個人には特定のスキルがあり、これらのスキルは通常、将来のパフォーマンスのインセンティブとして報酬（報酬）につながる公式または非公式のパフォーマンスメトリックに対して測定されます。組織の人々は、その文化、つまり一般的に採用されていると認識されている行動パターンと価値観を確立します。
ソフトウェア開発者の多くは、不適切な組織構造と戦うためにすべての時間を費やさなければならない場合、苦労して最終的には目標を達成できなくなります。
多くのソフトウェアの新興企業は、ガレージで作業する開発者が2〜3人にすぎないところから始まります。会社の歴史のこの時点では、それほど多くの組織構造は必要ありませんが、組織構造はまだ存在しています。たとえば、1977年にビルゲイツとポールアレンがパートナーシップを形成し、正式にMicrosoftと名付けたとき、同社の組織構造は最小限でした。マイクロソフトのニューメキシコ州アルバカーキにある最初のオフィスで働いていた従業員は12人未満で、誰もが誰が責任を負っていたかを知っていました。全員のレポート構造を理解するために複雑な組織図は必要ありませんでした。同時に、すべての従業員は会社での役割と、彼らが達成しようとしていたことを知っていました。これは、必要なあらゆる組織構造を各従業員間で非公式に伝達できるためです。
あなたは多くの異なる環境を持っているように聞こえます、そしてそれは「環境」をセットアップするために人々に多くの時間を要します。
あなたは異なる「環境」の最小数を手に入れられるはずですが、あなたと会社が望む多くの理由で多くのコピーを複製できるはずです（「環境を使用してシステム構成を意味する」）！
最適な違いは、次のとおりです。
- サイズ（最小、推奨、最大のサポート/テスト済み）;
- ステージングとプロダクションには開発ツールがありません
- データの偶発的な上書きからプロダクションを保護
- デモ、テスト、または[匿名化]クライアントのデータを開発サーバーまたはステージングサーバーに非常に簡単にロードできます。
次に、どのくらい多くの種類のテストを実行する必要があるかという問題は、リスク/コストのビジネス評価であり、企業レベルで決定します。これは、さまざまなクライアントに重大な障害が発生した場合にビジネス全体が影響を受けるためです。 。
後で編集：これにより、私の命名規則を合理化するように促されました私のWeb製品（質問に感謝します）。私は4つの "環境"を決定しました。テストは、qa（機能をテストするための最小の単一層）とステージング（本番環境と同じアーキテクチャ、負荷/パフォーマンス/ボリュームテスト用）に分割されています。
プロビジョニングの本当の違いは、DBを別のシステムに本番/ステージングインストールすることです。これは、異なるサーバーがどのグループに属しているかによって制御します。qa/ devには、Webサーバーとdbの両方の役割があります。負荷分散はcloudflareによって行われます。
また、システムに渡されるENV_NO変数もあるので、必要なだけ「qa」または「ステージング」の例を選択できます。
したがって、ライブからの最新のバックアップを含む2番目のqa環境をセットアップするには、コマンドは次のようになります。
git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch
git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two
ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)
最後に、私は、「readonly」と呼ばれる追加の（オプションの）サーバーを、最初のセーフティネットとして使用しました。これはqaシステムのようにプロビジョニングされますが、昨夜のバックアップと更新が無効になっています（ソフトウェアも昨夜に更新されます）。
「別のバスケットのすべての卵」アプローチを使用します。別の場所/ DNSレジストラー、DNSホスト、システムホストサービスプロバイダーでプロビジョニングされます。これは究極の/最後の安全策なので、すべてが炎上した場合、少なくとも昨夜までのデータにアクセスできます。プロビジョニングスクリプトは異なるプロバイダー間の違いを分離するため、99％は同じで、読み取り専用フラグのみです。 Cloudflareロードバランサーは、すべてのライブサーバーに障害が発生した場合、トラフィックを読み取り専用サイトにリダイレクトします。
時間、お金、テスト容易性、品質を忘れて...評判はどうですか。
開発の経験が不足しているマネージャーがこのアイデアをサポートするための、環境を分離するための良い、シンプル、反駁できない理由。
berは最近、ライブ環境のパスワードを含むコードをgithubに出荷しました 、「ハッカー」がすべての顧客の詳細をダウンロードできるようにします。 Uberはそれは違反だったと言い、他の誰もが言う「ロックのキーを公開ビューに配置しないでください。開発者が開発環境で完全に作業した場合、彼らはgithubで開発環境のキーを解放した可能性がありますが、それは完全です。本番環境がリリースされたことは、本番環境でdevを実行するというこの考え方がいかに貧弱かを示しています。
間違いが発生することをマネージャーに思い出させるだけです。そのため、ジャーナリストの前で火をつけようとするCEOの前に彼が引きずり込まれ、技術者に笑われるのを防ぐ方法は、それらの間違いが壊滅的なものになるのを防ぐために簡単で明白な手順を実行することですもの。
変更を加える場合は、専門家の意見に耳を傾け、提案された変更を実装する人がいても幸運です。
私の経験では、私が大きな変更を行う必要があるたびに、ビジネスがもたらす節約についてそれを正当化しなければなりませんでした。たとえば、ReSharperを開発パイプラインに導入することは非常に簡単でした。
ReSharperは、開発者1人あたり約50ポンドです。年間の開発者の平均コストは4万ポンドです。 ReSharperは、開発者の生産性を最大限に活用して、少なくとも20％増加させる必要があります。開発者が自分の時間の75％を実際にIDEでコードを書くことに費やしているとしましょう。 40kの75％は£30kです。現在、3万ポンドは開発者の生産性のコストです。年間の生産性の追加パーセント（1％）は£300です。さらに20％の生産性を得るには、企業は6,000ポンドを費やす必要があります。
これをビジネスの観点から考えると、誰かを雇って6千ポンドでさらに20％の生産性を得ることができます。または、ReSharperライセンスに50ポンドを費やすことで同じ結果を得ることができます。数値がビジネスの前に出たら、決定は簡単になります。
ここで、複数の環境を持つことについての質問に関して、あなたがしなければならないのは、これらの環境を現在持っていることでビジネスに毎年かかるコストを計算する方法を見つけることです。
同僚の開発者に、開発、配備などのためにアプリケーションを構成するために毎週費やした時間を追跡するよう依頼することができます。たとえば、10時間の上級開発者の時間は、ビジネスに500ポンドかかるかもしれません。これは、開発に費やすことができる10時間、またはもっと重要なものです。一定期間の数値を収集し、ビジネスに年間コストを提供します。
私は個人的にこの種の政治を嫌っていますが、それは一般的であり、私たちはそれと共存しなければなりません。