Commits semânticos: Melhore seus commits em 5 minutos!

Gustavo Rodrigues — Thu, 25 May 2023 17:06:10 +0000

Sério, eu DUVIDO que você nunca fez um commit assim:

git commit -m "force pipeline"

ou então:

git commit -m "dessa vez vai funcionar"

~~E as vezes eles até são necessários~~ HAHAHA ou mais rápidos para enviarmos nossa simples alteração ou então forçar uma pipeline por completo.

Alguns dos problemas dessa prática é que acabamos sujando o histórico de commits e por consequência acaba dificultando o CodeReview, manutenção de código e limita extrair métricas das changes.

Agora que sabemos o que não fazer com nossos commits, vamos ao assunto real. Você conhece a Conventional Commits? Ela é uma especificação para tornar nossos commits mais legíveis de acordo com algumas convenções que vamos ver.

Padrões de commit

De início eles sugerem que nossos commits sejam da seguinte forma:

<tipo>: descrição
ou
<tipo>(escopo opcional): descrição

Misericórdia! O que é esse tipo!?

Tipos são palavras reservadas para qual tipo de alteração você está subindo!
Exemplo:

fix: Nesse caso, estamos subindo uma correção de algum BUG existente na nossa aplicação. (Temos relação direta com o PATCH no versionamento semântico)
feat: Estamos subindo uma nova Feature para nosso sistema! (Temos relação direta com o MINOR no versionamento semântico)
docs: Commits que estão alterando alguma Documentação do nosso projeto.
test: Commits que estão alterando a camada de Testes da aplicação.
build: Commits que estão realizando modificações nos arquivos de Build e dependências do projeto.
perf: Commits que não alteram a feature mas melhoram sua performance.
style: Commits que apenas mexem na formatação de código ou removem algum código não utilizado.
refactor: Commits que apenas refatoram o código, não alterando a funcionalidade.
ci: Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

Olha quanta coisa que a gente pode fazer!

E o que é o escopo e descrição?

Basicamente, escopo é a palavra-chave do nosso commit e é opcional. Por exemplo, se eu estou corrigindo a funcionalidade de cadastro de usuários, faço da seguinte forma:

fix(users): Fix permission to create a user

Também temos Corpo e Rodapés!

Corpo do commit: priorize a descrição mais detalhada do seu commit.
Rodapé: geralmente preenchemos com número do Card do Kanban ou informações mais secundárias.

Agora vem a real parte boa! eu juro

Como quase tudo nessa vida pode ser automatizado, nós temos o plugin Commitizen, que basicamente é utilizado via Prompt e é um Helper para as especificações do Conventional Commits, com o qual você ainda pode criar suas próprias regras!

Muito legal esse assunto de Commits né!

Espero ter ajudado com este post e até a próxima!

AWS Lambda: do Zero ao Deploy [Parte 1]

Gustavo Rodrigues — Thu, 23 Mar 2023 02:19:28 +0000

Realmente nesse mundo de tecnologia nós precisamos estar constantemente nos atualizando de novas ferramentas e hoje estou aqui para tirar (ou tentar tirar) algumas duvidas que você ainda possa ter sobre AWS Lambda, bora lá? 😬

A AWS Lambda é um serviço de computação serverless, então ele permite que você execute código sem precisar se preocupar com a infraestrutura que irá executa-lo. Você simplesmente carrega seu código e a AWS executa automaticamente o código em resposta a eventos, como uma solicitação da API, uma atualização de banco de dados ou uma mensagem de fila.
Com a Lambda, você pode criar aplicativos escaláveis e altamente disponíveis sem precisar gerenciar servidores ou provisionar capacidade. É uma solução econômica e eficiente para muitos casos de uso de computação em nuvem.

Como nem tudo são flores 🌻 e nem balas de prata, precisamos balancear a nossa cabeça com vantagens e desvantagens do Lambda.

Vantagens das Lambdas na AWS

As Lambdas oferecem muitas vantagens para desenvolvedores e empresas que desejam aproveitar ao máximo a computação serverless na AWS. Algumas das vantagens mais significativas incluem:

Escala automática: As Lambdas podem escalar automaticamente para atender a demandas variáveis de tráfego (como já foi pontuado 😛).
Pagamento sob demanda: Você só paga pelo tempo que sua função é executada e pelo número de solicitações que ela processa. Isso significa que você não precisa pagar por capacidade ociosa ou antecipar a demanda futura.
Flexibilidade: As Lambdas são compatíveis com algumas linguagens de programação e podem ser integradas a vários serviços da AWS. Isso permite que você crie aplicativos altamente flexíveis e personalizados.
Fácil gerenciamento: A AWS gerencia automaticamente a infraestrutura necessária para executar suas funções. Então você não precisa se preocupar com o gerenciamento de servidores ou com a instalação e configuração de software. Aqui vale um contraponto rapido que apesar da AWS cuidar de muitos pontos sobre infraestrutura ainda temos algumas configurações a fazer1.
Tempo de resposta rápido: As Lambdas são executadas em milissegundos e podem ser configuradas para responder rapidamente a eventos em tempo real.

Desvantagens das Lambdas na AWS

Embora as Lambdas tenham muitas vantagens, elas também apresentam algumas desvantagens que os desenvolvedores precisam levar em consideração. Algumas das desvantagens mais significativas incluem:

Limitações de tempo de execução: As Lambdas têm limitações de tempo de execução que variam de acordo com a linguagem de programação utilizada. Isso pode limitar a complexidade e o tempo de execução das funções.
Limitações de tamanho do pacote: As Lambdas têm limitações no tamanho do pacote do deploy que pode ser carregado para sua execução. Isso pode limitar a complexidade e o tamanho dos aplicativos.
Cold Starts: As Lambdas têm um tempo de inicialização chamado "cold start" que ocorre quando uma função é invocada pela primeira vez ou após um período de inatividade. Esse ponto eu vou precisar detalhar melhor logo abaixo.
Dependência da AWS: As Lambdas são executadas em um ambiente gerenciado pela AWS, o que pode limitar a flexibilidade e o controle do desenvolvedor.

ColdStart nas Lambdas

O Cold Start do Lambda em cada linguagem suportada pode variar bastante. Como já mencionado, esse é o tempo que leva para a função ser inicializada (tecnicamente chamamos de trigger da Lambda) e executada pela primeira vez após um período de inatividade. É importante levar em consideração o ColdStart ao projetar e implementar suas funções Lambda para garantir a melhor experiência para o usuário final.

A tabela a seguir mostra o tempo médio de inicialização do ColdStart em cada linguagem suportada:

Linguagem	ColdStart Médio (em segundos)
Node.js	150ms - 3000ms
Python	200ms - 3000ms
Java	500ms - 5000ms
C#	500ms - 5000ms
Go	20ms - 1000ms
Ruby	200ms - 3000ms

É importante lembrar que esses valores são apenas médias e podem variar dependendo de vários fatores, como tamanho do pacote da função, quantidade de dependências, complexidade do código e recursos de hardware. Além disso, a AWS está em constante evolução e pode atualizar os tempos de inicialização de suas funções Lambda ao longo do tempo.

Mas um ponto é fato, as vezes escolher a linguagem com o melhor Cold Start (melhor = menor) pode ser crucial para a sua Lambda.

Resumindo em um tweet: a lambda é perfeita para nanos (ou até atômicos) serviços que precisamos fazer em nossas Apps, como: envio de e-mail, atualização de registros em resposta a algum evento no fluxo do negocio, ser executada a partir do upload de um arquivo, entre muitas outras aplicações.

Esse post foi bem teórico mas é uma conversa profunda que sempre precisamos ter sobre as tecnologias até mesmo para desenhar a nossa arquitetura melhor de acordo com a necessidade do produto que estamos desenvolvendo.

Na próxima parte, nós vamos desbravar como podemos realizar o deploy de uma Lambda + Python na AWS com o Terraform e também teremos a utilização da minha Stack no StackSpot.

See you later!