docs: release cycle refresh (#11137)

* docs: release cycle

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* remove TODOs

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* add release champion

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* formatting

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* no 2.6 champion yet

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* fix dates

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* checklist links

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* reorg

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* reuse roadmap doc, add note about Release Champion access requirements

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* note triage access requirement

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* release issue template

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* tweaks

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* simplify

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* update dates

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

* add notes for next release champion

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
This commit is contained in:
Michael Crenshaw
2023-01-11 17:12:26 -05:00
committed by GitHub
parent 88936be9ce
commit 8d262f2585
3 changed files with 95 additions and 253 deletions

32
.github/ISSUE_TEMPLATE/release.md vendored Normal file
View File

@@ -0,0 +1,32 @@
---
name: Argo CD Release
about: Used by our Release Champion to track progress of a minor release
title: 'Argo CD Release vX.X'
labels: 'release'
assignees: ''
---
Target RC1 date: ___. __, ____
Target GA date: ___. __, ____
- [ ] Create new section in the [Release Planning doc](https://docs.google.com/document/d/1trJIomcgXcfvLw0aYnERrFWfPjQOfYMDJOCh1S8nMBc/edit?usp=sharing)
- [ ] Schedule a Release Planning meeting roughly two weeks before the scheduled Release freeze date by adding it to the community calendar (or delegate this task to someone with write access to the community calendar)
- [ ] Include Zoom link in the invite
- [ ] Post in #argo-cd and #argo-contributors one week before the meeting
- [ ] Post again one hour before the meeting
- [ ] At the meeting, remove issues/PRs from the project's column for that release which have not been “claimed” by at least one Approver (add it to the next column if Approver requests that)
- [ ] 1wk before feature freeze post in #argo-contributors that PRs must be merged by DD-MM-YYYY to be included in the release - ask approvers to drop items from milestone they cant merge
- [ ] At least two days before RC1 date, draft RC blog post and submit it for review (or delegate this task)
- [ ] Cut RC1 (or delegate this task to an Approver and coordinate timing)
- [ ] Create new release branch
- [ ] Add the release branch to ReadTheDocs
- [ ] Confirm that tweet and blog post are ready
- [ ] Trigger the release
- [ ] After the release is finished, publish tweet and blog post
- [ ] Post in #argo-cd and #argo-announcements with lots of emojis announcing the release and requesting help testing
- [ ] Monitor support channels for issues, cherry-picking bugfixes and docs fixes as appropriate (or delegate this task to an Approver and coordinate timing)
- [ ] At release date, evaluate if any bugs justify delaying the release. If not, cut the release (or delegate this task to an Approver and coordinate timing)
- [ ] If unreleased changes are on the release branch for {current minor version minus 3}, cut a final patch release for that series (or delegate this task to an Approver and coordinate timing)
- [ ] After the release, post in #argo-cd that the {current minor version minus 3} has reached EOL (example: https://cloud-native.slack.com/archives/C01TSERG0KZ/p1667336234059729)
- [ ] (For the next release champion) Review the [items scheduled for the next release](https://github.com/orgs/argoproj/projects/25). If any item does not have an assignee who can commit to finish the feature, move it to the next release.
- [ ] (For the next release champion) Schedule a time mid-way through the release cycle to review items again.

View File

@@ -1,49 +1,78 @@
# Release Process And Cadence
Argo CD is being developed using the following process:
## Release Cycle
* Maintainers commit to work on set of features and enhancements and create GitHub milestone to track the work.
* We are trying to avoid delaying release and prefer moving the feature into the next release if we cannot complete it on time.
* The new release is published every **3 months**.
* Critical bug-fixes are cherry-picked into the release branch and delivered using patch releases as frequently as needed.
### Schedule
## Release Planning
These are the upcoming releases dates:
We are using GitHub milestones to perform release planning and tracking. Each release milestone includes two type of issues:
| Release | Release Planning Meeting | Release Candidate 1 | General Availability | Release Champion | Checklist |
|---------|--------------------------|-----------------------|----------------------|-------------------------------------------------------|---------------------------------------------------------------|
| v2.6 | Monday, Dec. 12, 2022 | Monday, Dec. 19, 2022 | Monday, Feb. 6, 2023 | [William Tam](https://github.com/wtam2018) | [checklist](https://github.com/argoproj/argo-cd/issues/11563) |
| v2.7 | Monday, Mar. 6, 2023 | Monday, Mar. 20, 2023 | Monday, May. 1, 2023 | [Pavel Kostohrys](https://github.com/pasha-codefresh) |
| v2.8 | Monday, Jun. 5, 2023 | Monday, Jun. 19, 2023 | Monday, Aug. 7, 2023 |
| v2.9 | Monday, Sep. 4, 2023 | Monday, Sep. 18, 2023 | Monday, Nov. 6, 2023 |
* Issues that maintainers committed to working on. Maintainers decide which features they are committing to work on during the next release based on
their availability. Typically issues added offline by each maintainer and finalized during the contributors' meeting. Each such issue should be
assigned to maintainer who plans to implement and test it.
* Nice to have improvements contributed by community contributors. Nice to have issues are typically not critical, smallish enhancements that could
be contributed by community contributors. Maintainers are not committing to implement them but committing to review PR from the community.
Actual release dates might differ from the plan by a few days.
The milestone should have a clear description of the most important features as well as the expected end date. This should provide clarity to end-users
about what to expect from the next release and when.
### Release Process
In addition to the next milestone, we need to maintain a draft of the upcoming release milestone.
#### Minor Releases (e.g. 2.x.0)
## Community Contributions
A minor Argo CD release occurs four times a year, once every three months. Each General Availability (GA) release is
preceded by several Release Candidates (RCs). The first RC is released three weeks before the scheduled GA date. This
effectively means that there is a three-week feature freeze.
We receive a lot of contributions from our awesome community, and we're very grateful for that fact. However, reviewing and testing PRs is a lot of (unplanned) work and therefore, we cannot guarantee that contributions (especially large or complex ones) made by the community receive a timely review within a release's time frame. Maintainers may decide on their own to put work on a PR together with the contributor and in this case, the maintainer will self-assigned the PR and thereby committing to review, eventually merge and later test it on the release scope.
These are the approximate release dates:
## Release Testing
* The first Monday of February
* The first Monday of May
* The first Monday of August
* The first Monday of November
We need to make sure that each change, both from maintainers and community contributors, is tested well and have someone who is going to fix last-minute
bugs. In order to ensure it, each merged pull request must have an assigned maintainer before it gets merged. The assigned maintainer will be working on
testing the introduced changes and fixing of any introduced bugs.
Dates may be shifted slightly to accommodate holidays. Those shifts should be minimal.
We have a code freeze period two weeks before the release until the release branch is created. During code freeze no feature PR should be merged and it is ok
to merge bug fixes.
#### Patch Releases (e.g. 2.5.x)
Maintainers assigned to a PR that's been merged should drive testing and work on fixing last-minute issues. For tracking purposes after verifying PR the assigned
the maintainer should label it with a `verified` label.
Argo CD patch releases occur on an as-needed basis. Only the three most recent minor versions are eligible for patch
releases. Versions older than the three most recent minor versions are considered EOL and will not receive bug fixes or
security updates.
## Releasing
#### Minor Release Planning Meeting
The releasing procedure is described in [releasing](./releasing.md) document. Before closing the release milestone following should be verified:
Roughly two weeks before the RC date, there will be a meeting to discuss which features are planned for the RC. This meeting is
for contributors to advocate for certain features. Features which have at least one approver (besides the contributor)
who can assure they will review/merge by the RC date will be included in the release milestone. All other features will
be dropped from the milestone (and potentially shifted to the next one).
- [ ] All merged PRs and verified (verify and remove `needs-verification` label):
- [ ] Triage issues reported by `yarn audit` and ensure there are no exploitable security issues.
- [ ] Roadmap is updated based one current release changes
- [ ] Next release milestone is created
- [ ] Upcoming release milestone is updated
Since not everyone will be able to attend the meeting, there will be a meeting doc. Contributors can add their feature
to a table, and Approvers can add their name to the table. Features with a corresponding approver will remain in the
release milestone.
#### Release Champion
To help manage all the steps involved in a release, we will have a Release Champion. The Release Champion will be
responsible for a checklist of items for their release. The checklist is an issue template in the Argo CD repository.
The Release Champion can be anyone in the Argo CD community. Some tasks (like cherry-picking bug fixes and cutting
releases) require [Approver](https://github.com/argoproj/argoproj/blob/master/community/membership.md#community-membership)
membership. The Release Champion can delegate tasks when necessary and will be responsible for coordinating with the
Approver.
### Feature Acceptance Criteria
To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the releases RC
date.
If it is a large feature that involves significant design decisions, that feature must be described in a Proposal, and
that Proposal must be reviewed and merged.
The feature PR must include:
* Tests (passing)
* Documentation
* If necessary, a note in the Upgrading docs for the planned minor release
* The PR must be reviewed, approved, and merged by an Approver.
If these criteria are not met by the RC date, the feature will be ineligible for inclusion in the RC series or GA for
that minor release. It will have to wait for the next minor release.

View File

@@ -1,224 +1,5 @@
# Roadmap
- [Roadmap](#roadmap)
- [v2.4](#v24)
- [Server side apply](#server-side-apply)
- [Input Forms UI Refresh](#input-forms-ui-refresh)
- [Web Shell](#web-shell)
- [Helm values from external repo](#helm-values-from-external-repo)
- [Support multiple sources for an Application](#support-multiple-sources-for-an-application)
- [Config Management Tools Enhancements: Parametrization & Security Improvements](#config-management-tools-enhancements-parametrization--security-improvements)
- [v2.5 and beyond](#v25-and-beyond)
- [Config Management Tools Enhancements: UI/CLI](#config-management-tools-enhancements-uicli)
- [First class support for ApplicationSet resources](#first-class-support-for-applicationset-resources)
- [Merge Argo CD Image Updater into Argo CD](#merge-argo-cd-image-updater-into-argo-cd)
- [Sharding application controller](#sharding-application-controller)
- [Add support for secrets in Application parameters](#add-support-for-secrets-in-application-parameters)
- [Allow specifying parent/child relationships in config](#allow-specifying-parentchild-relationships-in-config)
- [Dependencies between applications](#dependencies-between-applications)
- [Multi-tenancy improvements](#multi-tenancy-improvements)
- [GitOps Engine Enhancements](#gitops-engine-enhancements)
- [Completed](#completed)
- [✅ Merge Argo CD Notifications into Argo CD](#-merge-argo-cd-notifications-into-argo-cd)
- [✅ Merge ApplicationSet controller into Argo CD](#-merge-applicationset-controller-into-argo-cd)
- [✅ Compact resources tree](#-compact-resources-tree)
- [✅ Maintain difference in cluster and git values for specific fields](#-maintain-difference-in-cluster-and-git-values-for-specific-fields)
- [✅ ARM images and CLI binary](#-arm-images-and-cli-binary)
- [✅ Config Management Tools Integrations (proposal)](#-config-management-tools-integrations-proposal)
- [✅ Argo CD Extensions (proposal)](#-argo-cd-extensions-proposal)
- [✅ Project scoped repository and clusters (proposal)](#-project-scoped-repository-and-clusters-proposal)
- [✅ Core Argo CD (proposal)](#-core-argo-cd-proposal)
- [✅ Core Functionality Bug Fixes](#-core-functionality-bug-fixes)
- [✅ Performance](#-performance)
- [✅ ApplicationSet](#-applicationset)
- [✅ Large Applications support](#-large-applications-support)
- [✅ Serviceability](#-serviceability)
- [✅ Argo CD Notifications](#-argo-cd-notifications)
- [✅ Automated Registry Monitoring](#-automated-registry-monitoring)
- [✅ Projects Enhancements](#-projects-enhancements)
The Argo CD roadmap is maintained in [a GitHub Project](https://github.com/orgs/argoproj/projects/25/views/14).
## v2.4
> ETA: May 2022
### Server side apply
Support using [server side apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) during application syncing
[#2267](https://github.com/argoproj/argo-cd/issues/2267)
### Input Forms UI Refresh
Improved design of the input forms in Argo CD Web UI: https://www.figma.com/file/IIlsFqqmM5UhqMVul9fQNq/Argo-CD?node-id=0%3A1
### Web Shell
Exec into the Kubernetes Pod right from Argo CD Web UI! [#4351](https://github.com/argoproj/argo-cd/issues/4351)
### Helm values from external repo
The feature allows combining of-the-shelf Helm chart and value file in Git repository ([#2789](https://github.com/argoproj/argo-cd/issues/2789))
### Support multiple sources for an Application
Support more than one source for creating an Application [#8322](https://github.com/argoproj/argo-cd/pull/8322).
### Config Management Tools Enhancements: Parametrization & Security Improvements
The continuation of the Config Management Tools of [proposal](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/parameterized-config-management-plugins.md).
The Argo config management plugin configuration allows users to specify the accepted parameters, default values to eventually power UI and CLI.
Additionally, plugins implementation should provide better Argo CD tenant isolation and security.
## v2.5 and beyond
### Config Management Tools Enhancements: UI/CLI
The Argo CD should provide a first-class experience for configured third-party config management tools. User should be able to view supported parameters,
observe default parameter values and override them.
### First class support for ApplicationSet resources
The Argo CD UI/CLI/API allows to manage ApplicationSet resources same as Argo CD Applications ([#7352](https://github.com/argoproj/argo-cd/issues/7352)).
### Merge Argo CD Image Updater into Argo CD
The [Argo CD Image Updater](https://github.com/argoproj-labs/argocd-image-updater) should be merged into Argo CD and available out-of-the-box: [#7385](https://github.com/argoproj/argo-cd/issues/7385)
### Sharding application controller
Application controller to scale automatically to provide high availability[#8340](https://github.com/argoproj/argo-cd/issues/8340).
### Add support for secrets in Application parameters
The feature allows referencing secrets in Application parameters. [#1786](https://github.com/argoproj/argo-cd/issues/1786).
### Allow specifying parent/child relationships in config
The feature [#5082](https://github.com/argoproj/argo-cd/issues/5082) allows configuring parent/child relationships between resources. This allows to correctly
visualize custom resources that don't have owner references.
### Dependencies between applications
The feature allows specifying dependencies between applications that allow orchestrating synchronization of multiple applications. [#3517](https://github.com/argoproj/argo-cd/issues/3517)
### Multi-tenancy improvements
The multi-tenancy improvements that allow end-users to create Argo CD applications using Kubernetes directly without accessing Argo CD API.
* [Applications outside argocd namespace](https://github.com/argoproj/argo-cd/pull/6409)
* [AppSource](https://github.com/argoproj-labs/appsource)
### GitOps Engine Enhancements
The [GitOps Engine](https://github.com/argoproj/gitops-engine) is a library that implements core GitOps functions such as K8S resource reconciliation and diffing.
A lot of Argo CD features are still not available in GitOps engine. The following features have to be contributed to the GitOps Engine:
* an ability to customize resources health assessment and existing CRD health [assessment functions](https://github.com/argoproj/argo-cd/tree/master/resource_customizations).
* resource diffing [customization](../user-guide/diffing/).
* config management [tools](../user-guide/application_sources/) integration.
* unified syncing annotations [argoproj/gitops-engine#43](https://github.com/argoproj/gitops-engine/issues/43).
## Completed
### ✅ Merge Argo CD Notifications into Argo CD
The [Argo CD Notifications](https://github.com/argoproj-labs/argocd-notifications) should be merged into Argo CD and available out-of-the-box: [#7350](https://github.com/argoproj/argo-cd/issues/7350)
### ✅ Merge ApplicationSet controller into Argo CD
The ApplicationSet functionality is available in Argo CD out-of-the-box ([#7351](https://github.com/argoproj/argo-cd/issues/7351)).
### ✅ Compact resources tree
An ability to collaps leaf resources tree to improve visualization of very large applications: [#7349](https://github.com/argoproj/argo-cd/issues/7349)
### ✅ Maintain difference in cluster and git values for specific fields
The feature allows to avoid updating fields excluded from diffing ([#2913](https://github.com/argoproj/argo-cd/issues/2913)).
### ✅ ARM images and CLI binary
The release workflow should build and publish ARM images and CLI binaries: ([#4211](https://github.com/argoproj/argo-cd/issues/4211))
### ✅ Config Management Tools Integrations ([proposal](https://github.com/argoproj/argo-cd/pull/5927))
The community likes the first class support of Helm, Kustomize and keeps requesting support for more tools.
Argo CD provides a mechanism to integrate with any config management tool. We need to investigate why
it is not enough and implement missing features.
### ✅ Argo CD Extensions ([proposal](https://github.com/argoproj/argo-cd/pull/6240))
Argo CD supports customizing handling of Kubernetes resources via diffing customizations,
health checks, and custom actions. The Argo CD Extensions proposal takes it to next
level and allows to deliver the resource customizations along with custom visualization in Argo CD
via Git repository.
### ✅ Project scoped repository and clusters ([proposal](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/project-repos-and-clusters.md))
The feature streamlines the process of adding repositories and clusters to the project and makes it self-service.
Instead of asking an administrator to change Argo CD settings end users can perform the change independently.
### ✅ Core Argo CD ([proposal](https://github.com/argoproj/argo-cd/pull/6385))
Core Argo CD allows to installation and use of lightweight Argo CD that includes only the backend without exposing the API or UI.
The Core Argo CD provides a better experience to users who need only core Argo CD features and don't want to deal with multi-tenancy features.
### ✅ Core Functionality Bug Fixes
The core GitOps features still have several known bugs and limitations. The full list is available in [v1.9 milestone](
https://github.com/argoproj/argo-cd/issues?q=is%3Aopen+is%3Aissue+label%3Abug+milestone%3A%22v1.9%22+label%3Acomponent%3Acore)
The most notable issues:
* [Argo CD synchronization lasts incredibly long](https://github.com/argoproj/argo-cd/issues/3663)
### ✅ Performance
* 2000+ Applications support. The user interface becomes notably slower if one Argo CD instance manages more than 1 thousand applications.
A set of optimizations is required to fix that issue.
* 100+ Clusters support. The cluster addon management use-case requires connecting a large number of clusters to one Argo CD controller.
Currently Argo CD controller is unable to handle that many clusters. The solution is to support horizontal controller scaling and automated sharding.
* Mono Repository support. Argo CD is not optimized for mono repositories with a large number of applications. With 50+ applications in the same repository, manifest generation performance drops significantly. The repository server optimization is required to improve it.
### ✅ ApplicationSet
Argo CD Applications allow splitting the cluster configuration into logic groups that are managed independently. However, the set of applications
is a configuration that should be managed declaratively as well. The app-of-apps pattern solves this problem but still has some challenges such as
maintenance overhead, security, and lack of some additional features.
[ApplicationSet](https://github.com/argoproj-labs/applicationset) project provides a better solution for managing applications across multiple environments.
### ✅ Large Applications support
The application details page is not suitable to visualize applications that include a large number of resources (hundreds of resources). The page has to be reworked
to improve user experience.
### ✅ Serviceability
To make Argo CD successful we need to build tools that enable Argo CD administrators to handle scalability and performance issues in a self-service model.
That includes more metrics, out-of-the-box alerts and a cluster management user interface.
### ✅ Argo CD Notifications
[Argo CD Notifications](https://github.com/argoproj-labs/argocd-notifications) provides the ability to notify users about Argo CD Application
changes as well as implement integrations such as update GitHub commit status, trigger Jenkins job, set Grafana label, etc.
### ✅ Automated Registry Monitoring
[Argo CD Image Updater](https://github.com/argoproj-labs/argocd-image-updater) provides an ability to monitor Docker registries and automatically
update image versions in the deployment repository. See [https://github.com/argoproj/argo-cd/issues/1648](https://github.com/argoproj/argo-cd/issues/1648).
### ✅ Projects Enhancements
Argo CD projects accumulated a lot of debt:
* Users don't know how to use project roles and SSO. It is one of the key features but not documented well. We need to document and promote it
* Project management UI has evolved organically and needs a complete redesign. We packaged everything into one sliding panel which is painful to use
* Enhancements: [#3598](https://github.com/argoproj/argo-cd/issues/3598)
Releases are planned according to the [Release Process and Cadence](developer-guide/release-process-and-cadence.md) doc.