Package: plotter-cicd
poetry-cicd-exampleBare bones repository demonstrating a pythonpoetryproject using GitHub actionsAssumptions:Project is hosted on github.comProject uses an organization-scoped GitHub App for CICD operationsProject built usingpoetryDocker images will be published to ghcr.ioCredentials stored in GitHub SecretsCICD_APP_IDCICD_APP_PRIVATE_KEYSONAR_TOKENGITHUB_TOKENBranch names:main,develop,issues/*Project is usingsemantic versioningImportant NotesAfter merging tomaster, a new change request should be opened to mergemasterback in todevelopso that the version indevelopis at least one minor version
ahead ofmaster. This can't be automated because development likely will have continued while
the release was being evaluated and will cause merge conflicts since both branches will have
modified the version number.Changes made in release branches should also be pushed back todevelopif they are critical. Otherwise, the
merge frommastertodevelopafter release will incorporate the changes.It is recommended that only one change request targetingmastershould be open at any given time.Stages OverviewThe main unit of work for Jenkins pipelines are Stages. Stages can contain sub-stages and can be conditionally run. At a high-level, this template defines the following
stages listed below. In general, the stages are executed in order from top to bottom. However, some stages can be skipped for any particular run of the pipeline.CheckoutThis stage checks out the code as triggered by the server event.Git Branching StrategyThe template is built with the assumption that the project follows thegit-workflowbranching
strategy. A lot of the functionality is conditional on matching against branch naming conventions. Therefore, it is important that the project conform to this workflow.Software VersioningThis template assumes the use ofsemantic versioningfor the project being built. The strategy can be summarized as:Thedevelopbranch always contains aprereleaseversion of the projectThedevelopbranch will always be at least 1 minor version ahead ofmasterFeature branches (prefixed withissues/) are branched fromdevelop. When a feature branch is built,build metadatais appended to the prerelease versionEvery merge to develop increments the prerelease version number by oneRelease branches are branched fromdevelopand are named asrelease/<semver>where<semver>is a valid 'major.minor.patch' semantic version string.The<semver>part of the branch name is used as the version for the release. SeeReleasingfor detailsAs soon as a release branch is created, the minor version in thedevelopbranch is bumped automatically by therelease-created.ymlworkflowRelease candidates are created once a change request is created from arelease/*branch that targetsmasterWhen a release candidate is created, the prerelease identifier is set torcand the prerelease version is reset to 1Any change (commit) to a release candidate change request results in a bump to the prerelease versionMerges to master remove the prerelease version and identifier but leave the remaining 'major.minor.patch' versionTags using the version as the tag name are created for every new prerelease, release candidate, and releaseReleasingWhen it is time to cut a release from the develop branch, a decision must be made. Is the release a major, minor, or patch release?
There are rules that should be followed when determining if the release isminorormajor.If it is minor, create a branch prefixed withrelease/and followed by the development version without prerelease version or identifier.
For example, if0.2.0-alpha.4is the current develop version, then create a branch calledrelease/0.2.0If it is major, create a branch prefixed withrelease/and followed by the development major version incremented by 1 and using 0 for minor and patch number.
For example, if0.2.0-alpha.4is the current develop version, then create a branch calledrelease/1.0.0ReviewsThere are two points of review in this workflow:When a change request is initiated from a feature branch to develop. This is a chance for developers to review the code that was developed as part of the feature request
and suggest changes. The assumption is that code that makes it to develop is eligible for release and it will be deployed to a system integration testing (SIT) environment.When a change request is initiated from a release branch tomaster. This is a chance for other stakeholders to review the proposed changed that will be released
to operations (OPS). As soon as a change request is initiated, the software will be deployed to a user acceptance testing (UAT) environment so that functionality can be tested.
It is recommended that only one change request targetingmastershould be open at any given time.