Wróć do bloga

CI/CD na CloudHub 2.0: opublikuj raz w Exchange, promuj bez rebuildu

2026-09-17

Na CloudHub 2.0 deploy przez Mule Maven Plugin pobiera artefakt z Anypoint Exchange — tak jak na Runtime Fabric. Najpierw publikujesz GAV do Maven Facade v3, potem cloudhub2Deployment / -DmuleDeploy instaluje ten sam binariusz na Shared Space lub Private Space. Build once = jeden artefakt / jedna wersja; deploy many = mvn mule:deploy z env-specific properties / secureProperties — bez mvn clean package na UAT i PROD.

Czego ten tekst nie jest: skopiowanym pipeline’em CloudHub 1.0 z cloudHubDeployment, hasłem użytkownika w YAML i rebuildem na każdym środowisku. Jest przewodnikiem pułapek dla platform / DevOps / leadów integracji na Azure DevOps lub GitHub Actions (typowe w EU enterprise).

Poniżej: dlaczego CH2 psuje „stary” pipeline, karty pułapek (objaw → przyczyna → docs → wzorzec), szkic ADO/GHA, checklista oraz FAQ pod AEO.

Dlaczego CH2 psuje pipeline skopiowany z CH1

Exchange-first nie jest opcjonalne

Docs: The application is already published in Exchange oraz Facade v3 w distributionManagement (Deploying Apps with the Mule Maven Plugin — Before You Begin). Klasyczny błąd: No application with the provided GAV could be retrieved from Exchange.

EU org: Facade URL https://maven.eu1.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven (region wg Publish and Deploy Exchange Assets Using Maven).

cloudHubDeployment ≠ cloudhub2Deployment

CH2 wymaga elementu cloudhub2Deployment z provider=MC oraz target = region Shared Space (np. Cloudhub-US-East-1, Cloudhub-EU-West-1) albo nazwa Private Space. Profil CH1 (cloudHubDeployment, workers/region) na CH2 nie zadziała jako „ten sam pom”.

Twin runtime docs: Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin.

Pułapka #1: User/pass zamiast Connected App

Objaw: hasła ludzi w Variable Groups / GitHub Secrets; MFA blokuje CI; rotacja kont psuje pipeline; audyt „who deployed?” nieczytelny.

Przyczyna: przykłady w docs nadal pokazują username/password, ale dla CI/CD zalecane są Connected Apps (client_credentials). Password grant ujawnia credentials i koliduje z MFA (Connected Apps for Developers).

Docs: Connected App w Maven: connectedAppClientId, connectedAppClientSecret, connectedAppGrantType=client_credentials; wymagany scope Design Center Developer (ch2-deploy-maven — Authentication). Exchange: username ~~~Client~~~, password clientId~?~clientSecret (to-publish-assets-maven).

Wzorzec: Connected App (least privilege per BG/env) → settings.xml server lub explicit connectedApp* w POM. Zero user passwords w YAML.

Pułapka #2: Brakujące scopes → 403 po „udanym” deployu

Objaw: aplikacja pojawia się w Runtime Manager, ale Maven kończy się 403 (często na path domains / status verification).

Przyczyna: często brak Read Applications na właściwym Business Group + Environment. Deploy może przejść; weryfikacja statusu przez plugin pada (Help: 403 Connected App CH2; Minimum Permissions for CI/CD).

Wzorzec: przed pierwszym pipeline checklista scopes per BG i environment (Create Applications, Manage Settings, Manage Application Data, Read Applications + Design Center Developer). Test na Sandbox. Opcjonalnie skipDeploymentVerification tylko jako tymczasowy workaround — nie jako „fix” uprawnień.

Pułapka #3: Rebuild na UAT/PROD

Objaw: każde środowisko robi mvn clean package/deploy; drift binariusza; różne timestamps / dependency resolution; „działało na DEV”.

Docs: mvn clean deploy -DmuleDeploy albo mvn mule:deploy — To deploy the artifact without rebuilding it (ch2-deploy-maven — Deploy).

Wzorzec: CI = build + MUnit + flatten + publish stable GAV do Exchange. CD = mule:deploy na ten sam GAV; różnice env = tylko properties / secureProperties.

Pułapka #4: Secrets w YAML / properties zjadają UI

Objaw: po redeploy znikają properties z Runtime Manager; Key Vault „nie trafia”; brakuje części sekretów mimo „dokładki” w POM.

Docs: jeśli w POM jest którykolwiek z elementów properties lub secureProperties, CH2 używa tylko tego zestawu — bez merge z Runtime Manager; brakujące klucze są usuwane (ch2-deploy-maven).

Wzorzec: POM deploy = pełny desired state albo pomiń oba elementy przy redeploy „binary only”. Azure Key Vault / GitHub Environments → secureProperties w CD. Traktuj każdą promocję jako kompletny snapshot configu, nie delta.

Pułapka #5: Stary Mule Maven Plugin + LTS / Java 17

Objaw: nie da się wybrać LTS; releaseChannel/javaVersion ignorowane; default EDGE/Java 8 wbrew polityce org.

Docs: releaseChannel = NONE|EDGE|LTS (default EDGE); javaVersion = 8|17 (default 8). LTS nie dla pluginu ≤4.1.0 — upgrade do ≥4.1.1. Po EOL Mule 4.4 SS (Oct 2024): nowe app → 4.6 LTS lub 4.8 Edge. Deprecated m.in. 3.0.0–3.1.7 i 3.8.3 (ch2-deploy-maven).

Pin przy publish (2026-09-17): oficjalne release notes wskazują mule-maven-plugin 4.10.1 (14 Jul 2026) jako najnowszy w indeksie — security/bugfixy nad 4.10.0; wsparcie Java 8/11/17/21; Maven 3.9.0–3.9.15 (4.10.1 Release Notes, plugin release index). Przykłady w docs nadal pokazują 3.7.1 — nie kopiuj numeru z snippetu; pin ≥4.1.1 (preferuj aktualny latest z release notes).

Wzorzec: pin plugin 4.10.1 (lub nowszy z release notes w dniu cutoveru); jawnie ustaw releaseChannel + javaVersion w CD.

${revision} / flatten i SNAPSHOT

Exchange wymaga unikalnego GAV dla stable; SNAPSHOT nadpisuje development state — unikaj SNAPSHOT na PROD (ch2-deploy-maven — Exchange Snapshot Assets, to-publish-assets-maven). CI-friendly versions (${revision}) → resolve (np. flatten-maven-plugin) przed publish. Nie mieszaj maven-deploy-plugin z mule-maven-plugin przy publish do Exchange.

Szkic: Azure DevOps i GitHub Actions (ten sam kontrakt Maven)

Etap ADO GitHub Actions
CI Build + MUnit → flatten → publish Exchange Job build → publish Exchange
CD Release stages + Variable Groups + Key Vault → mule:deploy Environment jobs + approvals → mule:deploy
Auth Connected App secrets Connected App secrets
Zakaz User/pass, rebuild per env, SNAPSHOT na PROD To samo

Nie kopiuj happy-path YAML 1:1 — checklista failure modes powyżej jest ważniejsza niż szablon.

How-to wideo (oEmbed zweryfikowany 2026-09-17): #01: Anypoint CloudHub2.0 | Deploying… using Mule Maven Plugin (Mule Ace Academy) — publish Exchange → deploy Shared Space. Ops adjacency (HA/cluster): CloudHub 2.0 Part II… (Sanjeev Tripathi).

Checklista CI/CD CH2 (kolejność)

  1. Connected App (client_credentials) + scopes per BG/env (w tym Read Applications).
  2. Facade v3 w distributionManagement (właściwy region).
  3. POM: cloudhub2Deployment (provider=MC, target, applicationName, repliki/vCores).
  4. Plugin mule-maven 4.10.1 (min. ≥4.1.1); jawny releaseChannel / javaVersion gdy LTS/Java 17.
  5. Flatten / resolve ${revision} przed Exchange publish.
  6. CI: publish raz stable GAV (bez SNAPSHOT na PROD).
  7. CD: mvn mule:deploy bez rebuild; pełny zestaw properties/secureProperties albo żadnego.
  8. Smoke: status w Runtime Manager + brak 403 na verification.

FAQ

1. Czy deploy na CloudHub 2.0 wymaga publikacji w Anypoint Exchange?

Tak — dla ścieżki Maven. Docs wymagają, aby aplikacja już była w Exchange (Facade v3), zanim uruchomisz deploy na CH2.

2. Czym różni się cloudhub2Deployment od cloudHubDeployment?

cloudHubDeployment to model CH1 (workers/region). CH2 używa cloudhub2Deployment z provider=MC i target Shared/Private Space.

3. Dlaczego w CI/CD lepiej Connected App niż login/hasło?

Connected App działa programowo (client_credentials), nie wymaga MFA użytkownika i nie trzyma haseł ludzi w YAML. Docs wymagają m.in. scope Design Center Developer.

4. Jak wygląda build once, deploy many?

CI: mvn clean deploy (publish do Exchange). CD: mvn mule:deploy bez przebudowy artefaktu; różnice środowisk = properties.

5. Do czego służy flatten / ${revision}?

Żeby CI-friendly versions zostały zresolvowane przed publish — Exchange nie powinien dostać literału ${revision}. Stable GAV musi być unikalny.

6. Skąd brać sekrety na UAT/PROD?

Z vault / Key Vault / GitHub Environments → secureProperties w CD. Pamiętaj: obecność properties lub secureProperties w POM zastępuje (nie merguje) config z Runtime Manager.

7. Dlaczego pipeline dostaje 403 po „udanym” deployu?

Często brak scope Read Applications — app jest wdrożona, ale plugin nie może zweryfikować statusu. Sprawdź Help o 403 Connected App CH2.

8. Kiedy potrzebuję Mule Maven Plugin ≥ 4.1.1? Jaki pin dziś?

Gdy chcesz releaseChannel (LTS/EDGE) i javaVersion (8/17) przez Maven — LTS nie jest wspierane w pluginie ≤4.1.0. Przy publish (2026-09-17) pinuj 4.10.1 z oficjalnych release notes (nie 3.7.1 ze snippetów docs).

9. Czy wolno wdrażać SNAPSHOT na produkcję CloudHub 2.0?

Docs odradzają: snapshot assets mogą się zmieniać po deployu — unikaj na production; używaj do DEV/test iterate + redeploy.

Soft CTA

Budujesz pipeline CH2 (ADO / GitHub Actions) i chcesz przejrzeć Exchange-first, Connected App scopes i build once bez rebuildu na PROD? Solita to nordycki partner MuleSoft z dostawą z Polski (EU-shoring) — pomagamy ułożyć kontrakt Maven i checklistę failure modes. Bez obietnic „#1” i bez skopiowanego YAML marketingowego.

Źródła

Dokumentacja

Help

How-to wideo (oEmbed 2026-09-17)