Разработчики должны бояться обновлений своего программного обеспечения рабочей станции / стопка разработки?

Нет.

Поэтому Бог изобрел виртуальные машины.

Вид неприятности, если Вы - программист OS X, тем не менее, из-за основанной на аппаратных средствах защиты от копирования в ОС (необходимо работать на Apple, благословил аппаратные средства).

Обжегшись на молоке, будешь дуть и на воду.

Этого почти никогда не происходит, что целевая машина для программного обеспечения, которое Вы пишете, совпадает с Вашей машиной разработки. Поэтому не имеет большого смысла не обновлять и сохранять машину всеми помехами.

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

Хороший пример этого произошел на днях на моей работе. Команда IT развернула обновление нашего сервера разработки, который казался безопасным сначала. Машина имела необслуживаемый вход в систему, который должен был остаться, вошел в систему 24/7. Обновление для Windows (я должен был бы вытащить КБ) на самом деле автоматически выходит из системы тот тип пользователя. Приложения мы работаем на сервере, требуют посещенных логинов для выполнения (да, глупый, я знаю, но это - другая история). Внезапно наши системы начали выходить из строя, и жалобы насыпали это, некоторые используемые программные системы не работали.

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

Обновления должны быть проверены на то, какое воздействие на окружающую среду они могут иметь на Вашей ОС перед тем, чтобы быть реализованным, и даже затем они должны быть протестированы.

Сохраните операционную систему максимально актуальной, предпочтительно имея sys администраторский тест патчи прежде, чем выпустить их к остальной части компании.

Примените dev пакеты обновления среды обоснованно быстро, но проверьте VM сначала, таким образом, Вы видите, работает ли сборка все еще, и затем дайте ту сборку QA для испытания с помощью дыма прежде, чем обновить dev машины.

Измените dev среду (и/или платформа, например, обновляющий от Java 5 до Java 6), когда Вы будете видеть реальную выгоду, но будете позволять ее как явную задачу с планируемым временем. Идеально, время проекта бюджета для получения разработчиков до скорости также, таким образом, они могут максимально использовать его. Не делайте этого никакого времени около выпуска.

B, из соображений безопасности.

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

Если это - веб-приложение, Ваша 'платформа' является браузером (браузерами) и независимо от того, что Вы используете сторону сервера. Для меня, который является рубиновым, направляющие и плагины плюс apache/mysql и т.д. Сторона клиента, я не имею никакого контроля. Сторона сервера, я хочу применить, по крайней мере, патчи безопасности (в стороне: просьба серверным разработчикам, выпустите патчи безопасности на другом цикле к изменениям функциональности!).. Но обновления ОС обычно имеют мало эффекта на dev стопку сервера, которую я использую, и в любом случае моя среда развертывания использует другую ОС (я разрабатываю на OSX и Ubuntu и развертываюсь на Debian и Солярисе).

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

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

ОС: Актуальный (хотя я не фанатичен об этом).

Небольшие приложения: Не так. Я опасаюсь обновлений и не обновлю, если нет некоторая добавленная стоимость в нем для меня.

Сделайте обновление, но не во время критического периода в цикле разработки. Используйте распределение ОС, которое, как известно, было максимально стабильно и известное быть консервативными в том, как часто они выпускают обновления.

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

Существует много вещей посмотреть на (я пишу из опыта linux/unix, но вещи должны относиться к другим операционным системам также):

• Знайте о поврежденных обновлениях. Поврежденные обновления происходят, и благоразумно позволить другим перенести поломку. Особенно знайте о базовых компонентах, таких как c библиотека (включая интерфейсы ОС, обычно включенные), компоновщик, компилятор, и т.д.
• Обновление библиотек компонентов для Вашего продукта должно быть сделано осторожно (или в системе тестирования / vm сначала). Библиотеки, которыми высоко пользуются, такие как библиотека C обычно в порядке, но меньшие используемые могут содержать повреждения API или семантические изменения в API.
• Запишите свое программное обеспечение, чтобы быть терпимыми к его среде:
  • Предпочтительно используйте различные по-другому настроенные системы для записи
  • Запишите, не принимая атрибутов среды
  • Обновите систему при необходимости, если что-то повреждается, добираются до первопричины и устраняют это.
  • Особенно опасайтесь сложных системно-зависимых систем сборки (они требуют намного большего количества обслуживания, чем более простой (или автоматизированный)) помимо затрат на жесткость.

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

Существует старая поговорка. "Никогда не изменяйте рабочую систему". Я предполагаю, что страшные истории о скудных обновлениях являются легионом. Я просто могу сказать на основе своего опыта. При базировании Вас программное обеспечение на "хорошо подвешенном" компоненты, вероятность для повреждения их намного меньше, чем вещи под быстрым темпом изменения. Некоторый пример: Наш IDE основан на Победе API и работает почти неизменный начиная с Windows 3.1 (где это было разработано), мы добавили несколько nicecities за эти годы, таким образом, я поставил потребности пакета, по крайней мере, Windows 2000 для выполнения. Но я могу уверить Вас, что это переживает много обновлений ОС от XP по Windwos NT, Windows 2000, Windows 2003, Windows XP, Windows 2003-64 и "oh-so-shiny" Vista.

С другой стороны, я не мог быть в курсе базирующегося порта gtk его на Linux. Изменения API являются экстремальным значением. Таким образом, это - то, что я ненавижу большинство о сторонниках с открытым исходным кодом, Вы вынуждены восстановить свою работу много раз только для пребывания фактическими.

Другой пример, который имеет, взял меня, по крайней мере, хорошая неделя работы бледное обновление очень маленького приложения направляющих от Версии 1.1.6 до 2,2. (и это всего за два года). Я боялся, что это будет худшим, но было несколько positivly удивлено.

С уважением