Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added release-management.md #2657

Merged
merged 2 commits into from
Jul 5, 2019
Merged

Added release-management.md #2657

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
af5b4ff
Added release-managent.md
ChandanSagar Jul 1, 2019
470553f
Updated release-management.md
ChandanSagar Jul 1, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Added release-managent.md 
Added release-managent.md which contains the release-mangement process.

Signed-off-by: ChandanSagar <chandan.pradhan@mayadata.io>
  • Loading branch information
@ChandanSagar
ChandanSagar committed Jul 1, 2019
commit af5b4fff60edb59f3bd557d65f73aa03d0f41416
32 changes: 32 additions & 0 deletions contribute/design/release-management.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
OpenEBS Release Managent
OpenEBS Components are released as container images with versioned tags. The release process is triggered by creating a Release Tag on the repository. For major releases, the Release Tag is created on the master branch and for minor release, the release tag is triggered on the corresponding release branch.

The release process involves the following stages:
Release Candidate Builds
Update Installer and Documentation
Update the charts like Helm stable and other partner charts. (Rancher, OpenShift, IBM ICP Communty Charts, Netapp NKS Trusted Charts (formerly StackPointCloud), AWS Marketplace)
Update the openebs-operator.yaml
Final Release

Release Candidate Builds
On reaching the feature freeze date, the repositories are tagged with "Release-Name-RC1" tag. (Example 1.0.0-RC1).
The release tags are applied in the following order:
- openebs/libstor
- openebs/cstor
- openebs/istgt
- openebs/jiva
- openebs/ndm
- openebs/external-storage
- openebs/velero-plugin
- openebs/maya

The e2e pipeline and exploratory tests are executed using the RC tagged images. Any issues identified during this RC testing are tagged as release blockers.
After the issues are fixed and verified by the CI, next RC is triggered.(Example: 0.1.0-RC2)
ChandanSagar marked this conversation as resolved.
Show resolved Hide resolved
The above process is repeated till a RC has been arrived with all the release blockers fixed.
After the final RC, a release tag is created. (Example 0.1.0) in the same order as the release candidate builds. The e2e pipeline and exploratory tests are repeated on the release tagged builds.
ChandanSagar marked this conversation as resolved.
Show resolved Hide resolved

Once the release is triggered, travis build process has to be monitored. Once travis builds are passed images are pushed to docker hub and quay.io.
Images can be verified by going through docker hub and quay.io. Also the images shouldn't have any high level vulnerabilities.
Example:
https://quay.io/repository/openebs/cstor-pool?tab=tags
https://hub.docker.com/r/openebs/openebs-k8s-provisioner/tags