Лучшие практики для тестовых и производственных сред

Question

В компании, в которой я работаю, у нас есть 2 среды: тестирование и производство. В настоящее время мы не запускаем новую среду из-за стоимости.

Вот процедура, которой мы следуем: бизнес делает запрос функции, разработка делает это и разворачивается в тестовой среде. Затем бизнес тестирует его (UAT), и, если все в порядке, эта функция будет включена в следующее производственное развертывание.

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

Какова наилучшая практика в отношении окружающей среды? Можете ли вы порекомендовать статью об этом?

Answer 1

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

Answer 2

Я работал во многих компаниях, каждая из которых имела свой набор сред, в котором у меня больше всего было 5 сред:

1) Локальный: в основном ваша машина.Здесь вы кодируете и тестируете свои изменения, прежде чем даже попросить сверстника о проверке.

2) Dev: Если по какой-то причине вы не можете протестировать свой код локально (в основном это связано с зависимостями): «Мой код содержит neves, скомпилированные в моемна компьютере, но он прекрасно компилируется в Jenkins / Bamboo / Travis "), затем вы помещаете свои изменения в свою функциональную ветку в Git и заставляете Bamboo скомпилировать ее и развернуть на сервере разработки, где вы можете протестировать (вы все еще не уверены, будет ли эторабота, так что пока нет рецензии).

3) Постановка: Вы думаете, что ваш код работает, и вам нравится, как он выглядит.Вы создаете Pull Request для того, чтобы ваши коллеги могли взглянуть на него, прежде чем он будет объединен с главной веткой.Здесь они комментируют, и вы исправляете возможные проблемы, так как вы более уверены в своих изменениях, вы заставляете Bamboo развертывать его в промежуточной среде, где живет более «стабильный» код и более реалистичные данные хранятся в любой базе данных.После развертывания другой разработчик / тестировщик может проверить ваши изменения на самом деле и сделать вас «QA Sign off in Staging Env.»

4) Стабильно: Хорошо, теперь вы в полной мере уверены, что ваши изменения работают, так как вы внедрили в Stagingи ничего не сломалось.Вы объединяете свою ветвь с master, а Bamboo скомпилирует master и развертывает на других наборах серверов в стабильной среде (никто не должен сливаться с master до тех пор, пока вы не завершите развертывание в Production, чтобы избежать слияния не связанных слияний).Эта среда должна быть копией из Production, data, code и условия сервера.Здесь вы показываете свои изменения своему менеджеру, владельцу продукта или ответственному лицу, чтобы проверить вашу работу перед отправкой в ​​производство.Вы получаете окончательное одобрение, все хорошо, вы потные, вы работали 30 дней подряд, чтобы сделать это изменение, ваша жена развелась с вами, но вы очень уверены, что это работает отлично.

5)Производство: где клиенты подключаются для использования услуг компании или для окончательной сборки вашего программного обеспечения для отправки клиентам.С помощью нескольких щелчков в Bamboo вы можете развернуть его на производственных серверах или скомпилировать окончательную сборку.Это зеленый, все вроде бы нормально.Вы проверяете Splunk на наличие ошибок, все хорошо, жизнь хороша, вы выпиваете еще один глоток кофе перед отъездом, вы едете домой и всю ночь спите со своей собакой рядом с вами.

Это счастливый конец, потому что иметьтак много «тестовых» сред гарантируют качество, и никакие изменения не произойдут до тех пор, пока ВСЕ (не только вы) полностью не уверены, что изменения работают.

Answer 3

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

Answer 4

Я считаю, что для создания стратегии среды, которая поддерживает все требования ALM / SDLC, должны существовать 4 требования:

1) Среда разработки: чтобы Dev мог поиграть с новым кодом / концепциями и, как правило, проводить модульное тестирование с некоторыми базовыми интеграционными тестами с использованием заглушек и драйверов. Эта среда должна иметь процедуры контроля за изменениями и, как правило, не соответствовать масштабу производства. Именно здесь команда разработчиков может создавать и разбирать установки по мере необходимости.

2) Среда взаимодействия: где дальнейшее тестирование интеграции систем и расширение возможностей для нефункционального тестирования. Т.е. может быть устойчивой средой с большей масштабируемостью, чем Dev. Я бы увидел эту среду с более жестким контролем и управлением изменениями. Test будет выполнять интеграцию и тестирование системы в этой среде.

3) Эталонная архитектура: это то, что некоторые могут назвать pre-prod, но по сути то же самое, что и производство с точки зрения масштаба и устойчивости. Это будет иметь процедуры контроля и управления изменениями, сродни Prod. Эта среда будет поддерживать дальнейшие действия по тестированию, особенно полномасштабное тестирование производительности, аварийное переключение, а также операции по устранению неисправностей и обслуживанию после запуска продукта для клиентов.

4) Производство: эта среда будет поддерживать живых клиентов, поэтому тестирование будет ограничено, если это так. Он будет полностью управляемым и будет иметь строгие процессы управления изменениями и управления конфигурациями.

Надеюсь, это поможет