Skip to content

Decide the approach for post-deployment smoke testing on UAT/PROD #216

Description

@tmikula-dev

Background

database/migrations/V1.4.0.2__initial_schema.ddl  includes a  public_cps_za_test  table used to write/read a "test topic" event, originally added by @oto-macenauer-absa as a PoC mechanism for basic post-deployment smoke testing (write to a test topic, read via SQS, confirm the pipeline works end-to-end). New question was raised whether this is still needed now that a DEV environment exists for testing, and flagged that it means a test-only object lives permanently inside the real UAT/PROD schema. @miroslavpojer raised that running any automated smoke test — read or write — against PROD carries real risk, especially write-based tests, which could be silently forgotten and cause harm over time.

Questions To Answer

  1. Do we still need an automated post-deployment smoke test against UAT/PROD, given DEV exists for general testing?
  2. If yes, should it be read-only, write-based, or both?
  3. Should smoke-test objects (tables/topics) be kept separate from the real production schema/queues instead of embedded alongside real data (current solution)?
  4. Should  public_cps_za_test be removed, kept as-is, or replaced with a differently scoped mechanism?

Additional Resources

• Discussion thread #214 (comment).
• Related: #201 (Flyway migrations setup)

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions