Usar o controle da fonte com arquivos de solução
Publicado: janeiro de 2017
Aplicável a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
A ferramenta SolutionPackager pode ser usada com qualquer sistema de controle de fonte. Depois que um arquivo de solução .zip tiver sido extraído para uma pasta, basta adicionar e enviar os arquivos para o seu sistema de controle de fonte. Esses arquivos podem ser sincronizados em outro computador onde possam ser embalados em um novo arquivo de solução idêntico .zip.
Um aspecto importante ao usar arquivos de componente extraídos no controle de fonte é que adicionar todos os arquivos no controle de fonte pode causar duplicação desnecessária. Consulte Solution component file reference (SolutionPackager) para ver quais arquivos são gerados para cada tipo de componente e quais arquivos são recomendados para uso no controle de fonte.
Como são necessárias futuras personalizações e alterações para a solução, os desenvolvedores devem editar ou personalizar os componentes por meio dos meios existentes, exportar novamente para criar um arquivo .zip, e extrair o arquivo de solução compactado para a mesma pasta.
Importante
A edição manual de arquivos de componentes extraídos e arquivos .zip não tem suporte.
Quando a ferramenta SolutionPackager extrai os arquivos de componentes, isso não substituirá os arquivos de componentes existentes de mesmo nome se os conteúdos do arquivo forem idênticos. Além disso, a ferramenta honra o atributo somente leitura em arquivos de componentes que gera um aviso na janela de console de que arquivos específicos que não foram escritos. Isso permite que o usuário verifique, a partir do controle de código-fonte, o conjunto mínimo de arquivos que estão mudando. O parâmetro /clobber pode ser usado para substituir e gerar arquivos somente leitura a serem escritos ou excluídos. O parâmetro /allowWrite pode ser usado para avaliar qual impacto tem uma operação de extrair sem realmente fazer com que os arquivos sejam escritos ou excluídos. O uso do parâmetro /allowWrite com log detalhado é efetivo.
Após concluir a operação de extração com o conjunto mínimo de arquivos verificados a partir do controle de código-fonte, um desenvolvedor pode enviar os arquivos alterados de volta para o controle de código-fonte, como ocorre com qualquer outro tipo de arquivo de origem.
Neste tópico
Desenvolvimento em equipe
Criar uma solução
Modificar uma solução
Desenvolvimento em equipe
Quando há muitos desenvolvedores trabalhando no mesmo componente de solução, um conflito pode ocorrer onde as alterações de dois desenvolvedores resultam em alterações a um único arquivo. Essa ocorrência é minimizada decompondo cada componente ou subcomponente editável individualmente para um arquivo diferente. Considere o exemplo a seguir.
Os desenvolvedores A e B estão trabalhando na mesma solução.
Em computadores independentes, os dois pegam as últimas fontes da solução do controle de código-fonte, empacotam e importam um arquivo de solução não gerenciado .zip para organizações independentes Microsoft Dynamics 365.
O desenvolvedor A personaliza a exibição do sistema “Contatos ativos” e o formulário principal para a entidade de contato.
O desenvolvedor B personaliza o formulário principal para a entidade da conta e altera a "Exibição de pesquisa de contato".
Os dois desenvolvedores exportam um arquivo de solução não gerenciado .zip e extraem.
O desenvolvedor A precisará verificar um arquivo para o formulário principal de contato e um arquivo para a exibição de "Contatos ativos".
O desenvolvedor B precisará verificar um arquivo para o formulário principal da conta e um arquivo para a "Exibição de pesquisa de contatos".
Os dois desenvolvedores podem enviar, em qualquer ordem, já que suas respectivas alterações atingiram arquivos separados.
Depois que os dois envios forem concluídos, eles podem repetir a etapa 2 e então continuar a fazer outras alterações em suas organizações independentes. Cada um dos dois possui conjuntos de alterações, sem substituições do seu próprio trabalho.
O exemplo anterior funciona somente quando há alterações em arquivos separados. É inevitável que personalizações independentes precisem de alterações em um único arquivo. Com base no exemplo acima, considere que o desenvolvedor B personalizou a exibição de "Contatos ativos” enquanto o desenvolvedor A também estava personalizando-a. Neste novo exemplo, a ordem dos acontecimentos é importante. O processo correto para corrigir essa contrariedade, escrito por completo, é conforme segue.
Os desenvolvedores A e B estão trabalhando na mesma solução.
Em computadores independentes, os dois pegam as últimas fontes da solução do controle de código-fonte, empacotam e importam um arquivo de solução não gerenciado .zip para organizações independentes.
O desenvolvedor A personaliza a exibição do sistema “Contatos ativos” e o formulário principal para a entidade de contato.
O desenvolvedor B personaliza o formulário principal para a entidade da conta e altera os "Contatos ativos".
Os dois desenvolvedores exportam uma solução não gerenciada. Arquivo zip e extração.
O desenvolvedor A precisará verificar um arquivo para o formulário principal de contato e um arquivo para a exibição de "Contatos ativos".
O desenvolvedor B precisará verificar um arquivo para o formulário principal da conta e um arquivo para a exibição de "Contatos ativos".
O desenvolvedor A está pronto primeiro.
Antes de enviar ao controle de código-fonte, ele deve obter as últimas fontes para garantir que não haja nenhum conflito prévio com suas alterações.
Não existe nenhum conflito, por isso ele pode enviar.
O desenvolvedor B está pronto depois do desenvolvedor A.
Antes de enviar, ele deve obter as últimas fontes para garantir que não haja nenhum conflito prévio com suas alterações.
Há um conflito, pois o arquivo de "Contatos ativos” foi modificado já que ele recuperou por último as fontes mais recentes.
O desenvolvedor B deve corrigir o conflito. É possível que os recursos do sistema de controle de fonte em uso possam auxiliar este processo; caso contrário, as seguintes opções são todas viáveis.
O desenvolvedor B, através do histórico de controle de código-fonte, se disponível, poderá ver se o desenvolvedor A fez a alteração anterior. Por meio de comunicação direta, eles podem discutir cada alteração. Então o desenvolvedor B precisa apenas atualizar sua organização com a resolução concordada. Em seguida, ele exporta, extrai e substitui o arquivo em conflito e envia.
Permitir que o controle de código-fonte substitua o arquivo local. O desenvolvedor B embala a solução e a importa para sua organização, e então avalia o estado da exibição e a personaliza novamente conforme necessário. Em seguida, ele pode exportar, extrair, e substituir o arquivo em conflito.
Se a alteração anterior puder ser considerada desnecessária, o desenvolvedor B permite a cópia do arquivo para substituir a versão no controle de código-fonte e envia.
Seja trabalhando em uma organização compartilhada ou organizações independentes, o desenvolvimento em equipe de soluções Microsoft Dynamics 365 requer que as pessoas que estão trabalhando ativamente em uma solução comum estejam a par do trabalho dos outros. A ferramenta SolutionPackager não remove totalmente esta necessidade, mas ela possibilita a fácil união de alterações não conflitantes no nível de controle de código-fonte, e destaca proativamente os componentes concisos onde os conflitos ocorreram.
As seções a seguir são os processos genéricos para usar de forma eficaz a ferramenta SolutionPackager no controle de código-fonte ao desenvolver com equipes. Esses contatos trabalham igualmente com organizações independentes ou organizações compartilhadas de desenvolvimento, embora com organizações compartilhadas a exportação e a extração incluirão naturalmente todas as alterações presentes na solução, não apenas as feitas pelo desenvolvedor que executa a exportação. De maneira semelhante, ao importar um arquivo de solução .zip o comportamento natural para substituir todos os componentes ocorrerá.
Criar uma solução
O procedimento a seguir identifica as etapas típicas usadas ao criar uma solução pela primeira vez.
Em uma organização limpa, crie uma solução no servidor Microsoft Dynamics 365, e depois adicione ou crie componentes conforme necessário.
Quando estiver pronto para fazer check-in, faça o seguinte.
Exporte a solução não gerenciada.
Usando a ferramenta SolutionPackager, extraia a solução para os arquivos de componentes.
A partir destes arquivos de componentes extraídos, adicione os arquivos necessários para o controle de código-fonte.
Envie estas alterações para o controle de código-fonte.
Modificar uma solução
O procedimento a seguir identifica as etapas típicas usadas ao modificar uma solução existente.
Sincronize ou obtenha as últimas fontes do arquivo de componente da solução.
Usando a ferramenta SolutionPackager, embale os arquivos de componentes para um arquivo de solução não gerenciado .zip.
Importe o arquivo da solução não gerenciado para uma organização.
Personalize e edite a solução conforme necessário.
Quando estiver pronto para verificar as alterações no controle de código-fonte, realize o seguinte.
Exporte a solução não gerenciada.
Usando a ferramenta SolutionPackager, extraia a solução exportada para os arquivos de componentes.
Sincronize ou obtenha as últimas fontes do controle de código-fonte.
Corrija se houver algum conflito.
Envie as alterações para o controle de código-fonte.
As etapas 2 e 3 devem ser executadas antes que ocorram personalizações adicionais na organização de desenvolvimento. Na etapa 5, a etapa b deve ser concluída antes da etapa c.
Confira Também
Ferramentas da solução para desenvolvimento da equipe
Solution component file reference (SolutionPackager)
Use a ferramenta SolutionPackager para compactar e extrair um arquivo de soluções
Microsoft Dynamics 365
© 2017 Microsoft. Todos os direitos reservados. Direitos autorais