Алдан-3> Я максималист, мне подавай не просто отсутствие расхождений, а максимально приближённую копию.
По хорошему, девелоперская система должна по конфигурации максимально отличаться от рабочей. Другие пути, другие имена БД, даже другие кодировки, если у тебя боевая система, скажем, не в юникоде... Чтобы, если завтра потребуется переносить рабочую систему на другую машину, делать это максимально безболезненно
Вообще, у меня на любом сложном коммерческом проекте (Авиабаза - не в счёт
) - минимум три раздельных системы. Чисто девелоперская, как уже описано выше, максимально отличная от боевой, тестовая, расположенная на хостинге боевой и имеющая все общие настройки, для окончательного тестирования, и, собственно, боевая. Процесс работы выглядит так:
1. Пишем и отлаживаем новый компонент на девелоперской системе.
2. Пушим его на тестовую. Если что-то не работает (или, например, частая ошибка - забыли добавить файл в репозиторий) - фиксим. Доводим до ума в условиях боевой системы.
3. Пушим на боевую систему.
При соблюдении всей цепочки 3-й пункт вообще не вызывает сбоев
Другое дело, что в реальной жизни случается и прямо живую систему мучить иногда (когда начальство требует НЕМЕДЛЕННО ПОЛОЖИТЬ ВОТ ЭТО БАННЕР!). Кроме того, 3-й пункт гарантирует работоспсобность только нового компонента. Не не возможный отказ каких-то старых компонентов из-за изменений в API. Полноценое юнит-тестирование отнимает на написание тестов времени много больше, чем на само написание новых компонентов. Так что тестами обычно покрыта ничтожная часть компонентов