Como remover corretamente um módulo em um ambiente intermediário?


17

Alguns módulos possuem rotinas de desinstalação. Que normalmente remove as tabelas de dados para esse módulo, variáveis ​​da tabela de variáveis ​​e códigos de idioma introduzidos por esse módulo. Essas rotinas residem no .installmódulo.

Portanto, eles não podem ser executados sem a presença desse módulo. Então, aqui estão nossas etapas atuais. Minha pergunta é: isso pode ser feito de maneira mais simples e eficaz? Digamos que eu remova o módulo foo_bar.

  1. No RCS, prepare um novo release, onde:
    • Todas as substituições de css e temas usadas ou construídas em cima de foo_bar são removidas.
    • Todas as substituições de css e tema dos módulos, dependendo de foo_bar, são removidas.
  2. Empurre esse release para aceitação. Teste a desinstalação (de admin / modules) com uma cópia muito recente do banco de dados de produção.
  3. Se tudo der certo, implante a nova base de código na produção e desinstale o foo_bar e suas dependências. Isso invocará a desinstalação nos vários módulos, limpando o banco de dados.
  4. No RCS (git), prepare um novo release em que o código seja realmente removido.
  5. Implante isso para aceitação, onde testamos se nada dependia acidentalmente disso (alguns módulos ou funções temáticas feios incluem arquivos diretamente de outros módulos. Mais notavelmente CSS, JS ou arquivos de imagem).
  6. Se aceito, implante um novo release na produção. a produção agora tem um banco de dados limpo e uma base de código limpa .

O problema que não consigo ver como resolver é que isso sempre precisa de dois lançamentos. Como no Drupal, uma versão requer que o site esteja offline, isso significa duas vezes o tempo de inatividade apenas para remover um módulo. Também requer dois procedimentos de liberação que, em ambientes de hospedagem profissional, podem ser muito caros, demorados ou frustrantes.

Se removermos o módulo da base de código na primeira iteração, não poderemos executar os ganchos de desinstalação, mantendo muitos fiapos no banco de dados; não apenas algumas tabelas, mas principalmente variáveis ​​e localidades. Se não removermos o módulo da base de código, isso significa que ela crescerá com código antigo e não utilizado; isso não gera sobrecarga de desempenho, mas torna a manutenção do código cada vez mais difícil.

Como você lida com isso?

[editar: nota adicional sobre a implantação ser um procedimento difícil, geralmente]


2
Se você executar as etapas 1 a 6 em um servidor intermediário, não poderá atualizar o site ao vivo para HEAD ^, desinstalar e atualizar para HEAD (tudo em uma sessão)?
Andy

Se todos os meus projetos foram implantados em git, então sim. Mas alguns precisam de tarballs para serem enviados por correio, enquanto outros usam (somente!) Ftp e assim por diante. Mas olhar para o git e alguns scripts git-hook é certamente uma ideia muito interessante.
berkes

Por que exatamente é necessário derrubar o site?
Letharion

@ Letharion: 1) Desativar o site proíbe gravações indesejadas no banco de dados durante o processo de alteração desse banco de dados; Drupal não usa Transações. 2) A implantação de um novo código que depende de determinado estado do banco de dados (um tema que requer um determinado campo cck, por exemplo) interromperá seu site no tempo entre o lançamento do código e a atualização do banco de dados.
Berkes

Respostas:


7

Tenha muito cuidado em manter seu banco de dados e código sincronizados; como você mencionou na sua pergunta, os módulos a serem desinstalados precisam permanecer na base de código até que seus ganchos de desinstalação sejam executados no banco de dados ativo. Essa é uma limitação do Drupal que um fluxo de trabalho com git pull sozinho não resolverá.

Eu recomendaria que, em vez de tentar ajustar seu processo, procure maneiras de reduzir o tempo de inatividade necessário para processar suas atualizações. Eu recomendaria a configuração de um ambiente de armazenamento temporário multissite ying / yang para resolver esse problema. nb eu não usei os scripts contidos no link anterior; convém configurar as coisas de maneira diferente, seguindo a mesma idéia de que você pode trocar seus sites ao vivo e de palco durante a implantação.

Continue seguindo o mesmo procedimento descrito na sua pergunta com os seguintes ajustes:

uma. Sincronize do dev para o estágio (yang), como de costume. Teste fazendo uma desinstalação dos módulos a serem removidos, seguida pela remoção do código, etc. Notas sobre o fluxo de trabalho do Git: crie uma tag ou observe o hashid dos diferentes estados do seu código: todos os módulos em vigor antes da desinstalação, substituições & c. removido etc., conforme necessário. Talvez apenas duas referências sejam necessárias.

b. Quando o teste for concluído e aceito, restaure o código no palco (yang) para o estado de vida (ying).

c. Prepare o site ativo (ying) para atualização, desativando a capacidade de qualquer usuário de alterar o conteúdo do sistema. Uma atualização sql para a tabela de permissões geralmente é feita aqui. Nesse momento, os usuários ainda poderão ler o conteúdo no site ativo, mas receberão um erro de permissão negada se tentarem atualizar o conteúdo. (Se você é legal, talvez possa alterar o manipulador de permissão negada para imprimir um aviso apropriado de que a função está temporariamente indisponível).

d. Agora empurre o banco de dados ativo (ying) de volta ao banco de dados de estágio (yang), excluindo a tabela de permissões da atualização.

e Repita a etapa a. novamente. Se você tem suas hashtags à mão, deve ser fácil restaurar para o estado em que os módulos a serem removidos existem, executar os ganchos de desinstalação no banco de dados e voltar ao estado do código em que os itens da etapa 1 são mesclados de volta.

f. Agora você está pronto para trocar ying e yang. Faça isso ajustando suas diretrizes de configuração do Apache. Observe que, se você fizer um /etc/init.d/apache restart, algumas conexões poderão ser interrompidas, mas /etc/init.d/apache reloadpermitirão uma troca limpa.

g. Live agora é 'yang'; a tabela de permissões não é modificada aqui, para que os usuários possam criar conteúdo. Se você automatizar as etapas e. e f., o tempo indisponível deve ser muito baixo.

h. Empurre ao vivo (yang) de volta ao estágio (ying), código e banco de dados - ou empurre a partir do dev, conforme necessário. Agora você tem um ambiente limpo pronto para sua próxima iteração.


Ying-Yang falha terrivelmente no passo c. Somente sites muito específicos, como o editorial-anon-access-only, funcionarão. Isso ocorre principalmente porque não apenas os comentários, nós e outros itens devem ser desativados, mas a tabela de sessões, o watchdog, os contadores etc. serão atualizados e gravados. O tempo de inatividade parece um efeito colateral infeliz, mas inevitável. Embora, de fato, em certos sites, o ying-yang seja um conceito muito interessante para usar na implantação.
Berkes

Claro que você está correto; no entanto, se você criar o script da etapa final, a janela de tempo de inatividade ou perda de informações será baixa. Se você perder uma entrada da tabela de sessões, o usuário precisará efetuar login novamente. Um contador pode sair um pouco. Você pode perder uma ou duas notificações no watchdog. Se isso for pior do que um curto período de "este site está em manutenção", use a solução mais simples. Se você realmente quisesse, poderia tentar recuperar as mensagens do contador e do watchdog após a troca. Isso pode ser mais complicado do que valeu a pena, a menos que informações e tempo de atividade sejam MUITO valiosos.
Greg_1_anderson

Você pode considerar acompanhar as transações no site de transição usando o log binário do mysql. Consulte dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html . Eu ficaria relutante em mesclar as coisas, mas você poderia acompanhar as mensagens extras do contador / fiscalizador fora da banda. A maneira mais fácil de lidar com a tabela de sessões seria também desabilitar logins durante a transição.
greg_1_anderson

Seu comentário me levou a uma possível outra solução: agregue todos os hook_uninstall's de um módulo como hook_update_n () s de um módulo específico: uninstall.module. Dessa forma, posso remover a base de código na primeira iteração / e / obter uma desinstalação muito mais rápida na versão real. Pode ser um script drush que raspe essas informações.
Berkes

1
Mais uma coisa que ajudará um pouco. Altere todo o seu código php personalizado para que qualquer referência ao módulo a ser removido seja incluída if (module_exists('removeme')) { ... }. Implante esse código. Se você testar e confirmar que a remoção do módulo não quebra mais seu código personalizado, isso simplifica sua implantação. Ainda é aconselhável executar a etapa de desativação em um site que não esteja ativo, mas talvez isso restrinja sua janela um pouco. Não acho que seu gancho de atualização personalizado torne mais seguro desativar um módulo ativo.
greg_1_anderson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.