Olá, pessoal! Hoje vou falar de um assunto muito comum e recorrente; praticamente essencial para o trabalho em grupo e que facilita muito o versionamento das coisas inseridas em banco de dados: Features e Strongarm.

Features é um módulo fantástico, que nos permite exportar várias coisas configuradas no banco de dados do Drupal, como tipos de conteúdo, campos, entidades, esquema de permissões, entre outras coisas. Podemos fazer uma analogia e dizer que é um módulo para gerar módulos. Basicamente, ele pega informações que estão registradas em banco de dados e coloca em código, na forma de módulo, com a denominação de Feature. Assim, em outra instalação Drupal, podemos instalar essa Feature gerada, que teremos tudo aquilo escrito no código, inserido no banco de dados. O módulo Strongarm é essencial para trabalhar bem com Features, pois permite exportar variáveis definidas em banco de dados para o código gerado por uma Feature, expandindo as possibilidades de geração de Feature, possibilitando também a interação e compatibilidade com outros módulos que guardam informações no banco.

Essa prática possibilita criar pacotes e versões de funcionalidades diversas. Dou exemplo de duas situações:

1. Criação de pacote de funcionalidades

Vamos imaginar que usamos em vários sites a mesma funcionalidade ou um cliente pediu uma nova área no site, neste caso, uma galeria de imagens. Assim, podemos definir que compõem uma funcionalidade de galeria de imagens:

• Tipo de conteúdo “Galeria de Imagens”, com título (title padrão), descrição (body padrão) e imagens (campo múltiplo adicional);
• Dois estilos de imagens (um para miniatura e outro para exibição da imagem ampliada);
• Uma view que lista todas as imagens;
• Imagens ampliadas com modal (lightbox);
• Nível de permissão para dois papéis de usuários (redator e editor).
• Incluir todas as configurações necessárias de exibição.

Todas essas definições podem ser feitas por um site builder, via interface do Drupal, sem precisar programar. Assim, tudo fica gravado em banco de dados. Não vou entrar nos detalhes das configurações, pois o intuito aqui é mostrar como gerar uma Feature, que ao ser instalada, já conterá todas as definições.

Sabendo disso, vamos ver o que acontece na interface de criação de Features:

1. Nome: É o nome da feature, que também será o título do módulo, exibido na administração. Ao preenchê-lo, será dado um nome de máquina, editável, que seguindo as boas práticas de organização, terá um nome diferente do título, determinando o nome do módulo;
2. Descrição: Informação descritiva exibida na administração de módulos. É opcional, mas como boa prática, informo de forma resumida em quê consiste essa feature;
3. Package: O pacote em que a feature se enquadra. O mais comum é levar o nome do projeto em que estou trabalhando, mas também pode levar um nome mais genérico;
4. Versão: É a versão da feature (ou módulo). A cada modificação, vou incrementar o número, para ajudar a ter um controle de versão;
5. URL of update XML: Opcional. Caso eu tenha um XML em algum lugar para atualização da feature, informo aqui;
6. Path to generate feature module: Aqui podemos inserir um caminho informando onde os arquivos da feature serão salvos. Uma boa idéia é usar sites/all/modules/custom/custom_modulename, de acordo as boas práticas. Assim, depois de escolher os componentes da feature, basta clicar no botão ‘Generate feature’, que os arquivos serão gerados no caminho indicado. Nota: É necessário que o diretório de destino tenha permissão de execução e escrita (chmod 777);
7. Opções de comportamento para gerar a feature: Podemos definir alguns comportamentos interessantes, como detectar automaticamente as dependências logo que escolhermos algum componente e não deixar que a feature seja criada caso algum conflito for detectado;
8. Componentes: Aqui é onde escolhemos o que compõe nossa feature. Basta marcar os checkboxes referentes às configurações que queremos exportar em forma de módulo. Assim, tudo que for escolhido, passará de banco de dados para código;
9. Legenda: Indica qual a situação de cada componente selecionado;
10. Link de download da feature: Temos essa opção alternativa. Ao invés de informar o caminho de onde os arquivos serão gravados, podemos fazer download de um arquivo compactado nome-da-feature.tar.

Sabendo disso, as informações para a minha feature ficaram assim:

ATENÇÃO: Nessa feature eu incluí papéis de usuários. Isso não é uma boa prática, visto o tipo de feature e o uso dela. Mas incluí assim mesmo, somente para exemplificar e mostrar que é possível exportar isso em feature. Quando precisamos exportar configurações desse tipo, mais genérica, o mais sensato é criar uma feature de nome abrangente, tipo “Core”, “Nome do projeto” ou coisa parecida. Sabendo das boas práticas, podemos ter mais produtividade e evitar erros ou conflitos. Todos entendidos?

2. Melhorando ou alterando uma funcionalidade

Suponhamos que nós queremos incrementar um pacote de funcionalidades ou um cliente pediu essa incrementação. Pode ser qualquer coisa, mas para facilitar, vamos pensar nessa galeria de imagens. Assim, podemos definir que para incrementar a nossa galeria de imagens, precisamos de:

• Um novo estilo de imagem, para exibição quando estiver visualizando apenas um conteúdo do tipo galeria de imagens;
• Um campo de taxonomia no estilo free tags para que possa categorizar as galerias de imagens.

Sabendo disso, podemos fazer as configurações necessárias que adicionarão os novos requisitos no pacote de funcionalidades. Isso vai ter um comportamento muito interessante, pois quando voltarmos na página de administração das features, veremos a nossa “Galeria de imagens” exibindo o estado “Sobrescrito”. Outra coisa interessante é que, se estiver com o módulo Diff instalado, aparecerá uma nova aba “Review overrides” na visualização da Feature, que ao acessada exibirá exatamente o que foi alterado, nos padrões de Diff comuns, assim:

Claramente, mostra que o que está destacado foi adicionado, pois existe um sinal de mais (+) antes do destaque. Caso fosse removido, exibiria um sinal de menos (-).

Agora podemos recriar a feature, para poder adicionar as novas configurações no código. Vamos seguir o mesmo procedimento, só que ao invés de “criar” uma nova, vamos “recriar” a existente. Assim podemos ver que a Feature insere automaticamente alguns elementos e também podemos inserir os elementos adicionais, conforme visto na imagem acima.

Coisas importantes que devemos saber sobre Features

• O status “padrão” quer dizer que o código da feature e as informações no banco de dados estão iguais, ou seja, está tudo de acordo e nada precisa ser alterado.
• Quando recriamos uma feature, é muito importante alterar (incrementando a numeração) a versão da feature. A criação/recriação de uma feature, tecnicamente, pega as informações que estão em banco de dados e transforma em código.
• Quando instalamos ou revertemos uma feature, estamos pegando tudo que está em código e inserindo no banco de dados. Assim, toda vez que desejamos aplicar as aterações de uma feature, é uma boa prática conferir as diferenças do que está sobrescrito, para saber se precisamos recriar ou reverter uma feature existente.
• Trabalhar com Features é hoje a forma mais viável e segura quando existe desenvolvimento em equipe e também para versionar configurações do banco de dados, apesar de ainda não ser visto como o melhor método.
• Você pode usar o módulo gerado com Features e incrementá-lo, alterando o *.module e criando seus próprios arquivos. No entanto, não deve alterar os arquivos gerados com Features, exceto o *.module.

É isso pessoal! Acredito que abordei as principais questões sobre o uso de Features e como usar. Seguindo essas dicas, certamente terá uma boa experiência. Qualquer coisa, já sabe, né? Deixe um comentário aí!

***

Artigo publicado originalmente em Drupal de Elite: http://drupaldeelite.com.br/blog/exportar-e-versionar-configuracoes-do-banco-de-dados-com-features-e-strongarm