Como você implanta seu aplicativo da Web .NET? (Recomendações, por favor!)

Recentemente, atualizamos nosso site ASP.NET para um aplicativo Web e ficamos chocados com o súbito salto de dificuldade ao implantá-lo. Considerando o quão comum essa tarefa deve ser, fiquei pensando que plug-ins / software as pessoas usam para implantar um projeto em rápida evolução e armazenado remotamente (por exemplo, um site).

Deve haver uma maneira melhor do que apenas "Publicação" no Visual Studio e, em seguida, ter que FTP manualmente os arquivos que foram alterados? Não menos importante, porque o site é desativado quando estamos carregando nossos .DLLs.

Há tantas exceções de arquivo complicadas que eu devo automatizar o processo o máximo possível, para evitar envios acidentais.

Com a nossa solução antiga (em nosso site), usamos o Dispatch for ASP, que abalou totalmente e transformou todo o processo em um clique. Infelizmente, não é ótimo para DLLs (como mencionado anteriormente).

Então, como sua equipe faz isso?

Obrigado por qualquer conselho.

PS - Eu li que o Visual Studio 2010 deveria solucionar essas deficiências no VS2005 / 08, mas até então ...

Eu recomendo fortemente o uso da integração contínua.

Usamos uma combinação do TeamCity para CI, Rake e Albacore para automatizar a compilação.

O TeamCity verificará o código do seu repositório de código-fonte e, usando Rake, construa o aplicativo, execute testes de unidade e até mesmo execute os scripts do banco de dados, se desejar. Após uma compilação bem-sucedida, você pode empacotar seu código-fonte em um arquivo zip ou copiá-lo para um destino de sua escolha.

Usamos o Git, embora o TeamCity funcione com todos os sistemas de controle de origem.

O uso do TeamCity e Rake seria semelhante ao uso do CruiseControl e do NANT, sem a edição do arquivo XML. Obviamente, você pode usar o TeamCity com NANT, se preferir.

Uma pequena amostra retirada de um rakefile.rb que executa a compilação. IMHO, mais fácil de ler e depurar do que um arquivo XML.

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacore é um conjunto de tarefas Rake criadas especificamente para implantar o aplicativo .NET.

No Linux, usei fabric (fabfile.org) e capistrano (capify.org), que são ferramentas de automação para auxiliar nos comandos SSH e SCP remotos. Se você tiver o Cygwin instalado nos hosts do Windows, poderá reutilizá-los como ferramentas de implantação.

A publicação de um aplicativo Web no Visual Studio pode ser executada na linha de comando como msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". O diretório de destino é um aplicativo da web implementável.

As outras respostas que cobrem sua pergunta maior são boas. Eu também acrescentaria que você deve examinar vários projetos de aplicativos da web de código aberto e copiar o processo de criação que mais gosta.

Concordo com Scott que isso pode ser muito complicado e facilmente esquecido. A estratégia de implantação também é muito específica para aplicativos. Se seu aplicativo for completamente independente em uma pasta, pode ser mais fácil do que um aplicativo que faça referência ao GAC. O que, por sua vez, pode ser mais fácil ainda do que um servidor que precisa manter várias versões de um aplicativo que faz referência a várias versões de assemblies do GAC. Não queremos começar a falar sobre arquivos de políticas aqui :).

Dito tudo isso, combinar a Microsoft Web Deployment Tool com o Application Request Routing é uma boa opção. No IIS7, é possível criar pacotes de instalação usando a ferramenta. Também é possível apontar a ferramenta para um aplicativo Web e fazer backup do aplicativo inteiro em uma pasta de arquivamento de aplicativos. Você pode implantar a partir desta pasta de arquivamento em um servidor Web IIS6 ou IIS7 (IIS5 não suportado). Eu usaria o roteamento de solicitações de aplicativos, como Scott sugeriu para separar os sites ao vivo dos sites de teste. Depois de verificar se o site recém-publicado é bom, você pode definir o ARR para rotear para a nova versão.

PyroBatchFTP funciona muito bem para isso. Ele enviará apenas as alterações e você poderá criar um script para que seja possível clicar duas vezes em um arquivo em lotes.

Na Vaasnet , configuramos a solução dos sonhos para nós mesmos, mas ela é bastante envolvida, mas vale a pena usar alguns ou todos esses elementos, se possível. Aqui está o que é:

• SVN em todas as nossas máquinas de desenvolvimento
• SVN em nosso servidor de criação / implantação
• O Cruisecontrol.net observa as alterações no SVN e cria e prepara apenas os arquivos necessários em uma pasta de teste
• usando o PyroBatchFTP, enviamos para um site de teste (acionado pelo Cruisecontrol para que isso aconteça automaticamente)
• usando o IIS7 e o Application Request Routing (ARR) e a reconfiguração de URL, temos a seguinte configuração de preparação / produção:
  • O ARR antecipadamente direcionará o tráfego para a instância 01 ou 02, dependendo de qual é 'ao vivo' e qual é 'estadiamento'
  • a conta FTP está sempre vinculada a 'teste'
  • Eu tenho outro mini site de administração que trocará a preparação e viverá com um único clique. Leva apenas 1 segundo para alternar com zero tempo de inatividade e podemos voltar novamente se percebermos que algo estava errado com essa versão (embora seja raro, pois podemos testá-la com tanta facilidade antes de entrar no ar).

Portanto, o resultado líquido nos permite verificar o SVN e fazer com que ele seja compilado e enviado automaticamente para produção sem nenhuma interação manual. Depois de testarmos nosso URL de teste e determinarmos que ele está pronto para ser publicado, fazemos login em um site simples e, com um clique, ele fica ativo.

Por outra maneira que não foi sugerida, refiro-o aos 'Gu' e aos Projetos de configuração da Web

Isso basicamente cria um instalador MSI para seu aplicativo .NET. Este exemplo é para o VS2005, mas eu tenho o VS2010 e o tipo de projeto ainda está lá. Isso pode lhe dar muita personalização, se você precisar, ou apenas a instalação básica, se não precisar.

Pessoalmente, onde trabalho, fazemos uma implantação no estilo xcopy, mas eu gostaria de entregar um pacote ao grupo de servidores, dando a eles o controle de quando e como ele será implantado. (Acho que isso também facilita a implantação em massa usando algo como política de grupo, mas não estou muito familiarizado com isso)

Existem várias maneiras de esfolar esse gato, realmente depende de quanto acesso você pode ter no seu servidor. Meu método favorito pessoal ultimamente é configurar um script de compilação no projeto (normalmente usando o MSBUILD) que empacota todos os arquivos de implantação e, em seguida, usa o SVN para conectar esses arquivos à produção. E para versão dos arquivos de produção.

Em termos de banco de dados, a melhor aposta é usar algum tipo de estrutura de migração. Novamente, um monte de pessoas correndo e nenhuma resposta clara.

Pessoalmente, eu apenas uso um script vbs que escrevi para copiar pastas de tipos de arquivos específicos para o servidor dev (ou seja, deixar de fora os arquivos cs, etc.).

Quando trabalhei em uma grande empresa .com, foi isso que fizemos com nossas implantações .net.

Todo o nosso código-fonte e procedimentos armazenados foram armazenados no SVN. Todas as noites, um trabalho de banco de dados executa e puxa os procs armazenados de produção e os coloca em um diretório no SVN para que sempre houvesse a versão mais atual no controle de origem.

No dia da implantação de um projeto, usaríamos um script nAnt para extrair os projetos do SVN, criar uma construção personalizada dos projetos e extrair quaisquer dependências necessárias para esses projetos. Depois que o script nAnt foi executado, ele foi empacotado em um arquivo zip com extração automática. Os procs armazenados associados a essa implantação foram verificados no controle de origem e uma planilha do Excel foi atualizada com os scripts a serem executados e em que ordem.

Quando o deploymenet foi desativado, o arquivo zip com extração automática foi transferido para o servidor em que foi iniciado. Todos os arquivos foram extraídos nos diretórios corretos e o DBA executou os procedimentos armazenados no banco de dados da produção.

Em uma implantação típica usando esse sistema, passamos de uma implantação de cinco a seis horas para menos de uma hora ou menos.

Boa sorte e espero que isso ajude alguns a descobrir uma maneira de implantar seu aplicativo.

Deve haver uma maneira melhor do que apenas "Publicação" no Visual Studio e, em seguida, ter que FTP manualmente os arquivos que foram alterados?

A navalha de Occam é normalmente a abordagem preferida: quanto mais simples, melhor. O FTP é fácil, com pouca ou nenhuma complicação. Algumas pessoas usam XCOPY, Filezilla ou WSFTP, outras podem usar a MS Web Deployment Tool (com a qual ainda não estou familiarizado), mas, apesar de tudo, existe uma maneira melhor de implantar aplicativos Web do ASP.NET (e outros aplicativos em geral). Na IMO, se a implantação for levada em consideração desde o início do desenvolvimento, ela poderá ser integrada ao aplicativo Web, o que resultará em uma implantação suave e sem dor no futuro.

Como desenvolvedor .NET que trabalhou em várias empresas desenvolvendo aplicativos Web ASP.NET com tamanho, complexidade e número de usuários (de várias centenas de usuários a dezenas de milhares), a 'implantação' da IMO geralmente é o tópico mais "fluido". Algumas organizações levam isso muito longe em termos de burocracia, enquanto outras não tratam de nenhum problema com a implantação. Na minha experiência, os problemas com a implantação tendem a se enquadrar em 1 ou mais de 3 categorias em termos de dificuldades / falhas:

1. A implantação é ignorada / esquecida em profundidade durante a fase de design: a maioria dos aplicativos da Web tende a incorporar um servidor da Web e um banco de dados. Além do código do aplicativo, talvez alguns procedimentos armazenados e tabelas de banco de dados, a implantação não precisa de muita reflexão. ASP.NET é mais do que capaz de auxiliar na implantação, mas na maioria das vezes os desenvolvedores estão distraídos em termos de obter a aplicação real correndo e fazendo a sua tarefa, deixando o como de implantação como uma questão separada.

2. A implantação é complexa em vários sistemas e pessoas em jogo: a complexidade é uma chatice. No MSMQ, procedimentos e gatilhos armazenados T-SQL, Reporting Services, mensagens SOAP / XML, autenticação AD, SSAS / SSIS, etc. etc. o número de tecnologias em jogo aumenta o número de pessoas envolvidas. O pior de tudo é que todos esses componentes diferentes geralmente são gerenciados por diferentes entidades dentro de uma organização. A menos que todos estejam sincronizados, as implantações podem aumentar a complexidade rapidamente, levando a vários pontos de falha.

3. Preguiça, apatia ou falta de comunicação e / ou gerenciamento: de pouca ou nenhuma documentação à falta de comunicação e protocolo coordenados, é fácil estragar um processo relativamente simples. A implantação deve ser um procedimento simples, com inúmeras verificações, documentando o que está sendo feito, mas muitas vezes nunca é o caso. A maioria das pessoas só quer que o maldito site esteja funcionando. Na minha experiência, as pessoas (não programadores) realmente não se importam até que algo fique realmente fubar. A responsabilidade raramente recai sobre apenas uma pessoa para realmente fazer a implantação, pois ninguém realmente quer ser o motivo do fracasso, de modo que a responsabilidade geralmente é dispersa.

Há tantas exceções de arquivo complicadas que eu devo automatizar o processo o máximo possível, para evitar envios acidentais. Então, como sua equipe faz isso?

Não conheço nenhum fornecedor disponível para automatizar a implantação, embora não me surpreenda se houver alguns. Provavelmente, você pode criar um script de uma solução via VBScript / WMI ou fazer o lote de scripts de uma solução, mas a realidade é que você precisa adaptar uma solução para sites ASP.NET mais complexos. Sites simples que consistem em páginas, conectividade de banco de dados e nada mais, você não precisa fazer quase tanto para dimensionar seus esforços de implantação de acordo com a complexidade do próprio aplicativo.

Até agora, no meu trabalho atual, a implantação ainda é feita via FTP e a movimentação de vários arquivos. É feio, fácil de estragar e não há sentido de uma história precisa. Concedido que você poderia vasculhar os logs de FTP, ninguém realmente se incomoda em fazê-lo. Nossos aplicativos são bastante simples, sem muita necessidade além do FTP. Como minha equipe implementa nossos aplicativos da Web é muito pouco ou nada útil para você. Em vez disso, prefiro usar esta oportunidade para sugerir melhores práticas.

• Supor nada. Contas de usuário, privilégios R / W / X, ACLs, firewalls, tempo (quando implantar e quanto tempo você precisa ) e, se possível, teste a implantação em todos os ambientes antes da "data de lançamento" final.
• Antes que o desenvolvimento realmente comece, considere a implantação no desenvolvimento. Se é um site simples, que assim seja. Se houver várias partes móveis, leve em consideração tudo isso e construa um plano para o qual todos os componentes (código, banco de dados, relatórios, filas etc.) estejam todos no mesmo plano.
• Coordene com outras paridades e comunique-se de forma eficaz e eficiente.
• Documente o máximo possível de informações pertinentes.
• Ambiente: um servidor web versus web farm; 32 bits vs. 64 bits; encontre uma maneira de monitorar logs / erros / rotação, etc.
• Encontre (ou construa) ferramentas que possam ajudar na implantação.
• Se possível para implantação programável, escolha um paradigma e atenha-se a ele. Por exemplo, se você deseja usar um servidor de banco de dados como o principal meio para executar o estado, a implantação, o acesso de um aplicativo e outros, assine-o no aplicativo e atenha-se a ele. Se você preferir ler arquivos XML (como web.config) de qualquer maneira, fique com um paradigma consistente de implantação do aplicativo. Outro exemplo: algumas organizações deixam o web.config como um arquivo estático em cada ambiente que não deve ser implantado em outros ambientes. O programa web.config de outros, de forma que possa ser implantado em ambientes sem erros.

Sei que este post pode ser um exagero para a pergunta que foi feita originalmente. Infelizmente, a implantação não é uma coisa simples, pois os aplicativos podem variar em complexidade. Aposto que a maioria das organizações que implantam aplicativos ASP.NET complexos desenvolveu ao longo do tempo certas estratégias que funcionam (pelo menos) de maneira confiável.