Team Development Environment para .Net

5

Acabei de me juntar a uma nova empresa que recentemente mudou o desenvolvimento do PHP para o C # /. Net Core. Eles estão escrevendo um novo CMS desde o início neste novo ambiente.

Antes de mim, havia apenas um desenvolvedor trabalhando nesse novo sistema, e ele montou um sistema que é bem difícil de se trabalhar. Estou tentando pensar em maneiras de melhorá-lo, mas tenho dificuldade em encontrar informações sobre os recursos das várias ferramentas envolvidas.

Aviso: Descrição detalhada / entrada aleatória. TL / DR: o sistema atual torna o desenvolvimento do dia a dia muito ineficiente. Se você quiser, pode pular para as perguntas concretas abaixo.

Nossa configuração atual funciona assim: o sistema é dividido em uma parte principal e em peças específicas do cliente. Cada parte é dividida em vários pequenos projetos de acordo com divisões lógicas de responsabilidades. Até aí tudo bem.

Cada um desses projetos está em seu próprio repositório Git individual e consiste em uma única solução que geralmente contém dois projetos, uma biblioteca de classes contendo a funcionalidade e um projeto de teste de unidade. (Ocasionalmente, há mais de um desses pares, mas considero isso um acidente).

Os repositórios do Git são hospedados em um TFS. O TFS constrói automaticamente cada solução conforme as confirmações são enviadas e publica o resultado da compilação como um pacote NuGet. A dependência entre os vários projetos é tratada exclusivamente por dependências do NuGet.

Existem vários problemas com isso.

Quando preciso de um novo recurso, as alterações necessárias geralmente são divididas em diversos projetos. Como o CMS é muito novo, muitos novos recursos exigem adições ao núcleo; Além disso, um novo recurso pode exigir mudanças em vários projetos das partes específicas do cliente: a camada de controlador de visualizações (um projeto), a camada de sistemas (outro projeto) e alguma camada de dados (outro projeto).

Por causa da maneira como as dependências funcionam, para conseguir isso eu preciso mudar o projeto no final do gráfico de dependência, confirmar e enviar, esperar que o servidor publique o novo pacote, atualize a próxima camada, faça as alterações lá, comprometer e empurrar, etc, até chegar a camada final. Em qualquer ponto deste processo, a construção do mundo pode ser quebrada se eu mudar qualquer coisa de uma maneira incompatível.

Como você pode imaginar, este é um processo incrivelmente ineficiente. Além disso, se em algum momento eu perceber que uma alteração na camada inferior foi incorreta ou insuficiente, eu tenho que iniciar o processo novamente. Isso significa que eu posso facilmente acumular commits do Git que na verdade não são um estado útil do sistema. O que é ainda pior, se eu quiser experimentar algo em uma camada inferior (por exemplo, adicionar alguma saída de depuração), eu realmente tenho que cometer isso e empurrá-lo para o repositório oficial para obter uma compilação, e depois adicionar outro commit que desfaz o efeito .

Além disso, como todo pequeno projeto está em sua própria solução, eu tenho que abrir cada um em sua própria instância do Visual Studio. Atualmente tenho 6 instâncias em execução. Encontrar o caminho certo para um trabalho é às vezes confuso. Além disso, devido ao modo como a configuração do VS funciona, qualquer alteração que eu faça (por exemplo, layout de janelas de ferramentas) corre o risco de ser sobrescrita se a instância em que a obtive não for a última a ser encerrada.

Por fim, como os pacotes NuGet que estão sendo criados são versões de lançamento, a depuração na pilha é sub-ótima. (Além disso, atualmente não temos informações de símbolos ou fontes nos pacotes, então a depuração é completamente impossível, mas eu sei como corrigir esse problema específico.)

Perguntas

  1. Existe uma maneira de ter a configuração de dependência do NuGet para os builds de CI e uma configuração de dependência de projeto de solução única para as construções do desenvolvedor?

  2. O uso do NuGet aqui é útil? Existe uma maneira melhor de compor projetos que abrangem vários repositórios Git?

  3. Existe uma maneira de ter um repositório NuGet local para desenvolvedores que substitua o servidor de maneira previsível, para o qual as construções são automaticamente enviadas com um bom número de versão? Estou bastante preocupado com problemas de sincronização quando dois desenvolvedores trabalham no mesmo repositório simultaneamente.

  4. Seria um grande benefício fundir-se em apenas um repositório Git para o núcleo e um por material específico do cliente?

Ou, em outras palavras, o que é uma boa configuração de desenvolvimento em geral? Infelizmente esta é a primeira vez que estou trabalhando com o desenvolvimento do .Net, então eu estou com pouca experiência em geral.

    
por Sebastian Redl 27.01.2017 / 13:00
fonte

2 respostas

2

Parece-me que isto foi configurado muito bem.

Há algumas coisas que você pode fazer para tornar seu dia a dia mais fácil.

Problema 1: ter que publicar nugets antes que eles possam ser usados em projetos dependentes

Você pode publicar manualmente um nuget de pré-lançamento a partir de uma compilação local anexando -beta ao número da versão. Os projetos dependentes podem ser atualizados para usar esta versão de pré-lançamento e testados antes de você confirmar uma versão 'real'

Alternativamente: Empacote seu nuget de teste em sua máquina e copie para um diretório. configure este diretório como um repositório nuget local no VS

Alternativamente: você pode alterar a referência no projeto para a dll que você tem localmente

Problema 2: nugets compilados da versão de depuração.

O ideal é que você nunca tenha que fazer isso. Escreva testes unitários no projeto nuget para garantir que ele funcione corretamente

No entanto, você pode compilar uma versão de depuração e usar como pré-lançamento ou pop-lo em seu repositório local de nugets

    
por 27.01.2017 / 13:44
fonte
0
  1. Se eu entendi o que você está procurando corretamente, existe uma ferramenta chamada SlimJim que ajuda a lidar com isso, modificando a solução com todos os pacotes constituintes foram substituídos por suas referências de projeto.
  2. Isso significa que você pode ter diferentes partes específicas do cliente dependendo de diferentes versões do núcleo. Se você não quer que isso provavelmente não esteja te ajudando. Você poderia tentar submodules ou subtrees, mas eu não acho que eles seriam úteis nesse caso.
  3. Você não deve publicar no feed central a partir do seu espaço de trabalho local. Você pode hospedar uma fonte de pacote fora de um diretório local. Os detalhes variam dependendo da versão do Visual Studio com a qual você está trabalhando, mas este artigo você deve começar.
  4. Poderia haver, parece que você está usando a estrutura do projeto de um aplicativo muito maior para o seu aplicativo relativamente novo e atualmente pequeno e está causando excesso de sobrecarga.
por 27.01.2017 / 13:56
fonte