タグ付けされた質問 「configuration-management」

アプリケーションの構成には常にJSONファイルを使用しています。私は多くのJavaをコーディングしたときからそれらを使い始めましたが、現在は主にサーバーサイドとデータサイエンスのPython開発に取り組んでおり、JSONがこれ以上正しい方法であるかどうかはわかりません。 Celeryが実際のPythonファイルを構成に使用するのを見てきました。当初、私はそれについて懐疑的でした。しかし、構成に単純なPythonデータ構造を使用するという考えは、私に成長し始めています。いくつかの長所： データ構造は、通常コーディングしているものと同じです。そのため、心のフレームを変更する必要はありません。 私のIDE（PyCharm）は、構成とコードの関係を理解し​​ています。Ctrl+ Bを使用すると、構成とコードを簡単に切り替えることができます。 IMOの不要な厳密なJSONを使用する必要はありません。二重引用符、末尾のコンマ、コメントはありません。 作業中のアプリケーションでテスト構成を作成し、変換やJSON解析を行わずに簡単に構成ファイルに移植できます。 本当に必要な場合は、構成ファイルで非常に簡単なスクリプトを実行することができます。（これは非常に制限されるべきですが。） だから、私の質問は次のとおりです。切り替えた場合、どのように自分の足を撃ちますか？ 熟練していないエンドユーザーが構成ファイルを使用することはありません。構成ファイルへの変更はすべてGitに現在コミットされており、継続的な展開の一部としてサーバーにロールアウトされています。緊急事態があるか、開発中でない限り、手動で構成を変更することはありません。 （私はYAMLを検討しましたが、それについて何かが私をいらいらさせます。それで、今のところ、それはアメリカのテーブルから外れています。）

72 python  json  configuration  configuration-management  python-3.x 

私のチームはソース管理にTeam Foundation Serverを使用しています。今日、チェックインする前にいくつかのバグとスモークテストアプリケーションを修正しましたが、コードをコメントするのを忘れていました。（このコードにより、UIが少し奇妙になりました。） コードをチェックインする前に、どのような優れたプラクティスがあるのか​​を知りたい-この種の間違いを二度とやりたくない。

47 version-control  team-foundation-server  configuration-management 

ほとんどの場合、次のように、プロジェクトのルートディレクトリに開発アプリケーションの構成を保存します。 app |-- config.json しかし、この設定はバージョン管理システムに保存され、ユーザー名、パスワード、その他の機密情報が漏洩する可能性があるため、これは最善のアプローチではないようです。 12ファクターアプリガイドでは、構成ファイルをすべて削除し、構成セットアップに環境変数を使用することをお勧めします。 ...環境変数に設定を保存します。Env変数は、コードを変更せずにデプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコードリポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルやJavaシステムプロパティなどの他の構成メカニズムとは異なり、これらは言語およびOSに依存しない標準です。 それは本当にいいように思えますが、ソース変数にチェックインせずに、前述の環境変数をどこに保存しますか？そして、これらの変数をアプリに渡すためにどのツールを使用できますか？多数の設定オプションが存在する可能性があり、アプリを起動するたびに手動で入力するのは好ましくありません。したがって、それらはどこかの種類のファイルに保存する必要があります。したがって、このファイルはソース管理になり、元の場所に戻ります。 構成オプションを処理する一般的に受け入れられている方法はありますか。ソース管理にローカル構成を保存するリスクはありませんか？

38 architecture  configuration  configuration-management 

このプロジェクトでは、ユーザー固有の構成ファイルを使用します。このファイルは、ユーザーごとに異なるため、現在バージョン管理されていません。問題は、開発者が構成を必要とする新しいモジュールを追加するか、既存のモジュールの名前を変更すると、プライベート構成ファイルが更新されないため、他の開発者にエラーが発生することです。 この問題を解決するために、2つの構成ファイルで作業することを考えました。バージョン管理になり、新しいモジュールを追加する各開発者によって定期的に更新されるデフォルト/グローバル構成ファイルと、除外されるプライベート構成ファイルバージョン管理され、ユーザー固有の変更のみが含まれます。 ただし、これは依然としてアドホックなソリューションのようです。 より良い解決策を提案できますか？ 専門家は何をしますか？

36 version-control  configuration-management 

私が開発者として働いてきたこの3年間で、ユーザーがswitchステートメントを使用してURLのパス（バックエンドとフロントエンドの両方）を設定する多くの例を見てきました。以下に例を示します。 バックエンドの例（C＃）： public static string getHost(EnvironmentEnum environment){ var path = String.Empty; switch (environment) { case EnvironmentEnum.dev: path = "http://localhost:55793/"; break; case EnvironmentEnum.uat: path = "http://dev.yourpath.com/"; break; case EnvironmentEnum.production: path = "http://yourpath.com/"; break; } return path; } フロントエンドの例（JavaScript）： (function () { if (window.location.host.indexOf("localhost") !== -1) { window.serviceUrl = "http://localhost:57939/"; } else …

32 programming-languages  programming-practices  configuration-management  routing 

これは非常に基本的な質問です。誰かが私にユーモアを与え、彼らがこれをどのように処理するかを教えてくれたら、私はとてもうれしいです。 SynchToyをインストールして以下の問題を修正しようとしているため、これを投稿することにしました。 この状況にいると、何度も痛みを伴う明白な方法を見逃しています。これは、会社で唯一の開発者であることに起因しています。 職場のコンピューターで開発されたASP.NET Webアプリケーション ソリューションには2つのプロジェクトがあります。 ウェブサイト（ファイル） WebsiteLib（C＃/ dll） Gitリポジトリを使用する GoGrid 2008R2 Webサーバーに展開 展開： コードを変更します。 Gitにプッシュします。 サーバーへのリモートデスクトップ。 Gitからプルします。 Windowsエクスプローラーでドラッグ/ドロップして、ライブファイルを上書きします。 ステップ5では、Webサイトのルートからすべてのファイルを削除します。これは良いことではありません。だから、SynchToyをインストールしようとしています... 更新：すべての有用な応答に感謝します。答えをマークするものを選択することはできません-Web展開を使用する間に-いくつかの有用な提案があるように見えます： Webプロジェクト=単一のDLLにパッケージ化されたサイト全体-単純な更新をプッシュすることはできません-50人の会社の孤独な開発者であるため、これは時々より単純なもののままです。 SCMからサイトのWebルートに直接移動します-私はもともと、SCMの隠しディレクトリが公開されることを恐れてこれをしませんでしたが、ここでの回答はそれを乗り越えるのに役立ちました（私はまだ1確認するのを忘れることを心配することは、時間の経過とともにまだ真実です） Webファームを使用し、ノードに体系的に展開する-これは、ダウンタイムがゼロの理想的なソリューションです。これは、サイトが本質的に会社のリアルタイムの収益源であるため、実際に私が気にしていることです。ただし、サーバーのコストは2倍になります。 ->最後に、サイトのシングルクリック展開が必要であるか、または他に何か間違っている必要があるという基本原則の強化は、おそらく私が答えから得た最も有用なものです。 更新2：私はこれに戻って、今何ヶ月もの間存在し、完全に機能している実際のソリューションで更新すると思った（私の単一のWebサーバーソリューション）。 私が使用するプロセスは次のとおりです。 コードを変更する Gitにプッシュ サーバーへのリモートデスクトップ Gitからプル 次のバッチスクリプトを実行します。 cd C：\ Users \ Administrator ％systemroot％\ system32 \ inetsrv \ appcmd.exe停止サイト "/site.name:Default Web Site" robocopy Documents \ code …

21 web-development  deployment  websites  release-management  configuration-management 

プロジェクトの構成を保存したい 画面サイズ スクリーン位置 フォルダーパス ユーザー設定など。 これらを保存できる標準的な場所は、構成値です。 登録 INIファイル 個人用ファイル（* .cfgなど） これらの場所からどのように選択しますか？また、それらのいずれかを使用することの長所と短所はありますか？

19 windows  microsoft  configuration-management  persistence 

私はDI / IOCの大ファンです。ハードな依存関係の処理/抽象化に最適であり、作業が少し楽になります。 しかし、私はそれについて少し不満があり、それを解決する方法がわかりません。 DI / IOCの基本的な考え方は、オブジェクトがインスタンス化されると、その依存関係はすべてコンストラクター内で事前に入力されるということです。 ただし、IMHOには、コンストラクター用のパラメーターのタイプがいくつかあります（特にオブジェクトが不変の場合）。 依存関係（オブジェクトが機能するために必要なオブジェクト） 構成（作業を行うために必要な環境に関する情報） パラメーター（作業が行われるデータ） IOCは依存関係でうまく機能することがわかりました。しかし、私はまだ他の2つに対処する最善の方法を考えています。ただし、コンストラクターはIOCコンテナーによって実行されるように実行されるため、これらのアイテムをIOCコンテナーに配置する必要があるようです。 人々が採用している戦略/パターンと、人々が発見した利点と欠点を知りたい。 NB。これは非常に主観的な質問であることを認識しており、SEガイドラインに従って「良い」主観的な質問にしようとしました。

18 design-patterns  configuration-management  inversion-of-control 

私は、分散バージョン管理のタオで自分自身を再教育するのに苦労している別のSubversionユーザーです。 Subversionを使用するとき、私はプロジェクトマイナーアプローチの大ファンであり、以前の雇用主のほとんどと一緒にリポジトリブランチを構築しました。次のようなタグとトランク： branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk 実際のソースツリー内では、次のような構造（のようなもの）を使用します。 (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | …

16 mercurial  organization  continuous-integration  svn  configuration-management 

多数のサーバーがあるシステムを想像してください。それぞれに多くの設定があります： サーバーに固有のもの 地域固有のいくつか それらすべてに共通するもの このグループのサーバーは読み取り専用であるように、カスタムグループを作成できます 等 私が念頭に置いている現在のプラクティスは、オーバーライド機能を持つ単純なプロパティ構造です。 例の目的でGoogleサーバーを使用してみましょう。それぞれにロードする設定のリストがあります。 たとえば、ロンドンのサーバーには次のものがあります。 rootsettings.properties、europesettings.properties、londonsettings.properties、searchengine.properties、など 各ファイルに一連のプロパティが含まれており、読み込みシーケンスを使用するとプロパティをオーバーライドできます。 たとえば、次のようにrootsettings.properties持っていることがありaccessible=false、デフォルトとして、しかしでオーバーライドされるsearchengine.propertiesとaccessible=true 私がこの構造で抱えている問題は、制御不能になるのが非常に簡単なことです。構造化されていないため、任意のレベルで任意のプロパティを定義でき、多くのアイテムが廃止される可能性があります。 さらに、ネットワークの成長に伴い、非常に多くのサーバーに影響を与えるため、中間レベルの変更は不可能になります。 最後に重要なことですが、個々のインスタンスにはそれぞれ1つの特別なプロパティが必要になる場合があります。つまり、ツリーは最終的に各サーバーの構成になり、最適なソリューションではなくなります。 より良い構成管理アーキテクチャの提案/アイデアがあれば、私は大歓迎です。

15 configuration  configuration-management  properties 

バージョン管理管理システムで多くのコンポーネントを持つ大きなプロジェクトを管理する方法を知りたいです。 私の現在のプロジェクトには、4つの主要な部分があります。 ウェブ サーバ 管理コンソール プラットホーム。 Webとサーバーの部分は、私が書いた2つのライブラリーを使用します。合計で5つのgitリポジトリと1つのmercurialリポジトリがあります。プロジェクトビルドスクリプトはプラットフォームリポジトリにあります。構築プロセス全体を自動化します。 問題は、複数のコンポーネントに影響する新しい機能を追加するときに、影響を受ける各レポジトリに対してブランチを作成する必要があることです。機能を実装します。それを元に戻します。私の直感は「何かが間違っている」です。 単一のリポジトリを作成し、そこにすべてのコンポーネントを配置する必要がありますか？その場合、分岐が簡単になると思います。または、私が今やっていることをやるだけです。その場合、各リポジトリにブランチを作成するこの問題をどのように解決しますか？

13 version-control  branching  configuration-management  merging 

ユーザーが設定する必要のあるいくつかの変数を含むシェルスクリプトを作成しています。おそらく一連の質問をすることで、スクリプトをダウンロードして構成するためのインストーラーがあります。問題のスクリプトは、他の開発者を対象としています。 これは、いくつかの方法で実装できます。 スクリプト自体でプレースホルダーを使用し、sedインストール中にそれらを置き換えるために使用します（/programming/415677/how-to-replace-placeholders-in-a-text-fileのようなもの） 長所：すべての変数定義はスクリプト内に含まれています。スクリプトを手動でダウンロードし、インストーラーよりもエディターを好むユーザー向けに変数を構成するのは簡単です。 短所：インストーラーを使用して変数を設定し直すと、変数を再構成するのは困難です。エラーが発生しやすい、より複雑な正規表現を作成しない限り。 configファイルを使用します。基本的に、割り当てのある別のシェルスクリプトを使用sourceして、それを使用します。（そして、おそらくそれを配置し~/.scriptnameますか？メインスクリプトはにコピーされます/usr/local/bin） 長所：スクリプトの再構成は簡単です。メインスクリプトからそれを行うためのパラメータを追加することもできます（おそらく最初のソリューションでも動作しますが、それ自体からスクリプトを編集することは非常に良い考えのようには聞こえません） 短所：スクリプトは2つのファイルに依存するようになり、ユーザーは構成ファイルを作成するためにインストーラーを実行する必要があります。これは、構成ファイルが存在しない場合に構成ファイルを自動生成することで解決できます。ただし、外部の構成ファイルを見つけることは、スクリプトをダウンロードし、編集し、それを実行したいだけのユーザーにとっては依然として面倒です。 また、インストール後にユーザーが構成を管理する方法に関するいくつかのオプション： $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxyのようなGit $ myscript config server.httppath / home / johndoe / web Interactive $ myscript config サーバーのホスト名を入力します 。example.orgサーバー上のプロキシへのパスを入力します：/ home / johndoe / proxy サーバー上のhttpディレクトリへのパスを入力します：/ home / johndoe / …

13 configuration  configuration-management  shell  bash 

ご覧のとおり、コミュニティのメンバーにConfiguration Managerの役割についてお聞きしたいと思います。以前に質問されていた限り、Configuration Managementが何であるかは尋ねません。私が知る必要があるのは： Configuration Managerはチームでどのようなタスクを実行する（または実行する）と思いますか？ Configuration Managerの主な責任は何ですか？ Configuration Managerの二次的/補助的な責任とは何ですか？ Configuration Managerはプロジェクト/会社の開発プロセスを担当する必要がありますか、それとも何をすべきかを伝える必要がありますか？ 構成マネージャー、ビルドマネージャー、リリースマネージャー、展開エンジニア、CIエンジニアの役割の関係は何ですか？それらはすべて同じではありません-構成管理？ おそらく、構成管理という用語は冗長であり、代わりにテクニカル/チームリーダーが関連するすべての作業を行う必要がありますか？ あなたのビジョンと経験を共有できたら本当に素晴らしいでしょう。

11 team  teamwork  configuration-management  role 

2つのスクラムチームが同じソフトウェアコンポーネントを使用する場合、そのコンポーネントの明確なアーキテクチャビジョンを提供し、コードベースの進化に合わせてこのビジョンを維持/開発する責任を持つのは誰ですか？スクラムでは、共同でコードを所有することになっているので、チームAが行った開発がチームBが行った開発に干渉しないようにする方法を教えてください。

10 architecture  scrum  code-quality  configuration-management 

ソフトウェア構成について考えるとき、ランタイムによって読み取られるファイルについて考えます。このファイルには、サーバーが使用するポート、暗号化を使用するかどうか、さまざまなリソースのパスなどが含まれます。 最初に「ソフトウェア構成管理」に出くわしたとき、それは構成ファイルの管理だけを意味すると思っていましたが、SCMツールは構成ファイルだけでなく、ソフトウェアコード、ソフトウェア実行可能ファイル/バイナリ、およびリソースにも関係していることにすぐに気付きました。 では、なぜ「ソフトウェア構成管理」という用語を使用するのでしょうか。「ソフトウェア管理」はもっと包括的ではないでしょうか？それとも、「構成」と見なされるものについての私の理解は不足していますか？

9 terminology  configuration-management