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

Question

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

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

• Обеспечиваете ли вы наличие мониторинга для серверных приложений?До какой степени...просто то, что он реагирует на ping, что он может поразить все свои зависимости в любой данный момент, что логика, которую приложение фактически обслуживает, верна (например, сервис, который вычисляет 2 + 2, на самом деле возвращает "4")
• Требуются ли вам сценарии автоматической сборки перед выпуском кода?То есть, любой разработчик может зайти в новую коробку, вытащить что-то из системы управления версиями и начать разработку?Конечно, с учетом таких вещей, как ОС и IDE.
• Как насчет сценариев автоматического развертывания для серверных приложений?
• Какой уровень документации вам требуется для того, чтобы проект был "выполнен"?
• Вы чертовски уверены, что у вас есть полноценный план резервного копирования для всех основных компонентов системы, если она серверная?
• Соблюдаете ли вы стандарты качества кода?Подумайте о StyleCop для .Оценки СЕТЕВОЙ или цикломатической сложности.
• Модульное тестирование?Интеграционные тесты?Нагрузочное тестирование производительности?
• Есть ли у вас стандарты того, как обрабатывается протоколирование ошибок вашего приложения?Как насчет уведомления об ошибке?

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

Answer 1

Минимальный:

1. модульные тесты работают
2. интеграционные тесты работают
3. развертывание на стадии тестирования ок
4. ручная короткая проверка на этапе тестирования

Лучше:

1. модульные тесты работают
2. контрольный стиль ОК
3. интеграционные тесты работают
4. такие показатели, как jметр и тестовое покрытие пройдено
5. развертывание на стадии тестирования ок
6. некоторые ручные тесты на стадии тестирования

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

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

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

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

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

Answer 2

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

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

Есть еще что-то, я знаю, что есть, но прямо сейчас я не могу ни о чем думать.

Answer 3

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

Без какого - либо определенного порядка:

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

2) Моментальный снимок точного кода, использованного для создания релиза.(для этого подойдет лейбл или ветвь релиза в системе SCM)

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

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

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

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

7) Отслеживание дефектов показывает, что все невыполненные позиции помечены как: а) исправленные; б) не являющиеся дефектом; в) отложенные.

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

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

Answer 4

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

Answer 5

Для веб-/ внутренних приложений одна вещь в дополнение к другим предложениям.

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

Answer 6

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

Answer 7

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

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

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

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

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

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

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

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

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

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

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

Answer 8

1. нет видимых ошибок?ОК
2. работа с модульным тестированием?хорошо (некоторые проигнорированы) ха, ну хорошо
3. настрой, ты уверен.ОК
4. протоколирование ошибок ?сбился с курса !:-) нам это нужно !чтобы исправить ошибки!
5. все включено cruisecontrol.net мило.