コード管理に git を使用する場合、開発ブランチ dev とオンライン ブランチ pro があります。
開発中、全員が dev ブランチから独自のブランチをプルして開発し、完了後に dev ブランチにマージします。
オンライン環境が更新されると、最新のコードが pro ブランチから取得され、サービスが再起動されます。
ここで問題が発生します。dev ブランチと pro ブランチには、構成ファイルや設定など、複数の異なるファイルが存在することがよくあります。この状況ではどのようなアプローチが適切でしょうか?
設定ファイルが git に含まれていない場合、設定ファイルを更新する必要がある場合は、オンライン環境でコードを手動で変更する必要があります。
どうやってやったの？ git を組み合わせて自動デプロイメントとロールバックを実現しますか?
ありがとう
高洛峰2017-05-02 09:27:01
実稼働環境と非実稼働環境 (開発環境、テスト環境など) の違いは、構成に加えて、依存するリソースも異なる場合があります。
ここで私が使用する一般的な方法は、運用環境と他の環境のすべての構成をその構成ファイル (または複数のファイル config/dev.json、config/pro.json...) に書き込み、構成プロセッサーを用意することです。これは、ローカル環境が何であるかを読み取り (これらは git のスコープに含まれており、初期化モジュールである場合もあります)、構成ファイルが 1 つしかない場合は、構成ファイル内の対応する環境の構成を読み取ります。 、これは次のようなものです:
リーリー設定プロセッサはどのようにして現在の環境を認識するのでしょうか? ここに 环境标识,比较直接粗放的可以是IP地址,比如生产环境是部署在某个固定IP(适合单服单应用情况)上,配置文件的生产环境配置就写在这个IP下面,那配置处理器取到当前运行环境的IP后,去读取配置文件指定IP模块的配置.
还有一种方式是在使用一个标识文件,比如应用运行的所有的环境下都有一个/data/tag文本文件(也可以在项目目录下,但是用.gitignore包含),这个文件不在git范围内就行,其中就只有一行,写了pro或dev,这样配置处理器通过读这个文件就知道取配置文件中的哪部分配置了.
最常用的方式还有环境变量,比如export APP_ENV=production があり、最初にこの変数を読み取り、次に環境の対応する設定を読み取る必要があります。
この構成サーバーでは、どのサーバーがどの構成を使用するかを個別に構成できます (通常は、リクエスターの IP で構成されます)。各アプリケーションは、起動時に構成サーバーにアクセスして独自の構成を要求します。 このようにして、アプリケーションは完全にステートレスになるために、設定ファイルはまったく必要ありません
、設定を好きなだけ細かく制御できます（たとえば、リクエストを増やしたい）特定のサーバーのトラフィックを削減し、グレースケールリリース（一部のサーバーに新しいコードをデプロイする）を実装するのが、現在ほとんどのインターネット企業で採用されている方法ではないかと思います
