About ways to define your environment

I don't know, how do you define your own project's environment, I say the environment is online (master), test (Beta), development (Dev), native (local) this, like we do by setting up the machine's host

// 环境选择if (gethostname() === 'TBJ-Test') {    define('ENV_MODE', 'dev');} elseif (gethostname() === 'TBJBeta') {    define('ENV_MODE', 'beta');}  elseif (strpos(gethostname(), 'TBJ-') === 0) {    define('ENV_MODE', 'local');} else {    define('ENV_MODE', 'online');}

Don't know what a better way to be than this?

Reply content:

I don't know, how do you define your own project's environment, I say the environment is online (master), test (Beta), development (Dev), native (local) this, like we do by setting up the machine's host

// 环境选择if (gethostname() === 'TBJ-Test') {    define('ENV_MODE', 'dev');} elseif (gethostname() === 'TBJBeta') {    define('ENV_MODE', 'beta');}  elseif (strpos(gethostname(), 'TBJ-') === 0) {    define('ENV_MODE', 'local');} else {    define('ENV_MODE', 'online');}

Don't know what a better way to be than this?

I have two options here:
One is written in the configuration file. However, this method is not very useful, especially when the project has a repository that needs to be continuously integrated, it will be more troublesome.
Second, through specific documents to identify, such as the online version of an release.lock empty file, the program detects that the file is considered to be on-line version, in the repository when you can ignore these several identification files.

Almost, on the server, custom environment variables
Like Laravel, in Nginx's config file.

fastcgi_param  APP_ENV            testing;

And then. The suffix of the env file is loaded according to the environment variable, and the. env.testing configuration file is loaded.
So now it's more customary to use this form

