Essa apresentação mostra como fazemos os microserviços na Convenia, aspectos de arquiterura e comunicação entre microservoços, bem como métodos de teste e fluxo de code review.

1. BPO Under The Hood

3. Reage a eventos
(Event Driven)

4. A forma mais clássica de alimentar um
sistema é através de um backoffice,
nesse tipo de aplicação o esforço do
desenvolvedor fica canalizado em
formulários e listagens (CRUD).
O BPO em contrapartida se alimenta
dos eventos que acontecem no
ecossistema (core e colab), nesse caso
o esforço do desenvolvedor fica
canalizado no desenvolvimento dos
listeners para esses eventos.
Event Driver

5. Formulários e listagens são testados
de forma desajeitada, através de
testes end to end, apesar da facilidade
que temos com pacotes como o Dusk o
desenvolvimento de um Listener é
bem mais simples.
Um listener pode ser testado mais
isoladamente (teste unitário) e contém
apenas código php que é mais fácil de
testar se compararmos isso com um
blade, ainda mais se contando com os
incríveis métodos de testes do Pigeon.
Vantagens

7. Exige um setup mais complicado com
algum tipo de gerenciamento de
processo, como Systemd ou
Supervisor.
Não temos meios eficientes de fazer
testes entre sistemas e garantir
contratos, isso é uma limitação que
enfrentamos em praticamente todas
as linguagens :(
Desvantagens

8. Async

9. Em uma abordagem event driven é
impossível garantir a ordem das
mensagens, nem tudo acontece da
forma como deveria acontecer e isso
traz uma série de dificuldades.
Essa é uma dificuldade conhecida em
arquitetura orientada a
serviços/microserviços, e existem
várias formas lidar com isso, cada
serviço pode lidar com isso de maneira
diferente.
Async

11. Desenvolvendo

12. Testes

13. Code Coverage

14. 22
2
Cobertura de código é uma métrica
bem interessante para tentarmos
mensurar a qualidade da nossa suite
de testes.
Sempre que um teste passar faça o
exercício de comentar a linha do
código de produção para ver ele
falhando, isso vai evitar que você
colha um falso positivo
A cobertura do BPO é de 98.90, e
raramente ocorrem bugs em produção.
Code
Coverage

15. Cut Of Tests

16. 22
2
As vezes é necessário replicar o
mesmo cenário de testes várias vezes
para conseguir cobrir com eficiência
subchamadas de métodos.
O phpunit nos permite mockar esses
métodos e testá-los separadamente
em outra classe de testes.
Ao fazer isso tenha em mente que
você vai trocar um pouco de
consistência por higiene na suite de
testes, você escolhe... fodase...
Cut Of Tests

20. Cardinalidade entre teste
e código

21. Para os testes unitários é interessante
que a estrutura de pastas da suite de
testes seja um espelho do código de
produção.
Seria legal se a classe de teste tivesse
a capacidade de cobrir apenas e
completamente sua classe
correspondente de produção.
Isso já não é verdade para um teste de
feature, onde a classe de teste leva o
nome da feature testada e
provavelmente a feature envolverá
várias classes.
Cardinalidade

23. O que devo testar?

24. 22
2
Se o código está sobre sua
governança, seria legal testa-lo.
Se o código sobre sua governança está
muito foda de testar ou você está cm
preguiça, esse código deve aparecer
como não coberto.
O que
Testar?

25. Infection

26. 22
2
O infection é um pacote bem
interessante para verificar a eficiência
da sua suite de testes, ele um pacote
de testes de mutação.
Basicamente o que ele faz é inserir
varias zueirinhas no seu código e ver
se a suite pega, ele mede a eficiência
por um índice chamado MSI(Mutation
Score Indicator)
Infection

29. Logs

30. Uma das dificuldades de lidar com
eventos é a observabilidade, isso
geralmente vem atrelado a
ferramentas como Newrelic e
Dynatrace mas uma estratégia de log
eficiente também pode ajudar na
observabilidade.
No BPO temos uma série de exceções
de domínio, o tratamento da exceção
sempre envolve um log.
Logar mesmo quando o dado é
processado com sucesso tem se
mostrado algo importante, atualmente
estamos sofrendo com isso uma vez
que não temos como garantir que tudo
ocorreu bem através dos logs.
Logs

31. Code Review

32. 3
Fluxo
Testar feature manualmente
Verificar mensagens caindo no ladrão
Verificar auditoria(mensagens caindo
no audit)
Verificar se os logs estão sendo
escritos(no datadog em staging)
Inspecionar o código
Garantir cobertura do novo código
Verificar se o changelog está
atualizado com o novo código

33. Construa um roteiro de
testes

35. Construa um roteiro de
deploy

37. Dificuldades

38. 3
Dificuldades
Listeners duplicados
Autenticação do BPO
Notificações
Dificuldade com prazo da
feature(principalmente quando
envolve o core)

39. Bora Almoçar!!!