Ambiente de Staging Automatizado com Deploy por Branch
Oi! Aqui é a Sensei da GeHost 🥋 e hoje eu vou te ensinar uma das coisas que mais separa um site "amador" de um projeto profissional: ter um ambiente de staging — uma cópia de teste do seu site, separada da versão que seus clientes/visitantes veem, que atualiza sozinha sempre que você sobe uma nova versão do código numa branch específica do Git.
Antes de começar, um recado importante: os planos de hospedagem da GeHost rodam em cPanel (ambiente compartilhado gerenciado), não é acesso root de VPS "cru". Isso não te impede em nada de ter esse fluxo de staging automatizado — a gente só usa a ferramenta certa pra isso, que é o Git™ Version Control do próprio cPanel. O resultado final é o mesmo que você imaginou: cada push numa branch atualiza o ambiente sozinho.
💡 Dica da Sensei: a disponibilidade da ferramenta Git™ Version Control pode variar conforme a configuração do seu plano/servidor. Se você não encontrar essa opção no seu painel, chama o suporte da GeHost pelo painel.gehost.com.br que a equipe confirma pra você certinho.
O que você vai precisar
- Acesso ao seu cPanel (usuário e senha, os mesmos do e-mail que você recebeu na contratação).
- Um repositório Git do seu projeto (GitHub, GitLab, Bitbucket etc.) com pelo menos duas branches: uma de produção (ex.: main) e uma de staging (ex.: staging ou homolog).
- Um subdomínio livre pra hospedar a versão de testes, tipo staging.seudominio.com.br.
Passo 1 — Acesse o cPanel
Primeiro, entra no seu cPanel com seu usuário e senha.
Passo 2 — Crie o subdomínio de staging
- No painel principal do cPanel, procure a ferramenta Subdomínios (fica no grupo "Domínios").
- Crie algo como staging.seudominio.com.br, apontando pra uma pasta separada (ex.: staging), diferente da pasta public_html que é a sua produção.
- Confirme e aguarde alguns minutinhos pra propagar.
💡 Dica da Sensei: nunca use a mesma pasta da produção pro staging! São ambientes que precisam ficar bem separadinhos, senão um teste mal feito pode derrubar o site que seus visitantes estão vendo.
Passo 3 — Ative o Git™ Version Control
- Volte à tela inicial do cPanel e procure a ferramenta Git™ Version Control (normalmente no grupo "Arquivos" ou "Avançado").
- Clique em "Criar" (Create) e informe:
- A URL do seu repositório (ex.: git@github.com:seuusuario/seurepositorio.git);
- O nome da branch (aqui você usa a de staging, não a de produção);
- O caminho da pasta que você criou no Passo 2.
- Salve. O cPanel vai clonar o repositório direto naquela pasta.
Passo 4 — Automatize o deploy a cada push
É aqui que a mágica acontece! O Git™ Version Control do cPanel permite configurar um deploy hook (arquivo .cpanel.yml na raiz do repositório) que copia automaticamente os arquivos da branch pra pasta pública toda vez que você faz um pull. Combine isso com um webhook do seu provedor Git (GitHub/GitLab) apontando pra sua rotina de atualização, e cada push na branch de staging já reflete no ambiente de testes sozinho, sem você precisar subir arquivo manual.
🔧 Dica da Sensei: se o seu fluxo de CI/CD for mais robusto (testes automatizados, build de frontend, containers etc.), isso já é um cenário mais avançado. Chama o nosso suporte pelo painel.gehost.com.br pra gente avaliar junto qual é o melhor caminho pro seu projeto.
Passo 5 — Proteja o ambiente de staging
Ambiente de teste também merece SSL! Vá até a ferramenta SSL/TLS do cPanel e emita/instale um certificado pro seu subdomínio de staging, do mesmo jeito que você faz com o domínio principal.
🔒 Dica da Sensei: como o staging não é pra ser visto pelo público, também vale colocar uma senha de acesso na pasta (proteção por diretório, direto no cPanel) e um robots.txt bloqueando indexação — assim o Google não encontra sua versão de testes por engano.
Passo 6 — Confira e organize os arquivos
Depois do primeiro deploy, use o Gerenciador de Arquivos pra conferir se tudo chegou certinho na pasta de staging.
Boas práticas da Sensei 🥋
- Sempre teste na branch de staging antes de fazer o merge pra produção (main).
- Use configurações e variáveis de ambiente diferentes entre staging e produção (ex.: uma cópia separada do banco de dados, pra não bagunçar dados reais).
- Faça um backup antes de mesclar mudanças grandes na produção — o cPanel tem a ferramenta Backup prontinha pra isso.
- Revise sempre o que está sendo automatizado no .cpanel.yml — evite comandos que apaguem pastas inteiras sem necessidade.
Precisa de uma ajudinha?
Se você travar em qualquer passo, ou seu projeto precisar de um fluxo de deploy mais elaborado, fala com a gente pelo painel.gehost.com.br. A equipe da GeHost tá aqui pra te ajudar a colocar esse fluxo de pé! 🚀