# Utilizar o Staging: Enviar para Produção e Importar da Produção

Source: https://support.kapsulehost.com/pt-pt/wordpress-staging-workflow

Staging destina-se a sites WordPress e WooCommerce. Assim que existe uma cópia de teste, há duas operações que a mantêm útil: publicar as alterações testadas no site ao vivo e repor o ambiente de teste para uma cópia nova da produção. Este guia aborda ambas as direções em detalhe, as confirmações que protegem o seu site ao vivo e os casos em que publicar uma base de dados destruiria dados.

Se ainda não criou um ambiente de teste, comece por [Utilizar Ambientes de Teste](https://support.kapsulehost.com/pt-pt/staging-environments). Este artigo parte do ponto em que o ambiente de teste já existe.

## As Duas Direções

| Operação | O que substitui | Quando a usar |
|---|---|---|
| **Publicar em Produção** | O seu site ao vivo | As alterações no ambiente de teste estão testadas e prontas para entrar em produção |
| **Repor a partir de Produção** | O seu site de teste | Pretende uma cópia limpa do site ao vivo atual para trabalhar sobre ela |

Ambas as operações estão no mesmo ecrã: **Websites**, depois o seu site, depois **Environment**, depois **Testes**.

![A página de Staging de um site no KPanel, a mostrar o domínio de teste, o seu estado e a última sincronização](https://support.kapsulehost.com/help/screenshots/wordpress-staging-workflow.8f62c65f.webp)

O cartão no topo desse ecrã mostra o seu domínio de teste, o respetivo estado, há quanto tempo foi sincronizado pela última vez a partir da produção e quando foi publicado pela última vez. **WP Admin** inicia sessão diretamente no painel do site de teste, e **Visitar site** abre a interface pública do ambiente de teste.

> **Tip:** Uma cópia de teste que não é sincronizada há uma semana ou mais é assinalada a âmbar nesse cartão. Um ambiente de teste desatualizado é pior do que não ter nenhum: acaba por testar contra um site que já não se assemelha ao ambiente ao vivo. Reponha antes de iniciar um novo trabalho, não depois.

## Publicar Testes em Produção

Isto substitui parte ou a totalidade do seu site ao vivo pelo que está no ambiente de teste.

1. Abra **Environment**, depois **Testes**.
2. Percorra até **Publicar Teste em Produção**.
3. Escolha o que publicar através das caixas de verificação: **Ficheiros**, **Base de dados**, ou ambas.
4. Se assinalou **Base de dados**, deixe **Reescrever URLs** assinalado. Esta opção executa uma pesquisa e substituição em todas as tabelas para que o nome de anfitrião de teste seja trocado pelo da produção como parte da publicação.
5. Assinale **Compreendo que isto modifica o meu site de produção activo.**
6. Introduza o seu domínio de produção na caixa de confirmação exatamente como é apresentado.
7. Clique em **Publicar em Produção**.

O botão permanece desativado até que a caixa de verificação esteja assinalada e o domínio corresponda, de modo que um clique prematuro não possa iniciar uma publicação.

> **Warning:** Uma publicação substitui, não combina. Tudo o que mudou na produção desde a sua última reposição é substituído pelo que estiver no ambiente de teste. Isto inclui novas publicações, novas contas de clientes, novas entradas de formulários e novas encomendas.

É feita automaticamente uma cópia de segurança completa da produção antes de qualquer escrita, e se a publicação falhar a meio, a produção é revertida para essa cópia de segurança. Sites pequenos terminam normalmente em bem menos de um minuto; uma base de dados grande ou uma biblioteca de multimédia com vários gigabytes demora mais tempo.

### Escolher Files, Database, ou Ambos

Esta é a decisão mais importante, e a resposta normalmente não é "ambos".

**Apenas Files.** A opção segura por defeito para um site que recolhe qualquer tipo de informação dos visitantes. Alterações de tema, atualizações de plugins, alterações de modelos e código personalizado residem todos em ficheiros. Publicar apenas ficheiros deixa intactos todos os artigos, comentários, encomendas e utilizadores na produção.

**Apenas Database.** Para alterações de conteúdo ou de definições feitas no ambiente de teste, num site onde ninguém edita diretamente a produção. Raro na prática.

**Ambos.** Correto para um redesenho ou uma reconstrução em que o ambiente de teste é o novo site e a produção vai ser substituída por completo. Anuncie-o, faça-o fora de horas, e confirme primeiro que tem uma cópia de segurança atual.

> **Important:** Publicar a base de dados numa loja ao vivo elimina encomendas. O WooCommerce guarda encomendas, clientes, subscrições, cupões e níveis de stock na base de dados, pelo que todas as encomendas feitas desde a sua última reposição a partir da produção desaparecem assim que a publicação termina. Não existe recuperação parcial. Numa loja, publique apenas ficheiros, e faça alterações ao nível da base de dados diretamente na produção. Consulte [Configurar o WooCommerce](https://support.kapsulehost.com/pt-pt/wordpress-woocommerce).

A mesma armadilha aplica-se, de forma menos dramática, a qualquer site com comentários, submissões de formulários, registos de membros ou uma lista de correio armazenada no WordPress.

## Repor o Ambiente de Teste a partir da Produção

Esta é a direção segura: substitui o ambiente de teste pelo site ao vivo atual e nunca toca na produção.

1. Abra **Environment**, depois **Testes**.
2. Localize **Repor a partir de Produção**.
3. Assinale **Ficheiros**, **Base de dados**, ou ambas.
4. Clique em **Repor a partir de Produção**.

Faça isto sempre que:

- A produção tiver avançado, com novos artigos, novas encomendas ou alterações de conteúdo.
- Estiver a iniciar um novo trabalho e quiser uma base realista.
- O ambiente de teste se tiver afastado o suficiente para que um resultado de teste aí obtido já não tenha significado.

Tudo o que estiver no ambiente de teste e não tiver sido publicado é perdido. Se houver trabalho no ambiente de teste que ainda pretenda manter, publique-o primeiro, ou copie os ficheiros alterados através de **Definições**, depois **Gestor de Ficheiros**, antes de repor.

## Como Funciona a Reescrita de URLs

O WordPress guarda o seu próprio endereço na base de dados, nas linhas `siteurl` e `home` da tabela de opções, e os URLs absolutos também acabam por surgir no conteúdo das publicações, nos valores de metadados, nas definições de widgets e nas opções de tema.

O seu site de teste é executado em `staging.` seguido do seu domínio, pelo que todos esses valores apontam para o nome de anfitrião de teste enquanto trabalha nele. **Reescrever URLs** durante a publicação executa uma pesquisa e substituição adequada em todas as tabelas, tratando corretamente as definições de plugins serializadas, e troca o nome de anfitrião de teste pelo da produção.

Deixe esta opção assinalada, salvo se tiver uma razão específica para não o fazer. Se publicar apenas ficheiros, ou se sobreviver algum URL de teste isolado, corrija-o com [Executar uma Pesquisa e Substituição](https://support.kapsulehost.com/pt-pt/wordpress-search-replace).

## Um Fluxo de Trabalho Fiável

1. **Reponha a partir da produção** para que o ambiente de teste corresponda ao site ao vivo.
2. **Faça uma cópia de segurança da produção** antes de começar, para ter um ponto de restauro independente da publicação: [Fazer uma Cópia de Segurança](https://support.kapsulehost.com/pt-pt/taking-a-backup).
3. **Faça o trabalho no ambiente de teste.** Atualizações de plugins e temas, novo código, alterações de esquema.
4. **Teste no domínio de teste.** Carregue as páginas que alterou, e as que não alterou. Numa loja, execute uma encomenda de teste de ponta a ponta.
5. **Publique apenas ficheiros**, a menos que tenha decidido deliberadamente que a base de dados também deve ser incluída.
6. **Verifique a produção imediatamente.** Página inicial, uma página mais profunda, o checkout e o painel de administração.
7. **Reponha novamente o ambiente de teste a partir da produção** assim que estiver satisfeito, para que a ronda seguinte comece limpa.

> **Note:** O ambiente de teste é gerido inteiramente a partir do seu site de produção. Não aparece como uma entrada separada na lista **Websites**, pelo que todos os controlos associados a ele, incluindo a sua eliminação, se encontram neste único separador.

## Eliminar o Ambiente de Teste

O cartão **Eliminar Testes** na parte inferior do mesmo ecrã remove a cópia de teste. A produção não é afetada. Elimine-o quando um projeto estiver concluído: o ambiente de teste conta para o espaço de armazenamento do seu plano, e uma cópia desatualizada é um encargo e não uma vantagem.

## Resolução de Problemas

**O botão Publicar em Produção não ativa.** Ambas as condições têm de ser cumpridas: a caixa de verificação de confirmação assinalada, e o domínio de produção introduzido exatamente, sem `https://` e sem barra final.

**A publicação terminou mas o site continua a mostrar conteúdo antigo.** É caching. Limpe a partir de **WordPress**, depois **Ações Rápidas**, depois **Limpar Cache**, elimine o CDN a partir de **Desempenho**, depois **Kapsule CDN**, e recarregue numa janela privada.

**Estão a aparecer URLs de teste no site ao vivo depois de uma publicação.** A base de dados foi transferida sem **Reescrever URLs** assinalado. Execute uma pesquisa e substituição do nome de anfitrião de teste para o seu domínio de produção: [Executar uma Pesquisa e Substituição](https://support.kapsulehost.com/pt-pt/wordpress-search-replace).

**Publiquei a base de dados e perdi encomendas.** Restaure imediatamente a cópia de segurança automática anterior à publicação, antes que cheguem mais encomendas à base de dados substituída: [Restaurar a partir de uma Cópia de Segurança](https://support.kapsulehost.com/pt-pt/restoring-from-backup).

**O ambiente de teste apresenta um erro depois de uma reposição.** Um plugin que codifica diretamente o domínio de produção é a causa habitual. Inicie sessão com **WP Admin** no cartão de teste e desative os plugins aí até o erro desaparecer, depois corrija ou substitua o plugin problemático na produção.