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 então sincronizados noutro computador onde podem ser colocados em pacotes num novo ficheiro .zip da solução idêntico.

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.

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 mais recentes origens da solução a partir do controlo de origem, colocam em pacote e importam um ficheiro .zip da solução não gerida em organizações independentes do Microsoft Dataverse.

3. O Programador A personaliza a vista 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 programador A terá de dar saída de um ficheiro para o formulário principal Contacto e um ficheiro para a vista "Contactos Ativos".

   2. O programador B terá de dar saída de um ficheiro para o formulário principal Conta e um ficheiro para a "Vista de Pesquisa de Contactos".

6. Ambos os programadores poderão submeter, por qualquer ordem, porque 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. Baseado no exemplo mostrado anteriormente, considere que o programador B personalizou a vista "Contactos Ativos", enquanto o programador A também o 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 origens da solução a partir do controlo de origem, colocam em pacote e importam um ficheiro .zip da solução não gerida em organizações independentes.

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

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

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

   1. O programador A terá de dar saída de um ficheiro para o formulário principal Contacto e um ficheiro para a vista "Contactos Ativos".

   2. O programador B terá de dar saída de um ficheiro para o formulário principal 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ários obter as origens mais recentes para garantir que não há verificações anteriores em conflito com as alterações.

   2. Não há conflitos, pelo que o programado 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. Existe um conflito porque o ficheiro para "Contactos Ativos" foi modificado desde a última vez que o programador B obteve as origens 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 coloca a solução num pacote e importa-a para a organização, depois avalia o estado da vista e volta a personalizá-lo, 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 uma ficheiro .zip da solução, ocorre o comportamento natural para substituir todos os componentes.

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

   2. Com a ferramenta Solution Packager, extraia a solução para 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 mais recentes origens de ficheiro de componente da solução.

2. Com a ferramenta Solution Packager, coloque os ficheiros de componentes num pacote num ficheiro .zip não gerido.

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 dar entrada das alterações no controlo de código fonte, 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 origens a partir do controlo de origem.

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