3 minutes to learn multi-environment knowledge in enterprise development

Hello everyone, I am fishskin, today to share with you the important knowledge of enterprise project development – multi-environment.

Outline of this paper:

What is multi-environment?

Let’s start with a question.

Let’s say we have a web site that millions of users are using, and the web files are deployed on several servers. So now we’re going to launch a new feature, how do we do that?

Little brother abba asked: write good code, directly update the server on the web page file?

I slap away: that if your code has a Bug, won’t it affect the use of online users?

My brother thought: that after writing good code, after the local test runs no problem, and then released online?

Me: That’s a good idea, but the problem is that if you run your project locally and online, the same database is connected, then when you test locally and insert fake data into the database, or change the structure of the database table, it will affect the online data.

Brother clap hands: right, that how to make the local test does not affect the online project?

This requires multiple environments. According to the actual needs, the same project (or the same set of code) according to a certain method to distinguish, and the required resources and the project itself deployed to different machines. Projects in different environments can have different behaviors and can coexist without affecting each other.

For example, you can set up a development environment for an online project. The data of the development environment is stored in a separate development database, and for debugging convenience, all user data can be accessed without logging in:

In this way, local and online projects are completely separated, and developers can do whatever they want locally! This is the benefit of multiple environments.

Common environment

Having multiple environments sounds great, but in fact, the more environments the better!

On the one hand, it takes extra work to build multiple environments. On the other hand, the more resources a project relies on, the more expensive it is and the more difficult it is to maintain.

Therefore, there are only a few commonly used environments in the enterprise, which are almost becoming a conventional norm. Here is an introduction.

For your information, different teams may have different ways of distinguishing environments.

The local environment

Generally, it is marked with Local. It refers to an environment where the front-end or back-end is independently developed and tested. It is often the case that projects and dependencies run on our own computers, such as databases, caches, queues, and other services that may need to be set up locally.

The development environment

Commonly identified by dev, it refers to an environment in which the front end and back end (or multiple programmers) work together to develop and coordinate. Usually, projects and dependencies are placed on the development machine, which can be accessed directly by employees’ computers. Instead of building projects by themselves, projects can be run directly to improve the efficiency of development and collaboration.

For small teams, one development and one local environment is sufficient, since services such as a common database can be connected locally.

The test environment

Generally marked with test, it refers to the environment where front-end and back-end development and joint adjustment are completed, and a complete new function is made and handed over to test students to find bugs.

Usually in the test environment need to have a separate test database and other services, let the test students show their skills. After modifying the Bug each time, we also need to release the project to the test environment again for the test students to re-verify.

Pre-release environment

Generally, pre is used to mark the project, which is the closest environment to online projects. The project can be released to this environment only after passing the test verification and product manager experience.

In fact, the back-end interface, database and services invoked by the project in the pre-release environment are the same as those of the online project. The only difference is that the domain name accessed by the front-end is different.

Because of this, the pre-release environment sees real user data and can find more bugs that the test environment missed because of insufficient data.

The production environment

Generally identified by PROD, also known as the online environment, is the environment for all real users to use.

Therefore, it should not be modified arbitrarily, and great care must be taken when publishing projects to this environment. Online databases, machines and other resources are generally in the charge of professional operation and maintenance. To log in to the machines and modify configurations, strict approval is required.

How to do that?

Finally, I will introduce the realization of multiple environments. In fact, it is similar with minor differences. It follows three steps: abstract configuration class + configuration file + injection of environment parameters, which can be easily realized

Abstract configuration class

Organize variables in the project code that need to change as the environment changes into one or more configuration classes for centralized management.

For example, to connect to a database, we need database IP, port, configuration, etc. The code is as follows:

// Basic database information
DB db = new DB();
db.setIp("10.0.0.1");
db.setPort(3306);
// Database connection configuration
DBConnection c = new DBConncetion();
c.setTimeout(1000);
Copy the code

We can replace all the dead values in this code with variables, putting the same class variables into one class:

// Database configuration class
class DBConfig {
  String ip = "10.0.0.1";
  int port = 3306;
  long timeout = 1000L;
}
Copy the code

Then read the value of the variable from this class:

DB db = new DB();
DBConfig cf= new DBConfig() 
// From the class
db.setIp(cf.getIp());
db.setPort(cf.getPort());
DBConnection c = new DBConncetion();
c.setTimeout(cf.getTimeout());
Copy the code

The advantage is that if these variables are used elsewhere in the code, they can all be retrieved from the same class, rather than having to write dead values multiple times and be difficult to maintain.

Configuration file

We can maintain the configuration with a special configuration file, which makes it easier for users to modify the configuration without having to find and change the code.

Common configuration file formats include properties, YAMl, yML, json, etc. For example, create a new database configuration file db.properties:

db.ip=10.0.0.1
db.port=3306
db.timeout=1000
Copy the code

Then, when initializing the database, load the values from the configuration file into the configuration class written in the previous step and read:

// Read the configured value from the file
DBConfig cf = new DBConfig("db.properties"); db.setIp(cf.getIp()); db.setPort(cf.getPort()); .Copy the code

It simply moves the configured value from the code to the file

But this way, we can load any configuration file we want!

For example, to configure a test environment, simply create a new db-test.properties file (with the environment name in the file name), write a separate configuration in this file, and then load the file in the code:

new DBConfig("db-test.properties");
Copy the code

Most multi-environment implementations, whether front-end or back-end, follow this principle — multiple sets of configurations, so you’ll always see similar configuration files in your project:

Injection environment parameters

So far, we’ve actually written dead values in the code that tell the program which name of the configuration file to load.

Db-dev. Properties = db-dev. Properties = db-dev. Properties = db-dev. Properties = db-dev.

However, this is not only troublesome, but also can forget to modify, the development environment project posted online.

Ideally, no matter which environment the project switches to, the entire project doesn’t have to change at all.

Therefore, we can leave specifying the environment to last and include the environment parameters when ordering to package or start the project.

For example, when we start a Java project, we pass different arguments to the env system variable:

#The test environment
java -jar -Denv=test dist.jar
#The production environment
java -jar -Dend=prod dist.jar
Copy the code

Then read this parameter in the program and load the corresponding configuration:

// Read the env argument
String env = System.getProperty("env");
new DBConfig("db-" + env + ".properties");
Copy the code

Similarly, for front-end projects, you can pass in environment variables when you package a build and read them in your own code, or hand them over to a packaging tool like Webpack:

{  "scripts": {    "serve": "env=dev serve"."build:test": "env=test build"    "build": "env=prod build"}}Copy the code

OK, so that’s sharing in multiple environments. In fact, in the enterprise, multiple environments are much more complex than this! In addition to distinguishing environments in code, pipelining, mirroring, and containers should also be differentiated. But the principle is the same

Recently organized my original 140 programming experience and technical articles, welcome everyone to read, grow together!

Directions: t. 1 yb. Co/marketing

I am fish skin, learn friends for a praise, this will be my continued creation of power ❤️