Qual é a melhor prática para atualizar o núcleo do Drupal sem interromper o repositório Git e o site de produção

Eu tenho um repositório Git no qual todo o meu código está na ramificação mestre e anteriormente estava ignorando todos os arquivos do Drupal, para manter uma separação estrita entre o código que escrevi (ou modifiquei ou pode modificar) e o código que poderia ser gerado com Drush ou o que seja.

Parecia uma boa estratégia até que eu tive que atualizar o Drupal. Percebi que quero ser capaz de reverter se as coisas correrem mal e que ferramenta melhor usar do que o Git para fazer isso. Pensei comigo mesmo que essa seria a situação perfeita para um ramo de recursos; portanto, criei um drupal-7.14ramo, dando-lhe o direito .gitignorede ignorar todos os meus arquivos de código e configurações e prestando atenção apenas nos arquivos que fazem parte da instalação do Drupal que eu não faria ' Não toque. Fiz uma atualização manualmente (faça o download, descompacte, descompacte, copie), classificando os casos limítrofes como robots.txt e .htaccess e substituindo o .gitignore do Drupal pelos meus. Corrigi algumas configurações que funcionavam com o 7.14, mas não com o 7.15, para recuperar um erro de 500 e, em seguida, tudo parecia perfeito. Renomeei o ramo para drupal-7.15e estava prestes a seguir feliz no meu caminho.

Até que eu percebi o que havia feito inadvertidamente: arquivos que anteriormente não eram rastreados pelo meu ramo mestre, mas deixados no diretório de trabalho, agora eram removidos do diretório de trabalho quando eu fazia o check-out do mestre, já que não eram mais arquivos não rastreados! D'oh!

Se eu mesclar o drupal-7.15ramo com o mestre, perderei a separação do código.

Provavelmente existe uma maneira de converter uma ramificação em um submódulo. Supondo que isso seja possível, essa pode ser a melhor estratégia. Antes de fazer isso, eu sabia que os submódulos eram a solução "certa", mas como não percebi o efeito colateral de usar ramificações para arquivos não rastreados anteriormente, decidi cortar os cantos e seguir esse caminho. (Além disso, todas as abordagens que utilizei nos submódulos com o Drupal assumem que você está iniciando um novo projeto e o Drupal será o ramo principal. É indesejável para mim tornar o código de outra pessoa o ramo principal, e eu já tinha um repositório com uma ramificação mestre. Parecia que seria desnecessariamente complicado apenas fazer uma atualização.)

Pode haver alguma outra solução que eu não tenha pensado.

Como posso me recuperar melhor com o menor número possível de desvantagens?

ATUALIZAÇÃO : Isso está em desenvolvimento (em uma VM Linux no meu laptop) e ainda não foi produzido. No momento em que vamos para a produção, planejo incluir tudo em módulos de recursos, mas isso ainda não está em vigor.

ATUALIZAÇÃO 2 : Sub-módulos podem não funcionar. De acordo com o Pro Git , "Os submódulos permitem manter um repositório Git como um subdiretório de outro repositório Git". Drupal não fornece uma separação tão agradável. Em vez de todo o código Drupal estar em um subdiretório, o relacionamento é mais ou menos invertido, mas ainda não existe uma separação limpa, pois você pode estar editando seu .htaccess e robots.txt, para que seu código e o repositório Drupal sejam misturados. Estou procurando uma solução alternativa para esse problema .

version-control upgrading

— iconoclasta
fonte

Sua pergunta é realmente sobre o git. Acho que você obterá melhores respostas migrando para um site que não é específico do Drupal. Sobre atualizações: eu sempre faço atualizações criando o arquivo make em um novo diretório e atualizo o link simbólico do diretório público antigo para o novo, o que torna as reversões de código triviais.

— Letharion 4/12/12

@ Letharion eu discordo. Todos passarão por esse processo de atualização do site da versão atual para uma nova. O uso do git para atualizar o núcleo é bastante comum, pois esse é um método amplamente usado para atualizar os módulos. Muitas pessoas terão problemas com esse problema, como já tive antes. Atualmente, não existe uma boa documentação na Web que resolva esse problema e acredito que este seja um bom local para isso.

— IStryker

Apenas para esclarecer, acho que uma pergunta sobre "A melhor prática para atualizar o Drupal" seria mais adequada, pois essa pergunta é realmente "Como faço para reparar um erro de git", que acho que não pertence aqui. Não tenha sentimentos fortes sobre o assunto, então deixarei assim. :)

— Letharion

Ok, justo o suficiente. O problema que Brandon tem é bastante comum. Talvez eu deva criar uma nova pergunta ou reescrever esta (e passar o resto para outra pergunta). O primeiro 2-3 parágrafo é comum. Você cria um repositório git de 7.x-1.0 e deseja atualizar para 7.x-1.1. Os arquivos com problemas são .gitignore, .htaccess e robot.txt. Às vezes, você deseja que eles sejam rastreados porque eles são modificados; Ao atualizar o repositório, você cria uma nova ramificação, a mesclagem ou apenas atualiza o mestre. @Letharion Suggestion?

— iStryker 4/12/12

@ Letharion: Pensei em colocar isso no StackOverflow como uma pergunta do Git ou aqui como uma pergunta do Drupal. Se eu colocasse lá, todo mundo reclamaria e diria que isso é realmente sobre o Drupal, e acho que eles realmente estariam certos. Embora o Git possa ser a ferramenta usada para reparar a situação, a direção tomada depende do conhecimento do Drupal. Todo usuário do Drupal usa o Git (ou deveria, se não o fizer), mas apenas uma pequena fração dos usuários do Git usa o Drupal. As pessoas que responderem à pergunta sobre o Git não entenderão o contexto do Drupal.

— iconoclast

Respostas:

Parece da discussão acima que sua pergunta não é sobre como corrigir seu repositório git, mas sobre como manter um site Drupal no git e como isso funciona com as atualizações principais.

Eu acho que a prática padrão é de fato manter todos os arquivos no seu repositório, incluindo o núcleo do Drupal. A separação do código Drupal do código personalizado parece uma boa ideia, mas não acho que seja necessário e não vejo quais vantagens ele oferece. Parece também presumir que você nunca desejará corrigir o núcleo (ou precisará fazê-lo como parte de sua implantação), que, embora não seja uma prática recomendada, é definitivamente algo que você deseja poder fazer se algo quebrar em produção. Manter seus compromissos agradáveis e focados também ajuda a obter esse tipo de separação.

A solução que usei é manter todo o código no mesmo repositório, colocar o máximo possível em Recursos ou outros tipos de exportação / código / configuração e manter uma lista de patches que precisam ser aplicados a -box core e contrib.

Ao atualizar o núcleo, inicie no seu ambiente de desenvolvimento:

Verifique se o diretório de trabalho está limpo
Despejar o banco de dados mais recente ( drush sql-dump). Faça um commit com o despejo ou salve-o em algum lugar seguro.
Atualizar núcleo ( drush up drupal)
Confirme todas as alterações.
Verifique o arquivo de patches. Se algum patch precisar ser aplicado, aplique-o e faça outro commit
Execute update.php, se necessário (já feito, se você usou drush para a atualização)
Teste seu site de desenvolvimento. Se tudo estiver bem, envie o código para produção. Execute drush updbna produção.
Se houver um problema e você precisar reverter, reverta ou redefina seu repositório ( git reset --hard HEAD~2deve fazê-lo) ou reverta as duas confirmações se desejar manter o histórico. Substitua seu banco de dados pelo despejo.

O despejo de banco de dados é necessário porque, caso contrário, não é possível desfazer as alterações feitas no banco de dados por atualizações. Você também pode fazer a atualização em uma ramificação; nesse caso, reverter significa apenas fazer check-out do mestre. É um pouco desaconselhável se você estiver trabalhando em um site de desenvolvimento porque não pode realmente voltar ao master e continuar trabalhando lá em paralelo por causa do banco de dados.

O uso desse fluxo de trabalho mais simples do lado do git permitirá que você use toda a força do git quando necessário, sem a complicação dos submódulos etc. Se isso não parecer adequado, você poderia explicar por que precisa de mais separação de código?

— goron
fonte

Dos meus comentários acima, esta pergunta é sobre como manter os arquivos de um site Drupal com o git e como isso funciona com as atualizações principais. Você não mencionou nada sobre como fazer backup e atualizar o banco de dados. Vou tentar não copiar nada da resposta do goron.

Eu criei uma postagem no blog sobre esse problema Atualizando o núcleo do Drupal no seu site com o Git

Métodos alternativos

Executar comando Drush drush up drupal

Aplique um patch das diferenças entre as versões. Veja http://drupal.org/node/359234 & http://fuerstnet.de/en/drupal-upgrade-easier

Você não declarou isso, mas se estiver interessado em acompanhar as alterações entre as versões do Drupal, eu faria isso usando tags em vez de branches . Depois de concluir a confirmação de atualização para mestre , marque seu código como 7.x.

— iStryker
fonte

Se entendi corretamente, você também está sugerindo que eu mantenha todo o código principal do Drupal no mesmo repositório. Este parece ser o consenso. Estou relutante, mas posso ter que desistir e fazê-lo dessa maneira.

— iconoclast

Sim, tudo em um repositório. Eu tenho módulos, perfis e temas dentro do repositório principal / principal que são seus próprios repositórios git. Eu não sei se o melhor caminho, mas é o melhor caminho que eu conheço.

— IStryker 5/09/12

Esta solução não oferece nenhuma maneira de voltar atrás. minha razão para votar.

— Andre Baumeier 07/02

@Serpiente: Não vejo por que a falta de uma maneira de voltar deve ser uma razão para um voto negativo. Se é a melhor abordagem, basta. Se você não considera a melhor abordagem, indique por que não.

— Iconoclast

@iconoclast, qual é o problema de um sistema de revisão se você não pode voltar na sua linha do tempo? por exemplo, pense em uma atualização com falha - qual seria o caminho para se recuperar aqui? Uma versão enviada do software "qualquer que seja" deve ter dependências claras, incluindo especialmente o núcleo da estrutura. Caso contrário, você pode simplesmente largar seu git e começar a fazer lançamentos de FTP novamente. apenas meus 2 centavos.

— Andre Baumeier

Estou executando a instalação com duas ramificações, assim como o OP: uma ramificação apenas com meu código personalizado e uma ramificação que possui meus arquivos personalizados e principais. Corri para a mesma situação: os arquivos principais ignorados são removidos ao alternar entre ramificações.

Acabei tendo dois diretórios git idênticos: - um para trabalhar no meu código personalizado, com os arquivos principais presentes, mas ignorados, e nunca mudaria para a ramificação "completa" neste diretório - uma para executar mesclagens, para que eu execute a alternância e mesclagem de ramificações somente dentro deste diretório.

A razão pela qual escolhi essa configuração de duas filiais é porque desejo rastrear facilmente todas as confirmações locais nos arquivos principais; é mais fácil examinar e reaplicar os mods principais ao atualizar os arquivos principais.

— sillyxone
fonte