Compartilhar via


Particionamento de soluções de sistemas distribuídos para implementação

Quando as equipes de desenvolvimento estiverem prontas para implementar as definições de aplicativo no diagrama de aplicativo que oferecem suporte à implementação, o líder de desenvolvimento pode gerar os projetos para essas definições no Visual Studio.Esses projetos aparecem no gerenciador de soluções juntamente com outros itens na mesma solução.No entanto, pode haver situações em que deseja particionar a solução em soluções menores.Criar soluções menores que contêm apenas um subconjunto dos aplicativos é uma maneira flexível para organizar projetos para desenvolvimento.O Visual Studio torna possível incluir projetos de várias soluções para que você possa criar soluções que contêm um subconjunto de projetos.Além disso, pode ser útil manter a solução original sistema autônomo uma solução "mestre" que torna possível reconciliar sistema autônomo alterações entre o escopo original da solução e criar sistemas e definir implantação dentro desse escopo.

Observação:

As diretrizes neste tópico e abordagens suponha que o uso do controle do código-fonte.Para obter mais informações, consulte Sistema Definition Model (SDM) documentos sob controle de fonte.Ao particionar soluções, é recomendável que você use portas estáticas em arquivo baseado em sistemas de aplicativos ASP.NET, que usa portas dinâmicas por padrão.Portas dinâmicas em um aplicativo ASP.NET podem fazer com que os números de porta alterar qualquer uma das seus serviços da Web, que faz com que as referências da Web correspondentes para desconectado.Para obter mais informações, consulte Visão geral sobre ASP.NET Applications on Application Diagrams.

As seções a seguir contêm mais informações sobre particionamento de soluções:

  • Soluções particionadas de uma solução mestre

  • Mantendo a solução original sistema autônomo a solução mestre

  • Atualizando a solução principal com alterações para soluções particionadas

Soluções particionadas de uma solução mestre

Em cenários onde as definições do aplicativo para um sistema de grandes aplicativos complexos são criadas em uma única solução, talvez seja mais gerenciável para dividir a solução em menores soluções para implementação de aplicativos.Cada solução particionada contém um subconjunto de definições de aplicativos e seus projetos correspondentes, incluindo arquivos de código, arquivos de configuração e .sdm arquivos, que contêm as informações do SDM (sistema Definition Model) para as definições de aplicativo associado.

Você pode empregar diversas estratégias de particionamento de uma solução.Por exemplo, se o sistema geral consiste em membro claramente delineados sistemas, você poderá criar soluções baseadas nos limites de cada sistema na solução.Cada solução, em seguida, conterá os projetos para as definições de aplicativo referenciados por um sistema.Dependendo da complexidade de cada sistema, essas soluções particionadas podem ser ainda mais divididas em soluções ainda menores.Você também pode particionar soluções para o nível de desenvolvedores individuais de modo que solução cada desenvolvedor contém somente as partes do sistema para o qual cada desenvolvedor tem responsabilidade.Você também pode compartilhar projetos usando o controle do código-fonte.No entanto, esteja atento a certos problemas ao compartilhar projetos.Para obter mais informações, consulte Alterações para documentos do sistema Definition Model (SDM) e check-out simultâneas.

Observação:

Embora os limites do sistema forneceria uma base lógica para dividir as definições de aplicativo e seus projetos a partir de uma única solução em soluções menores, não há nenhuma exigência para dividir uma solução dessa maneira.Em cenários em que os sistemas se sobrepõem (contêm usos da mesma definição de aplicativo), essa abordagem é menos prática.

Sumário de soluções particionados

Você pode adicionar um diagrama de aplicativo para cada solução particionada, fazendo com que as definições de aplicativo apareçam no diagrama com base em arquivos de definição (.sdm) do aplicativo nos projetos de solução.Após o processo de particionamento, qualquer novos projetos adicionados à solução são com engenharia reversa no diagrama de aplicativo, se apropriado.Cada solução particionada também pode conter qualquer diagramas do sistema para que indivíduos podem examinar os sistemas que contêm os usos dessas definições.Por exemplo, diagramas de sistema que compartilham as referências a uma definição de aplicativo podem ser incluídos em uma solução para fornecer contexto particionada.Você pode usar o diagrama de aplicativo ou adicionar diagramas de sistema para uma solução particionada para avaliar a implantação ou gerar relatórios de implantação usando o Distributed System Designers.Se você deseja usar soluções particionadas para desenvolvimento do projeto somente, não há nenhuma exigência de que um diagrama de sistema distribuído esteja presente nessas soluções.

Observação:

Se você excluir um arquivo .sdm enquanto o diagrama de aplicativo é fechado, o arquivo .sdm será regenerado na próxima vez que em em aberto o diagrama de aplicativo em uma solução que contém esse projeto.No entanto, esse arquivo gerado novamente .sdm contém apenas informações que podem ser recriadas de outra fonte.Qualquer informação que foi armazenada somente no arquivo .sdm excluído serão perdida.Além disso, referências a definição associada podem estar desfeitas.Para obter mais informações, consulte Solucionando problemas de diagramas de aplicativos.Se uma definição de aplicativo compartilhado não estiver presente em uma solução particionada, usa de definição nos diagramas de sistema que estão incluídos na solução aparecerá quebrada.Tentativas de definir ou avaliar a implantação de sistemas que fazem referência a uma definição de aplicativo ausente não será possível ou bem-sucedida.Para obter mais informações, consulte Sincronização entre documentos definição de sistema Model (SDM).Um diagrama de aplicativo deve existir a solução se os diagramas de sistema são adicionados.

Mantendo a solução original sistema autônomo a solução mestre

Após o particionamento de uma solução em soluções menores, você também pode manter solução original sistema autônomo uma solução "mestre".Essa abordagem torna possível exibir e analisar todo o sistema ocasionalmente.Além disso, não há nenhuma exigência para usar o diagrama de aplicativo em cada solução particionada se uma solução mestre existe e contém seu próprio diagrama de aplicativo.

Observação:

Não há nenhuma exigência de manter ou manter um mestre solução.Por exemplo, se sistema autônomo limites do sistema podem ser divididos claramente baseado sistema autônomo conexões entre Web services, e em seguida, pode ser suficiente gerenciar cada solução particionada separadamente e representam sistema autônomo interações entre eles sistema autônomo sistema autônomo conexões para serviços Web externos.Serviços Web externos são adicionados automaticamente ao diagrama de aplicativo em cada solução particionado onde referências de Web Services ultrapassam os limites de solução.Para obter mais informações, consulte Tipos de aplicativo e protótipos para definição de aplicativos.No entanto, se você quiser criar sistemas de nível mais alto que fazem referência a sistemas criados em soluções de nível inferior particionadas, você pode criar definições de sistema que incluem as definições de nível inferior necessários do sistema.No entanto, para definir e avaliar a implantação para esses sistemas, certifique-se de que a solução contém todos os aplicativos referenciados.

Por exemplo, suponha que uma equipe de desenvolvimento consiste em três desenvolvedores trabalhando em três soluções individuais, cada uma solução particionada que contém os projetos associados com as definições de aplicativo.Esses três soluções fazem parte de uma solução particionada maior que engloba os limites de um sistema único aplicativo.Por sua vez, a solução particionada é uma das muitas outras soluções particionadas que descrevem outros sistemas de aplicativos, que abrangem um sistema geral que existe dentro do escopo de um mestre solução.

À medida que sistema autônomo equipes de desenvolvimento trabalham em soluções particionadas, eles irão fazer check-in suas alterações para o controle do código-fonte.O líder de desenvolvimento pode então atualização a solução do controle de código de fonte fazendo check-out os diagramas apropriados e os arquivos mestre.Esta ação sincroniza as alterações nos arquivos de código e a configuração com os diagramas apropriados.Para obter mais informações, consulte Visão geral do definição de sistema Model (SDM) e Relacionamentos entre documentos definição de sistema Model (SDM).

Atualizando a solução principal com alterações para soluções particionadas

Arquitetos de aplicativos, líderes de desenvolvimento ou aqueles responsáveis pela arquitetura de um sistema podem atualizar periodicamente e validar a solução principal com as alterações feitas às soluções particionadas.Essa pessoa pode fazer check-out de uma solução particionada contendo esses projetos foram divididos entre as equipes de desenvolvimento, que podem estar trabalhando nesses projetos diretamente dentro da solução particionada ou em outras soluções particionadas.

Isso é útil para revisar todo o sistema se tiverem sido feitas alterações de arquitetura, para validar que o design geral do sistema ainda irá implantar corretamente e para propagar as alterações entre as soluções.Atualizando periódicos e revisão da solução mestre também são importante se a solução contém o diagrama de aplicativo somente em todas as soluções e é o único local no qual sistemas são mantidos.

Quando o diagrama de aplicativo é aberto na solução principal depois de atualizar seus projetos de controle do código-fonte, um cliente potencial arquiteto ou desenvolvimento de aplicativo pode analisar o impacto que esses projetos possuem alterações no diagrama.Para ver as alterações exatas, o principal arquiteto ou desenvolvimento pode examinar a lista de alterações que tenham sido verificados ou comparar as diferenças nos arquivos de código.O principal arquiteto ou desenvolvimento, em seguida, pode sincronizar o diagrama de aplicativo com o código do projeto ou resolver quaisquer avisos de sincronização fazendo check-out de projetos necessários para que podem propagar alterações que precisam ser feitas em definições de aplicativos e seus usos em definições do sistema.

Se o principal arquiteto ou desenvolvimento estiver satisfeito com as alterações feitas nesses projetos, essas alterações podem ser verificadas na solução.Caso contrário, o principal arquiteto ou desenvolvimento deve trabalhar com as equipes de desenvolvimento resolver qualquer conflito de modo que o código possa sincronizar com o diagrama.

Consulte também

Tarefas

Como: Resolver conflitos em documentos definição de sistema Model (SDM)

Referência

Alterações para documentos do sistema Definition Model (SDM) e check-out simultâneas

Outros recursos

Distribuído criadores de sistema em ambientes Team