Какие стандарты выполняет ваша команда для развертывания кода с большой версией?

Ответ 1

Минимум:

• Работа с модульными тестами
• интеграционные тесты работают
• развертывание на тестовом этапе ok
• ручная короткая проверка на этапе тестирования

лучше:

• Работа с модульными тестами
• checkstyle ok
• интеграционные тесты работают
• такие как jmeter и пройденное пройденное тестирование
• развертывание на тестовом этапе ok
• некоторые ручные тесты на этапе тестирования

окончательно развертывается на стадии производства

Все тесты на единицу и интеграцию работают автоматически, лучше всего на сервере непрерывной интеграции, например CruiseControl, выполняемом ant или maven. При разработке web-сервисов тестирование с soapui отлично работает.

Если используется база данных, выполняется автоматическое обновление (например, liquibase) перед развертыванием. Когда используются внешние службы, необходимы дополнительные тесты конфигурации, чтобы убедиться, что URL-адреса в порядке (запрос главы от приложения, подключение к базе данных, wsdl get,...). При разработке webpps полезно использовать HTML валидация на некоторых страницах. Ручная проверка макета (используйте browsershots, например). Было бы полезно.

(Все примеры ссылок для разработки Java)

И последнее (но не менее важное): все ли приемочные тесты все еще проходят? Является ли продукт тем, что хочет владелец? Сделайте живой обзор с ним в тестовой системе, прежде чем идти дальше!

Ответ 2

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

• Убедитесь, что все веб-службы обновлены.
• Убедитесь, что все сценарии/изменения/миграции базы данных уже развернуты на рабочем сервере.
• Мини файлы js и css.
• Убедитесь, что все тесты на единицу/функциональность/интеграцию/селену проходят (мы стремимся к охвату 95% + тестированием во время разработки, поэтому они обычно довольно точны при определении проблемы).

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

Ответ 3

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

Без особого порядка:

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

2) Снимок точного кода, используемого для создания выпуска. (метка или ветвь релиза в системе SCM хороша для этого)

3) Все инструменты, необходимые для воссоздания источника, должны быть отмечены и заархивированы (источник с шага 2 становится ограниченным использованием без этого)

4) Архив фактического релиза (копия точного установщика выпущена, кто знает через 7 лет ваши инструменты, возможно, не сможет ее построить, но теперь, по крайней мере, у вас есть исходный код и устанавливаемый на вашей стороне для целей расследования).

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

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

7) Отслеживание дефектов показывает, что все выдающиеся элементы отмечены как a) исправлено b) не является дефектом c) отложено.

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

Получайте удовольствие от штурма замка.

Ответ 4

• Codestyle (автоматизированный)
• Автоматизированные тесты (тесты для модулей и интеграции)
• Ручные тесты (включая тестовые и бета-этапы)
• Инструмент для тестирования проникновения белых ящиков (автоматизированный)
• Инструмент тестирования проникновения Blackbox (автоматизированный)
• Мониторинг ручного исключения/ведения журнала на тестовых/бета-этапах перед развертыванием
• возможность вернуться к предыдущей версии в любое время
• обзор кода и "незаконные проверки"

Ответ 5

Для веб-приложений и приложений в дополнение к другим предложениям.

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

Ответ 6

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

Ответ 7

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

• Выпускные кандидаты выходят в группу тестирования. Им нужно по крайней мере несколько дней, чтобы поиграть с ним. Если они обнаруживают ошибки, которые мы рассматриваем show-stop, выпуск прерывается. Это предполагает, что у вас есть группа тестирования. Мы освобождаем только освобождающего кандидата, если по крайней мере одна неделя прошла с момента его создания.

• Все автоматизированные испытания должны работать и проходить. Автоматическое тестирование считается дополнением к живым тестировщикам.

• Любые ошибки, отмеченные как "блокирующие", должны быть разрешены для окончательной сборки.

• Материалы для публикации должны быть готовы (в нашем случае, обновление веб-страницы и бюллетень электронной почты). Реселлеры предупреждены о том, что релиз наступает за несколько недель вперед, чтобы они могли также подготовить свой материал. Это в основном не проблема программистов, но мы проверяем маркетинговые претензии на точность.

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

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

• Любые ссылки на бета-версию необходимо удалить из самого приложения. Мы упустили некоторые из них, неловко.

• Файлы справки и руководства должны были быть полностью обновлены и исправлены, поскольку они были частью пакета выпуска.

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

Далеко и далеко, трудности крупного выпуска не были проблемами программирования, они были административными/маркетинговыми проблемами. Многие из этих вещей требовали внимания программистов - помогали с установщиками, проверяли список функций, чтобы убедиться, что ничто из этого не было бессмыслицей, прочтением технических разделов руководства, обновлением лицензирования и т.д. Главным техническим отличием был переход от исправление ошибок для устранения ошибок.

Ответ 8

• Нет видимых ошибок? ОК
• unit test работать? ok (некоторые игнорируются) ha хорошо ok
• настроить. ОК
• регистрация ошибок? конечно!:-) нам нужно это! исправить ошибки!
• все на cruisecontrol.net приятно.