Olá pessoal,
Há alguns dias atrás, perguntaram sobre estratégias para trabalhar com projetos de Dynamics.
Bem longe de ser uma pergunta que tenha uma resposta certa ou apenas que tenha uma única resposta. Aqui vai este post com algumas ideias/dicas para cada tipo de projeto (pequeno, intermediário/médio e grande), baseado nas minhas experiências ao longo desses 10 anos de Dynamics que podem ser úteis à VOCÊ!
Como eu disse anteriormente, a forma de categorização de cada tipo de projeto é algo que pode variar bem de organização para organização, além de não ser uma “receita de bolo” que sempre seja possível aplicá-la em todos os cenários, minha ideia neste post é dizer o que já fizemos por onde trabalhei/trabalho.
Antes de aprofundar em cada modelo de trabalho, é necessário de alguma forma padronizar os tipos de projeto. Embora muitas pessoas acreditem que a quantidade de membros da equipe é o fator decisório para aplicarmos o modelo de projeto ideal, por experiência pessoal, descobri que não pode ser o único fator. Assim, o tamanho das equipes devem unir-se a outros dois fatores: concorrência de recursos do Dynamics e grau de complexidade.
Costumamos considerar como equipes pequenas, times de 2 à 5 pessoas, equipes intermediárias/médias de 5 à 10 pessoas e grandes equipes, acima de 10 pessoas. Não usem os números acima como uma regra máxima, e sim como uma base para iniciar a estruturar suas ideias.
A necessidade de utilização dos mesmos recursos do Dynamics por mais do que uma pessoa, é algo em que o Dynamics possibilita nativamente, mas por não bloquear a edição simultânea, acaba abrindo a possibilidade de que uma pessoa interfira no trabalhado da outra.
Um de muitos exemplos sobre isso, seria quando uma pessoa precisa adicionar novos campos na entidade Conta e outra pessoa está criando outros campos no mesmo período, com isso existe uma boa chance de um “atrapalhar o outro”. Por exemplo:
A pessoa A, abre o formulário primeiro, a pessoa B abre o mesmo formulário segundos depois. A pessoa A cria alguns novos campos e adiciona no formulário, salvando e publicando, quando a pessoa B concluir sua tarefa irá acidentalmente remover todos os campos que a pessoa A adicionou no formulário.
Assim, a chances de um projeto de pequeno porte presenciar o exemplo acima é de certa forma baixa, já que é mais fácil evitar a ocorrência – mas não é impossível de ocorrer. Por outro lado, em projetos maiores existe a tendência de presenciar este cenário com mais frequencia.
Para determinarmos o grau de complexidade, é importante notarmos a necessidade de múltiplas fases/módulos de projeto ao mesmo tempo. Por exemplo: um projeto simples é aquele onde temos a equipe inteira trabalhando na mesma fase; um intermediário/médio, 2 pessoas podem estar trabalhando na versão 2.0 e outras 6 dando uma manutenção na versão 1.0; já em um complexo, temos a mesma situação de uma equipe média e ainda dentro da mesma versão temos duas ou mais equipes trabalhando em módulos diferentes.
Bom com a base no raciocínio acima, vamos ao que interessa…
Projetos de pequeno porte
Projetos de pequeno porte podem ser descritos como aqueles onde a equipe é pequena, não existe a necessidade de múltiplas pessoas estarem trabalhando com o mesmo recurso do Dynamics simultaneamente e quando o projeto possui uma única versão e fase/módulo em andamento ao mesmo tempo.
Na minha opinião, existem duas maneiras de trabalhar em projetos de pequeno porte:
- Única organização de Dynamics com múltiplas pessoas customizando/extendendo ao mesmo tempo, centralização do código fonte para a distribuição (deploy) nos demais ambientes (teste, homologação, produção)
No procedimento acima, em um único ambiente de desenvolvimento é possível ter múltiplas pessoas customizando e extendendo o Dynamics ao mesmo tempo. Já as customizações/extensões são utilizados de forma compartilhada, assim, temos as mudanças em um repositório central para que as distribuições (deploys) no demais ambientes (teste, homologação, produção) sejam extraídas.
Acredito que este seja a opção mais utilizada pela maioria dos projetos, porém ela possui uma série de problemas, quando o projeto não é de pequeno porte, tais como:
- Os funcionais/desenvolvedores, podem sobrescrever o trabalho um do outro;
- Entidades e atributos comummente são criados com nomes diferentes, tipo de dados diferentes, alterados e excluídos erroneamente;
- Quando desenvolvedores estão criando/depurando seus códigos, geralmente impedem de que os demais possam utilizar o mesmo recurso, em alguns casos um ou mais processos de negócio pode ficar indisponíveis neste período ou pararem de funcionar devido a um bug introduzido no desenvolvimento;
- Se estamos criando a documentação em tempo de projeto, será uma tarefa muito árdua de mante-la atualizada devido ao descontrole das mudanças;
Uma observação importante é que muitas pessoas pensam que apenas as extensões (web resource, plugins, workflows customizados) devem ser mantidas pelo repositório de código, assim, costumam adicionar apenas as soluções do Dynamics no repositório. Porém as customizações (entidades, atributos, processos, etc) podem e devem ser mantidas também no repositório, ferramentas com o Package Deployer e Solution Package ajudam nessa tarefa.
- Única organização de Dynamics com múltiplas pessoas extendendo ao mesmo tempo, porém apenas uma única pessoa (gatekeeper) irá customizar (entidades, atributos, relacionamentos, processos, direitos de acesso, dashboards, views e etc). Centralização do código fonte para a deploy nos demais ambientes
Acima temos um único ambiente de desenvolvimento com múltiplas pessoas extendendo o Dynamics ao mesmo, porém apenas uma única, o gatekeeper que customiza, deste modo, não temos alguns dos problemas citados na opção anterior. As demais etapas são as mesmas da opção anterior, com o código fonte compartilhado e centralizado, sendo utilizado para a distribuições nos demais ambientes.
Assim o gatekeeper resolve o problema de múltiplas pessoas estarem customizando o Dynamics ao mesmo tempo, porém a concorrência de recursos de extensão continua sendo um problema.
Projetos de médio porte
Projetos de médio porte são aqueles em que a equipe possui mais do que cinco membros, ou equipes pequenas mas que necessitam de múltiplas pessoas trabalhando com o mesmo recurso do Dynamics simultaneamente ou ainda quando o projeto possui mais do que uma única versão ou fase/módulo em andamento ao mesmo tempo.
Assim como os projetos de pequeno porte, acredito que existam duas formas de trabalho:
- Múltiplas organizações de Dynamics, onde cada membro da equipe possui a sua individual organização ou máquina virtual, podendo customizar/extender. O código fonte é centralizado para o deploy, porém, um gatekeeper irá consolidar todo o trabalho dos membros da equipe em um CRM central (master), realizando uma sequencia de testes para avaliar se nenhuma customizações ou extensão impede que as demais funcionem.
Quando o resultado dos testes é atendido, todas as organizações devem receber a última versão do CRM Central. Esta atividade pode ser executada de diversas formas, manualmente ou automaticamente, mas neste post não irei aprofundar neste assunto. Nesta opção é essencial o uso de Solution Packages!
Todos os problemas que não são resolvidos com o modelo para projetos de pequeno porte são solucionados com este modelo, devido a cada membro da equipe possuir seu ambiente individual. Não existe mais o problema de sobrescrever algo que outra pessoa fez ou ainda quando múltiplas pessoas precisam editar o mesmo componente.
O único ponto negativo neste cenário é a chance das customizações publicadas no repositório não funcionarem adequadamente quando promovidas para o CRM central, principalmente quando precisamos alterar o tipo de dado de um atributo, onde excluímos e recriamos com o novo tipo de dados. Se o CRM central já possuir este atributo com o tipo de dado anterior, a solução não poderá ser importada.
Deste modo, alguns tipos de controle de deploy precisam ser adicionados para garantir a qualidade das soluções, assim, quanto mais controles são adicionados, maior é tempo requerido para manter o modelo operando.
- Múltiplas organizações de Dynamics, onde cada membro da equipe possui sua organização ou máquina virtual individual, podendo apenas extender o Dynamics. O gatekeeper é o responsável pelas atividades de customização. As demais etapas são as mesmas da opção anterior, como o código centralizado para o deploy, consolidação do trabalho pelo gatekeeper no CRM central e propagação do CRM central para todos os membros da equipe
O modelo acima é o mais preparado para alto índice de customizações e extensões, e que possui um forte sistema de consolidação e distribuição. Além disso, por termos o gatekeeper como o único responsável por realizar as customizações, as chances de problemas com a solução no repositório diminuem drasticamente, reduzindo o tempo para manter o modelo de projeto.
Projetos de grande porte
Projetos de grande porte são aqueles em que a equipe possui muitos membros (mais do que dez membros), ou equipes pequenas e intermediárias mas que necessitam de múltiplas pessoas trabalhando com o mesmo recurso do Dynamics simultaneamente ou ainda, quando o projeto possui mais do que uma versão e fase/módulo em andamento ao mesmo tempo.
Para projetos de grande porte a boa novidade é que podemos implementar o mesmo modelo de projetos de médio porte, porém para cada versão, fase ou módulo do projeto devemos criar um processo adicional.
Por exemplo, o projeto XYZ, esta com uma equipe trabalhando na versão 1.0, outra na versão 2.0 no módulo de vendas e outra equipe também na versão 2.0, mas no módulo de serviços. Assim, cada equipe terá que utilizar o mesmo modelo dos projetos de médio porte. Os projetos irão caminhar de forma independente, assim temos ramificações do projeto (branches). Devido a isso, se faz necessário múltiplos ambientes de desenvolvimento, testes, homologação.
Porém, em algum momento as diferentes frentes de projeto terão que ser consolidadas para termos uma solução final em produção, neste momento, os branches devem ser consolidados, testados em um novo CRM central e por fim aplicados nos demais ambientes e em produção.
Bom, longo post, mais muita coisa tinha que ser mencionada, espero que isso ajude nos seus projetos!
[]’s,
Tiago Cardoso
Power Platform by Tiago Michelini Cardoso 