Ajuda do Wordpress Git Workflow

Estou procurando uma forte ideia de fluxo de trabalho simplificado para trabalhar com o Wordpress.

1. Gostaria de ter meu ambiente git no meu próprio servidor internamente, sem usar o Github para manipular repositórios.
2. Criação automática de subdomínios na criação da ramificação do git (development.domain.com, ryan.development.domain.com) - Provavelmente algum gancho de script de shell seria o ideal.
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

A operação provavelmente seria algo como isto:

1. obtendo a versão mais recente do wordpress atual e ramificando-a, o nome da ramificação recebe uma entrada de subdomínio (branchdevelopment.domain.com)
2. submódulo do tema que você deseja, se estiver disponível (eu gostaria de fazer meu próprio repositório git para isso, pois como uso da tese, gostaria de ter uma configuração em branco do git repo para obter internamente no servidor que já foi criado)
3. faça o check-out e faça as alterações, as revisões dos clientes, assim que for pressionado, o script do banco de dados iniciará automaticamente a alteração dos valores de URL serializados de localhost (ou subdomínio) para o URL ativo

Isso é possível? Ouvi dizer que Capistrano também é bom de utilizar, mas não tenho certeza de como o Capistrano funciona inteiramente.

Eu corro cerca de 200 sites no 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. A partir de agora, eu basicamente baixa uma imagem do site e trabalho localmente e depois carrego as alterações no servidor. Isso é muito tedioso hoje em dia.

Alguém tem alguma solução em relação a esse tipo de fluxo de trabalho / já trabalhou com isso no passado? Nesse caso, alguns recursos / respostas seriam muito apreciados.

Perguntas gerais respondidas

Nr.1. Gostaria de ter meu ambiente git no meu próprio servidor internamente, sem usar o Github para manipular repositórios.

A primeira coisa que eu faria é verificar o compositor e como ele funciona com o WordPress , que é um projeto de Andrey "@Rarst" Savchenko .

Nr.2. Criação automática de subdomínios na criação da ramificação do git ( development.example.com, ryan.development.example.com) - Provavelmente, algum gancho de script do shell seria ideal para isso.

Isso é algo fora do escopo deste site. Ou pedir ajuda em StackOverflow ou pedir ao seu hoster. Alguns hosters não permitem editar essas entradas você mesmo.

Nr.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

Eu configuraria uma instalação multisite / rede. Isso permite gerenciar facilmente todas as tabelas, manter os usuários em um local central, etc.

O WP Gear - um projeto de Robert "@Wyck" Ellison - tem uma lista de scripts de construção alternativos. Incluindo o WordPhing escrito por ele mesmo. Até agora, o script @TomJNowells /Interconnect.it não está nessa lista.

Perguntas de operação respondidas

Nr. 1. obtendo a versão atual mais recente do wordpress e ramificando-a, o nome da ramificação recebe uma entrada de subdomínio (branchdevelopment.domain.com)

Não sei por que alguém quer fazer isso: Um subdomínio para cada ramificação. Quando você olha para o repositório sincronizado do WordPress GitHub e a lista de ramificações , verá que cada ramificação é nomeada X.Y-branch. Portanto, seus subdomínios seriam nomeados, por exemplo 3.6-branch. Não tenho certeza se um subdomínio tem permissão para começar com um dígito (deveria ser, mas pergunte ao seu hoster) e existe o problema de você obter um subdomínio nomeado 6-branch, que tem um subdomínio nomeado 3e outro chamado 2. E acho que o emparelhamento de ramificações das versões 2 e 3 em um subdomínio não é o que você deseja alcançar.

Resumindo: apenas checkout 3.6-branchse você precisar trocar de ramificação.

Nr.2. submódulo do tema que você deseja, se estiver disponível (eu gostaria de fazer meu próprio repositório git para isso, pois como uso da tese, gostaria de ter uma configuração em branco do repositório git da tese para obter internamente no servidor que já foi criado)

Thomas "@toscho" Scholz escreveu um bom plugin que nos permite usar um subdomínio para lidar com temas fora do diretório WordPress. Você pode encontrá-lo nesta resposta e também nesta . Até atualizações automáticas funcionarão para temas desde o WP 3.6.

Você pode fazer o mesmo com MU-Plugins e Plugins simplesmente configurando as seguintes constantes no seu wp-config.phparquivo:

define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Agora basta colocar todos os seus plugins e temas sob controle de versão e enviá-los para o servidor. Você pode disponibilizá-los facilmente usando mu-plugins ou plug-ins padrão que ativam a rede.

Nr.3, faça o checkout e faça as alterações, as revisões dos clientes, depois de serem ativadas , o script do banco de dados iniciará automaticamente a alteração dos valores de URL serializados de localhost (ou subdomínio) para o URL ativo

Se o script / plugin do Toms não o ajudar até agora, saiba que ele aceita solicitação pull no GitHub .

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):

• Estou clonando o Wordpress no Github (você pode até fazer isso na árvore de origem a partir daqui: tierra / wordpress )

• Em seguida, eu o uso como via mesclagem de subárvore em meus próprios repositórios de sites (eu até atropelo um bug no git, mas a solução está aqui: -X subárvore = ... ).

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:

• Os aliases do git git accept-theirse git accept-theirssão úteis no caso de haver alterações conflitantes na linha de base, você sabe claramente com qual delas prefere lidar. Você encontra aqui: Ferramenta simples para 'aceitar a deles' ou 'aceitar a minha' em um arquivo inteiro usando git
• Olá Dolly. A maldição de uma geração inteira. Você precisa controlá-lo sempre.

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.