Лучшие практики для тестовых и производственных сред
В компании, в которой я работаю, у нас есть 2 среды: тестовая и производственная. В настоящее время мы не запускаем новую среду из-за стоимости.
Вот процедура, которой мы следуем: бизнес делает запрос функции, разработка делает это и разворачивается в тестовой среде. Затем бизнес тестирует его (UAT), и, если все в порядке, функция будет включена в следующее производственное развертывание.
Проблема раскрывается на тестовой БД. Разработчики рассматривают тестовую среду как свою площадку, а иногда они переводят БД в исходное состояние для целей тестирования. С другой стороны, деловые люди считают, что тестовая БД должна быть стабильной и не должна быть сброшена. Мы хотели бы решить эту проблему и решить, должна ли тестовая среда принадлежать группе разработчиков или бизнес-группе. (Разработчики не хотят, чтобы бизнес заглядывал в тестовую среду, но бизнес-команда платит за серверы.)
Какова лучшая практика об окружающей среде? Можете ли вы порекомендовать статью об этом?
5 ответов
У нас также есть две базы данных: тестовая и производственная. Тестовая база данных в основном используется для тестирования разработчиками, но иногда и для бизнес-тестов. Эта база данных обновляется ежедневно с использованием фактической копии производственной базы данных. Таким образом, эта база данных может быть как игровой площадкой, так и серьезной базой для тестирования. Но в-третьих, разработка базы данных - лучший вариант. У нас был один, но он сломан в данный момент. Но когда вы получаете один из них, вы должны убедиться, что он обновляется достаточно часто. Когда разработчики используют его в качестве игровой площадки, он будет отклоняться от производственной среды, а его данные будут как устаревшими, так и прерывистыми. Из-за этого разработчики не смогут хорошо себя протестировать. Поэтому убедитесь, что вы периодически обновляете эту базу данных (возможно, ежедневно или хотя бы раз в неделю).
Я работал во многих компаниях, каждая из которых имела свой набор сред, в котором у меня больше всего было 5 сред:
1) Локальный: в основном ваша машина. Здесь вы кодируете и тестируете свои изменения, прежде чем даже попросить сверстника о пересмотре.
2) Dev: Если по какой-то причине вы не можете протестировать свой код локально (в основном это касается зависимостей: "Мой код имеет neves, скомпилированные на моей машине, но он прекрасно компилируется в Jenkins/Bamboo/Travis"), тогда вы вносите свои изменения в ветку функций. в Git и заставьте Bamboo скомпилировать его и развернуть на dev-сервере, где вы можете протестировать (вы все еще не уверены, сработает ли он, поэтому пока нет рецензирования).
3) Постановка: вы думаете, что ваш код работает, и вам нравится, как он выглядит. Вы создаете Pull Request для того, чтобы ваши коллеги могли взглянуть на него, прежде чем он будет объединен с главной веткой. Здесь они комментируют, и вы исправляете возможные проблемы, так как вы более уверены в своих изменениях, вы заставляете Bamboo развертывать его в промежуточной среде, где живет более "стабильный" код и более реалистичные данные хранятся в любой базе данных. После развертывания другой разработчик / тестировщик может проверить, действительно ли ваши изменения работают, и сделать вас "QA Sign off in Staging Env".
4) Стабильно: Хорошо, теперь вы абсолютно уверены, что ваши изменения работают, так как вы развернули в Staging и ничего не сломалось. Вы объединяете свою ветку с master, а Bamboo скомпилирует master и развертывает на других наборах серверов в стабильной среде (никто не должен сливаться с master до тех пор, пока вы не завершите развертывание в Production, чтобы избежать слияния не связанных слияний). Эта среда должна быть копией из Production, data, code и условия сервера. Здесь вы показываете свои изменения своему менеджеру, владельцу продукта или ответственному лицу, чтобы проверить вашу работу перед отправкой в производство. Вы получаете окончательное одобрение, все хорошо, вы потные, вы работали 30 дней подряд, чтобы сделать это изменение, ваша жена развелась с вами, но вы очень уверены, что это работает отлично.
5) Производство: где клиенты подключаются для использования услуг компании или окончательной сборки вашего программного обеспечения для отправки клиентам. С помощью нескольких щелчков в Bamboo вы можете развернуть его на производственных серверах или скомпилировать окончательную сборку. Это зеленый, все вроде бы нормально. Вы проверяете Splunk на наличие ошибок, все хорошо, жизнь хороша, вы выпиваете еще один глоток кофе перед отъездом, едете домой и всю ночь спите с собакой на вашей стороне.
Это счастливый конец, потому что так много "тестовых" сред гарантируют качество, и никакие изменения не произойдут до тех пор, пока ВСЕ (не только вы) не будут полностью уверены, что изменения работают.
Если возможно, предоставьте каждому разработчику свою собственную базу данных на своем локальном компьютере. Таким образом, она может делать с ней все, что захочет, не затрагивая никого другого. Это должно значительно уменьшить ее желание играть с тестовой базой данных, обеспечивая более стабильную среду для бизнес-UAT.
Я считаю, что для того, чтобы создать стратегию среды, которая поддерживает все требования ALM/SDLC, должны существовать 4 требования:
1) Среда разработки: позволить Dev поиграть с новым кодом / концепциями и, как правило, с модульным тестированием с некоторыми базовыми интеграционными тестами с использованием заглушек и драйверов. Эта среда должна иметь процедуры контроля изменений и, как правило, не соответствовать масштабу производства. Именно здесь команда разработчиков может создавать и разбирать настройки по мере необходимости.
2) Среда взаимодействия: где можно дополнительно протестировать интеграцию систем и расширить возможности для нефункционального тестирования, т. Е. Может быть устойчивой средой с большей масштабируемостью, чем Dev. Я бы увидел, что эта среда имеет более жесткий контроль и управление изменениями. Test будет выполнять интеграцию и тестирование системы в этой среде.
3) Эталонная архитектура: это то, что некоторые могут назвать pre-prod, но по сути то же самое, что и производство с точки зрения масштаба и устойчивости. Это будет иметь процедуры контроля и управления изменениями, сродни Prod. Эта среда будет поддерживать дальнейшие действия по тестированию, особенно полномасштабное тестирование производительности, аварийное переключение, а также операции по устранению неисправностей и обслуживанию, когда продукт будет запущен для клиентов.
4) Производство: эта среда будет поддерживать живых клиентов, поэтому тестирование будет ограничено, если это так. Это будет полностью управляемым и иметь строгие процессы управления изменениями и управления конфигурациями.
Надеюсь это поможет
Вы можете дать каждому разработчику последний образ докера базы данных, с которым они могут играть в своей локальной среде. Если данные повреждены, они могут просто воссоздать контейнер.