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

Question

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

стратегия А.) Оставьте систему такой, какая она есть, потому что это возможно.

Мне лично нравится, чтобы моя система была как можно более современной (ОС и приложения), потому что, как правило, у меня меньше проблем с такой работой.

стратегия Б.) ВСЕГДА ДО ДАТЫ

Какой вы разработчик? И почему?

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

номер

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Answer 7

Однажды укушенный, дважды застенчивый.

Answer 8

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

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

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

Привет

Answer 9

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

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

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

Answer 10

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

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