Skip to content

Development & Deployment Principles

The Talisman platform, built upon the open-source foundation of Apache Camel Karavan, is engineered to streamline integration development, enforce architectural consistency, and guarantee a secure, repeatable promotion lifecycle. The following principles govern how development, artifact management, and versioning are handled within the ecosystem.

Project Governance

The platform mandates a decentralized, microservice approach to integration development.

  • Microservice-First Design: All development efforts are oriented around discrete, independently deployable integration microservices.
  • Standardized Project Structure: Microservices are maintained within a flat directory structure to reduce complexity. A standard project repository consists of deployment configurations alongside 5–10 Camel routes and 3–5 Groovy scripts.
  • Strict Route Organization: Routes are strictly authored using the Camel YAML DSL, enforcing a strict one-route-per-file convention to minimize merge conflicts and improve maintainability.
  • Access & Tenancy: A single Talisman instance maps directly to a single Git repository. All developers provisioned on a specific instance share access to the projects within that repository. A single developer typically owns a project. A single team typically owns an instance.
  • Environment Isolation: To enforce strict logical separation between distinct business domains or teams, administrators must deploy multiple independent Talisman instances, each utilizing dedicated Kubernetes namespaces and isolated Git repositories.

Artifact Lifecycle

Talisman relies on containerization to ensure consistency across all environments.

  • Software Over Code: The primary deliverable is functional, containerized software rather than raw source code. Container images serve as the exclusive artifact for deployment.
  • Build-Once Principle: Container images and their associated deployment manifests are generated only once within the Development (dev) environment.
  • Strict Production Parity: Source code is never recompiled or rebuilt for higher environments. The exact, immutable image validated in Development is promoted directly to Testing (test) and Production (prod). This guarantees absolute environmental consistency and eliminates build drift.

Single Branch Strategy

The Talisman ecosystem is optimized for a Single-Branch Architecture. To safeguard production environments while maintaining developer velocity, teams can utilize the following versioning strategies.

Image-Based Tagging

For sequential lifecycle management, stability is maintained by strictly controlling container image tags.

  • Production Lock: When a microservice is promoted to Production, the deployment manifest is locked to a specific, immutable version tag (e.g., v1.0.4).
  • Continuous Iteration: Because the Production deployment is bound to a static tag, developers can safely commit new code to the main branch and generate rolling development builds (e.g., latest or dev-snapshot) without risking disruption to live services.

Concurrent Project Versioning

If business requirements dictate running multiple major versions of the same service simultaneously in a live environment, developers must manage distinct project repositories. Kubernetes namespace constraints prohibit deploying multiple versions of an application under identical deployment names.

  • Side-by-Side Deployment: To host overlapping versions, developers must duplicate the service into a distinct project folder with a unique deployment identifier (e.g., payment-service-v1 and payment-service-v2).
  • Lifecycle Management: Existing code is maintained in v1 for critical patches, while next-generation architecture is developed independently in v2.
  • Deprecation: Once consumer traffic is successfully routed to the newer release and the legacy service is decommissioned from Production, the v1 project repository should be archived and deleted to reduce technical debt.