Методы для хранения Ваших проектов на [закрытой] последней версии
4 ответа
Я согласен с другими комментариями по поводу частого обновления. Если вы будете ждать слишком долго, работы будет достаточно, и вы заметите это в производительности проекта.
Мы делаем это следующим образом.
- Один человек в команде получает последнюю версию и следит за тем, чтобы все тесты выполнялись.
- Этот человек обновляет все библиотеки / инструменты, которые должны быть обновлены
- Он также документирует обновление.
- Скомпилировать весь код, внести необходимые изменения для его сборки
- Запустить все тесты , убедитесь, что они запущены.
- Ручной дымовой тест пользовательского интерфейса
- Отправить информацию остальной команде с документом об обновлении
- Проверить / убедиться, что сборка выполняется на сервере сборки
Таким образом мы не теряем производительности команда во время обновления. Обратите внимание, это было бы намного сложнее без модульных тестов.
«обновлять раньше, обновлять часто»
если вы ждете, будет все труднее и сложнее, поэтому установите высокий приоритет на обновление системы. Разработчики в основном любят быть на переднем крае, поэтому они не будут слишком возражать, основная задача - продать эту идею руководству.
Всегда полезно применять пошаговый подход, когда вы обновляете инструмент один за другим. Тогда также будет проще, если вам нужно будет вернуться к более старой версии. Подход «большого взрыва» сложнее, и многое может пойти не так.
Давайте будем реалистами, каждое обновление будет стоить вам времени, а также вашей команде, чтобы переключиться на новую версию инструментов, но через некоторое время команда научится с этим справляться. а уровень стресса при переключении версий намного меньше.
Довольно просто сделайте это приоритетом и улучшайте по мере продвижения. Если вы будете обновлять последнюю версию, критических изменений будет меньше, чем если бы вам пришлось обновлять 5 версий за раз.
Возможно, создайте ветку и выполните тестовое обновление бета-версий, чтобы вы знали о предстоящих проблемах, когда эта версия RTM будет выпущена (если вас беспокоит использование бета-версий).
С точки зрения управления, не обновляйте, если нет непреодолимая причина. Вы должны посмотреть, что обновление принесет вашему проекту. Если обновление не дает никаких преимуществ, не делайте этого. Очевидно, это не жесткое и быстрое правило, но у большинства команд, которых я знаю, нет времени на обновление систем без причины, они слишком заняты запросами функций и исправлениями ошибок. Я рекомендую работать над обновлениями на следующей основе:
- Новая версия работает [значительно] быстрее или больше эффективно и ваш клиенты / клиенты увидят это улучшение или это уменьшит ваш имманентные потребности в оборудовании.
- Особенности были добавлены, что вы или ваш клиенты / клиенты хотят и могут взять [немедленное] преимущество.
- Повышение безопасности для ценной бумаги недостаток, который влияет на ваш текущий или архитектура ближайшего будущего.
- Причины лицензии / поддержки. Если ты в конце вашего контракта вы возможно захочет сделать финал перейти к последней версии программное обеспечение, на которое вы имеете право пока у вас все еще есть поддержка Обновить. В качестве альтернативы, если вы на такая старая версия софта что поиск подтверждающей документации потому что это сложно затем обновить безусловно требуется.
- Некоторые аспекты вашего проекта на работу напрямую влияет программное обеспечение, которое может быть обновлен. Если ты уже идешь работать с этим и тестировать функциональность, вероятно, это хорошее время для обновления и [вероятно] не добавит значительной нагрузки проект.
- Основные изменения. Если твой проект или программное обеспечение, на которое он опирается претерпели серьезные изменения, тогда это вероятно, хорошее время, чтобы добавить обновление (я) в вашем плане проекта. Основные изменения предполагают более сложный путь обновления и должен быть уговаривать по расписанию скорее чем необходимость в последнюю минуту из-за необходимого исправления или улучшения.
Конкретные причины не обновлять:
- Программное обеспечение, установка и регрессионное тестирование стоит денег. Отсюда необходимость в веской причине для обновления.
- Новое программное обеспечение часто содержит ошибки или имеет неизвестные «функции». По этой причине многие предпочитают отставать от последней версии на одну версию.
- Новые версии часто могут быть медленнее, чем предыдущие версии, особенно это касается небольших обновлений и исправлений.
- Проблемы совместимости. Обновления ломают вещи, лучше пропустить как можно больше дополнительных обновлений, чтобы избежать обновлений, которые нарушают совместимость, совместимость, которая может быть исправлена в следующем обновлении.
Я рекомендую вести список всего программного обеспечения, которое используется в вашем проекте, с указанием их версии и даты последнего обновления (вместе с другой важной информацией, такой как информация о лицензировании, информация о поддержке и т. Д.). Оценивайте каждый элемент в этом списке один раз в год, чтобы убедиться, что вы не пропустите никаких обновлений, соответствующих причине обновления, которое вы могли пропустить. Программное обеспечение в этом списке со старой версией / датой и доступной более новой версией может быть достаточным стимулом, чтобы убедить руководство в необходимости обновления.