DEV Community: Anthony Vinicius

Be a better developer with these Git good practices

Anthony Vinicius — Fri, 16 Feb 2024 20:44:23 +0000

If you're a developer, you probably use the versioning system called Git on a daily basis. The use of this tool is crucial for the development process of an application, whether working in a team or individually. However, it's common to encounter messy repositories, commits with unclear messages that don't convey useful information, and misuse of branches, among other issues. Knowing how to use Git correctly and following good practices is essential for those who want to excel in the job market.

Naming Conventions for Git Branches
Branch Names Convention Prefixes
Commit Message
Conventional Commit's

Naming Conventions for Git Branches

When we're working with code versioning, one of the main good practices that we should follow is using clear and descriptive names for branches, commits, pull requests, etc. Ensuring a concise workflow for all team members is essential. In addition to gaining productivity, documenting the development process of the project historically simplifies teamwork. By following these practices, you'll see benefits soon.

Based on it, the community created a branch naming convention that you can follow in your project. The use of the following items below is optional, but they can help improve your development skills.

1. Lowercase: Don't use uppercase letters in the branch name, stick to lowercase;

2. Hyphen separated: If your branch name consists of more than one word, separate them with a hyphen. following the kebab-case convention. Avoid PascalCase, camelCase, or snake_case;

3. (a-z, 0-9): Use only alphanumeric characters and hyphens in your branch name. Avoid any non-alphanumeric character;

4. Please, don't use continuous hyphens (--). This practice can be confusing. For example, if you have branch types (such as a feature, bugfix, hotfix, etc.), use a slash (/) instead;

5. Avoid ending your branch name with a hyphen. It does not make sense because a hyphen separates words, and there's no word to separate at the end;

6. This practice is the most important: Use descriptive, concise, and clear names that explain what was done on the branch;

Wrong branch names

fixSidebar
feature-new-sidebar-
FeatureNewSidebar
feat_add_sidebar

Good branch names

feature/new-sidebar
add-new-sidebar
hotfix/interval-query-param-on-get-historical-data

Branch Names Convention Prefixes

Sometimes the purpose of a branch isn't clear. It could be a new feature, a bug fix, documentation updates, or anything else. To address this, it's a common practice to use a prefix on the branch name to quickly explain the purpose of the branch.

feature: It conveys a new feature that will be developed. For example, feature/add-filters;
release: Used to prepare a new release. The prefix release/ is commonly used to do tasks such as last touched and revisions before merging the new updates from the branch master to create a release. For example, release/v3.3.1-beta;
bugfix: It conveys that you're solving a bug in the code and it's usually related to an issue. For instance, bugfix/sign-in-flow;
hotfix: Similar to bugfix, but it is related to fixing a critical bug present in the production environment. For example, hotfix/cors-error;
docs: To write some documentation. For example, docs/quick-start;

If you're working in a workflow with task management, like Jira, Trello, ClickUp, or any similar tool that can create User Stories, each card has a number associated. So, is commonly use these card numbers on the prefix of branch names. For example:

feature/T-531-add-sidebar
docs/T-789-update-readme
hotfix/T-142-security-path

Commit Message

Let's go talk about commit messages. Unfortunately, is so easy to find projects with commit messages like "added a lot of things" or "Pikachu, I choose you"... Yeah, I once found a project where the commit messages were related to a Pokémon fight.

Commit messages are really important in the development process. Creating a good history will help you a lot of times in your journey. Like branches, commits also have conventions created by the community, which you can learn about below:

A commit message has three important sections: Subject, Description, and Footer. The subject of a commit is required and defines the purpose of a commit. The description (body) is used to provide additional context and explanation for the commit's purpose. Lastly, there's the footer, commonly used for metadata like assigning a commit. While utilizing both the description and footer is considered a good practice, it's not required.
Use the imperative mood in the subject line. For example:

Add README.md ✅;
Added README.md ❌;
Adding README.md ❌;

Capitalize the first letter of the subject line. For example:

Add user authentication ✅;
add user authentication ❌;

Don't end the subject line with a period. For example:

Update unit tests ✅;
Update unit tests. ❌;

Limit the subject line to 50 characters, i.e., be clear and concise;
Wrap the body at 72 characters and separate the subject from a blank line;
If your body of commit has more than one paragraph, so use blank lines to separate them;
If necessary, use bullet points instead of only paragraphs;

Conventional Commit's

"The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history."

The quote below was obtained from the Conventional Commit's official website. This specification is the most used convention to commit messages in the community.

Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Type

The first structure that we have to study is the commit type. It provides a clear context about what's done in this commit. Below you can see the list of commit types and when to use them:

feat: Introductions of new functionalities;
fix: Rectifications of software bugs;
refactor: Employed for code alterations preserving its overall functionality;
chore: Updates not impacting production code, involving tool, config, or library adjustments;
docs: Additions or modifications to documentation files;
perf: Code changes enhancing performance;
style: Adjustments related to code presentation, like formatting and whitespace;
test: Inclusion or correction of tests;
build: Modifications affecting the build system or external dependencies;
ci: Alterations to CI configuration files and scripts;
env: Describes adjustments or additions to configuration files within CI processes, such as container configuration parameters.

Scope

A scope is a structure that can be added after the commit's type to provide additional contextual information:

fix(ui): resolve issue with button alignment
feat(auth): implement user authentication

Body

The body of a commit message provides detailed explanations about the changes introduced by the commit. It's typically added after a blank line following the subject line.

Example:

Add new functionality to handle user authentication.

This commit introduces a new module to manage user authentication. It includes
functions for user login, registration, and password recovery.

Footer

The footer of a commit message is used to provide additional information related to the commit. This can include details such as who reviewed or approved the changes.

Example:

Signed-off-by: John <john.doe@example.com>
Reviewed-by: Anthony <anthony@example.com>

Breaking Change

Indicate that the commit includes significant changes that may lead to compatibility issues or require modifications in dependent code. You can add a BREAKING CHANGE in the footer or include ! after the type/scope.

Examples of commits using conventional commits

chore: add commitlint and husky
chore(eslint): enforce the use of double quotes in JSX
refactor: type refactoring
feat: add axios and data handling
feat(page/home): create next routing
chore!: drop support for Node 18

With subject, body and footer:

feat: add function to convert colors in hexadecimal to rgba

Lorem Ipsum is simply dummy text of the printing and typesetting industry.

Lorem Ipsum has been the industry's standard dummy text ever since the 1500s.

Reviewed-by: 2
Refs: #345

References

[PT-BR] Tudo que você, desenvolvedor, precisa saber sobre Pods no Kubernetes

Anthony Vinicius — Thu, 01 Feb 2024 15:00:49 +0000

Imagem do banner obtida no Pixabay, autor lucasbieri.

Se destacar no mercado de trabalho depende de muitas variáveis e diferentes decisões ao longo da jornada profissional. Atualmente, no momento da escrita deste conteúdo, uma tecnologia vem se destacando forte no mercado e caso você, desenvolvedor, não saiba utilizá-la, com certeza ficará para trás.

O Kubernetes é uma plataforma open-source voltada para a orquestração de containers (e caso você não sabe o que é um container, e lembrando que container não é Docker, recomendo você deixar esta aba aberta e ir dar uma estudada rápida sobre containers antes de iniciar essa leitura) que automatiza o processo implantação, dimensionamento e operação dos aplicativos nos containers.

Este conteúdo faz parte de uma série de artigos onde é abordado todos os principais recursos do Kubernetes aos quais você deverá conhecer. E para começar essa série com o pé direito, seria impossível não começar com ele, a menor unidade do Kubernetes. Venha comigo aprender sobre os Pods.

O Pod, como mencionado anteriormente, representa a menor unidade de implantação no ecossistema do Kubernetes. Ele desempenha um papel crucial ao servir como um ambiente isolado que abriga um ou mais containers. É fundamental entender que o Kubernetes gerencia as aplicações em unidades chamadas Pods, e é dentro desses objetos do Kubernetes que os containers realmente operam.

Cada Pod possui seus próprios recursos dedicados, que incluem um endereço IP exclusivo, alocação de memória, capacidade de CPU e outros recursos essenciais. Esses recursos são alocados de forma independente para cada Pod, garantindo assim o isolamento e a autonomia das aplicações em execução.

Para aqueles que já possuem familiaridade com o conceito de containers, a transição para o entendimento dos Pods será bastante natural. No entanto, é crucial não confundir um Pod com um container individual, uma vez que os Pods podem conter um ou mais containers em seu interior. Vale ressaltar que, quando um Pod abriga mais de um container, esses containers operam em estreita colaboração, compartilhando os recursos alocados pelo Pod. Isso significa que eles compartilham o mesmo endereço IP, CPU e memória, tornando essencial a coordenação entre os containers dentro do mesmo Pod para garantir o funcionamento harmonioso da aplicação como um todo. Essa prática pode até parecer inicialmente um pouco estranha, porém é algo muito comum de ser feita.

O ciclo de vida de um Pod possui exatos 7 fases que podem ser encontradas abaixo:

Pending: O Pod é criado, porém os containers internos a ele ainda não foram inicializados ou agendados para execução em um nó;
ContainerCreating: Os containers estão sendo inicializados dentro do Pod;
Running: O Pod está ativo, sem problemas, e processando as solicitações recebidas;
Terminated: Todos os containers presentes dentro de um Pod foram encerrados ou o Pod sofreu uma falha;
Succeeded: Fase posterior à Terminated, onde todos os containers dentro de um Pod foram concluídos com êxito;
Failed: Pelo menos um container presente no Pod falhou;
Unknown: O estado de vida do Pod não pôde ser identificado, ou seja, algo na comunicação com o nó sofreu falhas ou há problemas no cluster.

Agora que você tem uma noção sobre o que é um Pod e qual a função dele nesse ecossistema Kubernetes, vamos ao que você provavelmente entrou aqui procurando: "Como eu gerencio um Pod no Kubernetes?".

Gerenciando um Pod no Kubernetes

A primeira coisa que você deve ter instalado em sua máquina é a interface do kubectl. Com ela, é possível gerenciar tudo relacionado ao seu Kubernetes pelo terminal de forma simples. Caso você não a tenha, deixo abaixo um link para a documentação de como realizar essa instalação. O processo é bem simples e intuitivo!

Link para instalação do kubectl

Com ela instalada, se conecte ao seu ambiente de produção caso seja seu caso, ou caso queira criar um ambiente para estudos, recomendo a utilização do Minikube. Essa ferramenta permite a criação de um ambiente Kubernetes local onde você poderá testar e estudar todos os comandos. Deixo abaixo o link para instalação da mesma na sua máquina.

Link para instalação do Minikube

Antes de iniciarmos o aprendizado sobre gerenciamento de Pods, deixa eu te passar alguns comandos essenciais para te ajudar no processo de entendimento do Kubernetes.

Obter informações sobre o Cluster Kubernetes ao qual você está utilizando:

kubectl cluster-info

Obter todos os contextos configurados no kubeconfig:

kubectl config get-contexts

Contextos são os ambientes configurados aos quais a interface do kubectl pode gerenciar. Imagine que você trabalhe para uma empresa que possui um ambiente Kubernetes e queira, em casa, ter além da conexão com o ambiente da empresa, ter também um ambiente local com Minikube para estudar Kubernetes. Os contextos separam esses dois ambientes e você pode utilizá-los de forma única, a partir da seleção de um contexto que pode ser feito utilizando o comando abaixo:

kubectl config use-context CONTEXT_NAME

Obter o contexto atual em execução:

kubectl config current-context

Agora que você já tem uma base legal sobre Pods e inicialização do seu ambiente Kubernetes, vamos iniciar o estudo de gerenciamento dos Pods.

Caso você queira visualizar os Pods presentes no seu cluster Kubernetes, utilize:

kubectl get pods

Esse comando retorna todos os Pods presentes no namespace atual ao qual você está trabalhando. Caso queira especificar um namespace, basta utilizar a flag -n seguida do nome do namespace conforme abaixo:

kubectl get pods -n NAMESPACE_NAME

Caso queira visualizar todos os Pods presentes em todos os namespaces, basta utilizar da flag -A ou --all-namespaces conforme apresentado abaixo:

kubectl get pods -A

kubectl get pods --all-namespaces

Para visualizar um Pod específico, utilizamos:

kubectl get pods -n NAMESPACE_NAME POD_NAME

Ainda temos uma outra opção bem legal. Você deve ter percebido que, ao utilizar algum dos comandos acima, o resultado é uma tabela com as colunas Namespace, Name, Ready, Status, Restarts e Age. Porém, ainda é possível visualizar informações super importantes como o IP do Pod e o Node em que aquele Pod está sendo executado. Para isso, utilize da flag -o seguida do valor wide conforme apresentado abaixo:

kubectl get pods -o wide

Legal né? Agora vamos adentrar mais ainda no gerenciamento. Existem diversos momentos em que é necessário visualizar informações mais específicas de um Pod em execução. Para isso, utilize abaixo:

kubectl describe pods NOME_POD

Esse comando acima retornará diversas informações do Pod especificado, como endereço IP, configurações do mesmo e muitas outras. Continuando, uma outra prática interessante é visualizar o manifesto daquele Pod, ou seja, o arquivo .yaml (ou JSON) que define as configurações e parâmetros do mesmo. Para realizar isso é bem simples:

kubectl get pods POD_NAME -o yaml

Uma prática muito comum na criação dos Pods é atribuir a eles Labels. Para buscar os Pods de uma label específica é muito simples. Basta utilizar da flag -L seguida do nome da label.

kubectl get pods -L LABEL_NAME

Agora vamos para outra operação além de visualizar. Para você deletar um Pod existente, utilize do comando abaixo:

kubectl delete pods POD_NAME

E para criar um Pod, como eu faço? Para essa operação, existem algumas formas de realizá-la. Vamos passo a passo listando elas.

A primeira, e mais simples talvez, é utilizar diretamente uma imagem e as configurações default para um Pod. Para isso, basta executar o comando abaixo:

kubectl run POD_NAME --image IMAGE_NAME -n NAMESPACE_NAME

Algumas imagens pedem flags específicas, como por exemplo, um webserver como o NGINX solicita como flag a porta ao qual o Pod utilizará. Para criar um NGINX por exemplo, você pode fazer da seguinte forma:

kubectl run POD_NAME --image nginx --port 80 -n NAMESPACE_NAME

OBS.: Sempre busque a forma de criação para a imagem ao qual você deseja utilizar.

A segunda forma de criação, e a mais utilizada pelo mercado, é através de um manifesto, ou seja, um arquivo .yaml (ou JSON) que define as configurações do Pod que será criado. Veja um exemplo simples abaixo:

apiVersion: v1
kind: Pod
metadata:
  name: pod-nginx
spec:
  containers:
  - name: cont-nginx
    image: nginx
    ports:
      - containerPort: 80

Analisando o manifesto acima, temos:

apiVersion: Versão da API do Kubernetes;
kind: Tipo do objeto Kubernetes, nesse caso, Pod;
metadata: Dados do Pod que será criado, como o name, labels, etc.
spec: Configurações do Pod que será criado, como por exemplo, os dados do(s) container(s) em execução dentro do Pod.

Ainda existem diversas outras definições que podem ser inseridas dentro deste manifesto. Irei deixar abaixo um link para a documentação do Kubernetes onde você pode encontrá-las. Porém saiba que criar Pods desta forma que estamos informando não é comum, para ser sincero é legal saber como funciona mas você nem vai utilizar dessa maneira no seu dia a dia. A criação dos Pods utilizam de outros objetos do Kubernetes que vão deixar todo o processo mais inteligente, como os ReplicaSets e os Deployments que serão explicados em outros artigos dessa série.

Link para a documentação dos Pods

Continuando, "eu criei um arquivo .yaml, mas como crio o Pod necessariamente com isso?". Simples, basta executar o comando abaixo:

kubectl apply -f FILE_NAME.yaml

Esse comando aplica as configurações do manifesto definido no Cluster Kubernetes. Para visualizar seu Pod em execução, você pode usar algum dos comandos que listam os Pods citados acima ou pode usar o comando abaixo:

kubectl get all

Esse comando vai retornar todos os objetos presentes no ambiente Kubernetes, como os Pods, Deployments, etc.
Assim como no Docker, utilizando Kubernetes você também pode criar um container e interagir com ele acessando-o. Para isso, utilize da flag -ti para acessar o modo interativo.

kubectl run -ti POD_NAME --image NOME_IMAGE

Um exemplo para você testar é usar a imagem alpine e acessar seu bash:

kubectl run -ti POD_NAME --image alpine

Porém, você não vai em diversos momentos criar um Pod e acessar um container dele na mesma hora. Os comandos acima fazem isso (criam e acessam). Você pode, quando quiser, acessar um container que já está em execução. Para isso, basta utilizar do comando abaixo para "atachar" em um container dentro de um Pod:

kubectl attach POD_NAME -c CONTAINER_NAME -ti

Aqui nós temos um ponto super importante para comentar. O comando attach se conecta ao processo principal do container. Em containers que utilizam imagens que não são destinadas a servir como um ambiente de linha de comando, a conexão ocorre conforme o esperado. No entanto, em containers que são executados como daemons, ou seja, em que o processo principal do container não é um ambiente de linha de comando (como o shell bash), mas sim um serviço em segundo plano, como é o caso do NGINX, a conexão se comporta de maneira "anômala" porque não há um shell bash disponível nesse contexto. Nestes casos, recorremos para outro comando, o exec. Com ele é possível realizar a execução de comandos dentro do container. Nos exemplos abaixo, podemos utilizar o exec para acessar o shell bash de um container NGINX ou visualizar o conteúdo da página HTML respectivamente, em vez de nos conectarmos diretamente ao processo principal.

kubectl exec -ti CONTAINER_NAME -- bash

kubectl exec -ti CONTAINER_NAME -- cat /usr/share/nginx/html/index.html

As coisas estão ficando legais em! Mas calma que ainda temos muito conteúdo pela frente!

Continuando, vamos falar agora sobre uma flag com um comportamento que inicialmente pode causar estranheza, mas que depois você entenderá um de seus usos. A flag dry-run=client simula a execução de algo, ou seja, ela mostra o resultado da execução porém não faz a execução do comando em si. Estranho né? Mas vamos pensar no seguinte contexto. Imagina que você quer criar um manifesto de um Pod a partir de uma imagem e não sabe por onde começar. Seria muito legal ter um escopo base, porém como ter esse escopo sem ter que criar um Pod e visualizar seu manifesto? Simples, utilizando a flag dry-run=client você vai simular a criação do container e assim, visualizar seu manifesto sem tê-lo criado.

kubectl run POD_NAME --image IMAGE_NAME --dry-run=client -o yaml

Caso queira salvar o manifesto em algum arquivo, basta executar o comando no formato abaixo:

kubectl run POD_NAME --image IMAGE_NAME --dry-run=client -o yaml > manifesto.yaml

Perceba que o comando acima gera um arquivo .yaml no final. Caso o manifesto que você queira salvar seja em JSON, altere o comando para criar um arquivo JSON no final.

Bom, chegamos ao fim do nosso estudo sobre Pods. Será abordado em breve os outros objetos do Kubernetes que você deve conhecer e estudar sobre. Esse formato de artigo é pensado para passar de forma mais rápida e direta o que todo desenvolvedor precisa conhecer. Caso queira se especializar nos Pods do Kubernetes, recomendo uma leitura mais minuciosa em toda a parte teórica presente na documentação do mesmo ao qual deixo o link abaixo:

Documentação sobre os Pods do Kubernetes

Espero que tenha gostado e até a próxima!