README

Core reutilizável de Deployer para projetos WordPress (Bedrock e Native), incluindo tasks de provisionamento com EasyEngine, tasks de manutenção compartilhadas e artefatos de CI/templates prontos para uso.

O que o pacote contém

• deploy.php — entrypoint que carrega helpers, providers e todas as tasks. É o arquivo que o projeto consumidor inclui.
• src/helpers.php — funções auxiliares e adaptadores por tipo de projeto (PROJECT_TYPE).
• src/providers/easyengine.php — integração com EasyEngine.
• src/tasks/*.php — cadeia de deploy, provisionamento, backup e manutenção.
• templates/ — exemplos reutilizáveis de .gitattributes, workflows do GitHub Actions e comandos .ddev, organizados por tipo (bedrock/native) e comuns (common).
• bin/sync-templates — binário que sincroniza os templates do pacote para o projeto consumidor.

Requisitos

• PHP >= 8.3
• deployer/deployer ^8.0
• oscarotero/env ^2.1

Instalação

No projeto consumidor, instale como dependência de desenvolvimento:

composer require --dev infografic/wp-deployer-core

Ou diretamente no composer.json:

{
  "require-dev": {
    "infografic/wp-deployer-core": "^1.0"
  }
}

Quick start

No deploy.php do projeto consumidor:

<?php

namespace Deployer;

define('DEPLOY_ROOT', __DIR__);

// Configuração específica do projeto (hosts, secrets, env_required, etc.)
require __DIR__ . '/deploy/config.php';

// Core do pacote: carrega helpers, providers e todas as tasks
require __DIR__ . '/vendor/infografic/wp-deployer-core/deploy.php';

Os overrides específicos do projeto (configuração de hosts, secrets de CI, tasks customizadas) permanecem no repositório consumidor. O pacote fornece apenas a base reutilizável.

PROJECT_TYPE (Bedrock vs Native)

O comportamento do core se adapta ao tipo de projeto, definido pela variável de ambiente PROJECT_TYPE:

• bedrock (padrão) — estrutura Bedrock, com web/app e WordPress versionado via Composer.
• native — instalação WordPress tradicional.

Defina no .env do projeto consumidor:

PROJECT_TYPE=bedrock

Valores inválidos fazem as tasks falharem cedo com mensagem explícita.

Sincronizar templates

O pacote expõe um binário do Composer (vendor/bin/sync-templates) — não é necessário copiar nenhum arquivo para o projeto consumidor. Basta declarar os scripts no composer.json do consumidor:

{
  "scripts": {
    "deploy:templates:sync": "sync-templates",
    "deploy:templates:sync:force": "sync-templates --force"
  }
}

E rodar a partir da raiz do projeto:

composer deploy:templates:sync          # cria/atualiza apenas o que está ausente
composer deploy:templates:sync:force    # sobrescreve arquivos divergentes

O comando lê PROJECT_TYPE (do ambiente ou do .env) e sincroniza:

Por padrão, arquivos já existentes com conteúdo diferente são ignorados (preserva customizações locais); use --force para sobrescrevê-los.

O binário usa o diretório de trabalho atual como raiz do projeto. Para rodar de outro lugar, informe sync-templates --root=/caminho/do/projeto.

Tasks disponíveis

Liste todas as tasks no consumidor com:

vendor/bin/dep list

Rastreabilidade de versão

Para registrar exatamente qual versão de pacote/templates está ativa, defina no consumidor/CI:

• DEPLOY_PACKAGE_NAME
• DEPLOY_PACKAGE_VERSION
• DEPLOY_TEMPLATES_VERSION

Esses valores são exibidos pela task deploy:version:report no início do deploy.

Licença

MIT © Infografic