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

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

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

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

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

6
application-server build-process java testing

3 ответов

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

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

1

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

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

с уважением,
Stijn

1

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

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

0