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

Aberta
  • Algo errado?
#216 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
25/100
Tipo de issue
Documentação
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Stack de tecnologia
aws, postgresql
Domínio
databases, devops, testing-qa

Direção de pesquisa

Comece lendo database/migrations/V1.4.0.2__initial_schema.ddl e pesquisando no repositório referências a public_cps_za_test para localizar todos os caminhos de leitura/escrita. Em seguida, revise a discussão da PR vinculada (#214) e a issue relacionada #201 para confirmar as premissas atuais sobre migração, UAT/PROD e deployment. A issue não lista testes específicos, portanto a validação consiste principalmente em uma revisão de design/documentação; considera-se concluído quando houver uma decisão documentada e qualquer alteração de migração/configuração necessária para remover, substituir ou isolar o mecanismo de smoke test.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

question
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 https://github.com/AbsaOSS/EventGate/pull/214#discussion_r3813778453.
• Related: #201 (Flyway migrations setup)

Linguagem predominante
Python
Estrelas
4
Forks
0
Merge médio
3d 12h
PRs com merge (30d)
10

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de AbsaOSS/EventGate

Todas as issues de AbsaOSS/EventGate

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.