Qual é o fluxo de trabalho sugerido para a migração (CMI) da configuração dev -> stage -> production?

41

Tivemos um drupalcamp há alguns meses e alguém perguntou sobre o gerenciamento de implantações com o novo sistema de configuração (CMI). Um possível fluxo de trabalho ideal envolveria manter a configuração no controle de versão e ainda poder migrar a configuração entre os membros da equipe.

O melhor que pudemos descobrir na sala (parcialmente baseado na apresentação na DrupalCon Portland) foi:

Diga ao controle de versão para ignorar o diretório de configuração ativo.
Copie toda a Configuração para o diretório intermediário e confirme com o controle de versão.

E use o settings.php para reverter o diretório ativo / intermediário entre os 2 ambientes. No entanto, enquanto descobrir um fluxo de trabalho de implantação de um servidor para o outro era complexo, mas viável, qual é o fluxo de trabalho sugerido de vários ambientes locais (por exemplo, vários desenvolvedores) para dev (ou entre si) - um possível problema seria todo membro da equipe estaria compartilhando o mesmo ambiente ou semelhante; então, como ocorrem as alterações na máquina de um colega de equipe?

migration 8 version-control

— btmash
fonte

5

Eu realmente não concordo com os votos próximos atuais. Como o CMI é o foco do Drupal 8, acho que podemos ter boas respostas aqui.

— mpdonadio

3

Concordado, esta é a pergunta muito boa. Acredito que a tarefa crítica drupal.org/node/1703168 é sobre esse e outros tópicos e ainda não foi completamente resolvida, portanto, as respostas aqui podem ajudar a impulsionar esse problema.

— precisa saber é o seguinte

Peço desculpas se minha pergunta foi negativa em relação à iniciativa CMI (que não era minha intenção). Atualizei a pergunta para que pareça mais neutra.

— precisa saber é

2

eu quase diria "Você já tentou recursos". Talvez o "D8" deva aparecer no título da pergunta? A tag "8" é um pouco invisível.

— Donquixote

1

Revisto a título de modo questão pode ser visto tanto por tag ou através título :)

— btmash

19

Depois de conversar um pouco com os mantenedores do CMI, a discussão sobre qual é a melhor abordagem não está concluída, mas a seguir é o que faz mais sentido no momento.

Tentar manter a concisão por enquanto, tentará expandir com base em perguntas / quando o problema mencionado for resolvido com uma resposta oficial.

Então, primeiro, os fatos ...

Como já mencionado, há o diretório ativo e intermediário. O Active é totalmente gerenciado pelo Drupal, não sendo suportado fazer alterações diretamente (diretas ou indiretas, alternando para um local diferente).
A preparação é onde o Drupal procura a configuração para importar e, caso contrário, não se importa com isso.
O processo de importação é importante, as alterações na configuração podem afetar um site de uma certa maneira e precisam ser verificadas quanto à validade. Você não pode alterar o tipo de campo de um campo de texto para uma referência de entidade, por exemplo, que simplesmente não funciona.
A importação da configuração sempre precisa ser executada em toda a configuração; você não pode importar uma única visualização ou tipo de nó. Foi tentado, mas tentar lidar com dependências, remover / renomear e assim por diante resultou em um sistema muito complicado e não funcionou.
A única maneira de reinstalar a configuração padrão é reinstalar esse módulo. O que significa que ele tentaria primeiro remover todas as configurações (como campos). Portanto, isso não é realmente uma opção. Manual, mudanças específicas nas funções de atualização são possíveis, mas muito tediosas para isso, eu acho.
Como o módulo de recursos descreve, ele se concentrará em fornecer funcionalidades reutilizáveis, não implantações contínuas de configuração. Foi para isso que ele foi projetado, em primeiro lugar.

Dado isso, a recomendação agora é colocar o diretório temporário no controle de versão. Cada desenvolvedor tem controle total sobre o que ele coloca lá, copiando todo o diretório ativo ou apenas um arquivo de configuração específico. As alterações no diretório temporário são confirmadas, enviadas para produção e a importação da configuração é executada (na interface do usuário ou com drush).

— Berdir
fonte

O diretório de teste no controle de versão, eu entendo essa parte. As outras partes são o que minha mente está tentando processar. Portanto, se alguém fizer uma alteração, copie as alterações para o diretório intermediário e o confirme. Após esse ponto, os outros desenvolvedores / próximo servidor obtêm as alterações e os sincronizam com o diretório ativo. E lave e repita para qualquer outra cadeia de servidores ao longo do caminho (preparo, produção, etc.). E ele sempre passa pelo preparo para que não haja mais troca de diretório. Isso seria preciso?

— precisa saber é

Sim. Não deve haver alternância de diretório. Toda alteração na configuração deve passar pelo processo de importação ou você pode acabar com o site danificado. Por exemplo, a lista de módulos também é de configuração. A implantação significa que os módulos precisam ser instalados / desinstalados (Nota: isso ainda não funciona, mas há um problema para corrigi-lo).

— precisa saber é o seguinte

Ok, então ainda há mais perguntas (divididas em 2 comentários) :) Primeiro, você menciona que os módulos são de configuração. Portanto, mesmo que um módulo seja adicionado a um repositório e não esteja ativado / desativado, ele precisa ser instalado / desinstalado por apenas ficar sentado lá?

— precisa saber é o seguinte

E o seguinte: (A) Haverá um mecanismo para copiar as alterações do diretório ativo -> estadiamento (para simplificar versus uma pessoa acessando o diretório de configuração desses componentes - possivelmente uma maneira de escolher determinadas variáveis). (B) O diretório de armazenamento temporário é esvaziado depois que as alterações são sincronizadas do armazenamento temporário -> ativo? (B1) Se sim, então a estratégia do ponto de vista dos devops é redefinir esse diretório antes de um git pull? (B2) Caso contrário, é correto supor que, embora ocorra o teste-> sincronização ativa, não haja nenhum efeito na configuração que não tenha sido alterado?

— precisa saber é o seguinte

O status de instalação do módulo é configuração. Não é o módulo em si :) É isso que você implanta. a) Existe uma interface do usuário para baixar um tar.gz do diretório ativo, uma para carregar o tar.gz no diretório intermediário e outra para realmente importar, com visão geral e diferenças das alterações. B) Eu acredito que agora ele está vazio, mas eu suponho que você pode reverter isso facilmente com o git. Não tenho certeza, é fácil de verificar. Todas essas coisas são conectáveis, portanto, pode haver uma implementação ligeiramente diferente que não exclua. B2) Eu não entendi, mas acho que sim.

— Berdir

4

Great respondeu até agora. Obrigado a todos!

Iniciamos um projeto Drupal 8 recentemente e implementamos o seguinte fluxo de trabalho.

Temos três pastas ativas, preparadas e exportadas. Os desenvolvedores despejam seus para exportar. Eu não quero mantê-lo no palco. Eu acho que é mais fácil trabalhar quando a configuração compartilhada não é armazenada diretamente na pasta de teste. É apenas um sentimento que não tenho fatos concretos sobre isso ...

Nosso modelo de projeto atual do drupal 8 está disponível no github. Também escrevi alguns comandos úteis de drush para acelerar o fluxo de trabalho do devleoper. Nenhuma cópia manual do ativo para a exportação é necessária.

Modelo de projeto: https://github.com/webflo/d8-project-template
Comandos Drush adicionais: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
fonte

1

Até agora, eu concordo com essa abordagem. Eu adicionei todos os recursos dos links neste post aos comandos config-export e config-import do Drush. Espero que outras pessoas se juntem a mim e à @florian na exploração desta solução de 3 diretórios.

— Moshe weitzman

Como você lida com a sites/default/files/config_HASHpasta de configuração com um sufixo de hash, por exemplo, config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow É possível substituir o local dessas pastas. Basta procurar por "Localização dos arquivos de configuração do site". em settings.php eu uso o seguinte trecho. Isso significa que a configuração é armazenada fora do diretório raiz do Drupals. $ config_directories = array ('ativo' => '../config/active', 'staging' => '../config/staging',);

— Webflo

Obrigado @webflo eu vi isso. Qual seria o benefício de gerenciar uma base de código e uma configuração separadamente? Eu acho que essa separação é um pouco artificial, pois o código e a configuração (no yaml) determinam o comportamento e dependem um do outro. No Drupal 7, a configuração em código (ou rastreável pelo Git) foi feita com o módulo Features, criando um módulo para cada configuração específica que precisava ser rastreada no código. No Drupal 8, há o Features 3.x que, como eu o entendo, faz o mesmo, mas usa o YAML para armazenar a configuração e os módulos gerados não dependem do módulo de Features.

— Therobyouknow 19/06

Acho que você me entendeu mal, o diretório de configuração ainda está no git, mas meu site Drupal não está na raiz do repositório git. O site é armazenado / web. Portanto, / config e / web estão no mesmo nível.

— Webflo

2

Ainda não tentei isso, mas meu plano é criar um módulo personalizado que contenha arquivos de configuração "padrão" que contenham apenas a configuração que me interessa. Acredito que outros módulos podem conter configurações que substituem outros módulos. (Caso contrário, isso deve ser possível).

Eu acho que você deve deixar a pasta de configuração em paz. Ignore isto. É gerado automaticamente na instalação a partir de todos os arquivos de configuração dos módulos individuais. O caminho é longo e aleatório. Se você mantivesse tudo isso em um repositório, você precisaria de um repositório separado e levaria consigo vários arquivos de configuração padrão e desnecessários.

Colocar a configuração em um módulo personalizado faz parte da sua principal base de código.

O processo de implantação seria:

Git pull ou o que for para obter novos arquivos.
Limpar caches.
Redefina a configuração padrão. (Dos arquivos do seu módulo personalizado)

Você pode criar módulos personalizados (com sua própria configuração) para cada ambiente, se desejar.

— jonpugh
fonte

Isso soa muito como recursos, não é? Ou há uma diferença significativa que estou perdendo?

— Letharion

É uma abordagem interessante e eu gosto da ideia. No entanto, uma das maiores vantagens mencionadas como parte da iniciativa CMI é a capacidade de mover a configuração dos diretórios de configuração. E pelo que vejo, o arquivo settings.php permite que você determine onde estão os diretórios ativo / intermediário (ou seja, eles não precisam ser caminhos gerados automaticamente). Portanto, acho que um fluxo de trabalho com a configuração atual deve ser possível sem a necessidade de criar um recurso como o @Letharion menciona acima.

— precisa saber é

2

Nota: Compreendo que essa não seja uma resposta no sentido mais estrito em relação à pergunta, mas eu a coloquei aqui de qualquer maneira e revisitarei e edite / exclua uma vez que o Features tenha uma versão 8.x e a poeira tenha resolvido um pouco mais. Isso era muito grande para um comentário e eu queria receber meus 0,02 € em :-)

Como um grande fã de recursos , sugiro ficar de olho na encarnação D8 do módulo de recursos .

Retirado da página do projeto

A versão 3.x dos Recursos está planejada para que o Drupal 8 se integre ao novo sistema de gerenciamento de configurações. Se você simplesmente precisar exportar uma configuração simples do site, o sistema de gerenciamento de configuração D8 deve ser usado em vez de Recursos. Você usará os Recursos no D8 para exportar a funcionalidade incorporada (como um "recurso de galeria de fotos").

A maneira que eu meio que vejo é que essa idéia faz com que seja mais fácil para dev equipes para trabalhar em partes menores de um site. Ainda não vou entrar em um fluxo de trabalho, pois ainda há muitas variáveis desconhecidas, mas não vejo isso muito diferente de um procedimento de implantação de recursos atual.

Não posso deixar de pensar que sim, o CMI é incrível; mas a maioria dos meus sites ainda terminará com módulos de recursos (embora uma quantidade menor por não ter que exportar TODOS os tipos de conteúdo, permissões etc.)

— Chapabu
fonte

Embora eu concorde que os recursos mudarão levemente sua função e (espero) ser a ferramenta para agrupar componentes de configuração (como o recurso da galeria de fotos que você mencionou), a configuração (tanto quanto eu entendo) ainda será mantida pelo ativo diretório de configuração. Portanto, os recursos podem resolver um determinado componente, mas como o fluxo de trabalho do diretório de configuração é gerenciado nos ambientes é o problema real. O procedimento de implantação é um pouco diferente do procedimento de implantação de recursos atual, principalmente porque os dados do armazenamento ativo estão no banco de dados e o armazenamento de dados é arquivos.

— precisa saber é

... o procedimento de implantação de recursos do d7 envolve dados do armazenamento ativo no banco de dados e armazenamento de dados em arquivos. Estamos mudando para ambos os arquivos e precisamos apenas garantir como isso afeta uma mudança no fluxo de trabalho.

— precisa saber é

Observe que os recursos realmente não têm o conceito de ativo e armazenamento de dados / armazenamento temporário. Ou pelo menos não consistente, tudo depende do gancho específico / coisa com a qual ele se integra. As visualizações padrão vivem em código, por exemplo, as alterações são ativadas imediatamente (além do armazenamento em cache), não há processo de implantação controlado com recursos. Esse sempre foi um dos principais problemas ao usar recursos para implantações.

— Berdir

Você está certo. Não sei como misturei o módulo de configuração do D7 com os Recursos, mas o fiz.

— precisa saber é o seguinte