Частота и прогнозируемость выхода сборок для участников Программы предварительной оценки Windows
Всем доброго дня.
Мне задают много вопросов о том, как работает Программа предварительной оценки и как идет разработка Windows 10. Я получаю их и на форуме сообщества Windows 10, и в Twitter. Ответы не всегда доходят до всех желающих их услышать — или узнать подробности. Поэтому я периодически публикую ответы на часто задаваемые вопросы в Центре предварительной оценки или пишу их в блоге, как сейчас.
Первая тема, которая вот уже две недели не сходит со страниц моего веб-канала Twitter, звучит примерно так: «Я жду следующую сборку!» Что ж, прежде всего, меня радует неподдельный восторг, с которым люди ждут новых сборок и возможности испытать новые функции. По правде говоря, на это мы и надеялись, когда запускали Программу предварительной оценки Windows. И мы очень благодарны вам за такой энтузиазм.
Помимо этого, есть еще два распространенных вопроса, на которые я не мог достаточно подробно ответить в 140 символах Twitter.
1. «По-моему, в январе вы говорили, что теперь сборки будут выходить чаще, разве нет?»
2. «Почему вы не можете просто сообщить, когда выйдет следующая сборка? К чему такая скрытность?»
В этой записи блога я надеюсь подробно ответить на оба эти вопроса. Мы вовсе не стремимся намеренно скрывать от вас эту информацию, просто ответ на этот вопрос несколько сложнее, чем кажется. И признаем, что следовало прояснить эти моменты раньше.
Цикл выхода сборок: почему чаще не значит лучше
Если кратко, то мы пытаемся сдерживать выход сборок для участников, работающих в режиме быстрого получения обновлений.
В настоящее время мы активно обсуждаем, как нам быть дальше, и уже внесли несколько изменений в принципы работы. Реальность такова, что сборки, которые вы получаете быстрее, содержат больше ошибок, а мы стремимся к стабильности. Но несмотря на это участники программы с быстрым и медленным циклами обновлений получают примерно одинаковое количество сборок. Для внутреннего тестирования ситуация другая: круг Canary получает примерно вдвое-втрое больше сборок, чем круг OSG, потому что те сборки, в которых участники Canary выявляют ошибки, не передаются в OSG.
Это новый подход: мы учимся на своих ошибках и улучшаем работу. Со стороны кажется, что примерно то же самое было в прежних программах тестирования предварительных версий или старых программ CTP со времен Vista или даже раньше. Однако новые программы кардинально отличаются как подходом, так и базовыми технологиями. Мы также подготовили еще ряд интересных нововведений. Так, сейчас мы обсуждаем, стоит ли изменить соотношение скорости выхода сборки и риска для быстрого цикла или вообще создать новый круг для людей, которые действительно хотят получать новые сборки максимально быстро. (К слову, на прошлой неделе я обсуждал с коллегами круг «молниеносной скорости».) Когда мы примем решение, то сообщим его вам, чтобы вы знали, чего ожидать.
Иногда новая функциональность, которая включается в сборку, требует дополнительной стабилизации и доработки. Интеграция возможностей требует разного количества времени, поэтому заранее составить точный график выхода сборок для участников программы не удастся. Иногда они будут доступны раньше, а иногда — позже. Вот поэтому я уже писал в Twitter, что новую сборку можно ожидать «примерно раз в месяц». Иными словами, обычно сборки как раз и выходят каждые 30 дней или около того, хотя иногда они немного задерживаются (что сейчас и произошло).
Почему так сложно просто назвать дату выхода следующей сборки?
Казалось бы, это нелогично, но если объявлять дату заранее, сборки будут публиковаться медленнее и включать меньше нового содержимого, чем при открытой дате выхода. Почему?
- Если мы называем конкретную дату, то хотим быть точно уверены в том, что все успеем. Согласитесь, малоприятно узнать дату, а потом разочароваться, если сборка не выйдет. Для нас это тоже неприятный момент, а вдобавок еще и отвлекающий фактор. Более того, такая стратегия мешает работать и нашим инженерам. Не успевая к дате выхода, многие вынуждены браться за все подряд, стараясь доделать работу быстрее — вместо того чтобы поработать вдумчиво и продуктивно.
- Для уверенности мы бы выбрали максимально позднюю дату, чтобы избежать авралов. Мы бы выделили себе время на работу с ошибками и повторное создание сборки.
- Если бы у нас получилась отличная сборка, как часто и бывает, раньше назначенной даты, мы бы отложили ее поставку — до объявленного дня. Почему бы просто не выпустить ее раньше? Во-первых, некоторым не нравятся сюрпризы, а во-вторых, получается, что мы не всегда сдерживаем обещания. Мы хотим, чтобы люди знали: если мы сообщили точную дату, значит, на нее можно рассчитывать.
- В худшем случае, если нам встретится очень сложная проблема и времени на ее устранение не останется, сборка может выйти с опозданием. А это гораздо хуже, чем раньше времени. Это бы расстроило людей, которые надеялись получить обещанное в объявленную дату.
Поясню на примере будущей сборки. Сегодня 9 марта, и мы хотим, чтобы сборка успела выйти до конца месяца. Если бы мы назвали целевую дату, к которой продукт точно будет готов, то, скорее всего, это было бы 26 марта. Тогда у нас остается время на стабилизацию, плюс это четверг (а не понедельник или пятница, которых мы стараемся избегать). Время от времени мы по-прежнему получали бы полезные сведения по новым функциям, но в районе 17 марта нам бы уже пришлось сосредоточиться на стабилизации, внося только выборочные изменения. Гораздо проще стабилизировать сборку, когда дополнительного кода немного, поэтому мы бы отобрали только несколько основных исправлений. 23 марта была бы подготовлена сборка-кандидат, которую мы бы выпустили для обширного тестирования в Майкрософт, чтобы найти оставшиеся сбои и с уверенностью подойти к объявленной дате. Похоже, не так уж и плохо, правда? Вот только чтобы избежать худшего случая, когда мы опоздали бы к выходу и расстроили людей, мы выбрали бы относительно «безопасную» дату — примерно раз в месяц, а код обновлялся бы только частично .
Теперь поговорим о том, как мы хотим организовать работу. Сегодня 9 марта, и мы еще не назначили дату для следующей сборки. Сейчас у меня есть сборка, которую мы создали в пятницу. Ее проверили автоматическим тестированием, а потом она пройдет внутренние витки проверки: ее установят и начнут использовать тысячи людей в Майкрософт. Она включает самый свежий код со всеми новейшими возможностями и исправлениями. Если сборка удовлетворит всем критериям оценки, то вы получите ее в конце этой или в начале следующей недели. Это означает, что мы вполне можем выпустить в марте несколько сборок, а не одну, причем они будут содержать более актуальный код, чем при подходе с фиксированной датой. Понятно, что это звучит уж слишком самоуверенно, учитывая, что с выхода последней сборки прошло уже более 40 дней, а я тут рассказываю про несколько сборок в месяц. Однако таковы наши намерения и стремления: мы действительно хотим работать по-новому. Иными словами, не связывая себя точной датой выхода сборки, мы работаем быстрее. Приведу реальный пример. У нас возникли внутренние разногласия по поводу того, стоит ли обнародовать дату выхода для сборки 9926. Она была готова на следующий день после мероприятия по Windows 10, состоявшегося 21 января. Варианты были такие.
1. Объявить, что выпуск состоится 23 января, зная, что эту сборку мы создали еще несколько недель назад и что в ней нет большинства показанных на презентации возможностей.
2. Объявить, что выпуск состоится 15 февраля, чтобы временно придержать хорошую сборку.
3. Не объявлять дату, провести сборку по виткам тестирования и выпустить, когда все будет готово.
Мы выбрали третий вариант и не прогадали. Мы подготовили более новую сборку, куда вошли многие возможности и исправления, и смогли выпустить ее 23 января, как и предполагалось.
Мы ждем ваших отзывов и вопросов
Я надеюсь, что помог вам разобраться в том, как мы планируем цикл выпуска сборок и как отвечаем на ваши комментарии и предложения. Мы очень благодарны участникам Программы предварительной оценки Windows за время и силы, которые вы вкладываете в наш продукт, и за содержательную обратную связь. Именно благодаря вашей поддержке мы постоянно улучшаем продукт. И вскоре мы подготовим еще одну запись блога, в которой расскажем о внутренней работе с вашими отзывами (этот вопрос тоже интересует многих участников программы).
Спасибо за внимание, ваш Гейб Ол (Gabe Aul)