Plataforma de construção automatizada para o portfólio .NET - a melhor escolha? [fechadas]


10

Estou envolvido na manutenção de um portfólio bastante grande de aplicativos .NET. Também estão no portfólio aplicativos herdados criados sobre outras plataformas - C ++ nativo, ECLIPS Forms, etc.

Eu tenho uma estrutura de compilação complexa em cima do NAnt agora que gerencia as compilações para todos esses aplicativos. A estrutura de construção usa o NAnt para fazer várias coisas diferentes:

  • Retire o código do Subversion, bem como crie tags no Subversion
  • Crie o código usando o MSBuild for .NET ou outros compiladores para outras plataformas
  • Espie dentro dos arquivos AssemblyInfo para aumentar os números de versão
  • Exclui certos arquivos que não devem ser incluídos nas compilações / liberações
  • Libera código para pastas de implantação
  • Fecha o código para fins de backup
  • Implantar serviços do Windows; comece e pare-os
  • Etc.

A maioria dessas coisas pode ser feita apenas com o NAnt por si só, mas criamos algumas tarefas de extensão para o NAnt fazer algumas coisas específicas ao nosso ambiente. Além disso, a maioria dos processos acima é genérica e reutilizada em muitos de nossos diferentes scripts de criação de aplicativos, para que não repitamos a lógica. Portanto, não é um código NAnt simples, nem scripts de construção simples. Existem dezenas de arquivos NAnt que se reúnem para executar uma compilação.

Ultimamente, tenho ficado insatisfeito com o NAnt por duas razões: (1) a sintaxe é péssima - as linguagens de programação no XML são realmente horríveis de manter, (2) o projeto parece ter morrido na videira; Ultimamente, não houve muitas atualizações e parece que ninguém está realmente no comando. Tentar fazê-lo funcionar com o .NET 4 causou alguns problemas devido a essa falta de atividade.

Então, com todo esse histórico fora do caminho, aqui está minha pergunta. Dadas algumas das coisas que desejo realizar com base na lista acima, e considerando que estou principalmente em uma loja .NET, mas também preciso criar projetos que não sejam do .NET, existe uma alternativa ao NAnt que devo considerar Mudando para?

As coisas no meu radar incluem Powershell (com ou sem psake ), MSBuild por si só e rake . Todos eles têm prós e contras. Por exemplo, o MSBuild é poderoso o suficiente? Lembro-me de usá-lo anos atrás e não parecia ter tanto poder quanto o NAnt. Eu realmente quero que minha equipe aprenda Ruby apenas para fazer builds usando rake? O psake é realmente maduro o suficiente para um projeto para fixar meu portfólio? O Powershell está "muito próximo do metal" e acabarei tendo que escrever minha própria biblioteca de compilação semelhante ao psake para usá-lo por conta própria?

Existem outras ferramentas que devo considerar? Se você estivesse envolvido na manutenção de um portfólio .NET de complexidade significativa, qual ferramenta de construção você procuraria? O que sua equipe usa atualmente?

Respostas:


2

Se você já estiver usando o TeamCity, poderá usar os recursos existentes para a maior parte do que precisa. Ele suporta nativamente a criação de arquivos .sln do Visual Studio e, se você precisar de outras coisas para todos os seus projetos, poderá modificar os arquivos .targets do .NET Framework em suas máquinas de construção, para não precisar alterar os arquivos csproj individuais.

Ele fará check-out automaticamente no Subversion, artefatos zip, permitirá controlar quais arquivos são considerados artefatos implementáveis. A nova versão (6.0) também permite várias etapas de compilação, para que haja oportunidade para a implantação de artefatos em xcopy em um compartilhamento.

Você também pode escrever seus próprios aplicativos / tarefas que podem ser executados como parte de uma construção (por meio do corredor da linha de comando) e fazer o que quiser (como iniciar / parar processos do Windows).


3

Abordamos as coisas como três atividades diferentes, Compilar, Implantar e Instalar. Usamos o TFS para o servidor de construção com algumas frases de destaque para o Powershell. Em seguida, usamos o Powershell para realizar todas as peças de implantação e instalação que são bastante complexas e em vários servidores locais e na nuvem. Fiquei muito feliz em aprender o PowerShell sobre o MSBuild ou alguma outra ferramenta. Eu também tive uma boa experiência com o Visual Build no passado.


2

Dê uma olhada no Hudson e no MSBuild como um par. O poder vem dos fortes recursos do MSBuild e dos plugins de hudson .

Por exemplo, você pode usar hudson e executar seus scripts NAnt até migrar para o MSBuild e, em seguida, ele também pode executar os scripts do MSBuild.

Abordando especificamente seus pontos:

  • Subversão e Marcação
  • MSBuild
  • Foi perguntado sobre o SO do AssemblyInfo , mas a solução pode não ser do seu agrado
  • MSBuild pode excluir arquivos com facilidade
  • "Liberar código para pastas de implantação" - você pode fazer com que o sistema de construção pule essa etapa e implante-o automaticamente usando vários métodos. Ou você pode FTP, se quiser.
  • O MSBuild pode compactar
  • Serviços do Windows, novamente o MSBuild é seu amigo aqui.

Obrigado pela informação sobre o MSBuild. Parece que há mais poder do que na última vez que tentei usá-lo. Em relação ao Hudson, isso oferece benefícios além dos outros servidores de CI, como o TeamCity, que usamos atualmente? Estou tentando evitar perturbar muito o status quo aqui e substituir o servidor de IC ao mesmo tempo em que substituímos nossos scripts de construção parece mais doloroso.
RationalGeek

Na minha humilde opinião, acho que o TeamCity é fantástico ... e Hudson é melhor. Eles podem ser vistos executando as mesmas funções, até que você queira fazer algo incrível - então Hudson vence. Honestamente, o hudson pode analisar (stylecop / fxcop) -> build-> test-> tag-> backup local e externo-> implantar enquanto mantém você atualizado por RSS, SMS e XFD.
Steven Evers

Hmm ... nada nessa lista é impossível com o TeamCity, mas talvez seja mais fácil com o Hudson. De qualquer maneira, a menos que tenhamos problemas com o TC, acho que não mudaremos tão cedo.
RationalGeek

@jkohlhepp: A dificuldade é que existem muitas soluções no mesmo espaço. No final do dia, Hudson é fácil e é 100% gratuito. IIRC, uma coisa que a TC pode ter no hudson é a construção de vários agentes.
Steven Evers

2

Eu uso o Automated Build Studio . Eu quero me livrar disso.

A única razão pela qual eu não mudo para 100% MS Build ou Team Foundation Build é o custo que envolverá para reconstruir os scripts que funcionam perfeitamente hoje. Os scripts não mudam muito ...

No entanto, para o próximo produto, será o Team Foundation Build sem qualquer hesitação pelos seguintes motivos (são muitos mais):

  • É fácil de implantar (versão mais recente: 2010)
  • É totalmente integrado ao Visual Studio e Team Foundation Server
  • Está se tornando um padrão como o MS Build
  • É gratuito com o Bizspark (para startups)

Como você também está no .NET, recomendo que você use o TFB.

Se você não pode solicitar o Bizspark ou não pode comprar a licença, pode optar pelo CruiseControl.NET + MS Build e por alguns scripts de suporte. Em uma grande empresa de serviços públicos em que trabalhei, tínhamos usado o CruiseControl.NET para criar, testar, implantar e relatar todos os nossos projetos. Ele incluiu a implantação automática de serviços da web.


Eu não havia considerado essa opção, mas não acho que seria uma opção realista para nós, pois não estamos usando o TFS e vetamos tentativas de mudar para ele no passado (por orçamento e outros motivos). Mas obrigado pela sugestão que é uma ideia interessante.
RationalGeek

Não é tão expansivo. Se a sua gestão é sensível ao preço, o MS Build será uma combinação perfeita. Eu costumava trabalhar apenas com o MS Build + CruiseControl.NET e funcionou muito bem! Vou acrescentar isso na minha resposta.

@ Pierre 303: Por uma questão de curiosidade, por que você quer se livrar do Automated Build Studio?
RationalGeek

@ Pierre 303: A despesa do TFS não é a única preocupação. Minha loja faz parte de uma empresa maior, e eles padronizaram o Subversion e outras ferramentas, e ser "não padrão" e seguir o TFS causa problemas políticos.
RationalGeek

@jkohlhepp: não é fácil de usar, não está bem integrado ao Visual Studio (pelo menos a versão que tenho) e está longe de ser um padrão.

2

O FinalBuilder pode executar todos os itens solicitados, com uma boa interface gráfica do usuário e um aplicativo de servidor do construtor lançado gratuitamente.


2

Atualmente, estou fazendo o que você está fazendo (ou seja, do build ao empacotamento até a implantação) usando o MSBuild (> 3000 linhas de scripts). O IC está usando o CruiseControl.Net e espero poder mudar para o TeamBuild no futuro. O MSBuild é complicado (programação em XML), mas é bastante poderoso, especialmente o processamento em lote e o rastreamento de dependências. Ele é mantido e aprimorado ativamente nas novas versões .Net e é a base do sistema de criação no Visual Studio e no TFS. Também os arquivos de projeto do visual studio são na verdade projetos do MSBuild e posso conectar-me a vários pontos de extensão. O pacote de extensão MSBuildpossui muitas tarefas adicionais e é trivialmente fácil criar suas próprias tarefas programaticamente. Eu sugiro que o MSBuild pense seriamente. Ultimamente, também estou aprendendo PowerShell e facilitando determinadas tarefas, especialmente na fase de implantação, como instalar e configurar certificados, IIS etc.

Edite o projeto MSBuild no VisualStudio, pois ele compreende a sintaxe e fornece o intellisense. Aqui estão alguns outros utilitários que ajudarão o MSBuild.
Plataforma de Lançamento do MSBuild - Para extensões de shell
MSBuild SideKicks - Editar, executar e depurar scripts graficamente.


1

Talvez você esteja solicitando muito do script de compilação e não o suficiente do servidor de compilação - com team city, você pode facilmente ter scripts simples que realizam cada um de seus marcadores, em qualquer idioma ou pilha que faça sentido e use as tarefas de compilação do TeamCity para encadear as coisas, conforme apropriado.


Parece que a maioria dessas respostas está equiparando o IC a scripts de construção. Eu sempre considerei os scripts de compilação os mais inteligentes e o servidor de IC é o que inicia as compilações com base em gatilhos. Mas talvez você esteja certo e eu preciso repensar isso.
RationalGeek

1

Eu recomendo o TeamCity, é fácil de configurar e configurar. O MSBuild é preferível ao NAnt por uma simples razão: todos os arquivos de projeto / solução no vs2008 / 2010 são arquivos MSBuild tecnicamente, mas você pode configurar o TeamCity com o MSBuild ou o NAnt.

Claro, o TeamCity custará você. Eu, pessoalmente, tive uma escolha que preferiria o rake, simplesmente porque o atrito com as ferramentas Ruby comparado a outras, mesmo que o psake também seja um bom candidato.


11
O FYI TeamCity é gratuito se você tiver menos de 20 configurações de compilação e menos de 20 usuários. Além disso, se você é um projeto de código aberto, pode solicitar uma licença ilimitada gratuita.
RationalGeek

0

Você considerou Hudson ? Pode ser um aborrecimento, pois requer que o servidor de aplicativos Java seja executado, mas acho que poderia permitir que você usasse o script NAnt atual e desenvolvesse isso usando outras ferramentas.


Hudson é mais uma plataforma de integração contínua, e não realmente uma plataforma de construção. Temos um servidor de CI instalado - TeamCity, que funciona bem com o NAnt. No entanto, os motivos pelos quais desejo substituir o NAnt são porque a manutenção dos scripts do NAnt é dolorosa. O uso dos scripts atuais por meio do Hudson não resolve esse problema. Obrigado pela sugestão, no entanto.
RationalGeek

O IMHO Hudson é muito limitado no que faz corretamente com os projetos do VS. Os checkouts não estão vinculados aos conjuntos de alterações da maneira que você espera e, nos bastidores, ele não está fazendo nada além de executar um arquivo em lotes criado por meio de uma interface da web e muitos plug-ins. Os relatórios são agradáveis ​​se você conseguir que ele funcione bem.
Bill
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.