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

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

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

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

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

7
production-environment test-environments

4 ответов

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

7

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

1) Local: в основном ваша машина. Вот где вы кодируете и тестируете свои изменения, прежде чем даже просить коллегу для обзора.

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

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

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

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

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

5

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

4

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

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

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

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

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

надеюсь, что это помогает

2