Доработка сложного проекта, интернет-магазина, веб-сервиса, CRM системы — это всё равно, что чинить автомобиль который мчится на полном ходу. Чуть перетянул гайку — и получил грандиозную аварию. Поэтому разработка таких проектов обычно ведётся на отдельной копии сайта — его dev-версии, и только после тестирования доработки переносятся на «боевой» сайт.
Вторая технология правильной разработки — git-репозиторий. Он позволяет за 2-3 минуты переносить изменения с dev-версии сайта на продакшн, а при необходимости быстро откатывать изменения назад, ибо git хранит в себе всю историю изменений кода сайта.
Кажется, что такой подход решает все проблемы в разработке? Но вам, как владельцу проекта, нужно будет разобраться с новыми нюансами.
Чем грозит правильная технология разработки?
Придется иметь на сервере в 2 раза больше места
Ведь больших сайтов теперь будет два, а не один. И если на боевом хранится 25 гигов картинок — то придётся решать, переносить ли все это «добро» на dev-сервер или мириться с тем, что большинство картинок на dev будет отсутствовать.
Часто прямое увеличение дискового пространства на сервере невозможно и придется перевозить проект на другой сервер. И да, вы очень предусмотрительны, если сразу взяли сервер с хорошим запасом свободного места на диске.
Некоторые доработки перестанут работать на продакшне
Хотя до этого хорошо работали на dev-сервере, но после переноса на продакшн работать откажутся. Почему? Просто на работу сайта влияет не только код, но и база данных. На продакшне база уже «убежала» далеко вперед, а на dev лежит её старая версия.
Выход — заводить третью промежуточную копию сайта, stage, на котором перед выкладкой на «боевой» сайт объединять код с dev-версии и базу с продакшна. И да, места на сервере нужно будет ещё больше.
Разработчики могут затереть ваши изменения
Если вы их делали самостоятельно в файлах сайта: немного поправили код шаблона, сами добавили пиксель ретаргета или файл для верификации Яндекс.Вебмастера. Эти изменения не проводились через git-репозиторий, и если разработчик обновляет сайт не вникая в конфликты в коде, то все ваши правки потеряются без возможности восстановления.
Выход — правильная технология «накатки» изменений, когда разработчик анализирует каждый конфликт в файлах и принимает решение какую из версий файла оставить. Можно обойтись без внесения правок в файлы с вашей стороны и использовать тег-менеджер от Гугла чтобы вносить небольшие изменения во внешний вид сайта.
Если над проектом работает отдельная команда SEO-специалистов, то они должны уметь работать с git-репозиторием, либо ограничиться постановкой задач для ваших разработчиков.
Dev-сервер, открытый для поисковиков
Нужно проследить за тем, чтобы dev-сервер был закрыт от индексации, иначе вы рискуете тем, что dev-сайт будет проиндексирован со вытекающими неприятными последствиями.
Решение — использовать гитигнор. Это список файлов, которые не будут обновляться через гит. Проследите, чтобы разработчики добавили туда robots.txt и для dev-сайта запретили его индексирование. И закройте dev-сайт логином и паролем — это гарантия того, что на копию сайта не зайдут поисковые роботы и не имеющие отношения к проекту люди.
Сложно перенести отдельную доработку на продакшн
Если ваши разработчики делают несколько задач на dev-сервере, а вам срочно понадобилось перенести одну из них на «боевой» сервер (допустим, на dev она уже сделана) — это будет проблемой. Не то, чтобы это было совсем невозможно, но заметно увеличит время, которое программисты потратят на текущие задачи. А ещё никто не сможет гарантировать что перенос отдельной задачи не вызовет непредсказуемых багов на сайте.
Выводы
В любом случае использование dev-сервера и git-репозитория дают плюсов сложному проекту гораздо больше, чем создают проблем. Тем более что при грамотной работе все проблемы удается решить, а вы теперь знаете на что нужно обращать внимание разработчика.
Доработка и исправление ошибок на небольшом сайте обычно происходит сразу на «боевом» сайте, ибо доработки быстрые и практически не могут сломать какой-то другой функционал.