docs:upgrading Alauda DevOps from ACP 3.18 to 4.x.#59
Conversation
WalkthroughThe upgrade guide is retargeted to “Alauda DevOps (Next-Gen),” updates the Version Compatibility Matrix (including Harbor, SonarQube, Nexus), adds a special Pipelines note, restructures prerequisites around ACP-first upgrades, generalizes packaging/operator terminology, and revises UI/operator migration steps and cross-references accordingly. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Admin
participant ACP as ACP Platform
participant AD as Alauda DevOps (Next-Gen)
participant Ops as DevOps Operators
participant UI as DevOps UI
note over Admin,ACP: Prerequisite: Confirm versions via Compatibility Matrix
Admin->>ACP: Upgrade ACP to v4.x (from v3.18)
Note right of ACP: Platform ready
Admin->>Ops: Upload/align operator versions (per matrix)
Ops-->>AD: Operators installed/updated
Admin->>UI: Run UI-based upgrade/migration
UI-->>AD: Apply UI changes (v3 → Next-Gen)
note over UI,AD: Targets: Alauda DevOps v3 & Eventing v3
alt During ACP v3.18 → v4.x
note over AD: Pipelines supports only v4.0
end
Admin->>AD: Validate components (Harbor, SonarQube, Nexus, Eventing)
AD-->>Admin: Upgrade complete
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (8)
docs/en/upgrade/upgrading-devops-v3-to-v4.mdx (8)
6-9: Remove inline code formatting for product names and tighten version wordingUse plain text for product/brand names and specify minor streams as x.y.x to avoid ambiguity.
Apply this diff:
-# Upgrading `Alauda DevOps` to `Alauda DevOps (Next-Gen)` +# Upgrading Alauda DevOps to Alauda DevOps (Next-Gen) -This guide details the upgrade strategy and procedures for `Alauda DevOps` to `Alauda DevOps (Next-Gen)` when upgrading from `Alauda Container Platform v3.18` to `v4.0` or `v4.1`. +This guide details the upgrade strategy and procedures for Alauda DevOps to Alauda DevOps (Next-Gen) when upgrading from Alauda Container Platform v3.18 to v4.0.x or v4.1.x.
10-24: Clarify scope of rows and fix “GitLab” capitalization
- Consider renaming the first column header to “Component/Operator” to reflect that the matrix mixes operators and external components.
- Confirm whether “Alauda DevOps v3” and “Alauda DevOps Eventing v3” rows refer to operator versions or product bundles; if operators, append “Operator” to each row label for consistency.
- Capitalize GitLab correctly.
Apply this diff to fix capitalization:
-| Alauda Build of Gitlab | v17.8.z | +| Alauda Build of GitLab | v17.8.z |Optionally, if these are operator versions, consider:
-| Alauda DevOps v3 | v3.20.z | -| Alauda DevOps Eventing v3 | v3.20.z | +| Alauda DevOps v3 Operator | v3.20.z | +| Alauda DevOps Eventing v3 Operator | v3.20.z |
29-34: Make the Pipelines support constraint explicit and verifiableThe note says Pipelines “only supports version v4.0” when ACP is upgraded to 4.0 or 4.1. If 4.1 is truly unsupported, say “supports only v4.0.x; 4.1.x is not supported.” If 4.1 is conditionally supported (specific patches), capture that precisely and link to the release notes.
Proposed edit:
-Special Note: In the scenario where `ACP v3.18` is upgraded to `v4.0` or `v4.1`, Alauda DevOps Pipelines only supports version `v4.0`. +Special Note: When upgrading ACP v3.18 to v4.0 or v4.1, Alauda DevOps Pipelines currently supports only version v4.0.x. Verify v4.1.x support in the Pipelines release notes before proceeding.
37-40: Strengthen the prerequisite with backup/checklist itemsUpgrades here are disruptive. Recommend adding explicit backup and preflight checks so operators don’t miss critical steps.
Suggested addition under Line 39:
First, upgrade the `ACP` platform to version `v4`. For detailed instructions, refer to <ExternalSiteLink name="container_platform" href="upgrade/overview.html" children="Upgrading Container Platform" />. +Before proceeding: +- Back up etcd snapshots and ACP configuration. +- Back up DevOps-related namespaces (PVCs, databases, and operator CRs). +- Schedule a maintenance window and notify users of pipeline/job downtime. +- Verify cluster capacity and add-on compatibility against the Version Compatibility Matrix.
41-47: Verify the linked UI/CLI page and align wording with what the link actually providesThe link text says “Uploading Operators,” but the href points to a CLI tools section. Ensure the link matches the actual step (downloading vs. uploading) and add the missing “install” action to avoid confusion.
Possible tweak if the current link is indeed for downloading:
-After completing the `ACP` platform upgrade, you need to separately prepare the `Alauda DevOps Operators` and upload them. For specific operation steps, refer to <ExternalSiteLink name="container_platform" href="ui/cli_tools/#downloading-the-tool" children="Uploading Operators" />. +After completing the ACP platform upgrade, separately download the Alauda DevOps operator packages, then upload and install them. For detailed steps, refer to <ExternalSiteLink name="container_platform" href="ui/cli_tools/#downloading-the-tool" children="Downloading the CLI tool" />.If there’s a dedicated “Uploading Operators” page, link that instead.
53-60: Gate the migration list by component presence and fix “GitLab” capitalizationClarify that these migrations apply only if the component is in use, and fix the product name.
Apply this diff:
-After completing the prerequisites, upgrade the following `Operators` as documented: +After completing the prerequisites, upgrade the following components if they are in use, following their product-specific guides: @@ -- [Migrating Alauda Build of Gitlab](https://docs.alauda.io/alauda-build-of-gitlab/17.8/upgrade/02_14_upgrade_to_17.html) +- [Migrating Alauda Build of GitLab](https://docs.alauda.io/alauda-build-of-gitlab/17.8/upgrade/02_14_upgrade_to_17.html)Optional: add a short reminder to back up each component’s data (DBs, object storage) before running its migration guide.
63-65: Add UI-channel guidance and validation stepIn many operator hubs, moving from v3 to v4 requires selecting the target update channel and approving install plans. Add a brief reminder to choose the correct channel and verify CRD upgrades in a staging environment first.
Suggested addition at the end of Line 65:
Navigate to `Administrator` -> `Marketplace` -> `Operator Hub`, switch to the target cluster and enter the corresponding Operator details page. Click the instance name you want to upgrade to enter the instance details page, then follow the instructions to complete the upgrade. +Ensure you select the v4 update channel (if applicable), review the install plan, and validate the CRD/API changes in a staging project before promoting to production.
69-69: Clarify “latest” and add a post-upgrade validation checklist“May not be the latest” is vague; suggest pointing to where to check “latest,” and include a short validation checklist to close out the upgrade.
Proposed wording:
-You have now completed the upgrade of `Alauda DevOps` in the `ACP v3` to `v4` upgrade scenario. However, the `Operators` upgraded via [Upgrade via Migration](#Migration) may not be the latest available versions. You can contact technical support to obtain the latest Operators and continue upgrading to the latest version using the [Upgrading Instances via UI](#UI) method. +You have now completed the upgrade of Alauda DevOps in the ACP v3 → v4 scenario. Operators upgraded via [Upgrade via Migration](#Migration) might not be on the latest patch stream. Check the latest supported versions in the Version Compatibility Matrix and product release notes, then continue with [Upgrading Instances via UI](#UI) as needed or contact Alauda Support for curated upgrade bundles. + +Post-upgrade quick checks: +- All operators report Healthy/Available. +- Pipelines can be created and run; existing pipeline runs/jobs are visible. +- DevOps portal loads without errors; core CRDs report expected versions. +- Component UIs (GitLab/Harbor/SonarQube/Nexus) are reachable and show the target versions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
docs/en/upgrade/upgrading-devops-v3-to-v4.mdx(3 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/en/upgrade/upgrading-devops-v3-to-v4.mdx
[grammar] ~14-~14: There might be a mistake here.
Context: ... Alauda DevOps Operator | Version | | ------------------------- | --------- ...
(QB_NEW_EN)
[grammar] ~15-~15: There might be a mistake here.
Context: ... ------------------------- | --------- | | Alauda DevOps v3 | v3.20.z ...
(QB_NEW_EN)
[grammar] ~16-~16: There might be a mistake here.
Context: ... Alauda DevOps v3 | v3.20.z | | Alauda DevOps Eventing v3 | v3.20.z ...
(QB_NEW_EN)
[grammar] ~17-~17: There might be a mistake here.
Context: ... Alauda DevOps Eventing v3 | v3.20.z | | Alauda DevOps Jenkins v3 | v3.20.z ...
(QB_NEW_EN)
[grammar] ~46-~46: There might be a mistake here.
Context: ...Version Compatibility Matrix](#Version). ::: ## Upgrading Alauda DevOps ### Upg...
(QB_NEW_EN)
🔇 Additional comments (1)
docs/en/upgrade/upgrading-devops-v3-to-v4.mdx (1)
55-59: All External Migration Links ValidatedAll four external migration guide URLs return HTTP 200 OK and are reachable as of this check. No broken or redirected links detected—ready to merge.
Summary by CodeRabbit