DEV Ops java libraries

[nikhileshtippana]

Github Workflows for packaging java libraries

Code Quality

https://docs.sonarsource.com/sonarqube/latest/devops-platform-integration/github-integration/adding-analysis-to-github-actions-workflow/

Strategies

1. Code scan need to perform before merging code to release branch and publishing package
   1. Code quality workflow will trigger on pull-request - opened, synchronize, reopened. Doing sonar scan during pull request helps peer reviewer to approve pull request only if sonar scan succeeds. Note: This check can be made mandatory in branch ruleset settings.
   2. Publish workflow will trigger on push (Upon code being merged to release branch)
2. Code scan need to perform in parallel to publishing package
   1. Code quality workflow will trigger on push
   2. Publish workflow will trigger on push
3. Publishing package need to perform after successful code scan
   1. Code quality workflow will trigger on push
   2. Publish workflow will trigger on workflow_run - completed (Upon completion of code quality workflow)

Releasing and maintaining actions

https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions

Branching Strategy

Development team should be able to develop on multiple releases (versions). The teams can decide to maintain release branches at major version or minor version Note: workflow runs on release branches only. workflow doesn't run feature branches -

PRIM-123
PRIM-5678
feature-a/PRIM-456
feature-a/PRIM-789
feature-b/PRIM-1234
...

Major version

This is suitable to most case scenarios and keeps simple. Release branches will be named as (let say)

releases/v1.x.x
releases/v2.x.x
releases/v3.x.x
...

Let's take releases/v1.x.x.

1. Initially it is set with version=1.0.0. As commits are made and pushed, Develop workflow (see below) will be triggered and builds version 1.0.0-SNAPSHOT and publishes into artifactory.
2. Many commits can be done on the same branch and so many SNAPSHOT artifacts will be published.
3. When testing is complete and ready for releasing the version, a GitHub Release is created and it will trigger Release workflow (see below). It builds 1.0.0 and publishes into artifactory. Last step it to increase patch version to 1.0.1 and commits in the same branch.
4. Repeat steps 2 and 3 for next patch version work.
5. If new feature needs to be added, then version need to be updated to 1.1.0.
6. Repeat step 2 as part of development work.
7. Repeat step 3 where 1.1.0 is built and published to artifactory. Last step it to increase patch version to 1.1.1 and commits in the same branch.
8. Repeat steps 5, 6 and 7 for next feature version work.

Minor version

When one wants more granularity in release branches management. Release branches will be named as (let say)

releases/v1.0.x
releases/v1.1.x
releases/v1.2.x
releases/v2.8.x
releases/v2.9.x
...

Let's take releases/v1.2.x.

1. Initially it is set with version=1.2.0. As commits are made and pushed, Develop workflow (see below) will be triggered and builds version 1.2.0-SNAPSHOT and publishes into artifactory.
2. Many commits can be done on the same branch and so many SNAPSHOT artifacts will be published.
3. When testing is complete and ready for releasing the version, a GitHub Release is created and it will trigger Release workflow (see below). It builds 1.2.0 and publishes into artifactory. Last step it to increase patch version to 1.2.1 and commits in the same branch.
4. Repeat steps 2 and 3 for next patch version work.
5. If new feature needs to be added, then create new branch releases/v1.3.x with version 1.3.0
6. Repeat step 2 as part of development work.
7. Repeat step 3 where 1.3.0 is built and published to artifactory. Last step it to increase patch version to 1.3.1 and commits in the same branch.
8. Repeat steps 5, 6 and 7 for next feature version work.

Consuming Packages

Maven and Gradle build tools support dynamic versioning.

Major version

Example: adding dependency in consuming application

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>[5.0.0,6.0.0)</version>
</dependency>

This way latest (minor or patch) version 5.x.x is picked as part of maven goals

Minor version

Example: adding dependency in consuming application

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>[5.2.0,5.3.0)</version>
</dependency>

This way latest (patch) version 5.2.x is picked as part of maven goals

Patch version

Example: adding dependency in consuming application

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>5.2.5</version>
</dependency>

This way specific version 5.2.5 is picked as part of maven goals. No new updates are picked up "automatically".

Develop workflow

on push trigger of main / release branch. Publish snapshot version and deploy to DEV

Assumption: pom.xml will define version in the format x.x.x

Jobs

1. Publish Package Steps
   1. Build (skip tests) with -SNAPSHOT using build-helper-maven-plugin
   2. Publish package (nexus or GitHub packages)
   3. Create a git tag v (used for releasing version) and git force commit

Release workflow

https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions on release trigger with tag created earlier and main / release branch. Publish release version and deploy to DEV -> QA -> PRD

Jobs

1. Publish Package Steps
   1. Build (skip tests) with
   2. Publish package (nexus or GitHub packages)
   3. Increment patch version and git commit (Ex: 2.3.0 -> 2.3.1)