Qual é a melhor estratégia de implantação?

82

Configurar uma loja Magento não é apenas uma questão de desenvolver extensões auto-instaláveis, mas também exige muitas operações de "entrada manual", como criar atributos de edição final, categorias, produtos, páginas CMS de regras de preços e assim por diante, sem mencionar todas as alterações na configuração do sistema.

Gostaria da sua ajuda para delinear a melhor estratégia para implantar uma loja Magento, do desenvolvimento ao ambiente de preparação e produção.

Uma estratégia minha é a de escrever um "módulo de implantação" que crie programaticamente as entidades mencionadas acima, mas é uma tarefa que consome muito tempo e, às vezes, parece-me um pouco exagerado.

Recentemente, comecei a usar o Selenium IDE para reproduzir tarefas de administrador, mas o tempo necessário para configurar todos os conjuntos de testes não está longe do mencionado acima.

Talvez uma solução ideal possa ser o uso de um módulo capaz de fazer uma captura instantânea de um sistema Magento, permitindo que você escolha o que implantar.

Assim:

qual é a sua estratégia para implantar?
existe um módulo capaz de fazer uma captura instantânea de um sistema Magento, permitindo que você escolha o que implantar?
se esse módulo não existir e, desde que seja uma solução razoável, há alguém interessado em contribuir com seu desenvolvimento?

Obrigado!

deploy admin entities

— Alessandro Ronchi
fonte

Isso pode indicar a necessidade de outra tag ou categoria de tag. Você é uma loja pontual ou procura sugestões gerais como prestador de serviços? Nesse último caso, qualquer resposta teria que ser "depende de quanto controle o cliente deseja sobre os dados da entidade".

— benmarks

Meu ponto de vista é o de um desenvolvedor pertencente a uma equipe de desenvolvimento. Suponha que eu esteja desenvolvendo uma seção que precise de alguns dados para funcionar, digamos, uma estrutura de categoria. Crio a estrutura via Admin, faço o código e envio o meu código. Gostaria de saber se a melhor estratégia é também escrever e enviar código que cria a estrutura de categorias necessária. E se minha estrutura ou configurações de categoria entrarem em conflito com as de outros desenvolvedores que desenvolveram suas próprias? Como lidar com conflitos? Esse é meu argumento.

— Alessandro Ronchi 27/01

@AlessandroRonchi Este é um ponto discutível e um conflito que nunca deve acontecer. Sua estrutura de categorias não é algo que deva mudar frivolamente; portanto, um desenvolvedor não deve promover uma grande mudança em sua estrutura, sem que os outros saibam disso. Se isso acontecer, você precisará endereçar sua comunicação entre os desenvolvedores. Geralmente, a estrutura de categorias de um site precisa ser fixada desde o primeiro dia e nunca precisa ser alterada novamente, basta ser adicionada. Se você precisar alterá-lo, não o selecionou corretamente da primeira vez.

— ProxiBlue

@dedmeet infelizmente, no mundo em que conheço e trabalho, as coisas mudam todos os dias; os clientes mudam de idéia, os desenvolvedores mudam de idéia, ocorrem cisnes negros. Eu tenho que estar preparado para mudanças; de qualquer maneira, mesmo que a estrutura da categoria não precise ser alterada desde o primeiro dia, é apenas uma pequena parte da parte inteira e a parte inteira é um projeto de "trabalho em andamento" que deve mudar para que as coisas sejam feitas.

— Alessandro Ronchi 29/01

ok, é verdade que trabalhamos em um ambiente em constante mudança, mas continuo afirmando que um conflito de estrutura de categoria não deve ocorrer. Múltiplas ramificações não devem existir onde cada uma altera a estrutura, isso levará apenas a problemas e perda de tempo de desenvolvimento. Por que o dev é passar um tempo fazendo mudanças na estrutura, enquanto o dev b está fazendo o mesmo, em uma estrutura diferente, e os dois pressionam seu trabalho? Se a estrutura precisar mudar, todos os desenvolvedores envolvidos no projeto deverão estar envolvidos no processo de definição da nova estrutura. Você pode fornecer um exemplo para me ajudar a entender quando isso pode acontecer?

— ProxiBlue

39

Minha opinião é escrever tudo. Normalmente, tenho um módulo de configuração base para qualquer coisa que não esteja diretamente relacionada funcionalmente a um módulo específico. (exemplo, criar reescritas personalizadas de URL para URL anterior do site para nova URL) e adicionar qualquer coisa relacionada a um módulo em seus próprios scripts de instalação.

A mentalidade por trás disso é que, se o site precisar ser reinstalado, usando um novo banco de dados, tudo voltará como você o tinha. Isso também ajuda no fato de eu atualizar periodicamente o site uat com uma cópia do banco de dados ativo. Os módulos no uat continuam trabalhando enquanto encaixam em suas configurações novamente.

Alterações nas taxas de postagem, regras de carrinho etc. (basicamente coisas que os clientes administram a si mesmos em administração) são consideradas 'dados voláteis' e não são roteirizadas. Isso inclui dados do produto. O cliente tem a opção e é incentivado a testar novas importações no site uat primeiro.

Os clientes são instruídos a não criar atributos, mas a criar através de uma solicitação de ticket. Isso então permite que eu também colete informações sobre qual é a intenção do cliente para o atributo e, às vezes, tenho uma sugestão melhor ou posso criar um código melhor, pois mantenho quais atributos existem, além de atributos selecionáveis, para garantir que os dados sejam limpar \ limpo.

Sim, o script leva mais tempo, mas vai demorar muito mais tempo para recriar manualmente um conjunto de configurações manualmente. Também pode ser embaraçoso se você esquecer algo e fazer com que o site não funcione corretamente ou tenha um novo trabalho de desenvolvedor em um site local que esteja com algumas configurações cruciais na configuração.

— ProxiBlue
fonte

1

Eu concordo com dedmeet. Quando você aprende a script de todas as atualizações, pode ser um trabalho mais inicial, mas se você precisar aplicar as atualizações de configuração manualmente para 3-4 desenvolvedores, teste, uat e live, a coordenação e o trabalho real levarão muito mais tempo. Nosso fluxo de trabalho é bastante semelhante: se a configuração for necessária para uma extensão (reutilizável), coloque-a lá. Se a configuração for específica do cliente, coloque-a em uma extensão específica do projeto. Uma das poucas exceções são as regras de carrinho que não são divertidas de atualizar / criar.

— Matthias Zeis 27/01

1

Acabei de lançar um módulo que ajuda a criar o script de configuração necessário, eliminando assim o trabalho comum de ter que criar manualmente os scripts de instalação. O módulo usa uma exibição em grade da tabela core_config_data para permitir a seleção dos valores de configuração a serem exportados. Simplifique minha vida um pouco e espero que funcione para os outros. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue 5/13

27

Eu fiz algumas pesquisas há vários meses. Aqui estão os sites que você pode consultar.

~~URLs base do Magento e instalações de~~
desenvolvimento ~~/ preparação~~ Magento Development and Deployment
Guia Magit Git e fluxo de trabalho
Despejo mais rápido de um banco de dados Magento MySQL para ramificação

— Oğuz Çelikdemir
fonte

1

Obrigado, vou ler todos eles e voltar com algumas considerações.

— Alessandro Ronchi 27/01

Eu li todos os recursos disponíveis; Eu já conhecia alguns deles, outros que não conhecia são muito interessantes. De qualquer forma, nenhum deles é a solução para o meu problema e decidi esboçar uma extensão que tentará atender às minhas necessidades. Obrigado a todos vocês que me deram conselhos preciosos. Espero voltar aqui com alguns resultados.

— Alessandro Ronchi

Caro Alessandro, eu gostaria de ver o seu caminho, que também estou parecendo uma técnica mais confortável!

— Oğuz Çelikdemir

18

Gostaria de agradecer a todos, porque suas considerações me inspiraram e me levaram a desenvolver uma extensão, chamada "Mageploy", com a intenção de resolver o problema de manter diferentes ambientes em sincronia.

http://www.mageploy.com

O Mageploy ainda precisa ser estendido, bem documentado e totalmente testado, mesmo se eu já o estiver usando em alguns projetos com alguns benefícios.

É de código aberto e qualquer ajuda ou sugestão será apreciada.

Saudações

— Alessandro Ronchi
fonte

7

Com relação à instalação de scripts e à criação de entidades, meu sentimento geral é que, se for exigido ou esperado por um módulo, ele deverá ser criado como parte de um script de instalação.

Recentemente, em termos de desenvolvimento / estágio / produção, usamos o site de preparação como a cópia principal do banco de dados para o conteúdo, pois significa que o cliente pode colaborar. No passado, provavelmente o maior problema que encontramos foi coordenar a entrada de conteúdo com o cliente, principalmente no que diz respeito ao upload de produtos.

Como você estava pensando que o instantâneo funcionaria? Eu acho que em um mundo ideal, você teria uma ferramenta que mostrasse a diferença entre dois bancos de dados em tipos específicos (produtos, categorias, CMS, etc.) e permitiria mesclar as alterações entre si, mas não tenho conhecimento de nada disponível como este.

— Paulo
fonte

1

"Com relação à instalação de scripts e à criação de entidades, meu sentimento geral é que, se for exigido ou esperado por um módulo, ele deverá ser criado como parte de um script de instalação". Este é o ponto mais importante a considerar e se aplica às definições de configuração. Meu teste rápido: quando preciso de um novo desenvolvedor para clonar o repositório e instalar o ambiente, o que precisa existir para o sistema funcionar?

— benmarks

Compartilhar um site intermediário com os clientes para colaborar na configuração é ótimo em teoria. Na prática, os clientes não contam tudo o que mudaram 99% das vezes, o que facilita a estragar alguma coisa. Podemos permitir que os clientes trabalhem em itens como regras, categorias, produtos ou similares, mas não permitimos que eles interfiram na configuração.

— Matthias Zeis 27/01

6

Na minha opinião, criar e editar atributos, categorias, produtos, regras de preço não tem nada a ver com uma "estratégia de implantação". Todos esses itens são bastante exclusivos de uma loja e, na maioria dos casos, exigem uma análise e pesquisa adequadas dos produtos que você vão vender.

Se você estiver criando lojas "tamanho único" com configuração semelhante de todos os elementos mencionados, poderá fazer uma exportação "instantânea" do seu banco de dados depois de ter feito toda a configuração necessária para cada loja.

— Rutger
fonte

Não, "tamanho único" não é o ponto; é a mesma situação em que nós, como desenvolvedores, entramos na hora de mesclar nosso código-fonte com o de outro membro da equipe de desenvolvimento: nesse caso, temos sistemas de controle de origem que fazem a mágica. Minha pergunta estava mais relacionada à oportunidade de mesclar coisas "não dev", como definições de configuração e configurações e entradas típicas de administrador.

— Alessandro Ronchi

Ah ok, que o torna mais clara

— Rutger

Digamos que estamos criando um novo site completo, portanto, não há problemas com dados antigos, etc. Quase sempre, todos os nossos desenvolvedores usam o mesmo banco de dados para o desenvolvimento. Isso resolve muitos problemas. Para outros casos, ainda não tenho uma solução melhor do que escrever todas as etapas necessárias em algum tipo de roteiro / script e reaplicá-las após a mesclagem. Se apenas uma pessoa for responsável pelas configurações administrativas do "magento core", elas não deverão ser executadas em várias etapas. Certa vez, encontrei isso, mas nunca tentei tinybrick.com/magento-modules/admin-tools/…

— Rutger

2

Gostaria de adicionar duas excelentes ferramentas de economia de tempo:

Para desenvolvimento: PhpStorm IDE com o plugin Magicento
Para implantação: Magentify , uma receita de Capistrano para Magento

— osondoar
fonte

Obrigado por nos informar sobre o Magentify, eu não sabia e vou tentar. Meu foco, porém, foi mais na sincronização de diferentes ambientes de desenvolvimento do que na implantação no sentido de publicar uma base de código. O Mageploy pode ser integrado ao Magentify, mas é uma ferramenta diferente, usada para manter automaticamente parte de alterações no banco de dados, independentemente dos IDs específicos que são diferentes entre diferentes ambientes. Atenciosamente, Alessandro

— Alessandro Ronchi