Design

Goals

Run E2E integration tests

Developers should be able to run BGTMOO integration tests using lcp-compose -

• Reliably - Lcp infrastructure reliably starts up/ shuts down
• Predictably - Failed test can be reproduced across environments e.g. - local/ft
• With Agility - A developer should be able to checkout the project, integrate a service and run tests in no more than 5 commands (no rebuilding lcpbox)

Experiment with and understand the LCP stack

As a playground, developers should be able to run all services in the LCP/BGTMOO stack locally to -

• Debug code - Be able to set breakpoints and step through code
• Inspect logs, view aggregated logs and trace transactions through correlation ids
• Extend feature set - To run storefront, console or loyalty-wallet locally
• Help on-board new developers

Faster feature turn-around

• Prototype, develop and test locally
• Complete Local testing - No FT deployment required to test new features
• No FT locks or race conditions

Principles

CLI tool first, library second

lcp-compose is designed to be a CLI tool first - all features should be exposed as CLI subcommands. This refrains developers from writing code that calls lcp-compose internal APIs.

A consistent command-line interface has the following advantages:

Transparency

All functions are available through commands. No more tracing through Python code to find out what a certain API call eventually does.

Another benefit - everything is repeatable through re-running the command, as opposed to re-run a piece of Python code that calls an API.

Straightforward Integration

Only a series of commands required to setup test infrastructure, prior to running nosetests when integrating a service with lcp-compose.

Difficult to Misuse

It is hard to extend and does not expose an API. Developers cannot build abstractions over the API - which eventually leads to deep nested sleuthing to debug/ understand execution flow.

Language Agnostic

The CLI makes it possible to write harness in any language, be it Python, Java or Bash.

Configuration through Templates

lcp-compose does not store configuration files for each individual service. Each service should have a templatized version of the configuration at a predictable location so lcp-compose can grab it, templatize it and copy it to the right place where the lcp-compose managed service can pick up.

Outsource Data Seeding

lcp-compose does not and should not be responsible for seeding initial data for individual services. Individual services should provide entrypoints to seed its own testing data.