Atualizações com falhas indicam um problema mais profundo


Windows 10 na apresentação de Tóquio julho de 2015

Obviamente, a atualização do Windows de 10 de outubro de 2018 não foi a mais bem-sucedida. Apareceram rapidamente mensagens sobre a perda de arquivos nos computadores, e a Microsoft parou de distribuir a atualização. Desde então, o bug foi corrigido , agora uma nova atualização está sendo testada antes de seu relançamento.

Esta não é a primeira atualização do Windows a ter problemas - nas atualizações anteriores vimos coisas como incompatibilidades significativas de hardware - mas claramente ficou pior. A maioria de nós sabe sobre backups, mas, na realidade, muitos dados, especialmente em computadores domésticos, não têm backup e seu desaparecimento é muito desagradável.

Windows como um serviço

No Windows 10, planejava-se alterar radicalmente o processo de desenvolvimento. A Microsoft queria responder melhor às necessidades dos clientes e do mercado - e mais frequentemente lançar novos recursos. O Windows 10 foi apresentado como a versão "mais recente" do Windows. Assim, todos os novos desenvolvimentos se tornarão atualizações do Windows 10, entregues através do sistema de atualização várias vezes ao ano. Esse novo modelo de desenvolvimento é chamado Windows como serviço. E, depois de uma confusão inicial, a Microsoft decidiu duas atualizações funcionais por ano : em abril e outubro.

Esses esforços foram bem sucedidos. A Microsoft está lançando novos recursos úteis para o novo modelo, sem forçar os usuários a esperar três anos para atualizar a versão principal. Por exemplo, um recurso conveniente foi lançado para o lançamento invisível do Edge em uma máquina virtual , que oferece maior proteção contra sites mal-intencionados. O Windows Subsystem for Linux (WSL), que permite a execução nativa de programas Linux em um sistema Windows, tornou-se uma ferramenta para desenvolvedores e administradores. Os benefícios para usuários comuns são um pouco mais difíceis de notar, mas você pode mencionar os recursos de VR compatíveis com o SteamVR , o desempenho aprimorado do jogo e um tema sombrio . Embora as melhorias não sejam tão significativas, em geral, o atual Windows 10 é certamente melhor do que o lançado três anos atrás.


Nos dias em que o Windows era atualizado apenas a cada três anos, era difícil imaginar que a WSL se tornasse uma ferramenta útil.

Tudo isso é bom, e algumas coisas dificilmente poderiam ter sido feitas (pelo menos com o mesmo sucesso) sem a introdução do Windows como modelo de serviço. O desenvolvimento da WSL, por exemplo, foi baseado no feedback do usuário. Os usuários falaram sobre incompatibilidades encontradas e ajudaram a priorizar o desenvolvimento de novos recursos. Não creio que a WSL receba esse ímpeto de desenvolvimento sem um progresso constante de atualização a cada seis meses - ninguém iria querer esperar três anos para ver uma correção menor. Por exemplo, para que um pacote importante comece a funcionar corretamente. As atualizações regulares recompensam as pessoas por mensagens de erro, porque todo mundo vê que os erros são corrigidos em tempo hábil.

O problema com o modelo do Windows como serviço é a qualidade. Problemas anteriores com esse modelo e as atualizações de segurança já minaram a confiança na política de atualização do Windows 10. Os usuários experientes acreditavam que a qualidade das atualizações mensais de segurança diminuía no Windows 10 e a instalação de atualizações semestrais de recursos assim que saem é insana . Essas reclamações também têm uma longa história. As atualizações ruins se tornaram motivo de preocupação logo após o lançamento do Windows 10.

O último problema com a exclusão de arquivos levou os especialistas a pensar que podem haver muitas atualizações de recursos por ano . Redmond deve reduzir seu número para um, e a Microsoft deve suspender o desenvolvimento de novos recursos e apenas corrigir bugs . Alguns temem que a empresa esteja perigosamente perto de uma séria perda de confiança nas atualizações, e para alguns usuários do Windows essa confiança já está perdida.

Essas não são as primeiras chamadas para a Microsoft para desacelerar as atualizações de recursos - temia-se que tudo isso seja difícil de digerir tanto para departamentos de TI quanto para usuários comuns, mas com os problemas óbvios da atualização mais recente, essas chamadas se tornam especialmente relevantes.

Não é uma questão de frequência, mas de COMO as atualizações estão sendo preparadas

Mas aqueles que insistem em uma atualização por ano, em vez de duas, perdem o objetivo. O problema não é a frequência de saída. O problema está no processo de desenvolvimento da Microsoft.

Por que o problema não está em termos? Podemos ver os agendamentos de atualização de outros sistemas operacionais.

Por um lado, o macOS, o iOS e o Android são atualizados com menos frequência, para que você possa ter a impressão de que a Microsoft é muito zelosa. Por outro lado, existem precedentes para atualizações bem-sucedidas com tanta frequência: para o Ubuntu, existem dois lançamentos por ano, e o ChromeOS do Google, como seu navegador Chrome, recebe atualizações a cada seis semanas. Se você for além do sistema operacional, o programa Microsoft Office Insider executa um canal mensal em que novos recursos são lançados para os usuários do Office todos os meses - e os desenvolvedores fazem o trabalho sem causar muitas reclamações e ao mesmo tempo fornecer um fluxo constante de novos recursos e correções. A equipe do Visual Studio também libera atualizações para seu ambiente de desenvolvimento e serviços interativos. Obviamente, a Microsoft possui equipes que se adaptaram bem à realidade, onde seus aplicativos são atualizados regularmente.

Iremos além do escopo do software local e examinaremos os serviços de rede e nuvem. Lá, a Microsoft e outras empresas estão introduzindo cada vez mais a entrega contínua . Cada atualização no sistema é implantada automaticamente nos servidores de produção após a aprovação de um número suficiente de testes automáticos.

Obviamente, nenhum desses projetos pode ser comparado em complexidade com o Windows. O Ubuntu pode ter uma variedade mais diversificada de pacotes, mas, em qualquer caso, muitos deles são desenvolvidos de forma independente. O fato permanece: a escala do Windows é extraordinariamente grande - e os componentes são integrados sem precedentes em uma única base de código. Em alguns lugares, o código do Windows é excepcionalmente antigo.

Obviamente, esses fatores complicam o desenvolvimento do Windows, mas é realmente impossível dominar duas atualizações por ano? Este não é o ponto. Você só precisa do processo de desenvolvimento certo.


Windows 10 na época do lançamento em 2015 (onde estão todos os meus ícones e o menu Iniciar?)

Um processo enraizado na história

A Microsoft não divulga detalhes específicos do processo de desenvolvimento do Windows 10, mas existem características observáveis ​​desse processo (como novos recursos são enviados para os iniciados, tipos de erros nas compilações dos iniciados) e há algumas informações de dentro da empresa. Todos esses fatos indiretos indicam a inferioridade do processo de desenvolvimento. Ele manteve algumas semelhanças com o processo de desenvolvimento usado pela empresa durante os três anos de lançamento do Windows. O tempo caiu, mas a abordagem básica não mudou.



Antigamente, quando entre dois e três anos se passavam entre os grandes lançamentos, a Microsoft chegou a um processo dividido em várias etapas:

1. design e planejamento;
2. desenvolvimento de componentes;
3. integração;
4. estabilização.

Cerca de 4-6 meses de planejamento e design, 6-8 semanas de codificação intensiva e, em seguida, 4 meses de integração (cada função é geralmente desenvolvida em seu próprio ramo, para que todos precisem ser coletados e combinados) e estabilização (teste e correção de erros). Durante o desenvolvimento do produto, esse ciclo é repetido duas ou três vezes; O Windows terá três iterações, a primeira das quais é um protótipo e as próximas duas são reais. A duração das fases pode variar, mas a estrutura básica é amplamente utilizada na empresa.

Algumas coisas são óbvias nesse processo. Talvez o mais impressionante seja que surpreendentemente pouco tempo seja gasto diretamente no desenvolvimento de um novo código: para o lançamento do Windows, são dois intervalos de 6 a 8 semanas durante todo o período de três anos. Muito tempo passa entre o estágio de planejamento / design e o produto que realmente funciona. Esse é o principal fator por que esse processo não pode ser descrito como "desenvolvimento flexível": novas funções estão firmemente incorporadas no produto final, por isso é difícil alterá-las em resposta ao feedback.

A separação do desenvolvimento e das correções de erros também é um problema: nos estágios de desenvolvimento e integração, a confiabilidade e a estabilidade do software são muito fracas. As funções integradas não são fundamentalmente testadas (porque o teste ocorre posteriormente) e nunca são usadas entre si (porque todas foram desenvolvidas separadamente em suas próprias ramificações antes da fase de integração). A confusão de software é então levada a um nível aceitável por meio de testes, relatórios de erros e correção de erros durante a longa fase de estabilização. Nesse processo, você precisa melhorar repetidamente a confiabilidade do produto.


Nadella apresenta o mundo ao Windows 10 em 2015

O novo mundo não é tão novo

No novo mundo, vemos que leva sete ou oito meses para um ciclo completo da empresa. Embora haja apenas seis meses entre os lançamentos, o início do próximo ciclo ocorre antes da conclusão do anterior - para os iniciados isso é evidente a partir da abertura do grupo Skip Ahead.

Como regra, cada atualização começa com um período bastante tranquilo, com várias alterações visíveis, e depois vem alguns meses com a introdução de grandes alterações - e um grande número de bugs. Cerca de um mês antes da atualização, vemos um abrandamento acentuado no número de alterações feitas e uma forte ênfase nas correções de bugs, e não nos novos recursos.

Como os próprios funcionários da Microsoft descrevem, os últimos meses de desenvolvimento incluem a fase "contar" e, em seguida, um mês da fase "pedir permissão". No estágio "notificar", o gerenciamento do Windows é informado das alterações feitas com a política de aceitar essas alterações por padrão. No estágio "pedir permissão", somente mudanças realmente significativas são permitidas, como regra, apenas algumas alterações por dia.

Por exemplo, a primeira versão da atualização de outubro (codinome RS5) foi lançada para iniciados em 14 de fevereiro e a versão estável da atualização de abril (RS4) ocorreu dois meses depois, em 16 de abril. O RS5 não recebeu novos recursos significativos até 7 de março. Muitos recursos foram adicionados durante maio, junho e julho, e somente pequenas alterações foram feitas em agosto e setembro. Vários pequenos recursos foram removidos em agosto, pois era difícil se preparar para o lançamento em outubro.

Obviamente, o processo mudou um pouco. Por exemplo, novos recursos aparecem em pré-construções ao longo de muitos meses. Isso indica que a integração de novas funções parece ocorrer muito antes - à medida que as funções são desenvolvidas, e não em um grande pacote de mesclagem no final.

Diminuição da qualidade

Mas existem semelhanças importantes. O mais importante é que um código de bugs deliberadamente é integrado a um banco de dados comum e a fase de teste e estabilização é usada para resolver qualquer problema. Esse momento é até explicitamente reconhecido: ao anunciar uma nova montagem preliminar , a Microsoft adverte: “Como sempre, no início do ciclo de desenvolvimento, as montagens podem conter bugs que podem ser dolorosos. Se isso lhe causar algum inconveniente, considere mudar para um ciclo de atualização lento (toque lento). Lá, as assembléias ainda terão maior qualidade. ”

Vemos isso na prática no RS5. Em outubro do ano passado, com a atualização, eles introduziram um novo recurso para o OneDrive: espaços reservados, que exibem arquivos na nuvem que não são baixados localmente. Sempre que um aplicativo tenta abrir um arquivo, o OneDrive extrai o arquivo de forma transparente do armazenamento em nuvem e o salva localmente, e o aplicativo nem sabe que o arquivo não estava inicialmente acessível localmente. A versão RS5 implementou a função de limpar arquivos em nuvem replicados do armazenamento local se o espaço em disco acabar.

Esse é um recurso realmente inteligente e útil que melhora a integração com o armazenamento em nuvem. Este é um novo código; Há um driver de kernel que fornece um link entre o código de sincronização da nuvem (usado para fazer upload de arquivos e baixar alterações) e os ícones no sistema de arquivos. Há também uma API (parece que terceiros também podem usar esse recurso para seus serviços de sincronização).


As pré-construções do Windows usam uma "tela de morte" verde em vez de azul, para facilitar a distinção

É razoável supor que a Microsoft faça um conjunto de testes para esse novo código: criando um arquivo, verificando a sincronização, excluindo uma cópia local e salvando o ícone, abrindo o ícone com o download do arquivo real, excluindo o arquivo completamente e assim por diante. Existem várias operações básicas para manipular arquivos e diretórios e, em qualquer processo de desenvolvimento flexível, há testes para verificar se todas as operações funcionam conforme o esperado e a API faz o que deve fazer.

Além disso, era razoável supor que qualquer alteração no código que interrompa os testes seria rejeitada e não permitida a integração. O código deve ser corrigido, ele deve passar nos testes antes de chegar à ramificação principal do Windows e, mais ainda, aos testadores beta.

No entanto, houve um erro em muitas compilações preliminares: o sistema desligou ao excluir um diretório sincronizado com o OneDrive. Este bug não foi apenas integrado ao código do Windows, mas também foi lançado para os usuários finais.

Teste o software antes do lançamento, não depois

Isso sugere alguns dos princípios fundamentais do desenvolvimento do Windows. Ou não há testes para esse código (disseram-me que sim, é permitido integrar o código sem testes, embora eu espere que isso não seja a norma), ou falhas de teste são consideradas aceitáveis, problemas sem bloqueio e os desenvolvedores podem integrar código que obviamente não é funciona corretamente. Lá fora, não podemos dizer exatamente o que exatamente está acontecendo - talvez até uma combinação das duas abordagens - mas nenhuma delas pode ser chamada de boa.

Para partes mais antigas do Windows, isso pode ser considerado mais desculpável - afinal, eles foram desenvolvidos antes da era dos testes automatizados e, na verdade, pode não haver testes. Mas os emblemas do OneDrive não são uma parte antiga do Windows; é um recurso completamente novo. Não há uma boa razão para não haver um conjunto sólido de testes para testar a funcionalidade básica do novo código. E um código defeituoso conhecido definitivamente não deve ser incluído na base de códigos até que seja corrigido, sem mencionar o envio aos testadores.

Como resultado, o desenvolvimento do Windows 10 ainda segue os princípios antigos. Novos recursos são lançados no banco de dados com a degradação da estabilidade e confiabilidade. Supõe-se que a base de código seja levada a um nível aceitável no estágio de teste e estabilização.

Testes automatizados inadequados e / ou ignorar erros de teste, por sua vez, significa que os desenvolvedores do Windows não podem ter certeza de que alterações e correções não causarão efeitos cascata. É daí que surgiu a fase de desenvolvimento "pedir permissão": quando a atualização é concluída, o número de alterações precisa ser minimizado, pois a Microsoft não tem certeza de que o escopo e o impacto de cada alteração sejam isolados. Essa confiança vem apenas com uma infraestrutura maciça de testes disciplinados: você sabe que a mudança é segura porque todos os testes passam com sucesso. Não importa que tipo de teste a empresa realize para o Windows, claramente não é suficiente para obter essa confiança.

Mas em outros aspectos, a Microsoft age como se tivesse essa certeza. A empresa tem muitos testes; Disseram-me que um ciclo completo de testes para o Windows leva várias semanas. Esse ciclo completo é realmente realizado, mas não nas montagens que realmente entram em produção. Um exemplo é a atualização de outubro de 2018: o código foi montado em 15 de setembro e, em 2 de outubro, a assembléia tornou-se pública. Independentemente de qual build do RS5 passou por um ciclo completo de testes, este não é o que realmente recebemos, porque um ciclo completo de testes leva muito tempo.

Esta é uma posição controversa. Se alterações subseqüentes no código forem feitas com um alto grau de confiança de que elas não quebraram nada, você poderá iniciar o ciclo de teste completo na montagem anterior. Mas se a Microsoft tivesse tanta confiança de que essas mudanças não quebrariam nada, não teria que estrangulá-las tanto no estágio de "pedir permissão".


O Windows 10 pode realmente funcionar como uma máquina confiável

Como fazer certo

Vemos uma diferença significativa nos projetos reais do Agile. Por exemplo, um processo de desenvolvimento que o Google usa para seu servidor de envio de anúncios.Essa é uma parte crítica da infraestrutura da empresa, mas os novos desenvolvedores da empresa descrevem que fizeram alterações para fechar um pequeno erro - e as alterações entraram em produção durante o dia. Quando uma correção é enviada ao repositório, ela é reconstruída automaticamente e submetida a uma bateria de testes. O mantenedor desta seção de código considera a alteração, a aceita e a combina com a base de código principal, que é testada novamente e implantada na produção.

Obviamente, é um pouco injusto comparar isso com o Windows: afinal, é muito mais fácil para os serviços em nuvem reverter a alteração quando um erro é detectado. Modificar o Windows com uma tela azul na inicialização do sistema é muito mais difícil de desfazer e restaurar. Mas, no entanto, o servidor de anúncios é um serviço essencial do Google; nele, a empresa ganha dinheiro, no final, e uma atualização malsucedida pode facilmente causar uma perda de milhões de dólares. Mas os testes automáticos e todo o processo estabelecido permitem que até um estagiário da empresa implante suas alterações na produção em poucas horas e faça isso com confiança.

A mentalidade de desenvolvimento é fundamentalmente diferente. Um novo recurso pode ser instável durante o desenvolvimento, mas, quando adicionado ao ramo principal, deve corresponder a um alto nível de qualidade. A abordagem da Microsoft é "mesclar todos os erros agora, vamos corrigi-los mais tarde" e, no processo certo, os erros são eliminados antes que a nova função seja lançada na ramificação principal.


Se você pegar a versão do Chrome no canal do desenvolvedor, geralmente a única evidência de que você tem uma versão não final é um ícone não padrão

Embora os aplicativos em nuvem ofereçam alguma flexibilidade, os métodos Agile também são adequados para o software de desktop. Por exemplo, o Google possui processos semelhantes para o Chrome. As versões beta do Chrome têm bugs raros, mas, em geral, seu código está próximo da qualidade da versão. De fato, o princípio do desenvolvimento do Chrome é que mesmo a versão mais recente deve ter qualidade de lançamento. Você pode usar a versão do desenvolvedor do Chrome como um navegador comum - e somente pelo ícone você entenderá que esse é um canal alfa, não estável. Isso é possível graças à ampla automação de testes e validação: durante todo o processo de desenvolvimento, o código do Chrome é de alta qualidade, sem uma queda de qualidade nas edições subsequentes que vemos no Windows.

Para fazer isso, o Google investiu em infraestrutura. Ela tem um sistema de compilação distribuído que cria o Chrome em paralelo em mil núcleos, para que uma compilação completa possa ser concluída em apenas alguns minutos. A ramificação disciplinada foi estabelecida para tornar as fusões fáceis e previsíveis. O Google possui uma ampla variedade de testes funcionais e de desempenho para detectar erros e regressões o mais cedo possível. Nada disso é gratuito, mas é importante para o Google lançar versões do Chrome de maneira sustentável e regular.

O processo de desenvolvimento do Windows sempre foi ruim

No novo processo de desenvolvimento, a Microsoft alocou proporcionalmente mais tempo para escrever novas funções e menos tempo para estabilizar e corrigir essas funções. Tudo ficaria bem se a qualidade das funções fosse alta desde o início, com uma infraestrutura de teste e padrões mais altos antes de integrar o novo código. Mas a experiência com o Windows 10 até agora é que a Microsoft não desenvolveu os processos e sistemas necessários para dar suporte a essa nova abordagem.

O problema de reduzir o número de problemas de dois para um por ano não resolverá o problema. Parece-me muitas vezes que as pessoas olham para o desenvolvimento anterior do Windows através de óculos cor de rosa. Mas se você se lembrar dos tempos do Windows 7 e anteriores, veremos problemas muito semelhantes. E, em seguida, o conselho usual era não atualizar para uma nova versão do Windows até o lançamento do Service Pack 1. Por que? Como a primeira versão sempre foi inaceitavelmente com erros e instável - e era melhor esperar até o Service Pack 1 resolver a maioria desses problemas.

A diferença não é que a nova abordagem para o desenvolvimento do Windows seja muito pior do que antes, ou que o processo antigo deu melhores resultados. Nem um pouco.Agora vemos a mesma coisa que antes, apenas o momento “esperar pelo Service Pack 1” chega duas vezes por ano. Após cada nova atualização, chega um momento em que a Microsoft acredita que o código é bom o suficiente para usuários corporativos - geralmente de três a quatro meses após o lançamento inicial. Este é o nosso "novo" Service Pack 1.

Portanto, temos o pior dos dois mundos: desde a abordagem antiga ao desenvolvimento do Windows, há versões ruins que precisam ser corrigidas. A partir de uma nova abordagem - lança duas vezes por ano, e não uma vez a cada três anos. Portanto, a instabilidade até o lançamento do Service Pack persiste na maior parte do ano.

A principal desvantagem é a desestabilização da base de código, integrando funções inadequadamente testadas na esperança de corrigi-la mais tarde. Este é um processo ruim. Isso era ruim no momento em que o Windows era lançado a cada três anos e era ruim quando era lançado a cada seis meses.

Este não é o trabalho de iniciados

O segundo problema é a natureza dos testes. A Microsoft costumava ter um grande número de testadores e um certo número de desenvolvedores e testadores foram atribuídos a cada função. Muitos deles foram demitidos ou transferidos para outros postos em 2014. A ideia era que mais responsabilidades de teste fossem atribuídas aos desenvolvedores que criam esses recursos. O programa Windows Insider também oferece uma grande quantidade de testes informais - com muitos milhões de participantes (insiders). Isso é muito mais do que em qualquer um dos programas beta anteriores do Windows.

Não tenho certeza se a abordagem antiga teria detectado um bug de perda de dados. Talvez os testadores profissionais não testem um cenário específico no qual os dados são excluídos. Mas está claro que a Microsoft não está lidando com o fluxo de mensagens de erro de pessoas de dentro da empresa. A perda de dados foi registrada três meses antes da atualização. Muitas mensagens de erro parecem ser de baixa qualidade, faltam os detalhes necessários ou a terminologia correta, mas se a empresa não perceber o problema há três meses, não é de todo óbvio que um período de desenvolvimento mais importante seja importante. Um período de desenvolvimento mais longo significa que o erro foi ignorado por seis meses, não três.

A Microsoft prometeu mudar o processo de feedback com pessoas de dentro para indicar a gravidade do problema e chamar mais atenção para esse tipo de problema. Isso pode ajudar se as pessoas de dentro da empresa usarem corretamente os indicadores de gravidade, mas parece insuficiente para resolver o problema principal: muitos relatórios de erros de qualidade muito baixa.

Isso se refere ao problema da qualidade do código. A verdadeira força do Insider é a variedade de hardware e software. Os especialistas podem identificar os bugs de compatibilidade mais exóticos, problemas com drivers e assim por diante. Mas especialistas não devem fazer testes básicos de funções. Mas muitas vezes há a sensação de que a Microsoft os usa como testadores em tempo integral.

Além disso, se a qualidade do código diminuir durante o desenvolvimento, as pré-construções geralmente não são adequadas para o uso diário em PCs comuns. Eles não são confiáveis ​​o suficiente. Por sua vez, isso prejudica o valor dos testes realizados por profissionais internos: eles não os instalam no PC principal e não sujeitam o conjunto a toda a gama de hardware e software. Eles usam PCs secundários e máquinas virtuais.

Você tem que investir em suas ferramentas

Desenvolver uma infraestrutura de teste como o Chrome para um projeto tão gigantesco como o Windows é uma tarefa muito séria. Embora algumas partes do Windows permitam testes offline, outras somente podem ser efetivamente testadas em um sistema integrado e integrado. Alguns deles, como o recurso de sincronização de arquivos do OneDrive, dependem até da operação de serviços de rede externos. Esta não é uma tarefa trivial.

Uma grande mudança seria a adoção do princípio de que o código do Windows deve fornecer qualidade de versão a todo momento - não "após vários meses de correção", mas "agora, a qualquer momento". Mas esta é uma condição necessária. A Microsoft deve alcançar uma situação em que cada nova atualização tenha qualidade de lançamento desde o primeiro dia. Situações em que a atualização para a versão mais recente não é um problema - e essa opção pode ser aceita com segurança. As atualizações de recursos devem estar invisíveis para os usuários. Reduzir o número de lançamentos para um por ano ou um em três anos não fornecerá essa situação, e nunca o fez. O processo em si deve mudar, não o tempo.