Обеспечение чистой, синхронной и последовательной работы тестовых и производственных серверов

Кажется, что компания, над которой я работаю, всегда борется с серверами наших клиентов.

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

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

Ive попытался найти в Интернете, но не мог найти никаких хороших ответов о том, что делать. Ive также попытался выяснить некоторые решения самостоятельно, но большинство моих идей, похоже, что-то проблематично. Новые процедуры, независимо от того, насколько строго, можно обойти. Регулярное клонирование производственных серверов для создания серверов тестирования - утомительный и часто очень медленный процесс. Автоматическая репликация не всегда надежна или даже возможна. Так что же нам делать с этой проблемой на Земле? Как мы можем гарантировать, что опыт, когда тестирование будет соответствовать опыту, когда вы живете?

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

С уважением,

Линус, разработчик шведских систем

Ответ 1

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

Для кода это означает системы управления версиями, такие как CVS, Subversion или GIT.

Для базы данных это означает инструмент сравнения структур или развертывание сценариев, которые обновляют производственную базу данных.

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

Пока у вас не будет процесса, который будет работать, у вас будут проблемы.

Ответ 2

Вы должны убедиться, что любые изменения в средах выполняются согласованным образом.

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

В идеале все требования должны быть проверены в вашей системе контроля версий (в соответствии с тем, как Rails позволяет хранить драгоценные камни в каталоге /vendor и предпочтительно загружать их во время выполнения) вместе с файлом readme, который точно описывает, как установить (требуемые библиотеки и т.д.). Файл readme должен быть строго обновлен любым, кто вносит изменения в среду.

Ответ 3

Ваши проблемы вполне нормальные. Есть, по крайней мере, две известные мне стратегии:

Если вы распространяете Linux, вы можете создать rpms/debs из своего процесса разработки и использовать функцию управления пакетами. Я знаю, что многие проекты делают это с большим успехом для внутренних проектов.

Другой альтернативой является упаковка всей среды как своего рода оболочка script. Эта оболочка script может/должна настраивать полную среду со всеми настройками. Обычно этот script поддерживается девелопментом, и этот script перезаписывает любые изменения, которые были сделаны вручную. A script, как это, обычно поддерживается разработкой, хранится под контролем версий и отправляется в развертывание в виде полного дистрибутива. Для этого мы используем cygwin. Обычно script считывает некоторую конфигурацию, которая может управляться операциями. У меня были сценарии, которые фактически настраивали всю систему с нуля, как если бы они устанавливались на совершенно пустой, только что установленный компьютер.

Обе эти стратегии должны предпочтительно включать автоматическое производство этих артефактов полностью из вашей системы сборки script/build. Чем более гладким будет этот процесс, тем лучше для всех вовлеченных сторон.

Ответ 4

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

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

Ответ 5

Для хранения баз данных MySQL в синхронизации я просто столкнулся с этим инструментом:

http://schemasync.org/

Я еще не использовал его, поэтому я не могу говорить о том, хорошо ли это, но нам нужно каким-то образом контролировать дрейф схемы между тестом и prod, поэтому мы собираемся дать ему шанс.