Multi-Project Environment Configuration and Health Check

Devops
1

Multi-Project Environment Configuration and Health Check

A Cautionary Tale: An Accident

Imagine a scenario where you develop a feature that sends a daily data message to your boss at 6:00 AM, but the process is not as smooth as you think. You test the feature on your computer, confirm its functionality, and then package it into a code that runs on the test server. However, the little sister test, who is responsible for rigorous testing, is not impressed. She tests the feature and finds it to be flawed. The critical issue is that you did not have time to ask someone to watch the recently released Marvel movie, and this issue is not related to the feature.

You put the code into the main branch and notify the publisher, who publishes the code to the production environment. However, when you receive a reminder from the operation and maintenance personnel, you realize that the boss did not receive any mail, and the mail information is crucial for an important meeting later in 2 hours. The data is finally trying to get, but exhaustion, fear, shame, and remorse have buried your mind.

Environmental Points

As a software engineer or systems architect, you need to have a full understanding and control of the system development and deployment process. This involves having a multi-project environment configuration and health check in place. The environment is a software system that is often more complex than a single project. The common environments include:

  • Dev: The development environment, where each developer builds their own environment and sets up services such as database development environment, distributed services, and in-house server.
  • Sit: The integrated test environment, where various modules are tested as a group.
  • UAT: The user acceptance testing environment, where the system is tested by people who are familiar with the development achievements and acceptance environment.
  • Sandbox: The sandbox environment, which is the most realistic simulation of the production environment.
  • Prod: The production environment, where the final product is delivered.

Sub-Environment to Achieve

To implement the sub-environment, there are many approaches, including Spring Profile, Spring Boot, and other implementations. Here, we will discuss a configuration using Maven profiles to implement sub-environments.

Designated Environment Packaged Shortcomings

The first issue with the current approach is that it is slow and can be said to waste coffee. Large-scale projects require more than half an hour to compile each file, which can save two hours of release time. To address this issue, we can use a multi-environment, multi-package release approach.

Only a Dozen Packages

To implement the multi-environment, multi-package release approach, we can use the following steps:

  1. Configure the Maven profiles in the pom.xml file to specify the configuration path for each environment.
  2. Use the maven-resources-plugin to copy the configuration files to the target directory.
  3. Use the mvn install command to package the project, specifying the environment on the command line.

Git Branch Management

To manage the git branches, we can use the following approach:

  1. Develop a branch with packaging and publishing to the sit environment.
  2. Test by merging the release branch into the master branch.
  3. Package the project and release it to the production environment.

Multi-Multi-Environment Package Released

Each environment is separately packaged and released, until finally all environmental testing is through production release.

Multiple Environment Released a Single Package

Played only a package release branch for all environmental release. Measure the bug is repackaged, bug until all tests are passed.

Version Check

To ensure a consistent version of the operation and maintenance personnel released version of the code with our function, we can use the git-commit-id-plugin. This plugin will generate a branch based on the current version number of git.properties file.

Check the Version of Address

To check the version of address, we can use the following controller:

@Api(value = "", description = "git info from git-commit-id-plugin")
@Controller
public class GitCommitController {
    @RequestMapping("/git/commit/info")
    @ResponseBody
    @ApiOperation(value = "get commit info", httpMethod = "GET")
    public String showGitCommitInfo() {
        //git.properties
        ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
        Map<String, String> map = new TreeMap<>();
        Enumeration<String> keysEnumeration = resourceBundle.getKeys();
        while (keysEnumeration.hasMoreElements()) {
            String key = keysEnumeration.nextElement();
            map.put(key, resourceBundle.getString(key));
        }
        return JSON.toJSONString(map, SerializerFeature.PrettyFormat);
    }

    @ApiOperation(value = "get commit id", httpMethod = "GET")
    @RequestMapping("/git/commit/id")
    @ResponseBody
    public String showGitCommitId() {
        //git.properties
        ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
        return resourceBundle.getString("git.commit.id");
    }
}

Start by Jetty plug-in project and access the Swagger UI address http://localhost:8241/swagger/index.html, and finally by http://localhost:8241/git/commit/info request to our git commit message.

To facilitate our general version rollback, when the release will be packaged by git commit id, if possible unanimously by the contrast between the two machines, to achieve the purpose of automatic inspection, rather than each time the need for manual checking.