Ensure reliable microservice deployment with Spring Boot build information Maven plugin

Learn how to improve the reliability of your deployment pipeline by validating your microservice deployments with the Spring Boot Build Info Maven plugin.

        In terms of microservices, we faced a unique challenge: when deploying a container, we could not verify that the latest container version with the expected code was deployed. It's easy to verify when a new feature is deployed and can be tested in production. However, for fintech applications, we are not necessarily able to validate brand new production APIs. In some cases, there are also bug fixes to existing APIs, and you cannot execute that API use case in production. Sometimes, the DevOps team notifies us that the container has been lifted and deployed from the lower UAT environment, but when the actual production traffic starts, we don't see the bug fixes taking effect. To avoid this, we want to make sure there is a way to verify the latest code when pushing containers.
        In our case we are dealing with Spring based microservices. This is where the Spring Boot Maven plugin comes in handy. The build-info Maven plugin needs to be added to the project's pom.xml file.

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>
              build-info
            </goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

        After the build information is configured and the project is built, you can view the build-info.properties file in the target/classes/META-INFO directory. It looks like this:

build.artifact=core-build-info-api
build.group=com.dzone
build.name=core-build-info-api
build.time=2023-07-29T15\:47\:25.387Z
build.version=1.0-SNAPSHOT

        To access these properties at runtime, Spring provides the BuildProperties class, which exposes all the properties in the above file. Here's a code snippet for a generic service that builds build information for deployed microservices:

@Service
public class BuildInfoService {

    @Autowired
    BuildProperties buildProperties;

    @Autowired
    Environment environment;

    public BuildInfoResponse getBuildInfo(){
        BuildInfoResponse buildInfoResponse = new BuildInfoResponse();
        buildInfoResponse.setName(this.buildProperties.getName());
        buildInfoResponse.setVersion(this.buildProperties.getVersion());
        buildInfoResponse.setTime(this.buildProperties.getTime());
        buildInfoResponse.setActiveProfile(this.environment.getActiveProfiles());
        buildInfoResponse.setSpringVersion(this.buildProperties.getVersion());
        buildInfoResponse.setGroup(this.buildProperties.getGroup());
        buildInfoResponse.setArtifact(this.buildProperties.getArtifact());
        return buildInfoResponse;
    }
}

        You can then inject this service and build a generic endpoint to expose the container's build information. In our case, we build a generic package called core-build-info that includes the above services and a generic controller as follows:

@RestController
@RequestMapping("/${build-info.path}")
public class BuildInfoController {

    @Autowired
    BuildInfoService buildInfoService;

    @GetMapping("/build-info")
    public BuildInfoResponse getBuildInfo() {
        return this.buildInfoService.getBuildInfo();
    }
}

All business or utility microservices reference the common package and configure the following properties in the Spring profile properties file:

env=DEV
build-info.path=api/app-name/build

The application name can be your business base service path.
After integrating the public package, you can use the following URL to access the microservice's endpoint, which returns the following:

{
    "name": "core-build-info-api",
    "version": "0.0.1",
    "time": "2023-07-29T16:13:42.251Z",
    "artifact": "core-build-info-api",
    "group": "com.dzone",
    "activeProfile": [
        "DEV"
    ],
    "springVersion": "6.0.10"
}

        You can verify versions if you configure version increments during your build. Alternatively, you can always fall back to checking the build time, in this case "2023-07-29T16:13:42.251Z".

        In conclusion, dealing with microservices and ensuring the latest code deployments can present unique challenges. We developed a robust approach to overcome this challenge by leveraging the capabilities of the Spring Boot Maven plugin and creating a common package to expose build information. This process allows us to confirm that the correct version and build of the microservice is deployed in production, providing confidence and assurance to our deployment pipeline. The real-world value of this approach is obvious: it's now the first thing we verify when deploying containers.

Guess you like

Origin blog.csdn.net/qq_28245905/article/details/132202299