Sitecore 7.5 e MongoDB em diferentes ambientes

Jan Löwgren, outro consultor Sitecore, em resposta ao meu post “Ambientes Sitecore para Dev, QA, UAT e Produção“, disse que seria interessante falar um pouco sobre como trabalhar com o MongoDB em diferentes ambientes. Estávamos, no projeto que estou trabalhando atualmente, fazendo o upgrade do Sitecore de 7.2 para 7.5, então a oportunidade de conhecer mais sobre o MongoDB era a desculpa que eu estava esperando para voluntariar-me à tarefa.

Acreditando em meus instintos

Minha primeira ideia antes de botar a mão na massa era tratar o MongoDB como normalmente trataríamos qualquer outro servidores de banco de dados: cada desenvolvedor teria uma instância local de MongoDB em suas máquinas.

Antes do Sitecore 7.5

Falando um pouco sobre o contexto do projeto, a configuração de nosso ambiente era muito similar ao que descrevi em meu primeiro artigo:

  1. Desenvolvedores backend e frontend trabalham em suas máquinas locais, com cópias da solução e bancos de dados – cada um com seu set de bancos “master”, “core” e “web”. O TDS é usado para sincronizar dados com o time;
  2. Temos uma instância de Sitecore para Integração (CI), periodicamente atualizada por nosso servidor TeamCity a cada mudança no build;
  3. Temos também uma instância de Sitecore para QA (qualidade), atualizada pelo TeamCity ao ter o deploy evocado pelo time de QA;
  4. A última instância é o servidor de UAT (teste de aceitação do usuário), também atualizada pelo TeamCity ao ter o deploy disparado por alguém com este privilégio (geralmente o Project Owner, a partir de um pedido do cliente);

Solução

O setup final acabou ficando muito similar ao meu primeiro pensamento. Faz sentido se você pensar que o MongoDB nada mais é do que um servidor normal de banco de dados. No Sitecore 7.5, o MongoDB armazena os dados de navegação do usuário, então podemos com segurança ter bancos separados para cada instância de Sitecore (Dev, CI, QA e UAT).

Instalação do MongoDB

Já que cada desenvolvedor precisa de um servidor MongoDB, eles terão que instalá-lo em suas máquinas e acessá-lo usando seu “localhost”. Esta operação, muito fácil, pode ser feito seguindo os passos deste artigo (Sitecore e xDB – Configurando o MongoDB na máquina do desenvolvedor).

É assim que ficariam as ConnectionStrings do desenvolvedor:

<add name=”analytics” connectionString=”mongodb://localhost/dotz_analytics” />
<add name=”tracking.live” connectionString=”mongodb://localhost/dotz_tracking_live” />
<add name=”tracking.history” connectionString=”mongodb://localhost/dotz_tracking_history” />

Inicializando o servidor MongoDB

O MongoDB não é um serviço que pode ser instalado no Windows – você precisa carregá-lo manualmente – então é recomendável ter um arquivo batch em seu menu iniciar para inicializar a instância de desenvolvimento.

Menu Iniciar do Windows com um link parao Batch que inicializa o MongoDB

Seu batch poderia conter o seguinte:

“C:\Program Files\MongoDB\Server\3.0\bin\mongod.exe” –dbpath “D:\MongoDB”

  • O primeiro caminho depende de onde seu MongoDB está instalado
  • O segundo caminho é onde o MongoDB cria os arquivos para gerenciar as bases de dados

E os servidores de CI, QA e UAT?

No servidor de CI, a instalação é basicamente a mesma, a única diferença em nosso caso é que optamos por centralizar o servidor de MongoDB, com conjuntos separados de bancos para cada instância de Sitecore (CI, QA e UAT).

Publicado em Continuous Integration, Environments, TDS, Team City

Leave a Reply

Your email address will not be published. Required fields are marked *

*

  Am Not Spammer

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>