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

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

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

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

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

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

Искренне,

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


synchronization production-environment consistency test-environments
person Community    schedule 12.03.2009    source источник
comment
Линус, это относится конкретно к доставке кода в среды ваших клиентов, верно? Насколько реально вы можете контролировать эти среды.   -  person Jeff Atwood    schedule 13.03.2009
comment
Кроме того, не могли бы вы перечислить, какие среды вы поддерживаете для своих клиентов? Окна? линукс? Мак? Какие требования у вас сейчас?   -  person Jeff Atwood    schedule 13.03.2009

Ответы (5)


arrow_upward
6
arrow_downward

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

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

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

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

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

person jonstjohn    schedule 12.03.2009
comment
для управления конфигурацией, если вы чувствуете себя действительно амбициозным, вы можете посмотреть cfengine или puppet, чтобы определить конфигурацию вашей системы (установленные пакеты, содержимое файла конфигурации и т. д.) с помощью декларативного языка. - person Peter Cordes; 09.12.2009

arrow_upward
0
arrow_downward

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

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

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

person Jarin Udom    schedule 12.03.2009

arrow_upward
0
arrow_downward

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

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

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

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

person krosenvold    schedule 12.03.2009

arrow_upward
0
arrow_downward

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

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

person Joel Coehoorn    schedule 13.03.2009

arrow_upward
0
arrow_downward

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

http://schemasync.org/

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

person Community    schedule 01.06.2011