Fazendo o Deploy do site com GitHub Actions

Configurar um site com GitHub Actions para fazer o deploy automático via FTP transforma seu fluxo de trabalho: você faz o git push e o GitHub cuida do resto.

O presente howto explica como fazer o deploy do seu site com GitHub Actions via FTP, comum em hospedagem compartilhada.

Segue os procedimentos:

1. Salve suas credenciais com segurança

Nunca coloque senhas diretamente no código. No seu repositório no GitHub:

Vá em Settings > Secrets and variables > Actions.

Clique em New repository secret e adicione:

FTP_SERVER: O endereço ou nome de domínio do seu servidor.

FTP_USERNAME: Seu usuário de FTP.

FTP_PASSWORD: Sua senha de FTP.

2. Crie o arquivo de Workflow

No seu projeto local, crie a pasta .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Cole o conteúdo abaixo:

Se o site foi desenvolvido apenas com HTML, CSS e JS

No seu projeto local, crie o diretório .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Segue:

.github/workflows/main.yml

Se o site foi desenvolvido com React

Diferente de um site estático simples (HTML/CSS/JS), o navegador não entende diretamente seu código React (JSX). O GitHub Actions precisa rodar o comando de compilação para criar a pasta final com os arquivos otimizados.

No seu arquivo .github/workflows/main.yml, use esta estrutura

.github/workflows/main.yml

3. Suba as alterações

Agora basta commitar e enviar para o GitHub:

git add .

git commit -m "Configurando deploy automático"

git push origin main


Você pode acompanhar o progresso em tempo real na aba Actions do seu repositório. Se tudo estiver certo, seu site será atualizado em poucos segundos!

Pontos importantes para React:

Diretório Local (local-dir): Se você usa Vite (o padrão atual), a pasta de saída é a dist/. Se usa o antigo Create React App, é a build/.

Roteamento (SPA): Se o seu site usa react-router-dom, lembre-se de configurar um arquivo .htaccess no seu servidor para redirecionar todas as rotas para o index.html, caso contrário, você receberá erro 404 ao atualizar a página.

Variáveis de Ambiente: Se o seu React usa .env, você precisará cadastrar essas variáveis nos Secrets do GitHub e injetá-las no passo de build.

Caso criou o projeto React com Vite, precisa adicionar uma configuração.

O segredo aqui é que o GitHub Actions vai criar um "computador virtual", instalar o Node.js, baixar suas bibliotecas e transformar seu código JSX em arquivos que qualquer servidor entende.

Dica de Ouro: O arquivo .htaccess

Para sites React (Single Page Applications), se você não configurar o servidor, as rotas (ex: ://seusite.com) darão erro 404 ao atualizar a página. Crie um arquivo chamado .htaccess na sua pasta public do projeto com este conteúdo:

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]

ATENÇÃO

1. Verifique se o nome da pasta de saída no seu projeto é realmente dist (padrão do Vite) ou build.
2. Certifique-se de que as Secrets (FTP_SERVER, FTP_USERNAME, FTP_PASSWORD) foram adicionadas corretamente no GitHub.
3. Faça o git push e acompanhe a "mágica" na aba Actions.

Feito!

A maturidade do desenvolvedor que fala por si através dos commits

Em processos seletivos técnicos, avaliações de performance ou até em análises informais entre pares, um padrão recorrente chama a atenção de qualquer desenvolvedor experiente ou arquiteto de software: repositórios públicos com um único commit intitulado "first commit", acompanhados de um README.md padrão gerado automaticamente por frameworks como React, Angular, Vue.js, Laravel, Spring Boot, Quarkus, NestJS ou AdonisJS.

Esse padrão, embora comum, carrega sinais claros, não apenas sobre o projeto em si, mas sobre o nível de maturidade profissional de quem o publica. O problema não está em fazer cursos online, tampouco em utilizar boilerplates ou scaffolds. O problema está em não compreender o repositório como um artefato profissional, parte essencial do portfólio e da narrativa técnica do desenvolvedor.

No presente artigo, vamos analisar de forma argumentativa por que commits granulares, históricos evolutivos e READMEs bem escritos são indicadores concretos de senioridade, pensamento arquitetural e responsabilidade profissional.

O repositório como evidência de pensamento técnico

Um repositório Git não é apenas um local de armazenamento de código. Ele é, essencialmente:

• Um registro histórico de decisões técnicas
• Uma linha do tempo da evolução de uma solução
• Um documento vivo de arquitetura, domínio e trade-offs

Quando um projeto possui apenas um commit genérico, o que se perde não é apenas a granularidade do código, mas a capacidade de avaliação do raciocínio técnico. Um arquiteto, um Tech Lead ou um recrutador sênior não avalia apenas o que foi feito, mas como foi feito.

E o "como" está nos commits.

Commits não são burocracia: são comunicação

Existe um equívoco comum entre desenvolvedores iniciantes (e até intermediários e avançados): tratar commits como uma obrigação mecânica, algo que "precisa existir" apenas para subir o código ao repositório remoto.

Na prática, commits são mensagens de comunicação assíncrona entre:

• Desenvolvedores do time
• O "eu do futuro"
• Revisores de código
• Auditores técnicos
• Ferramentas de CI/CD
• Gestores técnicos

Um histórico saudável de commits revela:

• Implementação incremental de features
• Correções de bugs contextualizadas
• Refatorações conscientes
• Ajustes arquiteturais
• Evolução de requisitos

Um único "first commit" apaga toda essa narrativa.

Projetos de curso vs. projetos autorais

Não há absolutamente nenhum problema em publicar projetos de cursos. O problema surge quando eles são apresentados como projetos autorais sem qualquer contextualização.

Projetos de curso geralmente têm características claras:

• Commits únicos ou genéricos
• README padrão do framework
• Ausência de contexto de negócio
• Código muito similar a centenas de outros repositórios
• Falta de decisões arquiteturais explícitas

Já projetos autorais, mesmo simples, costumam apresentar:

• Commits por feature ou tarefa
• Ajustes progressivos de estrutura
• README explicativo
• Escolhas tecnológicas justificadas
• Código com identidade própria

Para um arquiteto de software, essa distinção é evidente em poucos minutos de análise.

README.md: o documento mais subestimado do projeto

O README.md é, frequentemente, o primeiro e às vezes único ponto de contato de alguém com o projeto. Ainda assim, muitos repositórios mantêm:

• README padrão do React (npm start, npm test, etc.)
• README vazio
• README genérico sem contexto

Isso é um erro estratégico.

Um bom README não serve apenas para explicar como rodar o projeto. Ele serve para responder perguntas fundamentais:

1. Qual é o objetivo do projeto?

Todo projeto nasce de um problema. Um README profissional deixa isso explícito.

Exemplo:

"Este projeto surgiu da necessidade de automatizar o controle financeiro pessoal, reduzindo erros manuais e centralizando informações de receitas, despesas e contas."

Isso demonstra pensamento orientado a problema, não apenas a tecnologia.

2. Qual problema motivou a solução?

Arquitetura começa no problema, não no framework.

Explicitar o contexto inicial demonstra:

• Capacidade de análise
• Entendimento de domínio
• Clareza de propósito
3. Quais decisões técnicas foram tomadas e por quê?

Não basta listar tecnologias. É preciso justificar.

Exemplo:

Por que React e não Angular?

Por que PostgreSQL e não MySQL?

Por que arquitetura monolítica e não microsserviços?

Essa seção diferencia um executor de código de um engenheiro de software.

4. Stack tecnológica utilizada

Aqui sim entra a lista objetiva:

• Linguagem
• Frameworks
• Banco de dados
• Ferramentas auxiliares
• Infraestrutura (quando aplicável)

Mas sempre com coerência com o problema proposto.

5. Como configurar e executar o projeto localmente

Essa é a parte que muitos confundem como sendo "todo o README".

Ela é importante, mas não suficiente.

Inclua:

• Pré-requisitos
• Variáveis de ambiente
• Scripts de execução
• Observações específicas do ambiente

Isso demonstra preocupação com reprodutibilidade, um conceito fundamental em engenharia de software.

Commits granulares refletem maturidade

Vamos ser diretos:

Desenvolvedores seniores não trabalham com um commit único por projeto.

Commits granulares indicam:

• Organização mental
• Capacidade de dividir problemas
• Disciplina técnica
• Experiência com trabalho colaborativo
• Familiaridade com revisão de código

Exemplos de bons commits:

• feature: adicionar cadastro de usuários
• fix: corrigir cálculo de saldo negativo
• refactor: separar camada de serviço
• docs: atualizar README com instruções de setup

Esses commits contam uma estória. E arquitetos avaliam estórias.

O impacto disso em processos seletivos

Em entrevistas técnicas mais maduras, o repositório Git é analisado como:

• Evidência prática de experiência
• Fonte de discussão arquitetural
• Base para perguntas profundas

Um repositório com um único commit limita drasticamente essa conversa. Já um projeto bem versionado permite perguntas como:

• "Por que você refatorou essa parte?"
• "O que motivou essa decisão?"
• "Como você lidaria com esse código em escala?"

Ou seja: abre espaço para avaliar senioridade real.

Frameworks não definem senioridade

Outro ponto crítico: usar React, NextJS, Angular, Vue.js, Laravel, Spring Boot, Quarkus, NestJS, AdonisJS não torna ninguém automaticamente sênior. Frameworks são ferramentas. O que define maturidade é:

• Capacidade de modelar domínio
• Clareza arquitetural
• Organização do código
• Evolução incremental
• Comunicação técnica (commits e README)

Manter apenas o README padrão do framework passa a mensagem de que o projeto não foi apropriado pelo desenvolvedor, apenas executado.

O repositório como produto profissional

Um arquiteto de software enxerga o repositório como um produto em si. Mesmo projetos pessoais seguem padrões profissionais porque refletem:

• Identidade técnica
• Rigor conceitual
• Postura profissional

Isso é especialmente relevante para quem:

• Busca posições sênior
• Atua como PJ
• Trabalha como consultor
• Quer se posicionar como especialista

Seu GitHub é, na prática, um cartão de visitas técnico.

Qualidade não está na quantidade de projetos

Outro erro comum é tentar compensar falta de profundidade com volume de repositórios. Dez projetos com:

• Um commit cada
• README genérico
• Código semelhante

Valem menos do que um único projeto bem documentado, versionado e contextualizado.

Arquitetura é profundidade, não superficialidade.

Considerações finais

Repositórios com apenas um "first commit" e README padrão não são, por si só, um problema técnico. Eles são um sinal. Um sinal de que o desenvolvedor ainda não internalizou que:

• Código é comunicação
• Versionamento é narrativa
• README é documentação estratégica
• Projetos contam histórias profissionais

Como Analista Desenvolvedor Sênior (Full Cycle Developer), afirmo: não é a stack que revela maturidade, é o cuidado com o todo. Commits bem feitos, README bem escrito e clareza de propósito são marcas de quem entende que software é mais do que código, é engenharia, contexto e decisão.

Se o seu repositório fala pouco, ele será interpretado como pouco.

Faça com que ele fale por você.

Feito!

Configurando o Personal Access Token (PAT) no Azure DevOps e GitHub

Quando você trabalha com integrações seguras entre pipelines, repositórios e automações, é comum precisar autenticar via Personal Access Token (PAT), uma chave de acesso pessoal que substitui a senha de login, garantindo mais segurança e controle sobre as permissões.

No presente artigo, você vai aprender como gerar, converter e configurar um PAT no Azure DevOps e também como usar o mesmo conceito no GitHub.

Gerando o Personal Access Token (PAT) no Azure DevOps

1. Acesse o portal do Azure DevOps https://azure.microsoft.com
2. Faça login com sua conta.
3. No canto superior direito, clique na sua foto de perfil e selecione Security (ou “Segurança”).
4. No menu lateral, escolha Personal Access Tokens.
5. Clique em New Token.
6. Dê um nome para identificar o token (ex: Token-Pipeline ou Token-Pessoal
7. Defina a data de expiração — prefira um período longo (como 1 ano) se for um uso contínuo.
8. Selecione os escopos (permissões) necessários, como:

Code (Read & Write) para acesso a repositórios;

Build (Read & Execute) para pipelines;

Packaging (Read) para artefatos.

9. Clique em Create.

Importante: copie o token gerado imediatamente, ele será exibido apenas uma vez.

Convertendo o PAT em Base64

Após gerar o token, será necessário convertê-lo para o formato Base64, que é o padrão usado em autenticação HTTP Basic.

Você precisará do seu login (e-mail ou nome de usuário) e do PAT gerado.

No PowerShell:

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("LOGIN:PAT"))

Ou no Git Bash:

echo -n "LOGIN:PAT" | base64

Substituir o LOGIN e PAT, pelo seu login e token gerado, respectivamente.

Configurando o PAT no arquivo .gitconfig

Após obter o resultado em Base64, você pode configurar seu Git local para utilizar o token automaticamente nas conexões com o Azure DevOps.

Abra o arquivo de configuração global do Git: ~/.gitconfig

Adicione a seguinte linha dentro da seção [http]:

[http "https://dev.azure.com/"] extraHeader = Authorization: Basic PAT_BASE64

Substitua PAT_BASE64 pelo valor obtido na conversão em Base64.

E no GitHub?

O GitHub também utiliza Personal Access Tokens como método de autenticação em vez de senhas.

O processo é semelhante:

1. Acesse https://github.com/settings/tokens
2. Clique em Generate new token
3. Escolha o escopo (geralmente repo e workflow são os mais usados).
4. Copie o token gerado.
5. Converta-o da mesma forma:
echo -n "LOGIN:PAT" | base64
6. Adicione ao .gitconfig (substituindo o domínio pelo do GitHub):
[http "https://github.com/"] extraHeader = Authorization: Basic PAT_BASE64

Considerações finais

O uso do Personal Access Token (PAT) é uma prática recomendada para garantir segurança e controle de acesso em ambientes de integração contínua e repositórios Git.

Com ele, você:

Evita expor senhas reais;

Controla permissões específicas;

Automatiza autenticações em pipelines e scripts;

Pode revogar acessos rapidamente se necessário.

Manter o PAT seguro e criptografado é fundamental, trate-o como uma senha sensível e nunca o compartilhe em código público.

Feito!

Gerando um par de chaves pública e privada e adicionando à conta do GitHub

Na era digital, a segurança é uma prioridade fundamental, especialmente ao lidar com dados sensíveis e comunicações online. Uma maneira de garantir a segurança em suas interações online é por meio do uso de criptografia de chaves públicas e privadas. Neste artigo, vamos explorar como gerar um par de chaves e adicionar à sua conta do GitHub, fortalecendo a segurança de suas operações na plataforma.

O que são chaves pública e privada?

As chaves pública e privada formam a base da criptografia de chave assimétrica. Elas são usadas para criptografar e descriptografar dados, assinar e verificar assinaturas digitais e autenticar identidades online de forma segura.

Chave Pública: É compartilhada abertamente e usada para criptografar dados ou verificar assinaturas digitais. Qualquer pessoa pode criptografar mensagens usando a chave pública, mas apenas a chave privada correspondente pode descriptografar essas mensagens.

Chave Privada: Deve ser mantida em segredo. É usada para descriptografar mensagens criptografadas com a chave pública correspondente ou para assinar digitalmente documentos. É crucial proteger a chave privada para garantir a segurança das comunicações.

Gerando um par de chaves

Para gerar um par de chaves, você pode usar o algoritmo de criptografia RSA (Rivest-Shamir-Adleman) com a ajuda do utilitário ssh-keygen, amplamente disponível em sistemas Unix-like, como Linux e macOS, bem como no Windows por meio do Git Bash.

Abra o terminal ou Git Bash: Dependendo do sistema operacional que você está usando, abra o terminal ou Git Bash.

Execute o comando ssh-keygen: Este comando irá guiar você através do processo de geração das chaves. Por padrão, ele criará um par de chaves RSA com 2048 bits de comprimento.

ssh-keygen -t rsa -b 2048 -C "seuemail@dominio.com"

Substitua "seuemail@dominio.com" pelo seu endereço de e-mail associado à sua conta do GitHub.

Escolha um local para salvar as chaves: O ssh-keygen perguntará onde você deseja salvar o par de chaves. Você pode optar por salvar no local padrão ou escolher um diretório específico.

Defina uma senha (opcional): Você pode adicionar uma senha para proteger sua chave privada. Isso fornecerá uma camada adicional de segurança.

Adicionando a chave pública ao GitHub

Agora que você gerou o par de chaves, é hora de adicionar a chave pública à sua conta do GitHub para autenticar suas operações.

Copie a chave pública: Use um editor de texto ou comando cat para exibir o conteúdo da sua chave pública.

cat ~/.ssh/id_rsa.pub

Copie todo o conteúdo exibido no terminal.

Acesse as configurações do GitHub: Faça login na sua conta do GitHub e acesse as configurações do perfil.

Navegue até as configurações de SSH e GPG keys: No menu lateral esquerdo, clique em "SSH and GPG keys".

Adicione uma nova chave SSH: Clique em "New SSH key" (Nova chave SSH).

Cole a chave pública: Cole o conteúdo da sua chave pública no campo apropriado.

Dê um nome à chave: Dê um nome descritivo à chave para identificá-la mais tarde, caso você tenha várias chaves.

Adicionar chave: Clique em "Add SSH key" (Adicionar chave SSH) para salvar a chave.

Considerações finais:

Gerar e adicionar um par de chaves pública e privada à sua conta do GitHub é uma prática recomendada para aumentar a segurança das suas interações na plataforma. Essas chaves são usadas para autenticar operações remotas, como push e pull de repositórios, sem a necessidade de inserir suas credenciais de usuário e senha a cada interação. Além disso, a criptografia de chave pública e privada oferece uma camada adicional de segurança, garantindo que suas comunicações online sejam protegidas contra acesso não autorizado.

Ao seguir os passos descritos neste artigo, você estará fortalecendo a segurança da sua conta do GitHub e das suas atividades de desenvolvimento colaborativo. Nunca subestime a importância da segurança cibernética em um mundo cada vez mais conectado e digitalizado.

Feito!