Controle do código-fonte com arquivos de solução

A ferramenta SolutionPackager pode ser usada com qualquer sistema de controle do código-fonte. Depois que um arquivo .zip da solução for extraído para uma pasta, basta adicionar e enviar os arquivos para o seu sistema de controle do código-fonte. Esses arquivos podem ser sincronizados em outro computador onde possam ser embalados em um novo arquivo .zip de solução idêntica.

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 a Referência do Arquivo do Componente da Solução para descobrir quais arquivos são gerados para cada tipo de componente e quais são recomendados para uso no controle do código-fonte.

Como são necessárias futuras personalizações e alterações para a solução, os desenvolvedores devem editar ou personalizar os componentes através dos meios existentes, exportar novamente para criar um arquivo .zip e extrair o arquivo de solução compactado para a mesma pasta.

Quando a ferramenta Pacote de Soluções extrair 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, produzindo um aviso na janela do console de que arquivos específicos não foram escritos. Esta proteção 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 ignorar restrições e permitir que arquivos somente leitura sejam 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 logagem detalhada é 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.

Formatos de arquivo de controle do código-fonte

A ferramenta Empacotador de Soluções dá suporte a dois formatos de arquivo para arquivos de componente extraídos. Escolher o formato correto antecipadamente evita a necessidade de migrar a estrutura do repositório posteriormente.

Quando usar o formato YAML: Para todos os novos projetos e sempre que você usa a integração nativa do Dataverse Git. O formato YAML é compatível com versões futuras e produz um histórico de alterações mais limpo.

Quando usar o formato XML: Somente ao trabalhar com repositórios existentes que já usam o formato XML ou ao usar ferramentas herdadas que não dão suporte ao YAML.

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.

1. Os desenvolvedores A e B estão trabalhando na mesma solução.

2. Em computadores independentes, ambos obtêm as fontes mais recentes da solução do controle de versão, empacotam e importam um arquivo .zip de solução não gerenciada em organizações Microsoft Dataverse independentes.

3. O Desenvolvedor A personaliza a exibição do sistema "Contatos Ativos" e o formulário principal para a entidade Contact.

4. O desenvolvedor B personaliza o formulário principal para a entidade Conta e altera a "Visualização de Pesquisa de Contato".

5. Os dois desenvolvedores exportam um arquivo .zip de solução não gerenciada e extraem.

   1. O Desenvolvedor A precisará fazer o check-out de um arquivo para o Formulário Principal de Contato e um arquivo para a exibição "Contatos Ativos".

   2. O desenvolvedor B precisará verificar um arquivo para o formulário principal da conta e um arquivo para a "Exibição de Pesquisa de Contato".

6. Os dois desenvolvedores podem enviar, em qualquer ordem, já que suas respectivas alterações atingiram arquivos separados.

7. 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 deles possui ambos os conjuntos de alterações, sem sobrescrever o 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 mostrado anteriormente, considere que o desenvolvedor B personalizou a exibição "Contatos Ativos" enquanto o desenvolvedor A também a personalizava. Neste novo exemplo, a ordem dos acontecimentos é importante. O processo correto para corrigir essa contrariedade, escrito por completo, é descrito aqui.

1. Os desenvolvedores A e B estão trabalhando na mesma solução.

2. Em computadores independentes, os dois obtêm as últimas fontes da solução do controle de código-fonte, empacotam e importam um arquivo .zip de solução não gerenciada para organizações independentes.

3. O Desenvolvedor A personaliza o modo de exibição do sistema "Contatos Ativos" e o formulário principal da tabela Contato.

4. O desenvolvedor B personaliza o formulário principal para a tabela da conta e altera os "Contatos Ativos".

5. Os dois desenvolvedores exportam um arquivo .zip de solução não gerenciada e extraem.

   1. O desenvolvedor A precisará fazer check-out de um arquivo do formulário principal de Contato e de um arquivo para a exibição "Contatos Ativos".

   2. O desenvolvedor B precisará realizar o check-out de um arquivo para o formulário principal da conta e um arquivo para a vista "Contatos Ativos".

6. O desenvolvedor A está pronto primeiro.

   1. Antes do desenvolvedor A 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.

   2. Não existe nenhum conflito, por isso o desenvolvedor A pode enviar.

7. O desenvolvedor B está pronto depois do desenvolvedor A.

   1. Antes de o desenvolvedor B fazer o envio, ele deve obter o último código fonte para garantir que não haja nenhum conflito prévio com suas alterações.

   2. Há um conflito porque o arquivo para "Contatos Ativos" foi modificado desde a última vez que o desenvolvedor B recuperou as fontes mais recentes.

   3. 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.

      1. O desenvolvedor B, através do histórico de controle de código-fonte, se disponível, pode 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 a organização com a resolução concordada. O Desenvolvedor B, em seguida, exporta, extrai e substitui o arquivo em conflito e envia.

      2. Permitir que o controle de código-fonte substitua o arquivo local. O desenvolvedor B empacota 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, o desenvolvedor B pode exportar, extrair, e substituir o arquivo em conflito.

      3. Se a alteração anterior for 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 um ambiente compartilhado ou ambiente independentes, o desenvolvimento em equipe de soluções do Dataverse requer que as pessoas que estão trabalhando ativamente em uma solução comum estejam conscientes do trabalho dos outros. A ferramenta SolutionPackager não remove totalmente esta necessidade, mas ela possibilita a fácil mesclagem 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 ambientes funcionam igualmente bem com ambientes independentes ou de desenvolvimento compartilhados, embora, com ambientes compartilhados, a exportação e o processo de extração incluirão naturalmente todas as alterações presentes na solução, não apenas aquelas feitas pelo desenvolvedor que executa a exportação. De maneira semelhante, ao importar um arquivo .zip de solução, ocorre o comportamento natural para substituir todos os componentes.

Criar uma solução

Este procedimento identifica as etapas típicas usadas ao criar uma solução pela primeira vez.

1. Em uma organização limpa com o Dataverse, crie uma solução e depois adicione ou crie componentes, conforme necessário.

2. Quando estiver pronto para fazer check-in, siga estas etapas.

   1. Exporte a solução não gerenciada.

   2. Usando a ferramenta Solution Packager, extraia a solução em arquivos de componentes.

   3. A partir destes arquivos de componentes extraídos, adicione os arquivos necessários para o controle de código-fonte.

   4. 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.

1. Sincronize ou obtenha os arquivos mais recentes de componentes da solução.

2. Usando a ferramenta SolutionPackager, empacote os arquivos de componentes para um arquivo .zip de solução não gerenciada.

3. Importe o arquivo da solução não gerenciado para um ambiente.

4. Personalize e edite a solução conforme necessário.

5. Quando estiver pronto para verificar as alterações no controle de código-fonte, siga estas etapas.

   1. Exporte a solução não gerenciada.

   2. Usando a ferramenta SolutionPackager, extraia a solução exportada para os arquivos de componentes.

   3. Sincronize ou obtenha as últimas fontes do controle de código-fonte.

   4. Corrija se houver algum conflito.

   5. 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.

Consulte também

Referência de Arquivo do Componente da Solução (SolutionPackager)
A ferramenta SolutionPackager
Formatos de arquivo de controle do código-fonte