вопрос по управлению экземпляром приложения - PullRequest
Новая
       21

вопрос по управлению экземпляром приложения

6 голосов
/ 23 февраля 2010

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

  1. Непрерывная интеграция: монитор проверяет, был ли обновлен репозиторий кода, если это так, он выполняет сборку и запускает наш пакет модульных тестов. При возникновении ошибок команда получает уведомления по электронной почте
  2. Ежедневная сборка: разработчики используют эту сборку для проверки своих исправлений ошибок или нового кода на реальном сервере приложений, и, если «вещи» успешны, разработчик может решить задачу.
  3. Еженедельная сборка: тестеры проверяют очередь разрешенных проблем в этой сборке. Это более стабильная среда тестирования.
  4. Текущая версия сборки: используется для демонстрации и открытой платформы тестирования для потенциальных новых пользователей.

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

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

Ответы [ 3 ]

1 голос
/ 23 февраля 2010

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

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

1 голос
/ 23 февраля 2010

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

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

С уважением,
Стейн

0 голосов
/ 23 февраля 2010

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

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

...