Поддержание чистоты, синхронизации и согласованности сред тестирования и рабочих серверов

Question

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

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

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

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

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

С уважением,

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

Answer 1

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

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

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

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

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

Answer 2

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

http://schemasync.org/

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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