#Java Microsoft DevOps Maven CICD

[rmcguinness-blog]

Java and Microsoft DevOps

Scope

I've rencently been spending a bit of time using Microsoft's DevOps tool suite, formally Team Foundation Serveer (TFS). In brief, I'm impressed. They (Microsoft) has been able to create a development environment that DOES NOT require me to have five differnt tools, five different licensing agreements and renewal dates, etc.

Here are some tips I've learned along the way, and hopefully they will help you.

Components

I am using Boards, Repos, Pipelines and Artifacts with very specific intentions. As an organization owner, I have all of my products setup, each having their own permissions to backlogs and repositories. This is extremely important in the Enterprise as certian regulatory controls insist of behaviors of isolation. DevOps provides this in spades (more later). For now understand that Having a board, my git repos and my pipelines in one place is awesome, and being able to create a dashboard across all of those products... outstanding. Yes, you can do that with those five other tools, so long as you want to deal with staffing for those tools and building the expertise.

Boards

I was looking for a replacement for Jira, not because Jira is bad, but because the pricing after ten users is insane. If I have a dynamic workforce, why should I have to continually have that type of runtime cost. SAS to the rescue on this one.

The best thing for me about boards is this: I can customize each organization a little bit differently while still using an enterprise tagging schema. This really helps mre report across orgs with a new level of comfort.

Repositories

This is simple, a single place to keep my repos and my agile / scrum work, and when I check things in, the stories are linked and I don't have to manage multiple service hooks with expiring keys every thirty to ninty days.

Pilelines and Artifacts

The level of integration with third-party tools is great, even competitor cloud vendors like GCP and that Book Store company. Seriously though, having all of the permissions tied to my active directory day one and custome release worflows is great.

Timing

It's taken a little over two weeks and some trial and error to get to this stage but I thought it was worth sharing, so here goes:

A Tale of two builds

Methodology Matters

You may not be a fan of SNAPSHOTS, I personally am. I don't like burning revision numbers just because my CI pipeline told me to. Here, we'll break up the CI and the CD pipelines a bit, primarily because most companies really don't do CD well, and depending on the regulations may have pretty big process to adhere too.

You may branch you code, in this example all ideals flow branchs PRing to master, master always running a CI build, and a CD build being kicked off from a tag or revision.

Maven

A sigificant amount of work goes into create a build worthy POM file, with Azure, you really need to make sure you're using some of the latest plugins. Here's the most important snippet:

... <build> <plugins> ... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <argLine>${argLine} -Xmx256m</argLine> <forkCount>2</forkCount> <reuseForks>true</reuseForks> <useSystemClassLoader>false</useSystemClassLoader> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <configuration> <forkCount>2</forkCount> <reuseForks>true</reuseForks> <argLine>${argLine} -Xmx256m ${coverageAgent}</argLine> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <configuration> <detail>true</detail> <autoVersionSubmodules>true</autoVersionSubmodules> <updateDependencies>true</updateDependencies> <scmReleaseCommitComment>[skip ci] prepare release @{releaseLabel}</scmReleaseCommitComment> <releaseProfiles>release</releaseProfiles> </configuration> </plugin> ... </plugins> </build> <profiles> <profile> <id>default</id> <activation><activeByDefault>true</activeByDefault></activation> <properties> <!-- This is the only place I manage versions to SNAPSHOT --> </properties> </profile> <profile> <id>release</id> <activation><activeByDefault>false</activeByDefault></activation> <properties> <!-- This is the only place I manage versions to RELEASE Versions may be parameterized --> </properties> </profile> </profiles> ...

NOTE: the Maven release plugin is at the latest 3.x version, and the "[skip ci]" is in the scmReleaseComment tag. This MUST be in place in order to avoid duplicate builds.

CI

The CI pipeline is pretty simple, you can put the code coverage reports in the maven task, but that won't work for multimodule builds. This CI file assumes that the pom.xml file is labled as a SNAPSHOT, and will continually deploy to the artifacts repository specified in the secure "settings.xml" file. It's that simple.

. Tell the build system what type of server to use . Trigger a build whenever a change to maser is made, unless it's to docs or pipelines. . Checkout the reposository . Setup Git so any pipeline commits has a automated tag. . Run maven with a: "clean, deploy" so it will be pushed to artifacts . By the way, also record my test coverage and all those test cases.

pool: vmImage: 'ubuntu-latest' trigger: batch: true branches: include: - master paths: exclude: - docs/* - README.md - README.adoc - azure-pipeline.yml - azure-pipeline-ci.yml steps: - checkout: self persistCredentials: true - task: DownloadSecureFile@1 name: mavenSettings displayName: 'Setup: Maven' inputs: secureFile: 'settings.xml' - task: Bash@3 displayName: 'Setup: Git' inputs: targetType: 'inline' script: | git config --global user.email "some_really_cool_cat@whereever.com" git config --global user.name "DevOps Build Pipeline" git checkout $(Build.SourceBranchName) - task: Maven@3 displayName: 'Maven: Clean, Deploy' inputs: publishJUnitResults: true testResultsFiles: '**/TEST-*.xml' pmdRunAnalysis: true findBugsRunAnalysis: true jdkVersionOption: 1.8 javaHomeOption: 'JDKVersion' mavenVersionOption: 'Default' mavenPomFile: 'pom.xml' goals: 'clean deploy' options: '-s $(mavenSettings.secureFilePath)' - task: PublishCodeCoverageResults@1 displayName: 'Publish' inputs: codeCoverageTool: 'JaCoCo' summaryFileLocation: '$(System.DefaultWorkingDirectory)/target/site/jacoco/jacoco.xml' pathToSources: '$(System.DefaultWorkingDirectory)/src/main/java' additionalCodeCoverageFiles: '$(System.DefaultWorkingDirectory)/*/jacoco.exec'

CD

CD is a little different, I run those as manual pipelines. No, I am not running the current DEPLOY functionality in the DevOps Suite. I haven't figured out how to make that work elegently with the auto revisions and release life-cycle of the Maven Release Plugin.

pool: vmImage: 'ubuntu-latest' trigger: none steps: - checkout: self persistCredentials: true - task: DownloadSecureFile@1 name: mavenSettings displayName: 'Setup: Maven' inputs: secureFile: 'settings.xml' - task: Bash@3 displayName: 'Setup: Git' inputs: targetType: 'inline' script: | # Write your commands here git config --global user.email "some_really_cool_cat@whereever.com" git config --global user.name "DevOps Build Pipeline" git checkout $(Build.SourceBranchName) - task: Maven@3 displayName: 'Maven: Release' inputs: publishJUnitResults: fale jdkVersionOption: 1.8 javaHomeOption: 'JDKVersion' mavenVersionOption: 'Default' mavenPomFile: 'pom.xml' goals: 'release:prepare release:perform' options: '-s $(mavenSettings.secureFilePath) -B -Dusername=$(username) -Dpassword=$(pwd)'

This almost identical workflow requires the addition of a username and pwd parameter that are managed secrets within the build pipeline and point to expiring tokens rather than user account information.

Conclusion

Yeah, that's really it. Two pipelines, with minimal work and I have a CI/CD pipeline that can exectute to any cloud environment with an amazingly low TCO. The Microsoft team is continuing to fill a gap that other cloud providers haven't come close to filling. Microsoft has been up to some great work, and I hope this trend continues as they are making developers lives better and more to the point helping reduce the TCO of project infrastructure.