Module 15 Cheat Sheet

PROJECT
=======

pom.xml
  Maven dependencies/build/deploy

mule-artifact.json
  Mule application metadata


BUILD
=====

mvn test
mvn package

Deploy commonly:
mvn clean deploy -DmuleDeploy


TARGETS
=======

CloudHub 2.0
Runtime Fabric
On-prem


CLOUDHUB 2.0
============

managed/containerized
application replicas


RUNTIME MANAGER
===============

deploy
start/stop
status
monitor
troubleshoot
alerts


CI/CD
=====

PR
 ↓
MUnit
 ↓
build
 ↓
versioned artifact
 ↓
QA
 ↓
smoke tests
 ↓
PROD


CONFIGURATION
=============

same artifact

different:
endpoints
credentials
secrets
environment properties


OPERATIONS
==========

correlation IDs
structured logging
metrics
alerts
health/readiness


ROLLBACK
========

restore known-good artifact

BUT:

rollback does NOT
undo Salesforce/data side effects


SCALING
=======

multiple replicas
→ don't depend on local state


RELEASE SAFETY
==============

verify:
RUNNING
correct version
correct environment
Salesforce connectivity
smoke tests
error rate

The interview sentence to memorize is:

“I treat Mule deployment as a standard immutable-artifact CI/CD process: Maven build and MUnit first, deploy the same versioned artifact across environments with configuration and secrets injected separately, verify the runtime reaches RUNNING, execute smoke tests, and monitor the integration afterward. For rollback I also account for downstream side effects because reverting code doesn't undo Salesforce data.”

Next should be Module 16 — Production Engineering and Observability: timeouts, connection pools, retries, rate limiting, correlation IDs, logs, metrics, Salesforce API consumption, performance, alerting, runbooks, and how to diagnose “Mule is slow” without guessing.