Implementação de implantações com tempo de inatividade zero na Cloudways

Principais conclusões

• A implementação sem tempo de inatividade mantém o teu site disponível para os utilizadores enquanto as actualizações são lançadas em segundo plano.
• A Cloudways permite implantações com tempo de inatividade zero usando ambientes de preparação, fluxos de trabalho baseados em Git e comutação de versão atômica.
• Separar o código da aplicação dos dados garante que as implementações nunca substituem os carregamentos, a configuração ou o conteúdo da base de dados.
• Versões versionadas combinadas com um link simbólico ativo permitem a troca instantânea de versões e reversões confiáveis.

Imagina que fazes uma atualização de rotina no teu site e que, durante alguns minutos, os utilizadores começam a ver 500 erros, páginas danificadas ou conteúdos incompletos. Os compradores abandonam os carrinhos de compras, os utilizadores com sessão iniciada perdem sessões e os motores de busca procuram páginas de erro em vez do teu conteúdo real. Mesmo uma curta interrupção pode significar perda de receitas, utilizadores frustrados e danos a longo prazo em termos de SEO. Este é o tipo de perturbação que pode transformar uma simples atualização num verdadeiro problema comercial.

A implantação de tempo de inatividade zero é uma abordagem que permite que as atualizações de aplicativos sejam lançadas enquanto o site permanece disponível para os usuários, um princípio também suportado pelo SafeUpdates no Cloudways. Em vez de sobrescrever arquivos ativos ou reiniciar serviços no meio da solicitação, uma nova versão é preparada separadamente e colocada em produção instantaneamente.

Este guia apresenta uma abordagem pronta para produção para implementar implantações de tempo de inatividade zero no Cloudways usando preparação, automação baseada em Git e lançamentos atômicos.

Como as implementações de tempo de inatividade zero funcionam na Cloudways

As implementações de tempo de inatividade zero no Cloudways são ideais quando é necessário implementar alterações de código, como temas do WordPress, plug-ins, lógica personalizada ou até mesmo atualizações de núcleo sem interromper o tráfego em tempo real. Em vez de sobrescrever arquivos dentro do diretório do aplicativo ativo (public_html) durante uma implementação, essa abordagem prepara uma nova versão em uma pasta separada e a coloca em produção instantaneamente usando um link simbólico. Os utilizadores nunca vêem páginas danificadas, conteúdo em falta ou actualizações parcialmente carregadas.

O diagrama a seguir ilustra uma estrutura de implantação de tempo de inatividade zero no Cloudways usando um aplicativo WordPress como exemplo.

O teu site ao vivo é sempre servido a partir da ligação simbólica atual, que aponta para a versão ativa dentro do diretório de versões. O novo código é implementado numa versão separada em segundo plano, enquanto os ficheiros persistentes, como a configuração (wp-config.php) e os uploads, vivem no diretório partilhado e são partilhados entre todas as versões através de ligações simbólicas. Quando uma implementação está pronta, o tráfego é mudado instantaneamente, actualizando a ligação simbólica atual.

O princípio fundamental é implantar o código da aplicação, mantendo os dados intocados. Apenas os arquivos rastreados pelo Git, como temas, plug-ins e código PHP personalizado, são liberados. Todos os dados do WordPress, incluindo posts, pedidos, usuários e configurações, residem no banco de dados e nunca são tocados durante as implantações.

Essa abordagem é especialmente útil para usuários do Cloudways que desejam a automação do GitHub para atualizações frequentes sem colocar o site em modo de manutenção. Combinando GitHub Actions com lançamentos atômicos, você obtém implantações previsíveis e repetíveis que parecem instantâneas para os usuários e removem o risco de tempo de inatividade no meio da implantação.

As vantagens da implementação sem tempo de inatividade

A implementação de tempo de inatividade zero é uma prática crítica para as empresas de comércio eletrónico. Protege as vendas, a confiança dos utilizadores e a experiência geral de compra.

Para sites e aplicações de produção, a implementação sem tempo de inatividade oferece benefícios práticos, tais como:

• Experiência do utilizador sem interrupções: Os visitantes podem continuar a navegar, comprar ou interagir com a tua aplicação enquanto as actualizações são lançadas em segundo plano. Não existem ecrãs de manutenção, páginas danificadas ou sessões perdidas durante os lançamentos.
• Maior fiabilidade das receitas: Para lojas de comércio eletrónico, até mesmo breves interrupções podem levar à perda de vendas. A implementação de tempo de inatividade zero evita falhas no checkout e a perda de encomendas, mantendo o site totalmente acessível durante as actualizações, para que os clientes nunca se deparem com páginas de erro ou carrinhos partidos enquanto o novo código está a ser lançado.
• Melhoria da estabilidade SEO: Os motores de busca não reagem bem a sítios que devolvem regularmente erros 5xx ou que ficam offline durante as implementações. Manter-se consistentemente disponível ajuda a preservar a saúde do rastreio e a estabilidade da classificação.
• Reduz o risco de lançamento: As novas versões são preparadas e validadas antes de serem lançadas. Se algo correr mal, a mudança para a versão anterior é rápida e previsível, sem necessidade de hotfixes de emergência.
• Ciclos de envio mais rápidos: As equipas podem implementar actualizações mais pequenas com maior frequência sem terem de agendar janelas de manutenção nocturnas ou coordenarem-se em torno de quedas de tráfego. Isto leva a uma iteração mais rápida e a lançamentos mais fiáveis.

Estratégias de implementação com tempo de inatividade zero

Várias estratégias estabelecidas são comumente usadas para alcançar implementações de tempo de inatividade zero, incluindo implementações blue-green, atualizações contínuas e lançamentos canários. Embora algumas delas exijam uma infraestrutura complexa, o Cloudways oferece suporte a abordagens práticas que funcionam bem para aplicativos baseados em PHP.

A seguir estão as estratégias de implantação de tempo de inatividade zero mais eficazes que podes usar no Cloudways:

Ativar um ambiente de teste

A Cloudways permite criar um ambiente de preparação com apenas alguns cliques, facilitando o teste de atualizações antes que elas entrem em operação.

Como funciona

• Clona a aplicação de produção para criar um servidor de teste.
• Aplica e testa todas as actualizações, incluindo alterações de código, actualizações de plug-ins, alterações de temas e até mesmo migrações de bases de dados, primeiro no staging.
• Valida o desempenho, a funcionalidade e a compatibilidade num ambiente seguro.
• Quando tudo estiver confirmado, implementa as alterações testadas na produção.

Isto reduz o risco de implementações interrompidas e garante que as actualizações de produção são previsíveis e controladas.

Usa a implantação baseada em Git

A Cloudways suporta totalmente implantações baseadas em Git, facilitando o envio de novos códigos de um repositório Git, como GitHub ou GitLab, para o servidor.

Como funciona

• Conecta seu aplicativo Cloudways a um repositório Git.
• Envia atualizações para o ramo principal ou de teste.
• Desencadeia implementações automaticamente

Os fluxos de trabalho baseados em Git fornecem controlo de versões, reversões fáceis e um rasto de auditoria limpo das alterações. Quando combinados com ferramentas de automação como o GitHub Actions, eles se tornam a base para implantações totalmente sem intervenção e de baixo risco.

Implantações atômicas com links simbólicos por meio do GitHub Actions

As implantações atômicas são uma das maneiras mais confiáveis de obter um tempo de inatividade verdadeiramente zero no Cloudways.

Como funciona

• Cada nova versão é carregada para um diretório separado (por exemplo: /releases/20260101-000001).
• Uma ligação simbólica chamada current aponta para o diretório de lançamento ativo.
• Quando a nova versão estiver completamente carregada e preparada, a ligação simbólica é mudada para o novo diretório.
• A mudança ocorre quase instantaneamente, pelo que os utilizadores nunca passam por períodos de inatividade.

Isso funciona bem no Cloudways porque o servidor continua servindo o tráfego enquanto a nova versão está sendo preparada e, quando o link simbólico é trocado, isso acontece quase instantaneamente, portanto, não há interrupção visível do serviço. Se algo der errado, a reversão é igualmente simples, basta apontar o link simbólico de volta para a versão anterior.

Quando emparelhado com o GitHub Actions ou ferramentas CI/CD semelhantes, esta abordagem permite implementações totalmente automatizadas e sem tempo de inatividade com um mínimo de despesas operacionais.

Nota:

• A Cloudways também oferece suporte a implantações com tempo de inatividade zero usando ferramentas de automação de terceiros, como DeployHQ e Capistrano, que dependem de diretórios de versão e troca atômica de links simbólicos.
• Com implementações baseadas em links simbólicos, “tempo de inatividade zero” não significa 100% de tempo de atividade do site, pois uma breve reinicialização do PHP-FPM pode causar erros momentâneos que duram um ou dois segundos.

Utiliza CDN e Caching do lado do servidor

A Cloudways oferece suporte a redes de distribuição de conteúdo (CDNs) por meio da integração com o Cloudflare e outros serviços de CDN, e também oferece cache do lado do servidor usando Varnish, Redis e Memcached.

Como funciona

• As CDNs continuam a servir activos estáticos em cache enquanto as alterações de backend estão a ser implementadas. Consulta o nosso guia sobre cache do WordPress para saberes como isto funciona.
• O armazenamento em cache do lado do servidor reduz a carga na tua aplicação durante as implementações.
• Os utilizadores podem continuar a receber respostas em cache mesmo que os serviços de backend sejam reiniciados por breves instantes.

Esta camada extra de armazenamento em cache e distribuição aumenta a resiliência, garantindo que o teu site permanece acessível enquanto estão a ser lançadas novas versões de aplicações.

Obtendo implantações sem tempo de inatividade em Cloudways

Esta seção apresenta um fluxo de trabalho prático e pronto para produção para implementar implantações de tempo de inatividade zero no Cloudways usando o WordPress.

O WordPress é utilizado aqui como uma implementação de referência, mas a mesma estrutura de lançamento aplica-se a outras aplicações baseadas em PHP com ajustes específicos da estrutura.

Pré-requisitos

Antes de configurar implementações de tempo de inatividade zero, certifica-te de que as seguintes peças estão no lugar.

• Um aplicativo WordPress em execução no Cloudways: Este pode ser o teu site de produção ao vivo. Se estiveres apenas a começar, podes configurar uma aplicação WordPress usando a avaliação gratuita de 3 dias da Cloudways, que te permite implementar e testar sem adicionar detalhes de faturação.
• Um repositório GitHub para o teu código WordPress: O teu repositório deve conter o tema, os plugins personalizados ou qualquer código WordPress que planeies implementar. Esta será a fonte da verdade para todos os lançamentos.

Quando estiverem prontos, podes passar à criação de um ambiente de preparação para testes seguros e lançamentos controlados.

Passo 1: Cria uma aplicação de teste

O primeiro passo é criar uma cópia de teste da tua aplicação WordPress de produção. Isto dá-te um ambiente seguro para testares as alterações antes de as colocares em funcionamento.

• Faz login na Plataforma Cloudways usando suas credenciais.
• Navega para Aplicações e localiza a tua aplicação WordPress de produção.
• Clica nos pontos verticais e seleciona Clonar aplicação/Criar teste.

• Escolhe se pretende clonar a aplicação para o mesmo servidor para poupar custos ou para um servidor diferente se pretender um isolamento completo.
• Marca Criar como teste, escolhe um nome como yourdomain-staging e confirma a ação.

• Aguarda a Cloudways terminar de provisionar o aplicativo de teste. Quando ele aparecer, terá uma tag Staging e sua própria URL de aplicativo de teste.

Neste ponto, tens agora duas aplicações separadas, produção e teste, cada uma com o seu próprio caminho de pasta de aplicações. Podes testar com segurança as actualizações na fase de teste sem afetar o tráfego em produção.

Habilitar o acesso SSH para produção e preparação

Na plataforma Cloudways, navegue até Aplicativos e selecione seu aplicativo. Em Configurações do aplicativo, ative o Acesso ao shell SSH.

Repete os mesmos passos para as aplicações de produção e de teste.

Passo 2: Configuração do servidor

Esta é uma configuração única que prepara as tuas aplicações de produção e de teste para implementações atómicas sem tempo de inatividade. Neste passo, vais criar uma estrutura de versões, mover ficheiros persistentes para um diretório partilhado e atualizar a tua aplicação para que sirva sempre a partir de um caminho de versão estável em vez de ficheiros activos.

Só precisas de fazer isto uma vez para cada aplicação, mas certifica-te de que o repetes para as aplicações de produção e de teste para que se mantenham sincronizadas.

Para começar, vá para a plataforma Cloudways, navegue até Servidores e selecione seu servidor. Em Credenciais mestre, clique em Iniciar terminal SSH.

Executa os seguintes comandos no terminal SSH. Substitui APP_ID pelo nome da pasta do teu aplicativo. Podes encontrá-lo na plataforma Cloudways em Aplicações → seleciona a tua aplicação → Configurações da aplicação → Geral → Pasta.

# Vai para a raiz da aplicação
cd /home/master/applications/APP_ID/public_html
APP_ROOT="/home/master/applications/APP_ID/public_html"

# 1) Cria uma estrutura
# versões = versões da aplicação com carimbo de data/hora
# Partilhado = dados persistentes (nunca são substituídos)
mkdir -p releases shared shared/uploads

# 2) Copia os ficheiros persistentes


# Copia os segredos de configuração e de BD para shared
cp wp-config-sample.php shared/wp-config.php

# Copia os uploads existentes para shared
cp wp-content/uploads/* shared/uploads/ 2>/dev/null || true

# 3) Cria a primeira versão do código atual
RELEASE_DIR="releases/$(data +'%Y%m%d%H%M%S')"
mkdir "$RELEASE_DIR"

# Copia apenas o código, ignora as pastas de implementação e os dados
rsync -a --exclude='releases' --exclude='shared' ./ "$RELEASE_DIR/"

# 4) Adiciona links simbólicos dentro deste lançamento para que ele use configuração e uploads compartilhados
ln -sfn "$APP_ROOT/shared/wp-config.php" "$RELEASE_DIR/wp-config.php" || true
ln -sfn "$APP_ROOT/shared/uploads" "$RELEASE_DIR/wp-content/uploads" || true

# 5) Aponta a corrente para esta primeira versão
# Troca atómica, o Nginx serve a corrente
ln -sfn "$RELEASE_DIR" atual

  # 6) Recarregamentos
  # Acionador suave para ajudar o PHP a pegar a nova versão após a troca de link simbólico
toca em wp-config.php && dorme 2  
# Limpa o diretório de cache do WordPress se for utilizado por um plugin de cache
rm -rf wp-content/cache/* 2>/dev/null || true  

Este script configura uma estrutura de implantação do WordPress com tempo de inatividade zero:

• Cria um diretório de versões para implantações com controle de versão e um diretório compartilhado para dados persistentes (configuração e uploads).
• Move a configuração e os uploads para o modo compartilhado para que nunca sejam sobrescritos.
• Cria uma nova versão com carimbo de data e hora, copiando a base de código atual.
• Liga a configuração compartilhada e faz o upload para a nova versão.
• Troca atomicamente o link simbólico atual para apontar para a nova versão, tornando-o ativo instantaneamente.
• Aciona o PHP para pegar a mudança e limpa o cache se estiver presente.

Atualizar a raiz do documento na Cloudways

Agora que sua estrutura de lançamento está no lugar, o próximo passo é dizer ao Cloudways qual pasta deve ser tratada como o site ao vivo. Deste ponto em diante, seu aplicativo sempre servirá arquivos do link simbólico atual em vez de diretamente do public_html.

Repete os passos seguintes para as aplicações de produção e de teste:

1. Na plataforma Cloudways, navega até Aplicativos.
2. Seleciona a tua aplicação.
3. Abre as Definições da aplicação.
4. Define o Webroot para: /public_html/current

5. Guarda as alterações e visita o URL da tua aplicação.

O teu site WordPress e o painel de administração do WordPress devem carregar exatamente como antes, sem erros ou páginas quebradas.

Se tudo parecer bem, a tua aplicação está agora totalmente preparada para implementações com tempo de inatividade zero utilizando lançamentos atómicos.

Passo 3: Prepara o teu repositório GitHub

Este passo prepara o teu repositório GitHub para conter apenas o código WordPress implementável, como temas e plug-ins personalizados, excluindo os ficheiros persistentes e gerados pelo servidor. O objetivo é garantir que o rsync e o GitHub Actions copiem exatamente o que seu script de implantação de tempo de inatividade zero espera, sem sobrescrever dados como uploads ou arquivos de configuração.

Seu repositório do GitHub deve espelhar o layout public_html do Cloudways para implantações baseadas em rsync, mas na maioria dos casos você se concentrará apenas no código personalizado.

Orientações para a estrutura do repositório

• Mantém o teu tema personalizado em wp-content/themes/your-theme/.
• Mantém os plugins personalizados em wp-content/plugins/.
• Exclui dados persistentes e gerados pelo servidor usando .gitignore.
• Os ficheiros principais do WordPress, como wp-admin/ e wp-includes/, são opcionais. Podes omiti-los se actualizares o núcleo do WordPress através do painel de administração ou da Cloudways. Inclui-os apenas se gerires os ficheiros principais manualmente ou aplicares patches personalizados.

3.1 Cria o repositório GitHub

• Vai a github.com e clica em Novo repositório.
• Define um nome como wordpress-zero-downtime.

• Escolhe Privado (recomendado).
• Não inicializes o .gitignore porque vais fazer push a partir do Cloudways.
• Cria o repositório e copia o URL SSH.

Utilizarás um repositório com dois ramos, o principal para a produção e o de teste para as implementações de teste.

3.2 Enviar o código da aplicação para o repositório GitHub

Aqui, vais inicializar o Git dentro da tua aplicação Cloudways e enviar o código para o GitHub.

Repete o mesmo processo para as aplicações de produção e de teste, enviando o código de produção para o ramo principal e o código de teste para o ramo de teste.

Inicializar o Git no servidor Cloudways

Entra por SSH na tua aplicação e executa os seguintes comandos.

# Vai para a raiz da aplicação

cd /home/master/applications/APP_ID/public_html
git init

Criar e configurar o .gitignore

Cria um ficheiro .gitignore a partir da raiz do teu repositório e adiciona regras de ignorar específicas do WordPress para que os segredos, os uploads e as pastas de implementação nunca sejam rastreados.

toca em .gitignore

Abre o ficheiro .gitignore no nano ou vi e adiciona o seguinte conteúdo.

# Estrutura de implantação
liberta/
partilhado/
atual/
# Segredos
wp-config.php
.env
# Dados do utilizador
wp-content/uploads/
# Cache
wp-content/cache/
wp-content/breeze-config/
wp-content/object-cache.php
wp-content/advanced-cache.php
# Git/OS
.git/
.DS_Store
*.log

Guarda o ficheiro e verifica se os dados sensíveis não estão a ser controlados.

cat .gitignore
git status

Não deves ver uploads, ficheiros de configuração ou pastas de implementação na saída.

Confirmar e enviar para o GitHub

Quando tudo estiver limpo, confirma o código e envia-o para o teu novo repositório do GitHub.

git add .
git commit -m "Código inicial do WordPress"
git remote add origin [email protected]:YOUR_USERNAME/YOUR_REPO.git

• Substitui YOUR_USERNAME pelo teu nome de utilizador de GitHub ou nome da organização.
• Substitui YOUR_REPO pelo nome do repositório que criaste anteriormente, por exemplo wordpress-zero-downtime.

Isso conecta seu aplicativo Cloudways ao seu repositório GitHub para que futuras implantações possam extrair código dele.

Para a aplicação de produção, faz push para o ramo principal.

git branch -M main
git push -u origin main

Para a aplicação de teste, faz push para o ramo de teste.

git branch -M staging
git push -u origin staging

Neste ponto, os ramos de produção e de preparação estão ativos no GitHub e prontos para serem usados pelas implementações do Cloudways Git e GitHub Actions.

Passo 4: Configurar um fluxo de trabalho de GitHub Actions para implementações atómicas

É aqui que a automação entra em jogo. Um fluxo de trabalho do GitHub Actions monitora as ramificações principal e de preparação e se conecta com segurança ao seu servidor Cloudways por SSH para executar a implantação automaticamente. Todo o processo é projetado para alternar lançamentos atomicamente, garantindo que as atualizações cheguem à produção sem tempo de inatividade visível.

O diagrama a seguir mostra como esse fluxo de trabalho de implantação sem tempo de inatividade é executado desde o envio do código até o tráfego ativo.

Este fluxo de trabalho mostra como as atualizações de aplicativos são implantadas sem interromper o tráfego ao vivo. As alterações de código são enviadas para o GitHub, desencadeando uma implantação automatizada por meio do GitHub Actions. Uma nova versão é preparada em segundo plano enquanto o site ativo permanece intocado, com configuração compartilhada e uploads reutilizados com segurança. Uma vez pronta, uma mudança atómica de ligação simbólica ativa instantaneamente a nova versão, permitindo que o servidor sirva a versão actualizada imediatamente para que os utilizadores vejam a atualização sem tempo de inatividade ou janela de manutenção.

4.1 Gerar um par de chaves SSH para GitHub Actions

Para permitir que o GitHub Actions se conecte com segurança ao seu servidor Cloudways, você precisa de um par de chaves SSH dedicado.

Executa o seguinte comando na tua máquina local para gerar um par de chaves SSH:

ssh-keygen -t rsa -b 4096 -C "github-actions-deploy" -f ~/.ssh/cloudways_deploy_rsa -N ""

Este comando gera dois ficheiros:

• ~/.ssh/cloudways_deploy_rsa
  A chave privada, que GitHub Actions irá utilizar.
• ~/.ssh/cloudways_deploy_rsa.pub
  A chave pública, na qual a Cloudways confiará.

Adiciona a chave pública à Cloudways:

• Na plataforma Cloudways, navega até Servidores e seleciona seu servidor.
• Abre as credenciais de mestre.
• Clica em Chaves públicas SSH.

• Adiciona um nome de etiqueta.

• Cola o conteúdo completo da chave pública gerada por este comando:

cat ~/.ssh/cloudways_deploy_rsa.pub

• Clica em Enviar.

Adiciona a chave privada ao GitHub:

1. Abre o teu repositório GitHub.
2. Vai a Definições → Segredos e variáveis → Acções.
3. Clica em Novo segredo de repositório.
4. Cria um novo segredo chamado SSH_PRIVATE_KEY.
5. Cola o conteúdo completo da chave privada gerada por este comando:

cat ~/.ssh/cloudways_deploy_rsa

4.2 Adiciona os segredos necessários de GitHub Actions

Em seguida, fornece ao GitHub Actions os detalhes do ambiente necessários para implantar seu aplicativo no Cloudways.

No teu repositório GitHub, vai a Definições → Segredos e variáveis → Ações → Novo segredo de repositório e, em seguida, adiciona os seguintes segredos:

Chave secreta	Descrição	Como encontrar o valor
CLOUDWAYS_APP_PROD	Nome da pasta do aplicativo de produção	Plataforma Cloudways → Aplicativos → Selecionar seu aplicativo de produção → Configurações do aplicativo → Geral → Pasta (Copiar o nome da pasta)
CLOUDWAYS_HOST_PROD	Endereço IP público do servidor de produção	Plataforma Cloudways → Servidores → Selecionar o servidor que hospeda seu aplicativo de produção → Credenciais mestre → IP público (Copiar este IP)
CLOUDWAYS_APP_STAGING	Nome da pasta do aplicativo de teste	Plataforma Cloudways → Aplicativos → Selecionar o aplicativo de teste → Configurações do aplicativo → Geral → Pasta (Copiar o nome da pasta)
CLOUDWAYS_HOST_STAGING	Endereço IP público do servidor de preparação	Plataforma Cloudways → Servidores → Selecionar o servidor que hospeda seu aplicativo de teste → Credenciais mestre → IP público (Copiar este IP)
CLOUDWAYS_USER	Nome de usuário SSH mestre	Plataforma Cloudways → Servidores → Selecionar o teu servidor → Credenciais principais → Nome de utilizador (Copiar este nome de utilizador)
CLOUDWAYS_EMAIL	O teu ID de e-mail de início de sessão da Cloudways	Plataforma Cloudways → ID de e-mail de login
CHAVE_API_DA_NUVEM	Chave secreta da API da Cloudways	Plataforma Cloudways → Integração de conta → Copiar chave secreta da API (regenerar, se necessário)
CLOUDWAYS_SERVER_ID_PROD	ID numérica da URL do servidor de produção	Plataforma Cloudways → Servidores → Selecionar servidor de produção → Copiar ID da URL (https://unified.cloudways.com/server/[ID])
CLOUDWAYS_SERVER_ID_STAGING	ID numérica da URL do servidor de preparação	Plataforma Cloudways → Servidores → Selecionar servidor de preparação → Copiar ID da URL (https://unified.cloudways.com/server/[ID])
CLOUDWAYS_APP_ID_PROD	ID numérica da URL do aplicativo de produção	Plataforma Cloudways → Aplicativos → Selecionar aplicativo de produção → Copiar ID da URL (https://unified.cloudways.com/apps/[ID])
CLOUDWAYS_APP_ID_STAGING	ID numérica da URL do aplicativo de teste	Plataforma Cloudways → Aplicativos → Selecionar aplicativo de teste → Copiar ID da URL (https://unified.cloudways.com/apps/[ID])

Esses segredos permitem que o fluxo de trabalho encaminhe automaticamente as implantações para o servidor e o aplicativo corretos com base na ramificação que está sendo enviada.

4.3 Cria o ficheiro de fluxo de trabalho

No teu repositório, cria um novo ficheiro chamado deploy.yml. Podes fazer isto diretamente a partir da interface web do GitHub, clicando em Adicionar ficheiro → Criar novo ficheiro. No campo do nome do arquivo, digita: .github/workflows/deploy.yml

Este caminho é necessário para que o GitHub o reconheça como um fluxo de trabalho.

Este fluxo de trabalho escolhe automaticamente a produção ou a preparação com base no nome do ramo:

• git push implementa a versão principal em produção

• git push staging implementa no staging

A um nível elevado, o fluxo de trabalho faz o seguinte:

• Implanta o ramo principal na produção e o ramo de preparação na preparação.
• Cria uma nova pasta releases/<timestamp> usando o executor do GitHub Actions e o rsync.
• Copia o código da aplicação para a pasta da nova versão.
• Liga a configuração partilhada e carrega-a para a versão.
• Troca atomicamente a versão atual para a nova versão (a versão anterior permanece disponível para reversão).
• Reinicia o PHP-FPM através da API da Cloudways.
• Redefine a propriedade e as permissões do arquivo por meio da API do Cloudways.

Como você pode ver no GIF, quando eu envio um novo código para o GitHub, o GitHub Actions implanta automaticamente a atualização no Cloudways, muda o link simbólico para a nova versão e o site ao vivo é atualizado sem tempo de inatividade.

A seguir, um fluxo de trabalho deploy.yml pronto para produção que implanta o código no Cloudways usando lançamentos atômicos e comutação de tempo de inatividade zero:

nome: Zero Downtime WordPress Deploy to Cloudways
sobre:
  empurra:
  ramos: [ principal, staging ]
  fluxo de trabalho_dispatch:

empregos:
  Desdobra:
  runs-on: ubuntu-22.04 # Usa o ubuntu-22.04 para evitar estados de espera do runner vistos com o ubuntu-latest


  env:
  APP_FOLDER: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_APP_PROD || secrets.CLOUDWAYS_APP_STAGING }}
  HOST: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_HOST_PROD || secrets.CLOUDWAYS_HOST_STAGING }}
  USUÁRIO: ${{ secrets.CLOUDWAYS_USER }}


  passos:
  # 1) Puxa o código do repositório para o executor do GitHub
  - utiliza: actions/checkout@v4


  # 2) Gera um carimbo de data/hora utilizado como nome da pasta de lançamento
  - id: vars
  executa: echo "RELEASE=$(date +'%Y%m%d%H%M%S')"  >>  $GITHUB_OUTPUT
  shell: bash

  # 3) Carrega o código do repo para um novo releases/<carimbo de data/hora>  pasta no servidor
  # Exclui dados partilhados e em tempo de execução para que nunca substituamos uploads/config
  - nome: Código Rsync a lançar
  utiliza: burnett01/rsync-deployments@v8
  com:
  alterna: -az --delete --exclude=releases/* --exclude=shared/* --exclude=current --exclude='wp-content/uploads/*' --exclude=wp-config.php --exclude='.git*' --exclude='.github/*'
  caminho: .
  remote_path: /home/master/applications/${{ env.APP_FOLDER }}/public_html/releases/${{ steps.vars.outputs.RELEASE }}/
  remote_host: ${{ env.HOST }}
  utilizador_remoto: ${{ env.USER }}
  remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

  # 4) Do lado do servidor: prepara o estado partilhado, faz a ligação simbólica das persistências e depois muda atomicamente o estado atual
  - nome: Implantar via SSH + switch de link simbólico
  utiliza: appleboy/[email protected]
  com:
  host: ${{ env.HOST }}
  nome de utilizador: ${{ env.USER }}
  porta: 22
  chave: ${{ secrets.SSH_PRIVATE_KEY }}
  script_stop: true


  escreve: |
  set -x # Registo de depuração (desactiva quando estável)
  RELEASE="${{ steps.vars.outputs.RELEASE }}"
  APP_ROOT="/home/master/applications/${{ env.APP_FOLDER }}/public_html"


  cd "$APP_ROOT"


  # Certifica-te de que as pastas de implementação existem
  mkdir -p releases shared shared/uploads

  # Certifica-te de que o rsync criou efetivamente a pasta de lançamento  
  se [ ! -d "releases/$RELEASE" ]; então
  echo "Pasta de lançamento em falta: releases/$RELEASE"
  saída 1
  fi

  # Symlink persistents (Dentro da release, aponta config e uploads para shared)
  cd "releases/$RELEASE"
  rm -rf wp-content/uploads
  ln -sfn "$APP_ROOT/shared/wp-config.php" wp-config.php || true
  ln -sfn "$APP_ROOT/shared/uploads" wp-content/uploads || true

  # Interruptor atómico de tempo de inatividade zero
  cd "$APP_ROOT"
  ln -sfn "releases/$RELEASE" atual
  ls -la current && echo "Mudou para $RELEASE"
              
  # Acionador suave para ajudar o PHP a pegar a nova versão após a troca de link simbólico
  toca em "$APP_ROOT/current/wp-config.php" && sleep 2
          
  # Limpa a cache do WordPress após a implementação se o WP-CLI estiver disponível
  WP_CLI=$(comando -v wp || echo "")
  if [ -n "$WP_CLI" ] && [ -r "$APP_ROOT/current/wp-config.php" ]; then
  se o núcleo $WP_CLI estiver instalado --allow-root  >/dev/null 2>&1; então
  $WP_CLI cache flush --allow-root || true
  fi
  fi
            
  # Limpa o diretório de cache do WordPress se for utilizado por um plugin de cache
  rm -rf "$APP_ROOT/current/wp-content/cache/"* 2>/dev/null || true


  ecoa "$(readlink current) [$RELEASE]"

            
  # 5) Reinicia o PHP-FPM + redefine as permissões dos ficheiros
  - nome: Reinício e permissões da API da Cloudways
  env:
  CLOUDWAYS_EMAIL: ${{ secrets.CLOUDWAYS_EMAIL }}
  CLOUDWAYS_API_KEY: ${{ secrets.CLOUDWAYS_API_KEY }}
  CLOUDWAYS_SERVER_ID: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_SERVER_ID_PROD || secrets.CLOUDWAYS_SERVER_ID_STAGING }}
  CLOUDWAYS_APP_ID: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_APP_ID_PROD || secrets.CLOUDWAYS_APP_ID_STAGING }}
           
  corre: |
  # Obtém o token OAuth
  CLOUDWAYS_TOKEN=$(curl -s -X POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  -d "email=${CLOUDWAYS_EMAIL}&api_key=${CLOUDWAYS_API_KEY}" \
  'https://api.cloudways.com/api/v1/oauth/access_token' \
  | jq -r '.access_token')

  # Reinicia o PHP-FPM para este servidor
  curl -s -X POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  --header "Autorização: Portador ${CLOUDWAYS_TOKEN}" \
  -d "server_id=${CLOUDWAYS_SERVER_ID}&service=php8.1-fpm&state=restart" \
  'https://api.cloudways.com/api/v1/service/state'

  # Repor as permissões para a tua aplicação de teste ou de produção
  curl -s -X POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  --header "Autorização: Portador ${CLOUDWAYS_TOKEN}" \
  -d "server_id=${CLOUDWAYS_SERVER_ID}&app_id=${CLOUDWAYS_APP_ID}&ownership=sys_user" \
  'https://api.cloudways.com/api/v2/app/manage/reset_permissions'

  echo "Permissões redefinidas para app_id=${CLOUDWAYS_APP_ID}"
  shell: bash

Nota: Este fluxo de trabalho de implementação centra-se estritamente no código da aplicação. As alterações no banco de dados são tratadas separadamente e não fazem parte desse processo de implementação. O banco de dados é gerenciado de forma independente por meio do MySQL ou MariaDB no Cloudways e não faz parte do sistema de arquivos do aplicativo.

Passo 5: Valida o fluxo e entra em funcionamento

Nesta fase, o teu pipeline de implementação de tempo de inatividade zero está totalmente ligado e pronto para uma utilização real. Antes de colocar qualquer coisa no ar, é importante validar o fluxo completo de ponta a ponta usando o ambiente de teste. Essa verificação final garante que as implantações se comportem exatamente como esperado, sem afetar o tráfego real.

5.1 Testa o pipeline de implementação de preparação

Começa por ativar uma implementação no staging. Começa com uma alteração pequena e de baixo risco, como a atualização de um ficheiro CSS no teu tema ou a adição de um comentário visível num modelo. Isto facilita a confirmação de que a nova versão está realmente a ser implementada.

Confirma e envia a alteração para o ramo de preparação.

faz o checkout do git staging
git add .
git commit -m "Testa a implementação de staging"
git push origin staging

Quando o push for concluído, abre GitHub → Ações e observa a execução do fluxo de trabalho. Uma implantação bem-sucedida deve ser concluída com uma marca de verificação verde, confirmando que a automação foi executada sem erros.

Em seguida, verifica o local de preparação:

• Visita o URL da aplicação de teste
• Confirma que a nova alteração é visível
• Certifica-te de que o frontend é carregado corretamente
• Verifica se a administração do WordPress funciona como esperado
• Verifica se não aparecem erros durante o carregamento normal da página

Para validar totalmente a implantação, entra por SSH na aplicação de teste e confirma a estrutura de lançamento:

• Existe uma nova pasta com carimbo de data/hora dentro do diretório de lançamentos
• A ligação simbólica atual aponta para a versão mais recente
• Os ficheiros partilhados, como os carregamentos e a configuração, têm ligações simbólicas corretas

Se tudo parecer correto, o teu pipeline de implementação está a funcionar como pretendido sem tocar no tráfego em tempo real.

5.2 Promove mudanças na produção

Uma vez verificada a preparação, promover as mesmas alterações para a produção é intencionalmente simples.

Faz o merge do ramo de staging no principal e envia a atualização.

faz o checkout do git main
git merge staging
git push origin main

Isso aciona o mesmo fluxo de trabalho do GitHub Actions, desta vez usando segredos de produção. Vê os bastidores:

• Prepara um novo lançamento de produção em segundo plano
• A configuração partilhada e os carregamentos são reutilizados em segurança
• A ligação simbólica atual muda atomicamente

Enquanto a implantação é executada, monitora o fluxo de trabalho em GitHub Actions para confirmar que ele foi concluído com sucesso.

Após a implantação bem-sucedida, verifica o site de produção ao vivo:

• Abre o URL de produção
• Confirma que a atualização está visível
• Verifica a funcionalidade de administração do WordPress
• Revê os registos em Aplicações → Seleciona a tua aplicação → Monitorização → Registos

Do ponto de vista de um visitante, nada fica offline. A atualização fica simplesmente disponível.

Passo 6: Monitorização e reversões instantâneas

O tempo de inatividade zero não termina quando uma implementação termina. O monitoramento contínuo e a capacidade de recuperação rápida são o que tornam essa abordagem confiável na produção. A Cloudways fornece ferramentas integradas que facilitam a validação de implementações e respondem rapidamente se algo der errado.

6.1 Monitoriza as implementações em Cloudways

A monitorização deve ser integrada diretamente no teu processo de lançamento. Após cada implementação, dedica alguns momentos a verificar o comportamento da aplicação antes de considerar o lançamento completo.

Na plataforma Cloudways:

1. Navega para Aplicações
2. Seleciona a tua aplicação
3. Abre Monitorização → Registos

Analisa os seguintes registos:

• Acede aos registos para compreender os pedidos da Web, o estado dos pedidos, os IPs dos visitantes e as páginas visualizadas.
• Registos de erros para verificar erros e avisos que indicam potenciais problemas com eventos ou com a configuração da aplicação.

Tornar a monitorização pós-implementação um passo padrão no seu fluxo de trabalho ajuda a detetar problemas precocemente e reduz o risco de os utilizadores enfrentarem problemas.

6.2 Reverte instantaneamente (se necessário)

O planeamento da reversão também deve fazer parte do processo de implementação, e não algo decidido durante um incidente.

Como cada implantação é armazenada em seu próprio diretório de versão, a reversão no Cloudways é rápida, previsível e segura. Voltar para uma versão anterior é uma simples alteração de link simbólico, sem restaurações de arquivos ou correções de emergência.

Para retroceder:

• Identifica uma versão anterior conhecida como boa no diretório de versões
• Aponta a ligação simbólica atual para essa versão
• Limpa as caches da aplicação, se necessário

O tráfego regressa imediatamente, restaurando a versão anterior sem tempo de inatividade. Tratar a reversão como um passo definido do fluxo de trabalho garante que a recuperação é calma, controlada e fiável quando surgem problemas.

Práticas recomendadas de implantação com tempo de inatividade zero

Implementar a implantação de tempo de inatividade zero não é apenas uma questão de ferramentas e fluxos de trabalho que usas. A fiabilidade a longo prazo resulta do cumprimento de práticas recomendadas comprovadas de implementação de tempo de inatividade zero que mantêm as implementações seguras, previsíveis e fáceis de recuperar.

As seguintes diretrizes de implantação de tempo de inatividade zero funcionam especialmente bem para aplicativos hospedados no Cloudways.

Implementa sempre o código separadamente dos dados

O código da aplicação deve ser tratado como descartável, enquanto os dados devem permanecer persistentes. Mantém os ficheiros de configuração, os uploads e o conteúdo gerado pelo utilizador fora dos diretórios de lançamento e reutiliza-os através de ligações simbólicas. Isso garante que as implantações nunca sobrescrevam dados críticos e torna as reversões seguras e rápidas.

Utiliza o staging para cada lançamento

Um ambiente de teste é essencial para validar as alterações antes que elas cheguem à produção. Sempre testa implementações, atualizações de plugins e alterações de configuração na preparação primeiro. Na Cloudways, os aplicativos de preparação espelham de perto a produção, facilitando a deteção precoce de problemas e o lançamento com confiança.

Automatiza as implementações de ponta a ponta

As implementações manuais aumentam o risco de erro humano. Utiliza fluxos de trabalho baseados no Git e ferramentas de automatização como o GitHub Actions para normalizar a forma como o código é lançado. A automatização garante que todas as implementações seguem os mesmos passos, reduzindo as inconsistências entre ambientes.

Mantém os lançamentos pequenos e frequentes

As alterações mais pequenas são mais fáceis de testar, rever e reverter, se necessário. Lançamentos frequentes reduzem o impacto de qualquer implantação única e facilitam a identificação de problemas. Esta abordagem também se alinha bem com as estratégias de tempo de inatividade zero, em que as alterações são preparadas e trocadas atomicamente.

Monitoriza imediatamente após cada implementação

Os momentos após uma implantação são críticos. Analisa os logs de aplicativos, logs de erros e métricas de desempenho logo após cada lançamento. O Cloudways fornece acesso integrado aos logs de aplicativos, facilitando a deteção e a solução de problemas antes que eles afetem os usuários.

Torna a reversão parte do processo

A implementação sem tempo de inatividade está incompleta sem uma estratégia de reversão clara. Sempre mantém versões anteriores disponíveis e sabe exatamente como voltar se algo der errado. Na Cloudways, a reversão é tão simples quanto reposicionar a versão ativa e limpar os caches.

Documenta o teu fluxo de trabalho de implementação

Uma documentação clara ajuda as equipas a implementar de forma consistente e confiante. Documenta como as implantações funcionam, onde as versões residem e como as reversões são realizadas. Isso reduz o tempo de integração e garante que todos sigam o mesmo processo confiável.

Conclusão

A implantação de tempo de inatividade zero é agora um requisito padrão para manter a disponibilidade durante os lançamentos de produção. Com a Cloudways, não é necessária uma infraestrutura complexa para conseguir isso. Uma combinação bem estruturada de ambientes de preparação, fluxos de trabalho baseados em Git e troca atômica de links simbólicos é suficiente para fornecer atualizações confiáveis e sem interrupções.

Ao separar o código dos dados e ao automatizar as implementações através do GitHub Actions, cria um processo de lançamento repetível que se adapta ao crescimento do seu site. As atualizações se tornam previsíveis, as reversões são instantâneas e as implantações não parecem mais arriscadas. Quer estejas a gerir um site WordPress, uma loja de comércio eletrónico ou uma aplicação PHP personalizada, esta abordagem permite-te enviar alterações com confiança sem perturbar o tráfego em tempo real.

Uma vez implementada, a implementação de tempo de inatividade zero torna-se uma parte natural do seu fluxo de trabalho, permitindo que as actualizações cheguem à produção enquanto o site permanece totalmente disponível, para que a sua equipa se possa concentrar na criação de funcionalidades em vez de gerir lançamentos.