Controlo de origem com ficheiros de soluções
A ferramenta SolutionPackager pode ser utilizada com qualquer sistema de controlo da origem. Depois de extraído um ficheiro .zip para uma pasta, basta adicionar e enviar os ficheiros para o seu sistema de controlo de origem. 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 origem é o facto de adicionar todos os ficheiros ao controlo de origem poder causar duplicações desnecessárias. Consulte a 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 origem.
À 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.
Importante
Exceto para as secções descritas em Quando deve editar o ficheiro de personalização, a edição manual dos ficheiros de componentes extraídos e dos ficheiros .zip não é suportada.
Quando a ferramenta SolutionPackager extrai os ficheiros de componente, não substituirá 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. Isto permite ao utilizador verificar, a partir do controlo de origem, 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 origem, um programador pode submeter os ficheiros alterados de volta ao controlo de origem, 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.
O programador A e B estão ambos a trabalhar na mesma solução.
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.
O Programador A personaliza a vista do sistema "Contactos Ativos" e o formulário principal para a entidade Contacto.
O Programador B personaliza o formulário principal para a entidade Conta e altera a “Vista de Pesquisa de Contactos”.
Os dois programadores exportam um ficheiro .zip da solução não gerida e extraem.
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".
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".
Ambos os programadores podem submeter, por qualquer ordem, porque as respetivas alterações tocaram em ficheiros separados.
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 acima, 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, é o seguinte.
O programador A e B estão ambos a trabalhar na mesma solução.
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.
O Programador A personaliza a vista do sistema "Contactos Ativos" e o formulário principal para a entidade Contacto.
O Programador B personaliza o formulário principal para a entidade Conta e altera “Contactos Ativos”.
Ambos os programadores exportam um ficheiro .zip da solução não gerida e extraem.
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".
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".
O programador A está pronto primeiro.
Antes de o programador A submeter ao controlo de origem, é necessários obter as origens mais recentes para garantir que não há verificações anteriores em conflito com as alterações.
Não há conflitos, pelo que o programado A pode submeter.
O programador B está pronto a seguir ao programador A.
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.
Existe um conflito porque o ficheiro para "Contactos Ativos" foi modificado desde a última vez que o programador B obteve as origens mais recentes.
O programador B tem de reconciliar o conflito. É possível que as funcionalidades do sistema de controlo de origem em uso possam ajudar neste processo; caso contrário, as seguintes escolhas são todas viáveis.
O programador B, através do histórico de controlo de origem, se disponível, pode ver 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.
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á-la, conforme necessário. Em seguida, o programador B pode exportar, extrair e substituir o ficheiro em conflito.
Se a alteração anterior puder ser considerada desnecessária, o programador B permite que a cópia do ficheiro substitua a versão no controlo de origem e submete.
Quer esteja a trabalhar numa organização partilhada ou em organizações independentes, o desenvolvimento de soluções do Dataverse em equipa exigem que aqueles que trabalham ativamente numa solução comum estejam cientes do trabalho dos outros. A ferramenta SolutionPackager 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 origem, e realça proativamente os componentes concisos onde surgiram conflitos.
As secções seguintes são os processos genéricos para utilizar eficazmente a ferramenta SolutionPackager no controlo de origem ao programar com equipas. Também trabalham com as organizações independentes ou as organizações de desenvolvimento partilhadas, apesar de com as organizações partilhadas a exportação e a extração incluirá 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, ocorrerá o comportamento natural para substituir todos os componentes.
Criar uma solução
O seguinte procedimento identifica os passos típicos utilizados quando cria uma solução pela primeira vez.
Numa organização limpa, crie uma solução no servidor do Dataverse e, em seguida, adicione ou crie componentes conforme necessário.
Quando estiver pronto para fazer o registo de entrada, faça o seguinte.
Exporte a solução não gerida.
Com a ferramenta SolutionPackager, extraia a solução para ficheiros de componentes.
A partir dos ficheiros de componentes extraídos, adicione os ficheiros necessários ao controlo de origem.
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.
Sincronize ou obtenha as mais recentes origens de ficheiro de componente da solução.
Com a ferramenta SolutionPackager, coloque os ficheiros de componentes num pacote num ficheiro .zip não gerido.
Importe o ficheiro de solução não gerido para uma organização.
Personalize e edite a solução conforme necessário.
Quando estiver pronto para dar entrada das alterações no controlo de origem, faça o seguinte.
Exporte a solução não gerida.
Com a ferramenta SolutionPackager, extraia a solução exportada para ficheiros de componentes.
Sincronize ou obtenha as mais recentes origens a partir do controlo de origem.
Reconcilie se existirem conflitos.
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