Não há tempo para escrever uma resposta completa (eu sei que é meio idiota), mas provavelmente vale a pena compartilhar de qualquer maneira (talvez eu edite isso porque planejo um post sobre isso também):
Isso significa que você pode ter alguma configuração de WP baseada em tronco / versão que pode ser totalmente hackeada, inclusive. temas e plugins.
Como este é um repositório independente (local), você pode enviá-lo via ssh para outros repositórios, por exemplo:
- Isso fica no host remoto em que o site deve ser implantado (repositório simples).
- Isso tem ganchos para fazer outro repositório nesse host realmente se fundir nas alterações que você acabou de enviar.
Isso está descrito em Um fluxo de trabalho Git focado na Web (novembro de 2008; por Joe Maller) .
Se você tiver um comutador de configuração que escolhe o concreto com wp-config.phpbase no sistema em que está sendo executado, poderá configurar até todos os hosts centralmente (desenvolvimento, live, teste, amigos, ...) dentro do repositório.
Alterações upstream no WP, você apenas busca e mescla na subárvore.
Plugins que você acabou de atualizar e confirmar.
A implantação é simples $ git push remote.
Execute backups diários no host remoto para os repositórios git, o banco de dados e os arquivos enviados, e isso é barato, amigável para o desenvolvedor e flexível. Isso funciona bem para configurações de desenvolvedor único e para equipes pequenas, porque todos podem fazer o checkout a partir da reprodução simples no controle remoto.
Existem algumas advertências:
Agora, com sua lista de verificação e a configuração, conforme descrito acima:
1. Gostaria de ter meu ambiente git no meu próprio servidor internamente, sem usar o Github para lidar com repos.
O Github lida apenas com repositórios upstream aqui (Wordpress), não com o seu próprio.
2. Criação automática de subdomínios na criação da ramificação git (development.domain.com, ryan.development.domain.com) - Provavelmente, algum gancho de script de shell seria o ideal.
A configuração descrita é uma abordagem modular com um repo por site. Ele pode lidar com quantos hosts de desenvolvimento você desejar, mas também pode funcionar bem com uma instalação de vários sites para lidar com vários domínios, mas isso contaria como uma configuração do wordpress nessa abordagem.
3. Script Phing PHP / Shell Manipulação da migração db (algo como http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) para lidar com a substituição de banco de dados serializada ao pressionar
Isso não é necessário aqui, pois apenas o código está sob controle de versão, os bancos de dados são independentes entre desenvolvimento (preparação) e produção, como deveria ser.
Você pode estar procurando por um script de instalação que faça a migração correta do domínio, mas mesmo com um código melhor (disponível) que lide com a pesquisa e substituição de dados serializados, nesta configuração aqui normalmente não é necessário, basta pressionar as alterações para ativar , para os casos de teste, você pode criar rapidamente o conteúdo no banco de dados de desenvolvimento, que normalmente é o menor problema (da minha experiência prática, a sua pode ser diferente, mas eu também sugeriria manter esses tópicos relacionados à migração de banco de dados em questões sobre aqui no site - mas pergunte a eles).
Eu corro cerca de 200 sites em meu próprio servidor e gostaria de começar a implementar esses sites em um ambiente de fluxo de trabalho forte do git para que eu possa otimizar meu trabalho muito melhor.
Não consigo imaginar como esses sites se tornariam em um ambiente de fluxo de trabalho com string git. Talvez os scripts de configuração e os dados de configuração que você gerencia aqui sejam mantidos sob controle de versão do git. Isso poderia fazer sentido. Caso contrário, pela grande quantidade de sites, acho que não faz sentido manter todos aqueles em um repositório git. Talvez nem mesmo um deles, porque o que descrevi acima é para sites que você desenvolve (incluindo o código principal do WP), não apenas para tarefas de instalação. Portanto, você provavelmente precisa criar primeiro um pequeno mapa desses 200 sites e como eles interagem entre si e de quais pacotes (núcleo do WP, plugins, temas) esses sites consistem. A primeira coisa poderia ser criar uma planilha / matriz e colocar todos os sites.
Em seguida, você pode salvá-lo como CSV, colocá-lo sob controle de versão e fazer com que os scripts de implantação funcionem com base nesse arquivo.
E se eu aprendi algo com tarefas de automação: siga a filosofia do Unix, use as ferramentas existentes e que funcionem bem (é melhor passar meio dia lendo alguns comandos do que tentar procurar alternativas porque, na maioria dos trabalhos, os problemas foram resolvidos. já resolvidos) e se concentre nas ferramentas de linha de comando. Eles são mais poderosos.