Como você atualiza sites ao vivo com alterações de código?

Eu sei que esta é uma pergunta muito básica. Se alguém pudesse me divertir e me dizer como eles lidariam com isso, eu ficaria muito agradecido.

Decidi postar isso porque estou prestes a instalar o SynchToy para solucionar o problema abaixo e me sinto um pouco profissional usando um "Brinquedo", mas não consigo pensar em uma maneira melhor.

Muitas vezes, quando estou nessa situação, sinto falta de uma maneira dolorosamente óbvia de fazer as coisas - isso vem de ser o único desenvolvedor da empresa.

• Aplicativo da Web ASP.NET desenvolvido no meu computador no trabalho
• A solução possui 2 projetos:
  • Site (arquivos)
  • WebsiteLib (C # / dll)
• Usando um repositório Git
• Implantado em um servidor Web GoGrid 2008R2

Desdobramento, desenvolvimento:

1. Faça alterações no código.
2. Pressione para Git.
3. Área de trabalho remota para servidor.
4. Puxe do Git.
5. Sobrescreva os arquivos ao vivo arrastando / soltando com o Windows Explorer.

Na etapa 5, excluo todos os arquivos da raiz do site. Isso não pode ser uma boa coisa a fazer. É por isso que estou prestes a instalar o SynchToy ...

UPDATE: Obrigado por todas as respostas úteis. Não consigo escolher qual deles marcará a resposta - entre o uso de uma implantação na Web - parece que tenho várias sugestões úteis:

1. Projeto da Web = site inteiro empacotado em uma única DLL - o lado negativo para mim não é possível enviar atualizações simples - sendo um desenvolvedor solitário em uma empresa de 50 anos, isso continua sendo algo mais simples às vezes.
2. Puxando direto do SCM para a raiz do site - originalmente não fiz isso por medo de que meu diretório oculto do SCM acabasse sendo exposto, mas as respostas aqui me ajudaram a superar isso (embora eu ainda não goste de ter um mais algo para se preocupar em esquecer para garantir que isso ainda seja verdade ao longo do tempo)
3. Usando um web farm e implantando sistematicamente em nós - esta é a solução ideal para zero tempo de inatividade, o que é realmente algo que me interessa, já que o site é essencialmente uma fonte de receita em tempo real para minha empresa - talvez seja difícil convencê-los a dobrar o custo dos servidores.

-> finalmente, o reforço do princípio básico de que é necessário implantar um único clique no site OU MAIS ALGO ERRADO é provavelmente a coisa mais útil que obtive das respostas.

ATUALIZAÇÃO 2: Pensei em voltar a isso e atualizar com a solução real que já existe há muitos meses e está funcionando perfeitamente (para minha solução de servidor Web único).

O processo que eu uso é:

1. Faça alterações no código
2. Push to Git
3. Área de trabalho remota para servidor
4. Pull from Git

5. Execute o seguinte script em lote:

   CD C: \ Usuários \ Administrador

   % systemroot% \ system32 \ inetsrv \ appcmd.exe interrompe o site "/site.name:Default Web Site"

   Documentos de robocopy \ code \ da \ 1 \ work \ Tree \ LendingTreeWebSite1 c: \ inetpub \ wwwroot / E / XF connectionsconfig Web.config

   % systemroot% \ system32 \ inetsrv \ appcmd.exe site inicial "/site.name:Default Web Site"

Como você pode ver, isso derruba o site, usa robocopy para copiar de maneira inteligente os arquivos que foram alterados e, em seguida, recupera o site. Geralmente, é executado em menos de 2 segundos. Como o tráfego de pico neste site é de cerca de 2 solicitações por segundo, é aceitável a falta de 4 solicitações por atualização do site.

Sine Fiquei mais proficiente com o Git. Descobri que os quatro primeiros passos acima, como sendo um "processo manual", também são aceitáveis, embora eu tenha certeza de que poderia rolar tudo em um único clique, se quisesse.

A documentação para AppCmd.exe está aqui . A documentação do Robocopy está aqui .

Você deve verificar a implantação na Web do VS 2010. Se o GoGrid suportar, o pacote de implantação na web é uma boa solução.

http://weblogs.asp.net/scottgu/archive/2010/07/29/vs-2010-web-deployment.aspx

No meu empregador anterior, para implantar alterações de código, definimos o balanceador de cargapara parar de servir em um servidor da web. Pode levar 20 minutos para as sessões no primeiro servidor da web expirarem. Atualizamos o código nesse servidor da Web descompactando o arquivo zip de implantação e, em seguida, verificamos se tudo está funcionando corretamente, pressionando o endereço IP direto do primeiro servidor da Web. Quando estamos convencidos de que tudo funciona bem, configuramos o balanceador de carga para atingir o servidor da web agora atualizado e aguardamos as sessões expirarem em outro servidor e atualizamos esse (e assim por diante até que todos eles sejam atualizados). Depois que o check-out foi aprovado, configuramos o balanceador de carga para voltar a fazer seu trabalho. Isso ficou complicado quando tínhamos até 10 servidores da Web conectados ao balanceador de carga durante os picos de carga sazonal (portanto, atualizá-los um a um pode levar horas, pois não é possível desligar o site ao vivo - os clientes precisam conseguir para o site).

No ASP.NET, se você soltar qualquer arquivo nomeado App_Offline.htmno diretório raiz de um site, o websiten será descarregado, permitindo que você atualize o DLLS (e o que for). O IIS exibirá uma página intitulada "Aplicativo offline". Quando o arquivo é removido, renomeado ou excluído, o aplicativo Web será reiniciado e o IIS exibirá páginas da Web nesse site. É isso que o Visual Studio faz quando você publica um site de dentro do VS.

Normalmente, o que faço é manter tudo em um repositório SVN. Quando termino algumas alterações, faço o commit no site de desenvolvimento e depois faço o checkout da produção. Mantém tudo sincronizado, é rápido e fácil. Se o check-out for muito complicado, você pode configurar o Apache com o WebDAV e ele fará isso por você.

Para cada um dos meus aplicativos da web, tenho uma configuração de repositório git com três ramificações. Ao vivo, beta, recursos. Ao vivo, é claro, o site ao vivo. Beta é o site usado para corrigir bugs ou para o teste final dos recursos imediatamente antes da implementação. Então, como você disse, eu faço um simples git push, git pull ao vivo para obter as informações. Os recursos são usados ​​para aprimoramentos da "próxima versão".

Você está tentando resolver o problema da entrega contínua . Inicialmente, você começaria com etapas manuais, mas em breve perceberá os problemas. Estes são os mais comuns:

1. O código funciona no seu PC, não funciona na produção
2. Nova mudança quebra o código antigo
3. Alterações incrementais tornarão cada vez mais difícil implantar, você obterá novas bibliotecas para anexar, patches para aplicar etc.

Dê uma olhada no TeamCity (ou qualquer ferramenta similar).

Use um script automatizado de criação e implantação

A melhor maneira de fazer isso é usar um Script de Compilação e Implantação Automatizado, como MsBuild ou Nant.

• https://www.justinshield.com/2010/06/automated-deploy-to-iis7-using-nant/

O motivo é que você pode simplesmente digitar o comando 1 para lançar um site e, em seguida, simplesmente digitar o comando 1 para recuperá-lo. E se você for minucioso o suficiente, isso incluirá as migrações do esquema do banco de dados. (Migrator.Net)

Um dos principais motivos para não usar SVN ou GIT para implantar é que o ambiente pode mudar entre produção e preparação. No script NANT, você pode criar seus arquivos .config especificamente para o ambiente que você está direcionando. Isso evita o esquecimento de inserir uma configuração na produção.

Ele também automatiza todo o processo, tornando-se um caso de comando único, e qualquer número de processos manuais torna-se um processo simples.

Primeiro, você deve estar usando um projeto da web. Quais são as diferenças que você pergunta?

Um projeto da Web combinará todos os arquivos da classe C # (código por trás incluído) em uma única DLL (melhor para segurança e o fato de ser um arquivo a ser movido)

Segundo, você deve publicar o aplicativo e, em seguida, ainda pode usar a área de trabalho remota, arrastar todos os arquivos na sua pasta de publicação e simplesmente configurá-lo para sobrescrever (novos arquivos substituirão os antigos).

A publicação colocará todos os arquivos necessários para o aplicativo em uma pasta.

Meu empregador atual implanta usando fantoche . (Aqui estão mais pacotes de software que abordam o mesmo problema.)

Meu empregador anterior usou um sistema de controle de tarefas personalizado para lidar com a implantação de software, a reinicialização etc. Mesmo que estivesse disponível, era um exagero para suas necessidades.

O empregador que eu tinha anteriormente tinha scripts personalizados para copiar dados do subversion para servidores e fazer uma reinicialização contínua.

Vários lugares que vi anteriormente criaram arquivos para gerenciar a implantação. Eles geralmente usavam uma estratégia como cortar metade dos servidores Web do balanceador de carga, aguardar, parar a metade, distribuir o código, reiniciá-los e, em seguida, inverter o balanceador de carga, aguardar, parar a outra metade, reiniciá-los e trazer o balanceador de volta acima.

Em todos os lugares em que trabalhei, o lançamento do código era um único comando ou a falta de um único comando foi reconhecido como um problema a ser corrigido.

Normalmente, o que usamos para resolver esse problema com nossos sites é uma ferramenta incluída no Systems Internals chamada junção.

Usando esta ferramenta, somos capazes de criar links de um diretório para outro. A raiz do aplicativo no servidor contém 3 pastas. Vermelho, azul, atual. O IIS está configurado para sempre olhar em Atual para seus arquivos.

Você pode emitir um comando junction currentque lhe dirá qual pasta atual está apontada no momento. Digamos, por exemplo, que ele estava atualmente apontando para o azul. O que faríamos é enfileirar os arquivos em vermelho para a nova implantação e garantir que toda a configuração esteja pronta.

Quando estivermos prontos, podemos emitir o comando junction current redpara que ele reponha.

Há duas coisas que tornam essa solução tão boa

1) Você tem todo o tempo do mundo para enfileirar suas alterações na pasta. Sem pressa e o único tempo de inatividade é quando o pool de aplicativos está girando. (Existe uma maneira de pré-compilar esta etapa também.)

2) Se algo der errado com sua implantação, tudo o que você precisa fazer para reverter é emitir um comando em vez de tentar reverter as alterações. O comando no nosso caso seriajunction current blue

Esperamos que nossa maneira de fazer as coisas possa lançar alguma luz sobre uma nova solução para você.

O que fiz e não tenho certeza se você tem margem para isso, mas aqui vai. Um desenvolvedor verificaria o código em uma ramificação de controle de qualidade e, em seguida, seria carregado para um ambiente de controle de qualidade por um engenheiro de sistemas. Depois que passasse o controle de qualidade, seria promovido para a ramificação de produção. Havia pelo menos 2 de todos os sites conectados a um servidor com um balanceador de carga equivalente, nesse caso, um dos dois servidores seria colocado offline. quaisquer alterações do iis necessárias, o iis seria reiniciado e você passaria para o próximo servidor. Tudo isso foi script usando C # no nosso caso, mas foi feito no passado usando o script vb. Espero que ajude. Felicidades