Para tudo, basta 50 xícaras de café.
Além da regra geral descrita acima, publicamos uma breve nota sobre os pontos que precisam ser prestados com muita atenção, para que nada ocorra na batalha e nos processos. A observação foi feita em busca do lançamento de um serviço móvel que migrou completamente para o .Net Core (o começo foi definido aqui ). Conseguimos realizar essa operação despercebida pelo cliente, quase sem interromper o processo principal de desenvolvimento.
Abaixo está um plano de ação pronto, haverá uma lista de testes muito ampla, esta imagem estará aqui para o clima:
Então, nas etapas:
1. Planeje um sprint longo com grandes recursos e / ou regressão
Com a reescrita de código fundamental, o serviço precisará de tempo para insistir o máximo possível, a fim de ter tempo para corrigir todas as falhas no ambiente de teste.
2. No sprint exato para reescrever o código no .Net Core
Por que é importante não iniciar esse negócio com antecedência? Como você precisa puxar duas ramificações de código com o novo e o antigo .net, porque a qualquer momento um pássaro de urgência pode chegar ou você precisará realizar uma demonstração dos novos recursos e precisará fazer alterações no antigo ramo estável. Para experimentar uma preocupação mínima com isso, é melhor diminuir o momento do estado de transição.
A propósito, ao trabalhar com o código, chegamos rapidamente à conclusão de que é mais conveniente manter duas cópias do repositório localmente. É mais fácil e conveniente do que trocar duas ramificações enormes.
- Se possível, reescreva as interfaces WCF na webapi nos serviços usados
A implementação do .Net Core do cliente WCF ainda está longe do ideal. Apesar de as feridas antigas estarem de alguma forma consertadas, nas novas versões você ainda precisa usar a solução alternativa ( 1 , 2 ).
Para a história: no .Net Core 2.0, a versão estável do WCF é 4.4.2 do repositório myget. Ela, por exemplo, não tem problemas com um tempo limite inicial
No início da migração, usamos a versão do .Net Core 2.0. Enquanto isso, a Microsoft lançou o .Net Core 2.1. Quem está interessado em admirar o sucesso dos Redmond em otimizar a plataforma, leia o progresso do mecanismo de pesquisa do Bing ao atualizar para a nova versão (spoiler: latensi caiu 34%!)
Também atualizamos para o .Net Core 2.1 e o WCF 4.5.3. E não esquecemos de especificar no Dockerfile uma nova imagem básica da microsoft / dotnet: 2.1-aspnetcore-runtime. Qual foi a surpresa quando, em vez de 1,4 GB, eles viram um tamanho de imagem de 0,5 GB (estamos falando de uma imagem do Windows, se de repente).
3. Prepare-se para um teste e demonstração
Temos dois ambientes à nossa disposição. Deixamos a demo com a versão antiga como referência. Um novo serviço foi implantado no ambiente de teste - uma execução em desenvolvedores e testadores.
Houve alguma confusão devido ao fato de que os desenvolvedores geralmente trabalham com o teste e os testadores principalmente com uma demonstração. Se fosse necessário atualizar o serviço antigo, a situação era exatamente o oposto do normal. Portanto, uma discussão e uma folha de dicas sobre onde e o que procurar foram úteis.
Para executar o serviço .Net Core no IIS, você deve instalar o módulo que acompanha o tempo de execução.
AppPool alterne para CLR Runtime = Sem Código Gerenciado.
Na solução no web.config padrão , é importante não esquecer de definir o requestTimeout desejado e desativar o módulo WebDAV, se houver métodos DELETE.
Além disso, existem duas opções para publicar um serviço no IIS:
- você faz a sincronização do MSDeploy - significa que você precisa adicionalmente da opção -enableRule: AppOffline
- você publica o arquivo - significa exatamente antes da publicação que você precisa colocar o arquivo app_offline.htm no diretório de serviço e, após a publicação, excluí-lo
Tanto isso como outro permitem interromper um processo de trabalho e abrir arquivos executáveis. Caso contrário, ocorrerá um erro que os arquivos não estão disponíveis para substituição.
Recusamos o log via Nlog em favor do Serilog e perdemos a compactação automática de logs - no Serilog simplesmente não existe esse recurso. Nesse caso, você pode ser salvo usando ferramentas comuns do Windows e instalar a compactação NTFS nas propriedades do diretório.
4. Teste
Aqui está a lista de verificação mais reduzida para os lugares mais frágeis:
- verifique o retorno dos códigos de status Solicitação incorreta, Não autorizado, Não modificado, Não encontrado - tudo o que a API pode oferecer
- verifique o log de solicitação para todos os códigos de status
- faça um diagrama de dependências externas; Como regra, todas as informações necessárias estão em appsettings
- banir métodos que afetam seu trabalho
- verificar o log de solicitações externas
- verifique o funcionamento das configurações para os parâmetros de configurações de aplicativos; tente mudá-los para quente
- verifique o cache http quanto a códigos de status positivos e negativos
- Cabeçalho ETag
- controle de cache do cabeçalho
- verifique solicitações longas e tempos limite
- verifique pedidos com uma resposta vazia
- verifique os métodos DELETE (o WebDAV está desativado ou não)
- verifique o trabalho com conteúdo bruto
- carregar e baixar um / vários arquivos
- fazer upload de arquivos com tamanho acima do limite
- layout do cabeçalho Disposição de conteúdo
- verifique todos os outros cabeçalhos; juntá-los em código é bem fácil
- verifique a execução condicional do código ao alternar ambientes
if (env.IsDevelopment()) - verifique desconectar do cliente e servidor
- compare com o swagger.json padrão - ajudará a detectar a diferença nos campos transmitidos
Nosso aplicativo móvel usa um gerador de código para trabalhar com a API com base na descrição do swagger.json, por isso era importante que a diferença da descrição original fosse mínima. Na versão mais recente do Swashbuckle.AspNetCore, a interface e o swagger.json gerado mudaram bastante. Eu tive que reverter para a versão surrada do Swashbuckle.AspNetCore 1.2.0 e adicionar alguns filtros.
5. Prepare-se para uma briga enquanto bebe café
No nosso caso, o ambiente de combate consiste em dois nós: ativo e passivo.
Para que a mudança para o novo serviço passe despercebida, duplicamos o pool e o site em cada nó e escrevemos um script para alternar a ligação entre o site antigo e o novo.
Assim, em caso de emergência, fomos capazes de mudar rapidamente para a versão antiga.
Além disso, após a implantação na batalha, em uma semana nos convencemos da viabilidade do serviço e acendemos uma luz verde para o lançamento do aplicativo móvel. A vida no projeto retornou com segurança ao curso anterior.
Subtotal
Agora, nosso serviço está totalmente pronto para aumentar um contêiner de docker para entrega ao cluster. Estamos prontos para implantação no Kubernetes e no Service Fabric.
Agora, os preparativos estão em andamento para a apresentação da nova infraestrutura ao cliente. Vamos contar sobre as nossas realizações na próxima série, mantenha o dedo no pulso;)