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

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

Маленькие приложения: не так уж и много. Я с осторожностью отношусь к обновлениям и не буду обновляться, если они не принесут мне дополнительных преимуществ.

Нет.

Вот почему Бог изобрел виртуальные машины.

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

Идиома: обжегся на молоке - дует на воду.

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

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

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

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

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

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

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

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

Б. Определенно.

Если вы разрабатываете платформу с неопределенной родословной обновлений (например, The Real World), тогда виртуальные машины являются важным оружием, но стоит быть как можно более актуальным при выпуске.

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

Если вы разрабатываете исключительно для внутренней аудитории, у вас действительно есть только один вопрос:

• есть ли расписание обновлений для компании?
  • да: тогда вам нужно убедиться, что ваше программное обеспечение работает как на производстве, так и на всем, что будет
  • нет: наверное, лучше это исправить.

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

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

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

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

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

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

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

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

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

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

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

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

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

С Уважением