複数の環境を持っていることの良い、簡単な理由

私のキャリアを通して、私はさまざまな目的のためにさまざまな環境のコレクションを持つ企業で働いていました。デスクトップ環境、テスト環境、QA環境、ステージング環境、実稼働環境は常に多かれ少なかれありました。これは、サーバー/アプリケーションと私たちが使用していたデータソースの両方に当てはまりました。

現在の会社で仕事を始めたとき、アプリケーションの90％が実稼働データソースに対するデスクトップ環境で開発されたか、プラットフォームに応じて実稼働サーバーで直接開発されたことがわかりました。これは特に驚くことではありませんでした。開発チームの機能を改善するために一部変更を加えるために雇われたため、インタビュープロセスから明らかでした。私たちはゆっくりと哲学を変え始め、ほとんどすぐに、ほとんどのアプリをデスクトップ、テスト、または実稼働環境で実行できました。ステージングもまたそう長くはかからなかった。

現在、ほとんどの開発者はこの方法論の利点を理解し、慎重に防御しています。ただし、移行されていない多くのレガシーアプリがあります。また、これを時間の無駄だと考える多くのレガシープログラマもいます。残念ながら、リップサービスは受けましたが、経営陣からの完全な賛同を得ることはありませんでした。約1年前にこれに実質的に投資するというコミットメントだと思いましたが、かなりの計画を立てましたが、何も実現しませんでした。今、私たちはますます多くの環境を必要としていることに気付いています。セットアップにはサーバー/ネットワーク管理チームの支援が必要であり、リリースサイクルをサポートするにはビジネス関係者の参加が必要です。合理的な開発者が「通常」と考える機能をプロジェクトが機能できる場所になりました

私は完全な議論をしたいと思いますが、経営陣は重大な問題があるまで私を聞くことに時間と関心を本当に持っていません。単にそれが私にとって常に第二の性質であるように思えたので、私は単に利点を実際に明確にすることはできません。開発経験のないマネージャーがこのアイデアをサポートできるようにする環境を分離するための良い、シンプルで反論できない理由があるのだろうかと思っていましたか？。トピックに関する優れたリソース/文学はありますか？

答え：お金

実際の理由はどうでもいい。特に経営を扱う場合、お金はあなたの推論のすべての根源でなければなりません。

我々の両方が2時間部屋に座っている場合、我々は思い付くことができ、数十、複数の環境を持っている方がよい理由の。

問題は次のとおりです。理由がお金に基づいていない場合、それらはどれも重要ではありません。

プログラマーは賢く雇われるわけではありません。彼らは創造的であるために雇われていません。彼らは収入を増やすために雇われている-お金を稼ぐか、お金を節約することによって。これらのいずれかを行っていない場合は、履歴書をまとめた方が良いでしょう。

その観点から見ると、答えは簡単です。

環境が1つしかない場合、ダウンタイムが増加し、収益が失われます。複数の環境により、当社と同様に信頼性と信頼性の高いフロントエンドをユーザーに提供することにより、利益を保護することができます。

毎日繰り返します。

この回答に真の価値を追加する素晴らしいコメントがいくつかありますので、それらについて言及します。

• Karl Bielefeldtは、費用/便益分析が重要な要素であると述べたときに大きなポイントを持ちました。エコノミストは、それを複数の環境を追求する機会費用と呼ぶかもしれません。聞いて驚くかもしれませんが、複数の環境が答えではないシナリオがあります！あなたの会社のウェブサイトがごくわずかな追加である場合、予期しないダウンタイムが実際にビジネスを行うより費用効果の高い方法である可能性があります。これはあなたがいる位置のようには聞こえませんが、言及する価値があります。

• BlairHippoには、それを大災害のように見せることができるという点がありました（そして、データを失った場合はそうです！）。責任はマネージャーを説得するための優れたツールですが、それでも同じ理由で、訴訟は高価です。それらを避けることはお金を節約します。

補遺として、この記事は非常に優れていることがわかりました。それはあなたの質問に直接答えるわけではありませんが、プログラマが経営者にどのように見られているかを認識でき、それがこの答えにつながります。よく読んでください。

単一障害点

開発環境またはステージング環境を持たないことにより、これらのレガシーアプリケーションの単一障害点が発生します。これらの用語でレガシーアプリケーションを説明すると、管理者に通知されます。

あなたにとって意味のあるサウンドバイトでメッセージを売り込むことができる必要があります。「Programmer Speak」を議論から外し、「Manager Speak」に置き換えます。また、ポイントを取得するために30秒のエレベーターに乗るふりをします。

私の上司が歩兵海兵隊員である状況がありました。私は彼に、生産性を上げるために海兵隊のためのソフトウェアツールとコンピュータートレーニングが必要だと言い続けました。彼は理解できませんでした。ある日、ようやく彼のオフィスに行き、物事が終わったと言いました。

「戦争をしているなら、棒、岩、木の枝を使います。手need弾、バズーカ、機関銃が必要です。」彼はメッセージを受け取りました。

それは実際に重要ですか？

別々の環境を使用したいという願望を理解できます。非自明の質問は次のとおりです。

レガシーシステムを移行することは実際に重要ですか？

技術的に最も関心のある人は、学問でどちらが良いかという学術的な問題に集中する傾向があると思います。しかし、ビジネスでは最高の結果が得られるとは限りません。私はこれが否定的だと言ったり、炎戦争を始めたりするつもりはありません。私は、ソフトウェアビジネスに数年間携わってきた私たちにとって明らかなこと、または明白であるべきことを述べています。

通常、すべてのビジネス上の決定は、認識されたコスト/利益に基づいて行われます。したがって、ビジネスがおそらく求めている質問は次のとおりです。

追加のシステムとレガシーアプリケーションへの開発投資のコストは、同じ投資を別のプロジェクト/製品に投資するよりも価値がありますか？

私は、ソフトウェアの移行/書き換えだけでなく、通常はリードが関与する日々の意思決定において、定期的な費用便益分析を行っております。寿命が限られているため、古いソフトウェアの書き換え/移行を行っています。したがって値。

環境の分離

ビジネス環境を分離するための理由。

• リリースのリスクが少なくなり、バグが修正されます。 数字で証明してください。不良なリリース/バグが原因で、製品が何回失敗し、顧客の収益を犠牲にしましたか。
• 開発のリスクが少ない。 開発データベースを誤って吹き飛ばすことは、本番データベースを誤って吹き飛ばすこととは異なります
• 役割とアクセスを明確に分離する機能。より良いセキュリティ。生産パイの指の数を制限することは良いことです
• 環境を分離する機能、およびこのスタイルの開発に沿ったプラクティスと手順により、クラウドシステムへの将来の構築が可能になります。
• 環境の分離は、環境の複製において効率を強制する必要があります。これは、スケジュールされたスケーリングおよび動的なスケーリングに役立つ場合があります。

すべての「正しい」議論がすでに整っているようです。代わりに、もしそうなら、あなたは「赤ニシン」を経験しています。または、「ニンジンを追いかける」

経営陣は、重大な問題が発生するまで、私に声をかけることに本当に時間と関心を持っていません

それが本当の問題だと思うものです。私の経験では、会社があなたが説明するほど劣った開発慣行を持っている場合。それは単に「これ以上良いことを知らなかった」という問題ではありません。むしろ、その問題を知らない（気にする？）上級経営陣によって引き起こされた技術的負債の集大成です。

そのような場合、良いペップトークはあなたの方向に物事を突然揺り動かすつもりはありません。ひどいトラウマ（クライアントに見える製品の不具合と、悪い習慣に直接結びついている）かもしれませんが、話をしようとする前に、私は確かに精通した技術者です。

私の提案は、それを吸い込んで、彼らが何であるかについて物事を取るか、新しい位置を探すことです。

一度にアプリで作業する予定の人々のグループはいくつですか？通常、人々のグループごとに1つの環境を見てきました。これは開発者（DEV環境とDEV統合環境を取得します-100％必要ではないと言う人もいれば、プロジェクトによって異なると思います）、2つのテスト環境（非常に詳細なテストを行うテスターのグループ、高レベルのQAテスター-通常、彼らは訓練を受けたテスターではなく、実際のビジネスユーザーです。通常、隔離されたパフォーマンステスト環境もあります（したがって、膨大な量のデータをテストしたり、膨大な量のユーザーをシミュレートしたりすることができます... g）。

なぜこれらすべての環境なのか？したがって、異なるグループは、お互いの足指を踏むことなく、異なる機能をテストできます。開発者とテスターが同じ環境で作業している場合、悪夢です。テスターは、開発者によって毎分アクティブに変更されている機能の欠陥を開くことができます。テストのレベルが2つある場合、異なるアクティビティに焦点を当てることができ、互いのデータを台無しにする心配はありません。分離されたパフォーマンス環境を使用すると、マシンをハングさせる可能性のあるテストを実行できますが、分離されている場合、他のテスターは影響を受けません。

同じ環境であまりにも多くの人がさまざまなことをしようとすると、あるグループが別のグループのテストが終了してから実行できるようになるまで、多くの時間が無駄になります。そして、それは時間を無駄にし、無駄な時間は無駄なお金につながる可能性があり、Stargazer712が指摘したように、これは最も強力な利益を上げることができます。

別の理由（一般的ではありません）：データ：アプリケーションに機密の個人データまたはクレジットカードデータがある場合、通常はそれをテスト環境に置くことができず、通常はQAおよび実稼働環境以外のすべてにマスキング要件があります。

職場に文化的な変化をもたらすために多大な努力を注いだようです。変化は最高の状態では困難ですが、文化の変化は単に人々の心を変えることではなく、習慣を変えること、偏見を打破すること、そして最終的には閉じられた心をより大きな可能性に向けることです。したがって、この時点で自問すべき質問は「何が恋しいですか？」です。簡単な答えは、あなたが管理に完全に関与していないかもしれないということです。

経営陣から賛同を得るのは簡単ですが、さらに難しいことは受け入れられています。お金などに関する議論に関係なく、現実には、経営者の優先順位の考え方に影響を与えることができる必要があります。あなたの上司は予算を持ち、予算が賢明に適用され、会社の価値と優先事項に従って維持されていることを示したいでしょう。これらの優先事項の中には財政的なものもありますが、他のものは他のニーズに応えるものです。場合によっては、これは上司が常に望んでいた昇進を得るために、他のマネージャーの手のひらに油をさすことを意味する場合があります。ただし、ほとんどの場合、ビジネスを拡大する方法を見つけること、またはパートナーや顧客との関係を改善することについてです。あなたがこれらの用語であなたの主張をすることができない場合、あなたは行き​​詰まりに自分自身を見つける前に、ここまでしか行くことができません。

私の提案は、他の人が示唆しているように、生産性とこれが予算にどのように影響するかについて主張することを試みることですが、あなたの会社の優先順位と、あなたの生産性が他の会社との関係に直接どのように影響する可能性があるかについても主張することです。

ここに1つあります：テスト容易性。

テスト環境があると、本番環境で実行することはお勧めできませんが、データベースでテストを実行できます。

組織のソフトウェア開発方法を変更したいですか？「違うことをする」ための「理由」を心配するのを忘れてください。理性的な議論のために人間は行動を変えません。彼らは習慣に対する心理的影響のために変化します。

それで、私はこれでどこに行くのですか？

一方で、時折あなたは成功した議論を通じて、組織の動作を変更することができ、より良い仕事他の戦術があります。これらは次のとおりです。

• Grassrootsのサポート：ショットを提供してくれる他の「レガシー」開発者を1人見つけてください。彼とパートナーを組み、物事の仕組みを変えてください。変更を発表しないでください。変更するだけです。誰かがあなたにそれについて尋ねるなら、「ああ、そうです、それが私たちが今それをする方法です」と言うだけです。

• 責任を引き継ぐ。レガシーな人々のための展開を処理するボランティア。あなたがそれを愛するように振る舞います。彼らは喜んでその責任を放棄するかもしれません。次に、希望どおりに実行します。

• 自分の過ちについて適切な人々を非難する。石器時代の展開メカニズムのために、次にレガシーアプリのバグが本番環境に導入されたとき、それを指摘します。微妙に...メールではありません。次回、マネージャーとの会議に出席するときは、展開に問題があった理由の例を簡単に言及してください。「ええ、ボブが本番環境にチェックインしたFooのバグが原因で先週の金曜日にスクランブルしていたことを覚えていますか？

• より良い方法で簡単に実行できます。たとえば、iphoneを見てください。ボタンが1つあります。（まあ、2）。電源を入れるのはとても簡単です。複数環境への展開をばかげたバカにするのは簡単です。すべてのマネージャーができるようにそれをとても簡単にしてください！

相互接続されたシステムやレガシーシステム、ビジネスが動作し、正確であるために依存しているシステムの取り扱いを開始するとき、それはより多くの問題です。ステージ間で分離する必要があるため重要です。これが、PRODでDEVを実行しない理由です。これは、失われた時間で数百万ドル相当の損害を与える可能性があるためです。

常に同じハードウェアを使用して、DEV-> QA-> PRODを実行します（場合によっては、これらのステップは小さな断片に分割されます）。現在の生産データは、常にPRODからQA、DEVにプッシュされます。

DEV：は、この環境内のデータに対して試行、反復、およびbeat打される開発サンドボックスを目的としています。開発者は、単に問題を解決する方法を見つけるだけで、定期的に破棄されます。

QA：開発者がユニットテストに満足したら、テストグループがユニットテストに注目する時間です。テストケース、パフォーマンステストを実行し、バグを見つけます。これらのバグ/機能拡張はDEVにフィードバックされ、誰もが満足するまでサイクルが続きます。

PROD：この段階に到達したら、コードが現在のデータと連携して機能し、QAグループ/ビジネスユーザーが実装に満足していることを確認する必要があります。すべてを正しく行った場合は、コードを更新してそれを行うことができます。

同様に、テストされていない製品を顧客にリリースすることは決してありません。テストされていないコードを実稼働環境にリリースすることはできません。

会社がそれを適切に行うための時間を投資する意思がない場合、緊急メンテナンスとエラーのコストを10倍に返済します。

簡単な例として、私たちは自分で制作中のレポートに変更を加えることを決めた会社がありました。1年か2年後にさまざまな問題に対処するために私たちが参加するまで、それが変わることを誰も知りませんでした。

レポートで不規則性を指摘したとき、CFOの顔が白くなったのは、誰かが急いで変更を加えたために四半期に250,000ドルを失っていたことがわかりました。

あなたが思うよりも頻繁に起こる、あなたがそれを適切に行う余裕がないなら、それをしてはいけない。

これらの環境を生成する必要のあるソフトウェア会社とソフトウェア製品の成功の背後には、経営陣が大きな役割を果たしています。プロジェクトの例を見てみましょう。ソフトウェアが大規模に開発されている場合、プロジェクト要件、プロセス制御、テストビルドなどを管理しないと、失敗する可能性があります。プロジェクト管理が存在するように。

@ Stargazer712はあなたの声明がMoneyの問題を指していることに多少同意しますが、ソフトウェア開発に関するMarc Hamiltonの本から得た次の声明を確認してください：信頼性の高いシステムの構築（Prentice Hall PTR、1999、ISBN 0-13-081246- 3）。これらすべての要因を調べた後、あなたの質問についての私の意見は、シングル環境はあなたに節約を与えない、それはプロジェクト/ソフトウェアを完了するために長期的なプロセスを作るだろうということです。分散環境は、私がキャリアを始めた新興ソフトウェア企業で何が起こったのかを学んだ経験から見て、時間と収益を節約します。

成功のために重要なことを示す多くの記事があります。これをチェックして、成功するソフトウェア開発のために組織してください

組織内の各個人には特定のスキルがあり、これらのスキルは通常、将来のパフォーマンスに対するインセンティブとしての報酬（報酬）につながる公式または非公式のパフォーマンスメトリックに対して測定されます。組織内の人々は、その文化、つまり一般的に採用されていると認識されている行動パターンと価値を確立します。

多くのソフトウェア開発者は、不適当な組織構造との戦いに全時間を費やさなければならない場合、苦労し、最終的には目標を達成できません。

多くのソフトウェアスタートアップは、ガレージで働く2人以上の開発者で生活を始めています。会社の歴史のこの時点ではそれほど多くの組織構造は必要ありませんが、組織構造はまだ存在しています。たとえば、1977年にビルゲーツとポールアレンがパートナーシップを結び、正式にマイクロソフトと命名したとき、会社の組織構造は最小限でした。ニューメキシコ州アルバカーキにあるマイクロソフトの最初のオフィスで働いていた従業員は12人に満たず、誰もが誰が担当しているかを知っていました。全員のレポート構造を把握するのに複雑な組織図は必要ありませんでした。同時に、すべての従業員は会社での役割と達成しようとしていることを知っていました。これは、必要な組織構造を各従業員間で非公式に伝達できるためです。

時間、お金、テスト容易性、品質を忘れましょう... 評判はどうですか。

開発経験のないマネージャーがこのアイデアをサポートできるようになる環境を分離するための良い、シンプルで反論できない理由。

Uberは最近、ライブ環境のパスワードを含むコードをgithubに出荷し、「ハッカー」が顧客の詳細をすべてダウンロードできるようにしました。Uberによると、これは違反であり、他の人は「キーを公開ビューにロックしないでください。開発者が開発環境で完全に作業している場合、githubで開発環境のキーをリリースしたかもしれませんが、それは完全に実稼働環境でリリースされたことは、実稼働環境で開発を実行するというこのアイデアがどれほど貧弱であるかを示しています。

マネージャーにミスが発生することを思い出させてください。ジャーナリストの前でグリルを手に入れようとしていて技術大衆に笑われようとしているCEOの前に引っ張られないようにする方法は、それらのミスが壊滅的なものになるのを防ぐための簡単で明白な手段を講じることですもの。

多くの異なる環境を持っているように聞こえますが、「環境」をセットアップするのに多くの時間を費やしています。

逃げることができる「環境」の数は最小限にする必要がありますが、あなたと会社が望む多くの理由で多くのコピーを複製することができます（「システム構成を意味する環境」を使用して）！

最適な唯一の違いは次のとおりです。

1. サイズ（最小、推奨、最大サポート/テスト済み）;
2. ステージングとプロダクションには開発ツールがありません
3. 本番環境は偶発的なデータの上書きから保護されています
4. デモ、テスト、または[匿名化]クライアントデータを開発またはステージングサーバーに非常に簡単にロードできます。

その後、どの程度のテストを行うべきかという問題は、リスク/コストのビジネス評価であり、企業レベルで決定されます。これは、重大な障害がさまざまなクライアントに及ぶとビジネス全体が苦しむためです。 。

後の編集：これにより、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)

最後に、地面に着く前の最後のセーフティネットとして「読み取り専用」と呼ばれる1つの追加（オプション）サーバーがあります。qaシステムのようにプロビジョニングされますが、昨夜のバックアップと更新は無効になっています（ソフトウェアも昨夜に更新されます）。

「異なるバスケット内のすべての卵」アプローチを使用します。異なる場所/ DNSレジストラ、DNSホスト、システムホストサービスプロバイダーでプロビジョニングされます。これは究極の/最後の安全策であるため、すべてが炎上した場合、少なくとも昨晩までデータにアクセスできます。プロビジョニングスクリプトは異なるプロバイダー間の違いを分離するため、99％は同じで、読み取り専用フラグのみです。すべてのライブサーバーに障害が発生した場合、Cloudflareロードバランサーはトラフィックを読み取り専用サイトにリダイレクトします。

変更を行う場合、専門家の意見を聞いて、提案された変更を実施するだけの人がいるのは幸運です。

私の経験では、大きな変化を起こさなければならないたびに、ビジネスがもたらす節約の観点からそれを正当化する必要がありました。たとえば、ReSharperを開発パイプラインに導入するのは非常に簡単でした。

ReSharperの開発者あたりの費用は約50ポンドです。年間平均開発者費用は4万ポンドです。ReSharperは、開発者の生産性を最大限に活用して、開発者の生産性を少なくとも20％向上させるはずです。開発者が実際にIDEでコードを記述するのに費やす時間の75％を費やしているとします。4万の75％は3万ポンドです。現在、3万ポンドが開発者の生産性のコストです。年間生産性の追加パーセント（1％）は300ポンドの費用がかかります。さらに20％の生産性を得るには、企業は£6,000を費やす必要があります。

これをビジネスの観点に入れた場合、他の人を雇ってさらに6,000ポンドで20％の生産性を得ることができる、またはReSharperライセンスに£50を費やすことで同じ結果を得ることができます。数字がビジネスの前に出れば、決定は容易になります。

ここで、複数の環境を使用する場合の質問に関して、あなたがしなければならないのは、これらの環境を現在持つために毎年ビジネスにかかる費用を計算する方法を見つけることです。

仲間の開発者に、開発、展開などのためにアプリケーションを設定するために毎週費やされる時間を追跡するよう依頼することができます。たとえば、上級開発者の10時間は500ポンドの費用がかかります。それは開発に費やすことができる10時間、またはもっと重要なことです。一定期間の数値を収集し、ビジネスに年間コストを提供します。

私は個人的にこの種の政治を嫌いますが、それは一般的であり、私たちはそれと共に生きなければなりません。