When using git for code management, there are development branch dev and online branch pro.
During development, everyone will pull their own branch from the dev branch, develop it, and merge it into the dev branch after completion.
When the online environment is updated, the latest code will be pulled from the pro branch, and then the service will be restarted.
There is a problem here. The dev branch and the pro branch often have several different files, such as configuration files, settings, etc. What should be the appropriate approach in this situation?
If the setting file is not included in git, if the configuration file needs to be updated, the code needs to be modified manually in the online environment.
How did you do it? Combining git to achieve automated deployment and rollback?
Thank you
Differences in environment:
The difference between production environment and non-production environment (such as development environment, test environment, etc.), in addition to configuration, there may be some dependent resources that are also different.
Profile:
The common method I use here is to write all the configurations of the production environment and other environments into that configuration file (or multiple files config/dev.json, config/pro.json...), and then have a configuration processor It will be responsible for reading what the local environment is (these are included in the scope of git, and may be the initialization module), and then read the configuration of the corresponding environment in the configuration file. If there is only one configuration file, it is similar to the following:
Environmental label
How does the configuration processor know what the current environment is? There needs to be a
环境标识
,比较直接粗放的可以是IP地址,比如生产环境是部署在某个固定IP(适合单服单应用情况)上,配置文件的生产环境配置就写在这个IP下面,那配置处理器取到当前运行环境的IP后,去读取配置文件指定IP模块的配置.还有一种方式是在使用一个
标识文件
,比如应用运行的所有的环境下都有一个/data/tag文本文件(也可以在项目目录下,但是用.gitignore包含),这个文件不在git范围内就行,其中就只有一行,写了pro
或dev
,这样配置处理器通过读这个文件就知道取配置文件中的哪部分配置了.最常用的方式还有环境变量,比如
export APP_ENV=production
here, and then read this variable first and then read the corresponding configuration of the environment.Config Server
In the later period, as most applications are deployed in a distributed manner, that is, the same application may be deployed to more than 20 or more servers. At this time, there must be a config server to specifically handle, distribute, and update the application configuration of each server. .
On this config server, you can independently configure which servers use what configuration (usually configured with the requester's IP). Each application will go to the config server to request its own configuration when it starts.
In this way, the application can do To be completely stateless, there is no need for configuration files at all, and the configuration can be controlled as fine-grained as you like (for example, I want to increase the request traffic of a certain server), and implement grayscale release (deploy new code on some servers), I I think this may be the method adopted by most Internet companies at present.
Set the ignore file and store different configuration parameters in the ignore file.