Tag: post mortem

Olá pessoas!

Ao longo dos anos de trabalho eu fui desenvolvendo algumas manias no meu dia-a-dia de trabalho. Eu encaro-as como boas práticas que gosto de seguir.

Abaixo a lista de algumas dessas manias. A ordem não quer dizer nada a respeito da importância de cada uma.

• Assim que é feito o deploy de algum bug-fix ou feature em produção eu apago a branch que aquela solução foi desenvolvida. Isso evita branchs desnecessárias no servidor e que, provavelmente, não serão mais utilizadas. Se, por acaso, acontecer um bug ou faltar algo para desenvolver cria uma nova branch pois, bem provavelmente, foi criado outro card para isso.

• Gosto de nomear minhas branchs com os códigos do card combinando uma breve descrição. Exemplo: BUG-404-corrige-pagina-n-encontrada.

• Gosto de salvar todos os scripts que uso para fazer determinada tarefa (pode ser atendimento a algum card ou somente querys do dia a dia. E sigo um método de organização que é: tenho um diretório de nome scripts. Dentro desse um subdiretório para cada card e dentro do diretório do card a(s) query(s) com seu nome dizendo examente o que ela faz. Exemplo:

• Essa é uma das manias que mais luto para que ela seja seguida por todos nas squads: NUNCA marrete o banco de dados, ou seja, nunca execute um insert/update/delete via script sql. Quando preciso fazer isso e não tenho um método que faça exatamente isso eu crio uma rota (caso seja API) que irá receber a requisição e utilizar o próprio código da API para corrigir. Exemplo: tenho que atualizar o id do fabricante do fone de ouvido que tenho cadastrado na tabela fones. O invés de fazer um update via sql direto no banco de dados, eu chamo a rota de update passando as informações necessárias. Caso a rota não exista eu crio uma seguindo um nome padrão: atualiza-fone-emergencia. Essa rota irá utilizar o código já existente na API para atualizar. Após executar o que preciso eu deleto a rota. Fazendo assim eu consigo fazer as alterações necessárias e seguindo as regras de negócio que já estão todas na API e que, por sua vez, irão gerar logs na aplicação. Sim, sei que irão acontecer casos que realmente seja necessário marretar o banco de dados. Nesses casos não tem muito o que fazer mas, se isso foi necessário, então temos uma falha em algum momento no projeto (arquitetura, levantamento de requisitos, codificação, teste, etc).

• Documento de deploy. Gosto dele pois consigo criar um passo-a-passo do deploy. Quais PRs devem serem mergeados primeiro, se algum SQL deve ser executado no banco de dados e em qual momento (ordem) e até uma validação (o famoso NUNCA faça teste em produção) após o deploy. A idéia é que mesmo que a pessoa responsável pela alteração não esteja presente, qualquer outra pessoa da squad consiga fazer.

• Não podia faltar o famoso POST MORTEM. Aqui o objetivo não é identificar pessoas culpadas e sim processos e/ou métodos culpados. O porque aconteceu! Como uma investigação de acidente aéreo onde vai listando os eventos, em cadeia ou não, que levaram a falha (catastrófica ou não). Esse documento deve ficar público para as pessoas envolvidas para que este problema não volte a acontecer novamente, pelo menos não pelos mesmos motivos :).

Tem mais coisas/manias. De acordo que for lembrando vou criando novos posts sobre elas.