Saltar a contenido

Development Conventions

Camunda usa Conventional Commits, Google Java Format, JDK 21 (algunos módulos legacy en JDK 8 para compatibilidad de clientes), workflow basado en rebase + force-push, backporting automatizado vía labels. La heurística de severity más útil: "¿Hubo data loss o corrupción?" → CRITICAL inmediato. El módulo identity será renombrado a admin.

Severity Heuristic — la más valiosa

Para un workflow engine, Camunda define severity con preguntas concretas:

  1. ¿Hubo data loss o corruption? → CRITICAL
  2. ¿Hay configuration workaround?
  3. ¿El cluster recuperó automáticamente o requirió intervención manual?
  4. ¿Processing unavailable?
  5. ¿Exporting unavailable?

Esto revela las prioridades de negocio:

Data integrity > Availability > Exporting

Para el MVP: replicar esto en runbook operacional.

Nivel Definición
Critical Data loss, RCE, sin workaround
High Notable impact, sin workaround, regular crashes
Mid Notable impact, workaround conocido
Low Log noise, sin impacto al usuario
Unknown Tratar como High

Build commands

# Quick dev build (skips Optimize)
./mvnw clean install -Dquickly

# Full build sin tests
./mvnw clean install -DskipChecks -DskipTests

# Sin frontends
./mvnw clean install -DskipChecks -DskipTests -PskipFrontendBuild

# Full con tests
./mvnw clean install

# Quick tests
./mvnw verify -Dquickly -DskipTests=false

Output artifact: dist/target/camunda-zeebe-X.Y.Z-SNAPSHOT.tar.gz

Java version split

Módulos JDK version
Mayoría JDK 21 + language level 21
Cliente y protocolo JDK 8 language level

Módulos en JDK 8: - camunda-client-java - camunda-process-test-java - zeebe-bpmn-model - zeebe-build-tools - zeebe-gateway-protocol(-impl) - zeebe-protocol(-jackson)

Razón: clientes Java legacy aún usan JDK 8 en producción. Los módulos exportados deben ser compatibles.

Implicación MVP: si haces SDK para clientes, considerar compatibility con versiones más viejas del lenguaje target.

Code conventions

  • Google Java Format (auto-aplicado por Maven)
  • Zeebe Code Style (manual, en wiki interno)
  • Conventional Commits para mensajes
  • Squash commits relacionados antes de review

PR Workflow

1. Branch name: issueId-description
   git checkout -b 123-adding-bpel-support

2. Commit con conventional format
   git commit -am 'feat: add BPEL execution support'

3. Push y create PR
   git push -u origin 123-adding-bpel-support

4. Review (emoji code)

5. Squash commits si hay cleanup commits

6. Force push (lease)
   git push --force-with-lease

7. Merge queue: "Merge when ready" button
   - Bot merge con latest main
   - Run CI
   - Auto-merge si pasa

Review Emoji Code

Convención inspirada en Microsoft:

Emoji Cuándo usar
👍 / :+1: Like — feedback positivo
❓ / :question: Question — necesita clarificación
❌ / :x: Blocker — debe cambiar
🔧 / :wrench: Suggestion — opcional
💭 / :thought_balloon: Thinking out loud

Distingue claramente required vs optional changes en code review. Adoptable inmediatamente.

Backporting

Vía labels en el PR: - backport stable/8.5 → port a branch stable/8.5 - Multiple labels → port a multiple branches - Trigger automático on merge, o /backport comment para PR ya merged

Implementado vía zeebe-io/backport-action.

Implicación MVP: solo relevante cuando se mantienen multiple stable branches. Para MVP early stage, una sola main branch.

IntelliJ setup

Run config para development local:

Module: camunda-zeebe
Main class: io.camunda.application.StandaloneCamunda
Active profiles: admin,tasklist,operate,broker,consolidated-auth,dev,insecure

Env vars críticas (todos los componentes): - ZEEBE_BROKER_EXPORTERS_CAMUNDAEXPORTER_* — configuración de exporter - CAMUNDA_SECURITY_INITIALIZATION_USERS_* — usuario default demo/demo - CAMUNDA_SECURITY_INITIALIZATION_DEFAULTROLES_ADMIN_USERS_0_=demo

URLs locales: - Tasklist: http://localhost:8080/tasklist - Operate: http://localhost:8080/operate - Admin: http://localhost:8080/admin

Notas misceláneas

Apple Silicon Macs

Build puede fallar con errors de protoc. Solución: Rosetta debe estar instalado.

IntelliJ memory

Para archivos grandes (GatewayOuterClass), aumentar: 

idea.max.intellisense.filesize=9999

Identity → Admin rename

"identity - component within self-managed Camunda 8 responsible for authentication and authorization. Will soon be renamed to admin to better reflect its purpose."

Cambio de nombre venidero — solo afecta naming.

Implicaciones para el MVP

Adoptar inmediatamente

  1. Severity heuristic — runbook con preguntas concretas
  2. Conventional Commits — facilita changelog generation
  3. Review emoji code — clarity en code review
  4. Force-push with-lease — previene sobrescribir trabajo
  5. Squash commits pre-merge — historia limpia

Considerar más tarde

  1. Backporting action — solo cuando hay multiple stable branches
  2. JDK split — para clientes legacy si MVP los soporta
  3. Severity-based prioritization — cuando hay equipo

NO adoptar

  1. CLA proceso — para MVP open-source, license puro
  2. IntelliJ-specific tooling — debe funcionar en cualquier editor

Una lección key

La pregunta "¿Hubo data loss?" como primera question en triage es profundamente correcta para workflow engines. Replicarla:

def triage_severity(bug_report):
    if data_loss_or_corruption(bug_report):
        return Severity.CRITICAL
    if no_workaround(bug_report) and impacts_availability(bug_report):
        return Severity.HIGH
    if has_workaround(bug_report) and impacts_users(bug_report):
        return Severity.MID
    return Severity.LOW

Workflow engines son confiados con state-of-business. Data corruption es catastrophic en formas que availability no lo es.