ソフトウェア開発における環境命名基準?


15

私のプロジェクトは現在、環境の命名の問題に悩まされています。異なる環境では、どの環境に名前を付けるべきか、名前が何を指定するかについて異なる仮定を持っているため、それらを議論するときに混乱を引き起こしています。私は少し研究をしましたが、そこに標準は見つかりませんでした。

用語には、「ローカル」、「サンド」、「開発」、「テスト」、「ユーザー」、「QA」、「ステージング」、および「製品」が含まれます(さらに、さまざまな人々が尋ねたものもあります)

意見だけを探しているわけではありませんが、「誰もが」持っているものがあれば、それを受け入れます-非公式であっても、何らかの権限によって高度な定義を見つけようとしています。

現在使用している環境は次のとおりです。

  1. 開発者のPCの環境
  2. 開発者が自己テストにコードを直接アップロードする共有環境
  3. QA担当者が標準と機能をテストする共有環境
  4. 完成したQAチェック済みコードがプロジェクトリクエスターによって承認される共有環境
  5. 最終チェックとして、および展開の準備として最終環境をミラーリングする環境
  6. コードが使用されている最終環境

私はそれらを何呼ぶか知ってますが、これには何らかの標準がありますか?前もって感謝します。


ありがとう。私はそのSEを知りませんでした。ServerFaultやSuperUserに属していないことは知っていましたが、programmers.seのことは聞いたことがありません。

移動のフラグを立てたので、理想的には適切なサイトへの道を見つける必要があります。
リカルドアルタミラーノ

プロジェクトの範囲に応じて、環境の数は少なくなる場合も多くなる場合もあります。
ユスボフ

回答:


11

固定された標準がないだけでなく、実際には固定されたパターンもありません。構築しているものとそれを複製できる規模との間の依存関係は、ある種のプロジェクトから別のプロジェクトへの外観を決定します。

私はたった1つの環境と13もの環境で作業しました。

あなたが説明するシーケンスでは、私は通常、それらのような名前が表示されます

  1. 次のステップでdevを使用しない場合は、localまたはdev
  2. devまたは統合(これがマージ後の最初のデプロイである場合)
  3. テストまたはQA
  4. 手順3でQAを使用しなかった場合は、uatまたはacceptまたはQA
  5. 最終サインオフのパフォーマンスステップである場合は、事前準備、ステージング、またはパフォーマンス
  6. 製品

私のアドバイスは、すべての製品またはプロジェクトごとにそれぞれ名前と目的、および出入りする基準に同意することです。その後、7番目の環境が必要であるか、将来何らかの理由で5つだけが必要であることがわかったときにチーム。

名前のセマンティクスにこだわっているチームメンバがいる場合は、常に名前を削除して、prodマイナス6からprodマイナス1としてそれらを参照できます。1人のマネージャーが環境でのQAスタッフのテストを拒否しただけです。 「QA」という名前ではありませんでした

サーバー自体に名前を付けたい場合は、通常、サーバーの権限に基づいて名前を付けることをお勧めします。通常、これは次のようになります。

  • 開発者は開発マシンを操作できます
  • QAマシンは開発者が操作することはできませんが、本番サポートでは監視されません
  • prodマシンはprodサポートのビジネスです

ほとんどの人はこれらの種類の名前を接頭辞または接尾辞として使用するため、「devsqllweb」、「qasqlweb」、「prodsqlweb」などのようなチェーンができます。


あなたは基本的に私が来た結論を述べている。基本的に任意の標準を設定せずに状況を解決できるように、何らかの標準があることを望んでいました。私の問題は、私たちの「メイン」環境構造が、私が取り組んでいるこのプロジェクトよりも環境が少ないことです(したがって、通常使用しているものをミラーリングすることはできません)。同じ基準があります。この質問をさらに数時間開いて、誰かがチャイムを鳴らすかどうかを確認しますが、これは私が恐れていた答えです。
-Marcus_33

私はこれの標準を見てきました。残念ながら、これらはある種の状況に固有の意見または非常に具体的な基準の一種です。
ビル

2

私は、より構造化され、規制された業界から来ているのではないかと思いますが、サーバーに名前を付けるという選択肢は私にはない贅沢です。当社のサーバーは、当社のITポリシーに従って名前が付けられているため、マシンの実際のホスト名は管理できません。

私たちがやったことは、DNS名とエイリアスのルートがなくなったことです。ルールは、開発プロセス(ゾーン)でのサーバーの一般的な役割を識別する最初の文字です

  • p =生産
  • d =開発
  • s =ステージング
  • t =テスト

次に、マシンの役割を識別する最大3文字の名前があります

  • app =アプリケーション
  • db =データベース
  • web =フロントエンド/ web
  • kas =キャッシング

そのゾーンに複数のマシンがある場合、数字が続きます。これを内部のドキュメントサーバーで公開し、プロジェクトの新しいドキュメントの一部として、およびブートストラップ段階で提供します。

これらは、開発プロセスの一部であるサーバー用です。サポートマシンには、より自由なポリシーがあります。新しい補助サーバーをプロビジョニングする必要がある場合は、開発チームに好みの名前を付けるよう依頼します。

これはいくつかの興味深いものにつながりました。私の2つのお気に入りはcerberus(内部プロキシ)ボックスとhades(ドキュメントサーバー/イントラネット)です。

これはベストプラクティスではないと確信していますが、これは私たちが使用するものであり、私たちにとっては有効です。


1

固定の定義はありません。一般的なプラクティスで使用されているものがいくつかあります(リストされています)。Toy Storyで各環境にキャラクターの名前を付けたい場合は、できます(ただし、推奨しません)。

私がやることは、会社の用語集を作成することです。この用語集では、使用する名前を指定します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.