E falando de boas práticas, a gente pode citar aqui a questão do changelog, existe um padrãozinho para a gente fazer a geração dos changelogs, a gente utilize uma convenção de commits, então existe um padrãozinho também, e a parte de versionamento, é interessante que a gente siga o versionamento semântico, que já é um padrão amplamente adotado no mercado. Bom, vamos explorar um pouquinho mais sobre cada um desses temas. Então, se a gente ver aqui a questão do change log, é possível a gente notar aqui uma versão unreleased, no caso. Pegando aqui a última versão, a gente tem o padrãozinho de versão semântica, onde a gente tem o valor principal aqui como Major, o valor intermediário como Minor e o último valor como Patch. A gente tem a release date dessa versão 1.1 e o padrãozinho de changelog aqui, onde a gente cita todas as adições que a gente teve dentro desse código, quais foram as correções, o que foi alterado, o que foi removido e uma parada bem legal que a gente consegue utilizar, é justamente aqui a questão do Semantic Version, do Conventional Commits, perdão. Então, a gente consegue utilizar aqui, através das mensagens do commit que a gente faz dentro da nossa pipeline, dentro do nosso código, fazer o controle de versionamento que a gente deseja. Então se a gente está subindo algum tipo de fix, a gente pode passar um prefixo, fix dois pontos e a mensagem que a gente quer, que automaticamente vai ser gerado, incrementado ali um valor de patch dentro da nossa versão. Caso a gente queira gerar uma minor version, a gente pode utilizar o padrãozinho de fit dois pontos, e a gente também tem aqui a possibilidade de utilizar breaking change para a gente conseguir gerar versões do tipo major. E por final, a gente também tem aqui a questão do SDLC então a gente já comentou bastante sobre isso nas últimas aulas mas pode ser que vocês escutem o termo shift left shift right então quando a gente fala de shift left a gente está basicamente falando mais da parte de desenvolvimento, shift right mais da parte de operação. E existem algumas boas práticas quando a gente fala de shift left. Então, a gente está falando basicamente de utilizar linters, de rodar toda a nossa parte de teste, sejam eles testes unitários, testes integrados, toda a parte de qualidade de software, se a gente estiver falando de alguma pipeline de infraestrutura, a gente também tem algumas validações, rodar alguns dry runs do client-side, server-side, fazer validação de esquema. Então, o que vocês precisam ter em mente, principalmente, é que falando de boas práticas do mundo de SRE, DevOps, quanto mais validações a gente tiver em tempo de shift left, significa que a gente tem aí um ambiente mais próximo do que a gente entende que seria o ideal, então se a gente consegue pegar qualquer tipo de problema em tempo de shift left a gente acaba tendo uma economia de esforço, porque a gente não sobe essa funcionalidade para a produção e pensando em grandes organizações isso também é muito importante porque se a gente for parar para pensar a gente tem diversos guard-reios diversas diretrizes que a gente precisa seguir para deixar um código produtivo e muitas vezes essa mensagem, essas informações, elas não chegam para todos os desenvolvedores. Se tiver um funcionário novo, por exemplo, é quase impossível que ele tenha consciência de todas as validações, de todo o compliance que ele precisa seguir. Então, se a gente conseguir ter toda essa validação já do lado do shift left, a gente tem uma baita economia, né? Não sobe um código ali pra, não faz o deployment, né? Desse código e muitas vezes a gente vai ter algum guard-rail que depois o cara vai ser notificado, vai ter uma remediação. Então, importante ter isso em mente. Sempre que possível, a gente deixar o máximo de validações possíveis em tempo de shift left.