Controlo de origem com ficheiros de soluções

A ferramenta Solution Packager pode ser utilizada com qualquer sistema de controlo de código fonte. Depois de um ficheiro .zip ser extraído para uma pasta, adicione e submeta os ficheiros para o seu sistema de controlo de código fonte. Em seguida, estes ficheiros podem ser sincronizados noutro computador onde podem ser comprimidos num novo ficheiro .zip idêntico da solução.

Um aspeto importante ao utilizar ficheiros de componentes extraídos no controlo de código fonte é que adicionar todos os ficheiros ao controlo de código fonte poderá causar duplicações desnecessárias. Aceda à Referência do Ficheiro do Componente da Solução para ver que ficheiros são gerados para cada tipo de componente e quais os ficheiros recomendados para utilização no controlo de código fonte.

À medida que forem necessárias mais personalizações e alterações à solução, os programadores devem editar ou personalizar os componentes através dos meios existentes, exportá-los novamente para criar um ficheiro .zip e extrair o ficheiro de solução comprimido na mesma pasta.

Quando a ferramenta Solution Packager extrai os ficheiros de componente, não substitui os ficheiros de componente existentes com o mesmo nome se o conteúdo do ficheiro for idêntico. Além disso, a ferramenta respeita o atributo só de leitura nos ficheiros de componente que produzem um aviso na janela da consola a informar que os ficheiros específicos não foram escritos. Esta proteção permite ao utilizador verificar, a partir do controlo de código fonte, o conjunto mínimo de ficheiros que estão a ser alterados. O parâmetro /clobber pode ser utilizado para substituir e fazer com que os ficheiros só de leitura sejam escritos ou eliminados. O parâmetro /allowWrite pode ser usado para avaliar o impacto que uma operação de extração tem sem realmente fazer com que quaisquer ficheiros sejam escritos ou eliminados. A utilização do parâmetro /allowWrite com registo verboso é eficaz.

Após a conclusão da operação de extração com o conjunto mínimo de ficheiros verificados a partir do controlo de código fonte, um programador pode submeter os ficheiros alterados de volta ao controlo de código fonte, como é feito com qualquer outro tipo de ficheiro de origem.

Formatos de ficheiro de sistemas de controlo de versões

A ferramenta Solution Packager suporta dois formatos de ficheiro para ficheiros de componentes extraídos. Escolher o formato certo desde o início evita ter de migrar a estrutura do repositório mais tarde.

Quando usar o formato YAML: Para todos os projetos novos, e sempre que usares integração nativa com o Dataverse com 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: Só quando se trabalha com repositórios existentes que já usam o formato XML, ou quando se usa ferramentas legadas que não suportam YAML.

Desenvolvimento de equipa

Quando estão vários programadores a trabalhar no mesmo componente de solução, pode surgir um conflito em que as alterações de dois programadores resultam em alterações a um único ficheiro. Esta ocorrência é minimizada ao decompor cada componente ou subcomponente editável individualmente num ficheiro distinto. Considere o exemplo seguinte.

1. O programador A e B estão ambos a trabalhar na mesma solução.

2. Em computadores independentes, ambos obtêm as fontes mais recentes da solução através do controlo de fonte, empacotam e importam um .zip ficheiro de solução não gerida em organizações independentes do Microsoft Dataverse.

3. O Desenvolvedor A personaliza a visualização do sistema "Contactos Ativos" e o formulário principal para a entidade Contacto.

4. O Programador B personaliza o formulário principal para a entidade Conta e altera a "Vista de Pesquisa de Contactos".

5. Os dois programadores exportam um ficheiro .zip da solução não gerida e extraem.

   1. O Desenvolvedor A terá de verificar um ficheiro para o formulário principal de Contacto e outro para a vista "Contactos Ativos".

   2. O programador B terá de fazer check-out de um ficheiro para o formulário principal da Conta e um ficheiro para a "Vista de Pesquisa de Contacto".

6. Ambos os programadores podem submeter, por qualquer ordem, uma vez que as respetivas alterações tocaram em ficheiros separados.

7. Depois de concluídas ambas as submissões, podem repetir o passo n.º 2 e, em seguida, continuar a fazer novas alterações nas respetivas organizações independentes. Cada um tem ambos os conjuntos de alterações, sem substituições do próprio trabalho.

O exemplo anterior só funciona quando há alterações a ficheiros separados. É inevitável que as personalizações independentes exijam alterações num único ficheiro. Com base no exemplo mostrado anteriormente, considere que o programador B personalizou a vista de "Contactos Ativos" enquanto o programador A também a estava a personalizar. Neste novo exemplo, a ordem dos eventos torna-se importante. O processo correto para reconciliar este problema, indicado na íntegra, é descrito aqui.

1. O programador A e B estão ambos a trabalhar na mesma solução.

2. Em computadores independentes, ambos obtêm as mais recentes fontes da solução a partir do controlo de origem, criam pacotes e importam um ficheiro .zip da solução não gerida em organizações distintas.

3. O Desenvolvedor A personaliza a vista do sistema "Contactos Ativos" e o formulário principal para a tabela de contactos.

4. O Programador B personaliza o formulário principal para a tabela Conta e altera “Contactos Ativos”.

5. Ambos os programadores exportam um ficheiro .zip da solução não gerida e extraem o conteúdo.

   1. O Desenvolvedor A terá de verificar um ficheiro para o formulário principal de Contacto e outro para a vista "Contactos Ativos".

   2. O Desenvolvedor B terá de verificar um ficheiro para o formulário principal da Conta e um ficheiro para a vista "Contactos Ativos".

6. O programador A está pronto primeiro.

   1. Antes de o programador A submeter ao controlo de código fonte, é necessário obter as origens mais recentes para garantir que nenhuma submissão anterior conflita com as suas alterações.

   2. Não há conflitos, pelo que o programador A pode submeter.

7. O programador B está pronto a seguir ao programador A.

   1. Antes de o programador B submeter, é necessário obter as origens mais recentes para garantir que não há verificações anteriores em conflito com as alterações.

   2. Há um conflito porque o ficheiro de "Contactos Ativos" foi modificado desde a última vez que o programador B recuperou as fontes mais recentes.

   3. O programador B tem de reconciliar o conflito. É possível que as capacidades do sistema de controlo de código fonte em uso possam ajudar neste processo; caso contrário, as seguintes escolhas são todas viáveis.

      1. O programador B, através do histórico de controlo de origem, se disponível, pode notar que o programador A fez a alteração anterior. Através da comunicação direta, podem debater cada alteração. Em seguida, o programador B só tem de atualizar a organização com a resolução acordada. Em seguida, o programador B exporta, extrai e substitui o ficheiro em conflito e submete.

      2. Permitir que o controlo de origem substitua o ficheiro local. O programador B empacota a solução e importa-a para a organização, depois avalia o estado da visualização e personaliza-a novamente, conforme necessário. Em seguida, o programador B pode exportar, extrair e substituir o ficheiro em conflito.

      3. Se a alteração anterior for considerada desnecessária, o programador B permite que a sua cópia do ficheiro substitua a versão no controlo de código fonte e submete.

Quer esteja a trabalhar num ambiente partilhado ou num ambiente independente, o desenvolvimento de soluções do Dataverse em equipa exige que aqueles que trabalham ativamente numa solução comum estejam cientes do trabalho dos outros. A ferramenta Solution Packager não remove totalmente esta necessidade, mas permite uma intercalação fácil das alterações que não estão em conflito a nível do controlo de código fonte e realça proativamente os componentes concisos onde surgem conflitos.

As secções seguintes são os processos genéricos para utilizar eficazmente a ferramenta Solution Packager no controlo de origem ao programar com equipas. Também trabalham com ambientes independentes ou ambientes de desenvolvimento partilhados, apesar de com os ambientes partilhadas a exportação e a extração inclui naturalmente todas as alterações presentes na solução, não apenas as efetuadas pelo programador que está a efetuar a exportação. Da mesma forma, ao importar um ficheiro .zip de solução, é comum que todos os componentes sejam substituídos.

Criar uma solução

Este procedimento identifica os passos típicos utilizados quando cria uma solução pela primeira vez.

1. Num ambiente limpo com o Dataverse, crie uma solução e, em seguida, adicione ou crie componentes conforme necessário.

2. Quando estiver pronto para fazer check-in, siga estes passos.

   1. Exporte a solução não-gestionada.

   2. Com a ferramenta Solution Packager, extraia a solução em ficheiros de componentes.

   3. A partir dos ficheiros de componentes extraídos, adicione os ficheiros necessários ao controlo de origem.

   4. Envie estas alterações para o controlo de origem.

Modificar uma solução

O seguinte procedimento identifica os passos típicos utilizados quando modifica uma solução existente.

1. Sincronize ou obtenha as fontes mais recentes dos ficheiros de componentes da solução.

2. Usando a ferramenta Solution Packager, empacote os ficheiros de componentes num ficheiro .zip de solução não gerida.

3. Importe o ficheiro de solução não gerido para um ambiente.

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

5. Quando estiver pronto para efetuar as alterações no controlo de versão, siga estes passos.

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

   2. Com a ferramenta Solution Packager, extraia a solução exportada para ficheiros de componentes.

   3. Sincronize ou obtenha as mais recentes fontes a partir do controlo de versão.

   4. Reconcilie se existirem conflitos.

   5. Envie as alterações para o controlo de origem.

   Os passos 2 e 3 têm de ser feitos antes de ocorrerem mais personalizações na organização de desenvolvimento. No passo 5, o passo B tem de ser concluído antes do passo c.

Consulte também

Referência de Ficheiro do Componente da Solução (SolutionPackager)
SolutionPackager Ferramenta
Formatos de ficheiro de controlo de versões