Code scan need to perform before merging code to release branch and publishing package
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.
Publish workflow will trigger on push (Upon code being merged to release branch)
Code scan need to perform in parallel to publishing package
Code quality workflow will trigger on push
Publish workflow will trigger on push
Publishing package need to perform after successful code scan
Code quality workflow will trigger on push
Publish workflow will trigger on workflow_run - completed (Upon completion of code quality workflow)
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 -
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.
Many commits can be done on the same branch and so many SNAPSHOT artifacts will be published.
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.
Repeat steps 2 and 3 for next patch version work.
If new feature needs to be added, then version need to be updated to 1.1.0.
Repeat step 2 as part of development work.
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.
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)
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.
Many commits can be done on the same branch and so many SNAPSHOT artifacts will be published.
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.
Repeat steps 2 and 3 for next patch version work.
If new feature needs to be added, then create new branch releases/v1.3.x with version 1.3.0
Repeat step 2 as part of development work.
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.
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
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
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.push
(Upon code being merged to release branch)push
push
push
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 -
Major version
This is suitable to most case scenarios and keeps simple. Release branches will be named as (let say)
Let's take
releases/v1.x.x
.Minor version
When one wants more granularity in release branches management. Release branches will be named as (let say)
Let's take
releases/v1.2.x
.releases/v1.3.x
with version 1.3.0Consuming Packages
Maven and Gradle build tools support dynamic versioning.
Major version
Example: adding dependency in consuming application
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
This way latest (patch) version 5.2.x is picked as part of maven goals
Patch version
Example: adding dependency in consuming application
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 ofmain
/release
branch. Publish snapshot version and deploy to DEVAssumption: pom.xml will define version in the format x.x.x
Jobs
Release workflow
https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions on
release
trigger with tag created earlier andmain
/release
branch. Publish release version and deploy to DEV -> QA -> PRDJobs