Skip to main content

Release process overview

This document describes the end-to-end release process for delivering changes to ES Loyalty and ES LoyaltyBoost, from development through QA and into client production environments. It is intended for technical stakeholders, such as client engineering, architecture, and operations teams, who need to understand how changes are built, tested, and promoted.

Products covered​

Loyalty

ES Loyalty

A componentized platform made up of approximately 25 independently maintained services. Each component includes application source code, Jenkins build and deployment scripts, and AWS CloudFormation templates.

Optimization

ES LoyaltyBoost

A data-driven campaign optimization engine that works alongside ES Loyalty. Each release bundles multiple services, data science modules, and UI elements under a single version number.

Source control and versioning​

ES Loyalty​

ES Loyalty development follows a trunk-based model:

  • Feature work is done on short-lived branches.
  • Changes are merged into master via pull requests.
  • Release candidate builds are created from master.

If a production fix is required after a release is cut, the affected components may be branched from the release point, patched, and re-released.

ES LoyaltyBoost​

Each LoyaltyBoost release is assigned a unique version number, such as 2.9.3, which is used to track and manage deployments across environments. Each release also includes both user-facing and technical release notes that describe new features, changes, and operational considerations.

Deployment model​

ES Loyalty​

Deployments are orchestrated through Jenkins using a descriptor-based model. A descriptor pins the exact version of each component to be deployed to a given environment. Each repository includes the CloudFormation templates needed for infrastructure provisioning alongside the application code.

ES LoyaltyBoost​

Each LoyaltyBoost environment is defined by two artifacts:

  • A master version file that specifies the exact LoyaltyBoost release to deploy.
  • An environment configuration file that contains all client-specific and environment-specific settings, such as integrations, data pipelines, and feature toggles.

Deployments are fully automated and driven by these artifacts, which minimizes manual steps and reduces configuration drift.

Environments and path to production​

Both products move through the same sequence of environments before reaching client production.

Internal

QA

Integration testing and feature validation within the sprint.

›
Client

UAT / SIT

Client validation of functionality, integrations, and business rules.

›
Live

Production

The live environment that serves end users.

Typical path to production​

  1. Merge dev and feature branches into master.
  2. Generate a descriptor or version file and deploy to QA.
  3. After internal QA sign-off, deploy to UAT/SIT for each client.
  4. Once the client accepts UAT/SIT, deploy the release to production.

The same release version and configuration pattern is used at each stage, ensuring consistency and traceability throughout the process.

Deploying to QA​

ES Loyalty​

To deploy ES Loyalty to QA, the Release Manager or QA Lead does the following:

  1. Select the target descriptor from the S3 release-candidate bucket.
  2. Run the comprehensive deployment job for the target QA environment.
  3. Notify key stakeholders of the descriptor and version being deployed, the target environment, and the change summary from the Descriptor Delta job.
  4. Monitor Jenkins output and deployment status. Deployments typically take 30 to 40 minutes, after which an automated success or failure message is shared with key stakeholders.
  5. Validate post-deployment configuration.

ES LoyaltyBoost​

To deploy LoyaltyBoost to QA:

  1. Review and validate the target LoyaltyBoost version and environment configuration.
  2. Trigger the deployment job, which applies the specified version and configuration to the target environment.
  3. Run automated and manual tests to confirm application functionality, data integrity, and integration points.

Testing​

Testing within the sprint​

Each story or task typically includes a dedicated testing subtask. Automated test coverage requirements are decided during backlog grooming and sprint planning, and effort estimates include both dev and QA work.

As soon as changes are merged to master and included in a descriptor or version file, they can be deployed to QA for:

  • Component-level tests
  • End-to-end integration tests in ES Console and backend services
  • Regression checks on areas affected by the deployment delta

Client UAT and SIT​

Once a candidate release passes internal QA, it is deployed to UAT and SIT environments for each client. Clients exercise both functional and integration scenarios, often over several weeks, to validate:

  • Business rules and promotions
  • Downstream integrations
  • Reporting pipelines and dashboards

For LoyaltyBoost, the client team validates the release before it is promoted to production.

Production releases​

Release documentation​

For each release, document the following:

  1. Release version, demo version, and per-client UAT and production deployment dates.
  2. Associated versions of dependent components, such as Analytics, External Proxy, and GenAI (ES Loyalty), or data science modules and UI elements (LoyaltyBoost).
  3. A deployment checklist covering secrets, Cognito apps, Lambda layers, indexes, data migrations, and infrastructure changes.
  4. Links to user-facing release notes, technical release notes, and product-focused deployment tickets.

Execution and governance​

A typical production release for a client follows these steps:

1

Pre-deployment validation

Confirm that all checklist items are addressed, including secrets, Cognito configuration, Lambda layers, indexes, migrations, and third-party integrations such as Tableau Cloud and DIG connectors.

2

Deployment

Trigger the appropriate Jenkins comprehensive deployment job with the pinned descriptor or version file.

3

Post-deployment validation

Run smoke tests on ES Console and APIs, and verify reporting and analytics pipelines.

4

Client sign-off

Confirm with the client that the release passes their validation criteria.

5

Documentation and communication

Finalize and cross-link internal and user-facing release notes. Update product pages and help links as needed.

Operational principles​

Transparency

Every deployment is tied to a specific, documented release version.

Auditability

The artifact-driven approach ensures that all changes are reviewable and repeatable.

Consistency

The same release version and configuration pattern is used across all environments, from QA through to production.

Incremental delivery

New features and enhancements are introduced incrementally, with clear documentation to support client planning and integration.

Last updated on