вопрос об управлении экземпляром приложения
Я в настоящее время работаю над довольно крупным проектом с командой, распределенной по Соединенным Штатам. Разработчики обычный код фиксации в исходный репозиторий. У нас есть следующие сборки приложения (всеми управляют приложение, никакие ручные процессы):
- Непрерывная Интеграция: проверки старшим оператором, чтобы видеть, был ли репозиторий кода обновлен, раз так он делает сборку и выполняет наш комплект модульного теста. На ошибках команды получают уведомления по электронной почте
- Ежедневная Сборка: Разработчики используют эту сборку для проверки их исправлений ошибок или нового кода сервера реального приложения, и если "вещи" успешно выполняются, разработчик может разрешить задачу.
- Еженедельная Сборка: Тестеры проверяют разрешенную очередь проблемы на этой сборке. Это - более стабильная тестовая среда.
- Текущая Сборка конечных версий: используемый для демонстрации и открытой платформы тестирования для потенциально новых пользователей.
Каждая сборка обновляет базу данных, связанную с ним. Это чистит данные и проверяет любые изменения баз данных, которые соглашаются с новым кодом, втянуты. Одно беспокойство я получаю известие от наших тестеров, - то, что мы должны предварительно заполнить еженедельную базу данных сборки с некоторыми, ожидал тестировать данные, в противоположность большему количеству универсальных данных тот, разработчики работают с. Это кажется, что для обоснованного опасения / нужно, и что-то, что мы продолжаем работать.
Я бросаю то, что мы убираем, чтобы видеть, видит ли, ТАКИМ ОБРАЗОМ сообщество какой-либо разрыв с тем, что мы делаем или имеем любые проблемы. Вещи, кажется, работают хорошо, но Такое чувство, что это могло быть лучше. Ваши мысли?
3 ответа
Следующим дополнительным шагом является то, что как только сборка релиза проходит тесты (скажем, дымовой тест), она квалифицируется как хорошая сборка (например, золотая сборка), и вы используете какой-то механизм маркировки для маркировки всех артефактов ( код, сценарии установки, файлы makefiles, installable и т. д.), вошедшие в создание золотого образа. Золотая сборка может стать релиз-кандидатом позже или нет.
Вероятно, вы уже делаете это, поскольку вы не упомянули, что я добавил то, что наблюдал.
примерно так мы и делаем. БД самих тестеров сбрасываются только по запросу. Если мы будем обновлять это автоматически каждую неделю, то
- мы потеряем ссылки на симптомы ошибки; если ошибка обнаружена, но разработчик рассматривает ее только несколько недель спустя (или просто после выходных), тогда все признаки этой ошибки могли исчезнуть
- , тестировщики могут оказаться в середине большого тестового примера (требующего более 1 день, например)
- у нас есть тонны модульных тестов, которые работают с БД, которая обновляется (конечно, автоматически) каждый раз, когда выполняется сборка интеграции
касаемо,
Stijn
Я думаю, у вас есть хороший, всеобъемлющий процесс, если он соответствует тому, когда ваши клиенты хотят видеть обновления.Один возможный пробел, который я вижу, заключается в том, что похоже, что вы не сможете внедрить критическое исправление ошибки клиента в производство менее чем за неделю, поскольку ваши тестовые сборки выполняются еженедельно, и вам понадобится время, чтобы тестировщики проверили исправление.
Если вы хотите думать о вещах по-другому, взгляните на эту статью о непрерывном развертывании - поначалу может быть немного сложно принять эту концепцию, но она определенно имеет некоторый потенциал.