Главная » Хабрахабр » [Перевод] Проблема Windows не в частоте обновлений, а в процессе разработки

[Перевод] Проблема Windows не в частоте обновлений, а в процессе разработки

Глючные обновления указывают на более глубокую проблему


Windows 10 на презентации в Токио, июль 2015 года

Быстро появились сообщения о потере файлов на компьютерах, а Microsoft приостановила распространение обновления. Очевидно, обновление Windows от 10 октября 2018 года было не самым удачным. С тех пор баг исправили, сейчас идёт тестирование нового апдейта перед его повторным выпуском.

Большинство из нас знает о резервном копировании, но в реальности многие данные, особенно на домашних компьютерах, не имеют бэкапа, и их исчезновение весьма неприятно.
Это не первое обновление Windows, в котором возникли проблемы — в предыдущих апдейтах мы видели такие вещи, как значительные аппаратные несовместимости — но оно явно стало худшим.

В Windows 10 планировалось радикально изменить процесс разработки. Microsoft хотела лучше реагировать на потребности клиентов и рынка — и чаще выпускать новые функции. Windows 10 представлялась как «последняя» версия Windows. Мол, все новые разработки станут апдейтами Windows 10, поставляемыми через систему обновления несколько раз в год. Эта новая модель разработки получила название «Windows как сервис». И после некоторого первоначального беспорядка Microsoft остановилась на двух обновлениях функционала в год: в апреле и в октябре.

Microsoft выпускает полезные новые функции по новой модели, не заставляя пользователей ждать три года для обновления основной версии. Эти усилия увенчались успехом. Подсистема Windows для Linux (WSL), которая позволяет нативно запускать Linux-программы в системе Windows, стала подспорьем для разработчиков и администраторов. Например, вышла удобная функция для незаметного запуска Edge в виртуальной машине, обеспечивающая большую защиту от вредоносных веб-сайтов. Хотя улучшения не такие значительные, но в целом нынешняя Windows 10 безусловно лучше, чем та, что вышла три года назад. Преимущества для обычных пользователей чуть сложнее заметить, но можно упомянуть функции VR, совместимые с SteamVR, улучшенную производительность игр и тёмную тему оформления.


В те дни, когда Windows обновлялась только каждые три года, трудно было представить, что WSL когда-нибудь станет полезным инструментом

Разработка WSL, например, была основана на отзывах пользователей. Всё это хорошо, а некоторые вещи вряд ли могли быть сделаны (по крайней мере, так же успешно) без введения модели «Windows как сервис». Я не думаю, что WSL получила бы такой толчок к развитию без устойчивого прогресса обновлений каждые шесть месяцев — никто не захотел бы ждать три года, чтобы увидеть незначительное исправление. Пользователи рассказывали о найденных несовместимостях и помогали расставлять приоритеты в разработке новых функций. Регулярные обновления вознаграждают людей за сообщения об ошибках, потому что все действительно видят, что ошибки своевременно устраняются. Например, чтобы важный для них пакет начал правильно работать.

Предыдущие проблемы с этой моделью и обновлениями безопасности уже подорвали доверие к политике обновлений Windows 10. Проблема модели «Windows как сервис» — качество. Эти жалобы тоже имеют давнюю историю. Среди опытных пользователей распространилось мнение, что в Windows 10 снизилось качество ежемесячных обновлений безопасности, а установка полугодовых обновлений функций, как только они выходят, — безумие. Ненадёжные обновления стали причиной для беспокойства вскоре после выхода Windows 10.

Редмонд должен сократить их количество до одного, а Microsoft следует приостановить разработку новых функций и просто исправить ошибки. Последняя проблема с удалением файлов заставила специалистов рассуждать, что двух обновлений функций в год может быть слишком много. Некоторые беспокоятся, что компания находится в опасной близости к серьёзной потере доверия к обновлениям, а у некоторых пользователей Windows это доверие уже потеряно.

Это не первые призывы к Microsoft притормозить обновления функций — были опасения, что всё это трудно переварить и IT-отделам, и обычным пользователя, но с очевидными проблемами последнего апдейта эти призывы приобретают становятся особенно актуальны.

Но те, кто настаивают на одном обновлении в год вместо двух, упускают главное. Проблема не в частоте выхода. Проблема в процессе разработки Microsoft.

Можем посмотреть на графики обновления других ОС. Почему проблема не в сроках?

С другой стороны, есть прецеденты успешных обновлений с такой частотой: для Ubuntu выходит два релиза в год, а ChromeOS от Google, как и его браузер Chrome, получает обновления каждые шесть недель. С одной стороны, macOS, iOS и Android обновляются реже, так что может появиться впечатление, что Microsoft слишком усердствует. Команда Visual Studio тоже часто выпускает обновления для своей среды разработки и интерактивных служб. Если выйти за рамки ОС, то в программе Microsoft Office Insider работает ежемесячный канал, где новые функции для пользователей Office выходят каждый месяц — и разработчики справляются с работой, не вызывая слишком много жалоб и при этом обеспечивая устойчивый поток новых функций и исправлений. Очевидно, что в Microsoft есть команды, которые хорошо адаптировались к реальности, где их приложения обновляются регулярно.

Там и Microsoft, и другие компании всё чаще внедряют непрерывную доставку. Выйдем за рамки локального софта и посмотрим на сетевые и облачные сервисы. Каждое обновление в системе автоматически развёртывается на рабочих серверах после прохождения достаточного количества автоматических тестов.

Может, в Ubuntu более разнообразный массив пакетов, но в любом случае многие из них разрабатываются независимо. Конечно, ни один из этих проектов не сравнится по сложности с Windows. Местами код Windows исключительно старый. Факт остаётся фактом: масштаб Windows необычайно велик — и компоненты беспрецедентно интегрированы в единую кодовую базу.

Дело вообще не в этом. Безусловно, эти факторы усложняют разработку Windows, но неужели нельзя осилить два обновления в год? Просто нужен правильный процесс разработки.


Windows 10 примерно в момент выпуска в 2015 году (Где все мои значки и меню «Пуск»?)

Microsoft не раскрывает конкретные детали процесса разработки Windows 10, но есть наблюдаемые характеристики этого процесса (как новые функции отправляются инсайдерам, типы ошибок в инсайдерских билдах) и есть некоторая информация изнутри компании. Все эти косвенные факты свидетельствуют об ущербности процесса разработки. Он сохранил некоторые общие черты с процессом разработки, который компания использовала ещё во времена трёхлетних релизов Windows. Сроки сократились, но основной подход не изменился.

В былые времена, когда между большими релизами проходило от двух до трёх лет, Microsoft пришла к процессу, разделённому на несколько этапов:

  1. проектирование и планирование;
  2. разработка компонентов;
  3. интеграция;
  4. стабилизация.

Примерно 4−6 месяцев планирования и проектирования, 6−8 недель интенсивного кодирования, а затем 4 месяца интеграции (каждая функция обычно разрабатывается в собственной ветке, поэтому их все нужно собрать и объединить вместе) и стабилизации (тестирование и исправление ошибок). В течение разработки продукта этот цикл повторяется два или три раза; для Windows будет три итерации, первая из которых является прототипом, а следующие две — реальными. Продолжительность фаз может меняться, но базовая структура широко используется в компании.

Наверное, самое поразительное, что непосредственно на разработку нового кода тратится удивительно мало времени: для релиза Windows это два промежутка по 6−8 недель в течение всего трёхлетнего периода. Из этого процесса очевидны некоторые вещи. Это главный фактор, почему данный процесс нельзя описать как «гибкую разработку»: новые функции накрепко встраиваются в конечный продукт, так что их трудно изменить в ответ на обратную связь. Между этапом планирования/проектирования и фактически работающим продуктом проходит много времени.

Интегрируемые функции принципиально не тестируются (потому что тестирование происходит позже) и никогда не используются друг с другом (потому что все они были разработаны отдельно в своих собственных ветвях до фазы интеграции). Отделение друг от друга разработки и исправления ошибок также является проблемой: на этапах разработки и интеграции надёжность и стабильность программного обеспечения сильно хромают. В этом процессе нужно многократно улучшать надёжность продукта. Беспорядок программного обеспечения затем доводят до приемлемого уровня через тестирование, сообщения об ошибках и исправление ошибок во время длительной фазы стабилизации.


Наделла представляет миру в Windows 10 в 2015 году

В новом мире мы видим, что для полного цикла компании требуется, возможно, семь или восемь месяцев. Хотя между выпусками только шесть месяцев, начало следующего цикла происходит до завершения предыдущего — для инсайдеров это очевидно по открытию группы "Skip Ahead".

Примерно за месяц до выхода обновления мы видим резкое замедление количества внесённых изменений и сильный акцент на исправлениях ошибок, а не на новых функциях. Как правило, каждое обновление начинается с довольно тихого периода с несколькими видимыми изменениями, а затем наступает несколько месяцев с введением больших изменений — и огромного количества багов.

На этапе «уведомлять» руководству Windows сообщают о вносимых изменениях с политикой принятия этих изменений по умолчанию. Как описывают сами сотрудники Microsoft, последние несколько месяцев разработки включают фазу «уведомлять» (tell), затем один месяц фазы «спрашивать разрешения» (ask). На этапе «спрашивать разрешения» допускаются только действительно существенные изменения, как правило, всего несколько изменений в день.

RS5 не получил каких-либо существенных новых функций до 7 марта. Например, первая сборка октябрьского обновления (кодовое имя RS5) была выпущена для инсайдеров 14 февраля, а стабильный билд апрельского обновления (RS4) произошёл через два месяца 16 апреля. Несколько небольших функций даже удалили в августе, так как их трудно было подготовить к выходу в октябре. Много функций добавили в течение мая, июня и июля, а затем в августе и сентябре были сделаны лишь небольшие изменения.

Например, новые функции появляются в предварительных билдах в течение многих месяцев. Безусловно, процесс немного изменился. Это указывает на то, что интеграция новых функций, кажется, происходит гораздо раньше — по мере разработки функций, а не в одном большом пакете слияния в конце.

Но есть и ключевые сходства. Самое главное, что заведомо глючный код интегрируется в общую базу, а для решения любых проблем используется фаза тестирования и стабилизации. Этот момент даже признается явно: объявляя о новой предварительной сборке, Microsoft предупреждает: «Как обычно в начале цикла разработки, сборки могут содержать баги, которые бывают болезненными. Если это доставляет вам неудобства, вы можете рассмотреть возможность переключения на медленный цикл обновлений (Slow ring). Там сборки по-прежнему будут более высокого качества».

В октябре прошлого года с апдейтом внедрили новую функцию для OneDrive: значки (placeholders), которые отображают файлы в облачном хранилище, не загруженные локально. Мы видим это на практике в RS5. В билде RS5 реализовали функцию очистки реплицированных облачных файлов из локального хранилища, если заканчивается место на диске. Всякий раз, когда приложение пытается открыть файл, OneDrive прозрачно извлекает файл из облачного хранилища и сохраняет его локально, а приложение даже не знает, что файл изначально не был доступен локально.

Это и новый код; есть драйвер ядра, который обеспечивает связь между кодом синхронизации облака (используемым для загрузки файлов и загрузки изменений) и значками в файловой системе. Это действительно умная, полезная функция, которая улучшает интеграцию с облачным хранилищем. Есть ещё API (похоже, что третьи стороны тоже могут использовать эту функцию для своих служб синхронизации).


В предварительных билдах Windows используется зелёный «экран смерти» вместо синего, так что их легко отличить

Существует несколько основных операций по манипулированию файлами и каталогами, и в любом гибком процессе разработки есть тесты для проверки, что все операции работают как ожидалось, и API делает то, что должен делать. Разумно предположить, что Microsoft сделает набор тестов для этого нового кода: создание файла, проверка синхронизации, удаление локальной копии с сохранением значка, открытие значка с загрузкой реального файла, полное удаление файла и так далее, и так далее.

Код должен быть исправлен, он должен пройти свои тесты, прежде чем когда-нибудь попадёт в основную ветку Windows, а тем более отправится бета-тестерам. Кроме того, разумно было предположить, что любое изменение кода, которое ломает тесты, будет отклонено и не допущено к интеграции.

Этот баг не только интегрировали в код Windows, но и выпустили для конечных пользователей. И всё-таки во многих предварительных сборках был баг: система вешалась при удалении каталога, синхронизированного с OneDrive.

Это говорит о некоторых фундаментальных принципах разработки Windows. Либо для этого кода вообще нет тестов (мне сказали, что да, разрешено интегрировать код без тестов, хотя я надеюсь, что это не является нормой), либо сбои тестов рассматриваются как приемлемые, неблокирующие проблемы, а разработчикам разрешено интегрировать код, который заведомо не работает должным образом. Снаружи мы не можем точно сказать, что именно происходит — возможно даже сочетание обоих подходов — но ни один из них нельзя назвать хорошим.

Но значки OneDrive не являются старой частью Windows, это совершенно новая функция. Для старых частей Windows это можно считать более простительным — всё-таки они разработаны до эпохи автоматизированного тестирования, и там действительно может не оказаться тестов. И известный дефектный код определённо нельзя включать в кодовую базу, пока он не исправлен, не говоря уже об отправке тестировщикам. Нет никаких веских причин, почему для нового кода нет твёрдого набора тестов для проверки базовой функциональности.

Новые функции вливают в базу с деградацией стабильности и надёжности. В результате, разработка Windows 10 по-прежнему идёт по старым принципам. Предполагается, что кодовую базу доведут до приемлемого уровня на этапе тестирования и стабилизации.

Вот откуда появилась фаза разработки «спрашивать разрешения»: по мере завершения обновления количество изменений нужно свести к минимуму, потому что Microsoft не уверена, что область и влияние каждого изменения изолированы. Неадекватное автоматизированное тестирование и/или игнорирование ошибок тестирования, в свою очередь, означает, что разработчики Windows не могут быть уверены, что изменения и исправления не вызовут волновых эффектов. Независимо от того, какое тестирование компания проводит для Windows, его явно недостаточно, чтобы получить такую уверенность. Эта уверенность приходит только с массивной инфраструктурой дисциплинированного тестирования: вы знаете, что изменение безопасно, потому что все тесты успешно проходят.

У компании много тестов; мне сказали, что полный цикл тестирования для Windows занимает много недель. Но в других отношениях Microsoft действует так, словно у неё имеется эта уверенность. Примером может служить обновление от октября 2018 года: код был собран 15 сентября, а 2 октября сборка стала публичной. Этот полный цикл действительно проводится, просто не на сборках, которые фактически идут в продакшн. Независимо от того, какая сборка RS5 прошла полный цикл тестирования, это не та, которую мы в реальности получили, потому что полный цикл тестирования занимает слишком много времени.

Если последующие изменения кода сделаны с высокой степенью уверенности, что они ничего не сломали, можно запустить полный цикл тестирования на предыдущей сборке. Это противоречивая позиция. Но если у Microsoft такая высокая уверенность, что эти изменения ничего не сломают, ей не пришлось бы так сильно их душить на этапе «спрашивать разрешения».


Windows 10 действительно может работать как надёжная машина

Мы видим значительную разницу с реальными проектами Agile. Например, процесс разработки, который использует Google для своего сервера отгрузки рекламы. Это критическая часть инфраструктуры для компании, но новые разработчики в компании описывают, что они вносили изменения для закрытия маленькой ошибки — и изменения уходили в продакшн в течение дня. Когда исправление подаётся в репозиторий, тот автоматически пересобирается и подвергается батарее тестов. Мейнтейнер данного участка кода затем рассматривает изменение, принимает его и объединяет с основной кодовой базой, которая повторно тестируется и деплоится в продакшн.

Изменение Windows с синим экраном при загрузке системы гораздо труднее отменить и восстановить. Конечно, немного несправедливо сравнивать это с Windows: всё-таки для облачных сервисов гораздо легче откатить изменение при обнаружении ошибки. Но автоматические тесты и весь налаженный процесс позволяют даже стажёру в компании деплоить свои изменения в продакшн за несколько часов, и делать это с уверенностью. Но всё же рекламный сервер — это критический сервис Google, на нём компания зарабатывает деньги, в конце концов, и неудачный апдейт может легко нанести убыток в миллионы долларов.

Новая функция может быть нестабильной во время разработки, но при добавлении в основную ветку она должна соответствовать высокому уровню качества. Менталитет разработки принципиально иной. Подход Microsoft — «объединить сейчас все ошибки, мы исправим их позже», а в правильном процессе от багов избавляются до того, как влить новую функцию в основную ветку.


Если взять версию Chrome с канала для разработчиков, то обычно единственное свидетельство, что у вас не финальный релиз — это нестандартная иконка

Например, в Google налажены похожие процессы для Chrome. В то время как облачные приложения позволяют проявить определённую гибкость, методы Agile подходят и для десктопного ПО. Действительно, принцип разработки Chrome в том, что даже самый свежий билд должен быть релизного качества. В бета-версиях Chrome есть редкие баги, но в целом их код близок к релизному качеству. Такое возможно благодаря обширной автоматизации тестов и проверки: на протяжении всего процесса разработки код Chrome является высококачественным, без падения качества с последующими правками, которые мы видим в Windows. Вы можете использовать dev-версию Chrome как обычный браузер — и только по значку поймёте, что это альфа, а не стабильный канал.

У неё работает распределённая система сборки, которая собирает Chrome параллельно на тысяче ядер, поэтому полную сборку можно выполнить всего за несколько минут. Для этого Google вложилась в инфраструктуру. Google имеет широкий спектр функциональных тестов и тестов производительности, чтобы выявить ошибки и регрессии как можно раньше. Налажены дисциплинированные ветвления, чтобы сделать слияния лёгкими и предсказуемыми. Ничто из этого не даётся бесплатно, но для Google важно выдавать релизы Chrome на устойчивой, регулярной основе.

В новом процессе разработки Microsoft пропорционально больше времени выделено на написание новых функций и меньше — на стабилизацию и исправление этих функций. Всё было бы хорошо, если бы качество функций было высоким с самого начала, с инфраструктурой тестирования и более высокими стандартами перед интеграцией нового кода. Но опыт работы с Windows 10 до сих пор заключается в том, что Microsoft не разработала процессы и системы, необходимые для поддержания этого нового подхода.

Мне часто кажется, что люди смотрят на прежнюю разработку Windows сквозь розовые очки. Проблема сокращения числа выпусков с двух до одного в год не исправит проблему. И тогда обычным советом было не обновляться на новую версию Windows, пока не выйдет Service Pack 1. Но если вспомнить времена Windows 7 и ранее, то мы увидим очень похожие проблемы. Потому что первый релиз всегда был недопустимо глючным и нестабильным — и лучше было подождать, пока Service Pack 1 решит большинство этих проблем. Почему?

Вовсе нет. Разница не в том, что новый подход к разработке Windows намного хуже, чем раньше, или что старый процесс давал лучшие результаты. После каждого нового обновления наступает момент, когда Microsoft считает, что код достаточно хорош для корпоративных пользователей — обычно через три-четыре месяца после первоначального релиза. Сейчас мы видим то же самое, что и тогда, только момент «подождать Service Pack 1» наступает дважды в год. Это и есть наш «новый» Service Pack 1.

От нового подхода — релизы дважды в год, а не один раз в три года. Таким образом, мы получаем худшее из обоих миров: от старого подхода к разработке Windows остались плохие релизы, которые нужно исправлять. Таким образом, нестабильность до выхода Service Pack сохраняется в течение большей части года.

Это плохой процесс. Основной недостаток — в дестабилизации кодовой базы путём интеграции неадекватно протестированных функций в надежде всё исправить позже. Это было плохо во времена, когда Windows выпускалась каждые три года, и это плохо, когда она выпускается каждые шесть месяцев.

Вторая проблема — характер проводимых испытаний. В штате Microsoft раньше было огромное количество тестеров, и на каждую функцию назначали определённое количество разработчиков и тестеров. Многих из них уволили или перевели на другие должности в 2014 году. Идея была в том, что больше обязанностей по тестированию возложат на разработчиков, создающих эти функции. Программа Windows Insider также обеспечивает большой объём неформального тестирования — со многими миллионами участников (инсайдеров). Это гораздо больше, чем в любой из предыдущих бета-программ Windows.

Возможно, профессиональные тестеры не проверили бы конкретный сценарий, при котором удаляются данные. Не уверен, что старый подход обязательно обнаружил бы баг с потерей данных. Потерю данных зафиксировали за три месяца до выхода обновления. Но ясно, что Microsoft не справляется с обработкой потока сообщений об ошибках от инсайдеров. Более длительный период разработки будет означать, что ошибку проигнорировали в течение шести месяцев, а не трёх. Многие сообщения об ошибке кажутся низкого качества, им не хватает необходимых деталей или правильной терминологии, но если компания не заметила проблему в течение трёх месяцев, то совсем не очевидно, что более длительный период разработки имеет значение.

Это может помочь, если инсайдеры будут корректно использовать индикаторы серьёзности, но кажется недостаточным для решения главной проблемы: слишком большого количества отчётов об ошибках слишком низкого качества. Microsoft обещала изменить процесс обратной связи с инсайдерами, чтобы те указывали серьёзность проблемы и привлекали больше внимания к такого рода проблемам.

Реальная сила программы Insider — разнообразие аппаратного и программного обеспечения. Это относится к проблеме качества кода. Но инсайдеры не должны осуществлять базовое тестирование функций. Инсайдеры могут выявить самые экзотические баги совместимости, проблемы с драйверами и так далее. Но часто возникает ощущение, что Microsoft использует их как штатных тестировщиков.

Они недостаточно надёжны. Более того, если качество кода падает во время разработки, то предварительные сборки обычно не подходят для повседневного использования на обычных ПК. Они используют второстепенные ПК и виртуальные машины. В свою очередь, это подрывает ценность тестирования инсайдерами: они не устанавливают их на основной ПК и не подвергают сборки полному спектру аппаратного и программного обеспечения.

Разработка инфраструктуры тестирования как у Chrome для такого гигантского проекта как Windows — очень серьёзная задача. Хотя некоторые части Windows допускают автономное тестирование, но другие можно эффективно проверить только в интегрированной целостной системе. Некоторые из них, такие как функция синхронизации файлов OneDrive, даже зависят от работы внешних сетевых служб. Это совсем не тривиальная задача.

Но это необходимое условие. Огромным изменением стало бы принятие принципа, что код Windows должен в каждым момент времени обеспечивать релизное качество — не «после нескольких месяцев исправления», а «прямо сейчас, в любой момент». Ситуации, где апдейт на самую последнюю версию не является проблемой — и такой выбор можно с уверенностью принять. Microsoft должна добиться ситуации, когда каждое новое обновление обладает релизным качеством с первого дня. Сокращение количества релизов до одного в год или одного в три года не обеспечит такой ситуации, и никогда не обеспечивало. Обновления функций должны стать незаметными событиями для пользователей. Должен измениться сам процесс, а не сроки.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Введение в ptrace или инъекция кода в sshd ради веселья

Конечно, это несколько искусственная задача, так как есть множество других, более эффективных, способов достичь желаемого (и с гораздо меньшей вероятностью получить SEGV), однако, мне показалось клёвым сделать именно так. Цель, которой я задался, была весьма проста: узнать введённый в sshd ...

Дайджест свежих материалов из мира фронтенда за последнюю неделю №339 (12 — 18 ноября 2018)

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.     Медиа    |    Веб-разработка    |    CSS    |    Javascript    |    Браузеры    |    Занимательное Медиа • Подкаст «Frontend Weekend» #79 – Олег Поляков об основании CodeDojo и о том, как это стало основным местом работы• Подкаст «Пятиминутка React» ...