Это занимает немного больше времени чем ожидалось windows 10

Это занимает немного больше времени чем ожидалось windows 10

Сообщения: 287
Благодарности: 7

Конфигурация компьютера
Процессор: Intel i3 330
Материнская плата: GIGABYTE GA-H55N-USB3 (rev. 1.0)
Память: Samsung DDR3 1333 DIMM 2Gb
HDD: 160Gb
Видеокарта: IN i3 GA-H55N
Звук: 7.1CH, HDA, Realtek ALC892R
Блок питания: 500w nnm
CD/DVD: USB
Монитор: BenQ E2220HD
ОС: Windows 7 Ultimate x64
Индекс производительности Windows: Win+Pause

win 10 x64 pro интегрированны драйвера на чипсет «кофи лейк» физический ПК или даже виртуальный не важно.
После подготовки профиля, \sysprep.exe /generalize /oobe /shutdown /unattend:\sysprepcopy.xml
в файле sysprepcopy одна команда CopyProfile

Скрытый текст

Затем захват imagex (файл пока не используем лежит в сторонке)
Включаем этот же ПК или виртуалку.
Проходим выбор языка/соглашаемся и создаём пользователя.
Получаем экраны
Привет:
1. Это может занять некоторое время.
2. Это занимает немного больше времени чем ожидалось но мы постараемся.
3. Чёрный экран с курсором, вроде не завис но ничего не даёт сделать.
Перезагружаем насильно.
Бум-
Привет:
Почти готово.
Рабочий стол.

Подготовка Windows. Не выключайте компьютер долго висит в Windows 10

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

Причина сообщения «Подготовка Windows. Не выключайте компьютер»

Как известно, функционал ОС Windows 10 позволяет в автоматическом режиме устанавливать все необходимые обновления. Обычно обновления загружаются в систему в фоновом режиме, а потом, при выключении-включении ПК, автоматически устанавливаются в системе.

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

Самая большая проблема это то что гребаная десятка не показывает никаких сообщений и ничего не пишет в ходе процесса обновления. Никаких ползунков и процентов выполнения задачи. Просто висит одна надпись и всё. Совершенно не информативно и обычному пользователю сложно понять что происходит. Завис ПК или он выполняет какую-то трудоёмкую задачу и она вот вот закончится.

Причины зависаний могут быть такие:

• Программный конфликт при установке обновлений;
• В системе пользователя существует проблема, препятствующая установке конкретных обновлений;
• Нестабильное обновление от Майкрософт;
• Нестабильная работы службы обновления Win10;
• Наличие на ПК пользователя вирусных программ;
• Проблемы с оперативной памятью или жёстким диском ПК (бед секторы, пыль, «осыпание» диска и пр.)

Давайте разберёмся, что делать если такое сообщение очень долго висит на вашем экране в винде.

Убедитесь, что ваш компьютер действительно завис

Для установки многих обновлений в винде может понадобиться довольно много времени. Потому, если у вас зависло сообщение «Не выключайте компьютер», не спешите бить в бубен, и пытаться что-то исправить. Иначе вместо решения проблемы вы создадите другую проблему самостоятельно.

Если никуда не торопитесь и есть возможность оставить компьютер, пусть он повисит так хоть всю ночь или день. В любом случае говорить о наличии проблемы можно не ранее, нежели через пару часов после момента появления рассматриваемого нами сообщения. И это при условии, что вы не наблюдаете активности вашего ПК, а индикатор винчестера или вовсе не светится, или светится регулярно, но очень короткими включениями.

Если же проблеме уже более трёх часов, а никаких изменений не наблюдается, тогда идём дальше.

Использование Ctrl+Alt+Del, если компьютер долго висит

Установку некоторых апдейтов ОС Windows 10 можно прекратить с помощью нажатия на клавиши Ctrl-Alt-Del на клавиатуре вашего ПК. Особенно это актуально во время загрузки компьютера, когда после нажатия на указанное сочетание клавиш вы попадёте на экран выбора учётной записи. Войдите в систему обычным путём, и попробуйте вновь установить нужный апдейт.

Нажмите на ctrl+alt+del для устранения зависания

Перезагрузка ПК при ошибке о подготовке Windows 10

Если Ctrl-Alt-Del не срабатывает, и с момента запуска процесса обновления прошло более 3 часов, рекомендуем сбросить процесс обновлений, нажав на кнопку «reset» вашего ПК. Загрузитесь в обычном режиме, и попробуйте установить апдейт заново.

Загрузка системы в безопасном режиме

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

1. При включении системы и начале загрузки Windows быстро периодически жмите на клавишу F8.
2. При появлении системного меню выберите опцию «Безопасный режим» и дождитесь загрузки системы.
3. После окончания загрузки перезагрузите ПК в стандартном режиме. Это поможет устранить зависание надписи «Не выключайте компьютер» в Виндовс 10.

Загрузите систему в безопасном режиме

Другие варианты входа безопасный режим читайте в нашем материале «Как войти в безопасный режим Виндовс 10».

Восстановление системных файлов компьютера

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

1. Загрузитесь с данного USB-носителя.
2. Выберите на базовом экране язык и систему.
3. Затем нажмите внизу слева на надпись «Восстановление системы».
4. Далее выберите опцию «Поиск и устранение неисправностей».
5. Далее «Дополнительные параметры» и затем «Командная строка».

Выберите «Командная строка»

1. Далее наберите там: sfc /scannow
2. Нажмите ввод. Дождитесь окончания процесса и перезагрузите ваш ПК. Проблема может быть решена.

Тестирование системной памяти при ошибке «Подготовка Windows. Не выключайте компьютер»

Многие проблемы возникают из-за нестабильной работы планок памяти. Рекомендуем провести тест вашей памяти с программами уровня «MemTest86», с целью определения вышедших из строя планок памяти.

Используйте программы уровня «MemTest86» для проверки планок памяти ПК

Откат Windows 10 до стабильной ранней версии

Откат системы до стабильной версии может послужить удобным инструментом для решения проблемы «Подготовка Windows. Не выключайте компьютер».

Для этого выполните следующее:

1. Загрузитесь в безопасном режиме, как указано выше;
2. Нажмите на Win+R, и введите в появившейся рамке rstrui и нажмите ввод;
3. Появится окно для восстановления системы;
4. Среди перечня доступных для восстановления ранних дат выберите ту, при которой проблем с системой не наблюдалось (подойдёт любая ранняя дата);
5. Выполните процедуру восстановления, после которой перезагрузите ваш ПК. Проблема может быть решена.

Заключение

Зависание рассматриваемого сообщения на синем экране обычно сигнализирует о проблемах с установкой апдейтов в пользовательской системе. Для решения возникших проблем рекомендуем подождать какое-то время (до 3 часов). Если ничего не поменялось, тогда выполните весь комплекс перечисленных нами советов. Это позволит устранить дисфункцию «Подготовка Windows. Не выключайте компьютер» на вашем PC с Windows 10, если он долго висит.

• ← Как убрать Панель задач внизу экрана на Windows 10 при просмотре видео фуллскрин
• Эквалайзер для Windows 10 стандартный или сторонний? →

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

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

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

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

Windows как сервис

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

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

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

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

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

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

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

Дело не в частоте, а в том, КАК готовятся апдейты

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

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

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

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

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

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

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

Процесс, уходящий корнями в историю

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

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

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

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

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

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

Новый мир не такой уж и новый

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

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

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

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

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

Упадок качества

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

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

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

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

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

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

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

Тестируйте софт перед выпуском, а не после

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

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

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

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

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

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

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

Как сделать всё правильно

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

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

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

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

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

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

Процесс разработки Windows всегда был плох

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

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

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

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

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

Это не работа инсайдеров

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

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

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

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

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

Вы должны инвестировать в свои инструменты

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

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

• Windows 10
• обновления Windows
• непрерывная доставка
• автоматические тесты
• Agile

• Тестирование IT-систем
• Совершенный код
• Системное программирование
• Agile
• Разработка под Windows

Во время установки и обновления Windows 11 теперь можно поиграть

Теперь пользователям предлагается сделать перерыв и поиграть в казуальную игру Surf во время установки обновления. Впервые данное изменение обнаружено изданием The Verge во время установки Windows 11 на ноутбук Surface Laptop Studio 2.

Игра Surf интегрирована в браузер Microsoft Edge и доступна по адресу edge://surf. Для запуска игры не требуется подключение к Интернету.

Впервые игра была представлена в мае 2020 года в Microsoft Edge. Данный проект представляет собой современное переосмысление классической игры SkiFree, входящей в состав пакета Microsoft Entertainment Pack 3 для Windows 3.0, выпущенного в октябре 1991 года.

Теперь при установки Windows пользователи получают следующее предложение:

Хотите поиграть в игру, пока ждете? Загляните в полюбившуюся фанатам игру Surf! Введите edge://surf в Microsoft Edge, чтобы поиграть позже.

Microsoft добавила эту игру в процесс установки Windows, чтобы подготовить пользователей к потенциально длительной процедуре установки.

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

Игра может вызывать ностальгию у пользователей, особенно у тех, кто знаком с игрой по более ранним продуктам Microsoft.

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

Пока неясно, затрагивает данное изменение все устройства Windows или только Microsoft Surface. При тестировании на компьютере Windows 11 предложение не появлялось.