Práticas recomendadas de implantação / manutenção do ASP.NET

Estou no setor de desenvolvimento web há cerca de 5 anos, sempre trabalhando em um ambiente de código aberto. Principalmente apache, mysql e php com um pouco de ruby, usando git para controle de versão. Mas, recentemente, assumiu um cargo em que o desenvolvimento é inteiramente em C # ASP.NET MVC.

Embora eu tenha aprendido o idioma facilmente, etc, os outros membros da minha equipe (com muito mais experiência em MS Development do que eu) têm uma maneira diferente de pensar quando se trata de publicar e implantar o site final, e mudanças particularmente futuras.

A mentalidade com os outros desenvolvedores é que, depois que um site é publicado, ele é final. Não é possível fazer mais alterações no site, quando perguntei as razões por trás disso, as respostas foram que é muito perigoso, demorado ou difícil.

De minha experiência anterior, atualizar um site é simplesmente o caso de fazer upload dos arquivos alterados, o que geralmente é bastante rápido se houver uma pequena alteração ou colocar o site no modo de manutenção enquanto a atualização ocorre.

Publicamos recentemente um site MVC, e a empresa entrou em contato conosco para atualizar parte do texto e adicionar um link a um novo documento pdf. O resto da minha equipe foi rápido em dizer que isso não deveria ser feito, porque o site agora está ativo e não deve ser modificado. Há algo que eu perdi por não ser 'criado' como desenvolvedor da Microsoft?

Qual é o argumento contra a modificação de um aplicativo Web ao vivo em produção e essa mentalidade é exclusiva para desenvolvedores .NET?

Eu realmente gostaria de entender essa mentalidade e se ela se justifica em um ambiente de desenvolvimento da Microsoft ou se essa é apenas uma maneira mais antiga de pensar.

NOTA: Usamos o TFS para controle de versão e usamos perfis de publicação para determinar onde o site é implantado (UAT ou Produção)

Aplicativos ASP.NET MVC são compilados. Isso significa que você não pode simplesmente enviar os arquivos alterados, como você faz em um site PHP, por exemplo. Isso também significa que, quando você começar a atualizar o site, os usuários atuais serão descartados (perderão as sessões, por exemplo).

Também há muito mais a fazer do que simplesmente atualizar os arquivos: você precisa lidar com:

• Permissões

  A nova versão pode exigir um conjunto diferente de permissões no servidor.

• Configuração

  A nova versão pode exigir que o serviço Coordenador de Transações Distribuídas (MSDTC) seja instalado, ou queira usar um servidor SMTP diferente ou ter acesso ao Active Directory, etc. Isso envolve alterar a configuração do aplicativo e do próprio servidor .

• Dependências

  Por exemplo, um dos problemas frequentemente encontrados pelos iniciantes é que eles mantêm DLLs antigas /bine adicionam novas com nomes diferentes: o aplicativo ainda pode usar as antigas, o que cria uma situação louca na qual você altera o código do aplicação, mas o comportamento da aplicação permanece o mesmo.

• Dados

  E se o esquema do banco de dados fosse alterado e o aplicativo usar um servidor SQL comum em vez do NoSQL? Como executar a alteração no esquema? Como manter os dados corretos durante a alteração?

Lidar com a transição entre uma versão antiga e uma nova do aplicativo é uma tarefa difícil. Alguns anos atrás, era um dos problemas em que uma nova versão do aplicativo estava pronta, mas levava dias ou semanas para os administradores do sistema implantarem. O DevOps soluciona esse problema, mas exige que os desenvolvedores descrevam (por meio de código ou configuração) o sistema que hospedará o aplicativo.

Quanto maior a aplicação, mais complicada é essa tarefa.

• Para um pequeno aplicativo Web, copiar os arquivos de origem para o servidor é suficiente,

• Para algo maior, você precisa ter um processo automatizado que lide com o processo de atualização e a reversão caso algo dê errado,

• Para sistemas ainda maiores, a cada nova versão, novas VMs são criadas e implantadas, e as antigas são recicladas, garantindo a transição perfeita dos usuários da versão antiga para a nova.

Os aplicativos compilados simplesmente forçam / incentivam a automatizar o processo anteriormente.

a empresa entrou em contato conosco para atualizar parte do texto e adicionar um link a um novo documento pdf. O resto da minha equipe foi rápido em dizer que isso não deveria ser feito, porque o site agora está ativo

OMI, não há razões técnicas reais para essa recusa; eles só querem evitar fazê-lo, porque, se não for bem automatizada, a tarefa estará sujeita a erros .

O que geralmente acontece é que:

1. O aplicativo é implantado pela primeira vez.

2. A equipe passa algumas horas ajustando a configuração para fazê-la funcionar. Como era esperado que a equipe entregasse há três semanas, todo mundo corre, e ninguém faz as anotações das mudanças.

3. O aplicativo está agora em funcionamento.

4. Por algumas semanas, meses ou anos, algumas pessoas aleatórias alteram algumas coisas aleatórias no servidor: por exemplo, elas movem um banco de dados para um local diferente ou a senha SMTP é alterada, causando as alterações no Web.config.

Se você atualizar a nova versão agora, retornará à primeira etapa e poderá levar dias para recuperar a configuração correta. Como o site está ativo, isso deve ser evitado a todo custo.

Você tem gerentes de projeto, gerente de desenvolvimento ou outra pessoa que não os outros desenvolvedores?

Faz ZERO o sentido de que você não pode fazer uma implantação depois de entrar no ar.

É claro que essas mudanças precisam ser agendadas, custadas e com recursos entre outras coisas, mas apenas dizer "não" não faz sentido.

A principal razão do comportamento que você está vendo é que esses tipos de alterações são propensas a erros. A atualização manual do aplicativo faz com que as coisas sejam esquecidas e ficar fora de sincronia. Você ainda deve poder fazer novos lançamentos (e deve ser fácil) , mas não patches parciais.

Atualizações parciais, como alterar algum CSS ou texto em um site ao vivo, podem fazer com que os ambientes de teste, teste ou estágio sejam ignorados ou até mesmo não comprometam o código no controle de origem. Se for uma alteração no código, você pode acabar quebrando o site ao vivo sem nenhum plano de recuperação.

No .NET, porque o código é compilado, pode haver outros problemas, como longos tempos de carregamento e perda de sessões do usuário. Esses problemas podem ser mitigados na minha troca para um ambiente quente e no uso do estado da sessão fora do processo. No entanto, a menos que você queira pensar sobre esses tipos de problemas e outros específicos do seu aplicativo sempre que quiser fazer uma implantação. Em seguida, corrigir sites ativos é uma má idéia.

À medida que seu aplicativo cresce em tamanho e as pessoas vão e vêm, isso pode passar de um inconveniente para um problema sério. Portanto, para tornar as coisas mais seguras, seguimos regras como: Para atualizar um site ativo, ele deve ser uma implantação completa, nunca apenas corrigida.

Se você ainda não está automatizando suas implantações (o que torna fácil e rápido seguir a regra). Geralmente, novas implantações são feitas próximas à versão existente e, em seguida, seu site é apenas um ponteiro para a versão desejada (o esquema do banco de dados de nota torna isso um pouco mais complexo).

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

Na realidade, acho que todas as implantações devem ser realmente automatizadas e isso inclui implantações não .NET, por razões semelhantes. Depois de começar a automatizar as implantações, você pode garantir que elas sejam consistentemente rápidas e confiáveis.

Eu republico / reimplanto regularmente alguns sites ASP.NET MVC implantados no Amazon AWS, Windows Azure e servidores da web privados e não vejo nenhuma razão para que sua equipe faça isso muito.

No entanto, você deve projetar seus sites de tal maneira que tarefas como atualizar textos e links sejam executadas no banco de dados por meio da interface de administração do site.

O que quero dizer é que, embora as alterações em um site ativo sejam aceitáveis ​​(é chamado de desenvolvimento), a reimplantação do aplicativo para alterar uma sequência de texto provavelmente indica um design incorreto. Não estou sugerindo que a republicação possa ser feita sem cuidados.