Compartilhar via

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

  • Artigo

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

Importante

Exceto pelas seções descritas em Quando editar o arquivo de personalizações, a edição manual de arquivos de componentes extraídos e arquivos .zip não é suportada.

Quando a ferramenta SolutionPackager 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 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.

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, os dois pegam 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 do Microsoft Dataverse.

  3. O desenvolvedor A personaliza a exibição do sistema “Contatos ativos” e o formulário principal para a entidade de contato.

  4. O desenvolvedor B personaliza o formulário principal para a entidade da conta e altera a "Exibiçã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á verificar um arquivo para o formulário principal de contato e um arquivo para a exibição de "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 contatos".

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

  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 a exibição do sistema “Contatos ativos” e o formulário principal para a entidade de contato.

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

  5. Os dois desenvolvedores exportam uma solução não gerenciada. arquivo zip e extração.

    1. O desenvolvedor A precisará verificar um arquivo para o formulário principal de contato e um arquivo para a exibição de "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 "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 do desenvolvedor B enviar, ele deve obter as últimas fontes para garantir que não haja nenhum conflito prévio com suas alterações.

    2. Há um conflito, pois o arquivo de "Contatos Ativos” foi modificado já que o desenvolvedor B recuperou por último 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, 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 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 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, o desenvolvedor B pode exportar, extrair, e substituir o arquivo em conflito.

      3. 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 Dataverse 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 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 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 .zip de solução, ocorrerá o comportamento natural para substituir todos os componentes.

Criar uma solução

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

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

  2. Quando estiver pronto para fazer check-in, faça o seguinte.

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

    2. Usando a ferramenta SolutionPackager, extraia a solução para os 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 as últimas fontes do arquivo de componente 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 uma organização.

  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, realize o seguinte.

    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 de Componente de Solução (SolutionPackager)
Ferramenta SolutionPackager