Overall Release Process

[maleck13]

Define how Kuadrant as a whole is released. The operator should likely be the key component where everything is brought together. Not everything needs to be automated but the process should be understandable and executable by anyone in the eng team.

• Key areas

What criteria must be met in order to say this version is ready for release (e.g e2e test complete, deployed to our internal hosted environment etc)

When a new release of a component is created how do we test it as part of Kuadrant as a whole

How do we bring together the documentation for that release from the various Kuadrant components

How is the release made available to end users

@alexsnaps At a high level I think we want a process that enables a flow such as (and the below doesn't mean we have to do all this at once) below:

There are no doubt gaps and questions around this process it is intended as a getting started point

Master

• Example: Kuadrant Controller PR made (unit test, e2e tests etc)
• Kuadrant controller pr merged -> triggers pr to kuadrant operator to update the "alpha" or "nightly" channel via index image (for other components we will have to update their operator and then update the kuadrant operator)
• Kuadrant operator runs its checks (tests etc)
• release created of kuadrant operator and published via the nightly channel
• Kuadrant operator is deployed to our internal eng environment via nightly channel
• Nightly test run is done against the full environment (this should be a highly stable set of tests and given high priority if it fails)

Full Release

• When we decide we want to we cut a new release, we create a release branch for each component from master
• Tests re-run and builds done (related operators updated and tested)
• single PR to update the kuadrant operator with these new versions (tests re run)
• We may then want to release to different channel (beta?) and deploy to re-run our full e2e tests
• Final step is to publish to our stable channel via our index image

Patch release

• fix issue on master of affected component
• cherry-pick fix to release branch
• Tests re-run and builds done (only for affected component)
• single PR to update the kuadrant operator with this new version (tests re run)
• We may then want to release to different channel (beta?) and deploy to re-run our full e2e tests
• Final step is to publish to our stable channel via our index image

[maleck13]

@alexsnaps wondering should we expand this a little bit to cover overall release process but also the criteria for an individual component release? IE the individual component release feeds into the overall release

[alexsnaps]

See #32

[alexsnaps]

Some of us (myself @maleck13 @eguzki @didierofrivia @mikenairn) had a discussion on CI/CD pipeline that somewhat affects this and takes a different spin on #32

State of main branches

We base the following proposal on the current state of things, where main for all components refer to latest for their dependencies on other Kuadrant components (also see here).

CI/CD

There is a on-going (probably cron-based initially) testing of all our latest components, based of installing the kuadrant-operator in a cluster and test it all out again ever increasing test cases.

Since this would be testing latest of everything, we do expect some occasional breakage every now & then. Once we do experience these, we'd need to decide if "temporary red" on this CI is acceptable, or whether there is something better we can do in the future to avoid it.

Doing a release

• Hopefully the pipeline is green and all tests are passing
• By a manual step some "release" is tagged across all components, using the HEAD of main in all repos. e.g. kuadrant-v0.1.0-rc1 if the tag isn't already present…
• The CI/CD pipeline is triggered for that "tagged" release
  • if green, and all further additional and/or manual testing and verification has been performed, the release can be cut
  • if some additional fixes have to happen, they get done on main and ported back to a kuadrant-v0.1.0-rc1 branch cut of the previously created tag. (work can also happen on that branch and potentially be merged back to main, as best fits the issue tackled).
• The website gets regenerated, with the new docs and links to the released artifacts.

This isn't quite #32, but close…

Each component can still release individually, but kuadrant uses a specific version of each its components that match its own version. This could still mean that limitador-v1.3.5 is the same at the version limitador-kuadrant-v0.1.0, as they just use the same SHA as for both tags.

[alexsnaps]

Closing in favor of this RFC