web-dev-qa-db-ja.com

アプリケーションの開発/ステージング/本番バージョンを分割する方法

明確な解決策がないように思える状況に直面しているため、実際に何か間違っているのではないかと思います。ここでもう一度アドバイスを求めています。

私の問題をすばやく理解していただくために、製品コードを開発コードで分離するという点で、アプリのリリースやアプリの開発に問題があります。次に、詳しく説明します。

まず、これが私が過去に行った2つのことです。

単一のブランチ（git）で開発し、「dev」と言います。リリースする必要がある場合は、すべてを手動で「本番」状態に変更して、build-archive-releaseにすれば、問題ありません。

明らかな理由により、これは完全に保守不可能であり、単純なアプリをリリースする場合でも多くの作業を必要とします。

「dev」ブランチで開発し、満足したら、「beta」、次に「production」ブランチでマージし、出荷する必要があるブランチを出荷します。

これはより良い方法ですが、執拗なマージは「すべてを統治する1つのブランチ」の狂気と同じくらいエラーが発生しやすいと感じます。その上で、特定の構成ファイルに関しては、マージがファイルに対して正確に何を行うのかについて、私はかなり気づいていません。たとえば、devをベータ版にマージする場合、マージで選択するのはどのAPIキーですか？開発者またはベータキー？一部の資格情報またはバックエンドURLについても同様です。外側から見るとすっきりしますが、結局のところ、すべてのファイルを1つずつチェックすることになります。そして、私は悪い変化が起こったことがあります。悲しいことに、私は単なる偏執狂ではありません。

ですから、私はもっといいと思いますが、同じように保守可能です。

一部の人は#IF DEBUGしかし、コードが乱雑になり、2つの異なる環境のビットと断片がコードに広がってしまうので、私はそれに正反対です。結局、実際の製品をテストすることすらしないので、それは機能しません。

そして今、私はここにいます。他の人が何をしていて、彼らがその障害を克服する方法を知りません。是非聞きたいです。

注：ビルドサーバーについて少し読みましたが、実際にそれらを理解しているかどうかはわかりません。また、経験の浅い観点からは、リモートマシンで問題を解決しているように見えますが、ほとんど変わりません。

architecturegitdevelopment-processteamworkrelease-management
3
Gil Sand

ハードコーディングのように見える開発構成を本番構成から分離するために、異なるブランチを使用しないことを強くお勧めします。このタスクにSCMを使用すると、ますます異なるコードベースにつながります。

ビルドの違いを明確にするための優れた方法は、ビルドターゲットごとに1つのサブプロジェクトを作成することです。これらのプロジェクトでは、たとえば、メインコードから汎用ランチャーを拡張したり、環境固有のパラメーターを提供したりできます。構成ファイルを使用する場合でも、多くの場合、各ビルドターゲットのプロジェクトは構成ファイルを配置するのに適した場所です。

プロジェクトのレイアウトは次のようになります。

  • アプリケーション（ルートプロジェクト）
    • アプリケーションメイン
    • application-distribution-prod（application-mainを使用）
    • application-distribution-dev（application-mainを使用）

アプリケーションが大きく、さまざまなモジュールがある場合、さまざまな配布サブプロジェクトを作成するだけで、さまざまなモジュールアセンブリを作成できます。

本番環境と開発環境の間に複雑な違いがある場合、すべての可変的な側面をインターフェースに取り込むことをお勧めします。次に、これらのインターフェースを2つの異なるプロジェクトに実装します。環境間の切り替えは、依存関係の管理の問題になります。

拡張された例：

  • アプリケーション（ルートプロジェクト）
    • アプリケーションメイン
    • application-login-mock（application-mainからのログインAPIを実装）
    • application-login-google（application-mainからのログインAPIを実装）
    • application-distribution-prod（application-mainおよびapplication-login-googleを使用）
    • application-distribution-dev（application-main＆application-login-mockを使用）

この手法では、何らかの依存性注入またはサービスプロバイダーが必要になります。

2
chromanoid

12factor.netをご覧ください。アプリのメンテナンス性については、たくさんの良いアドバイスがあります。

彼らはすべての設定を環境変数として環境に保存することを提案しています。環境の選択された構成ファイルにそれらのいくつかを配置することなくそれらをスケーリングすることは難しいと思いますが、私は心から不同意変更可能なすべての変数をアプリケーションコードと一緒にパッケージ化するファイルに入れると言っている誰かのアドバイス。これは、細心の注意を払っていなければ、誤ってパスワードやその他のセキュリティ関連の情報を漏らしてしまう大きなチャンスです。

私はハイブリッドアプローチを採用する傾向があります。これは、静的ファイルにない場合、env varsから変数を受け入れることになります。次に、ファイルに機密変数を入れないでください。代わりに、本番システムのサービスアカウントを（一度）構成して、チェックインされないようにします。

CI/CDプロセスがある場合、手動のステップを削除したい場合は、デプロイ時にこれらの変数を構成するために使用されるローカルファイル（理想的には暗号化）を使用できます。

1
Paul