К чему стоит быть готовыми, если приносите проект на поддержку/развитие

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

Сначала мы просим от вас всю информацию по сайту, над которым будем корпеть. Основные пункты, которые нам нужны: 

1. Доступы в админку проекта: логин и пароль.

2. Доступы к серверу с работающим проектом: SSH/SFTP. Если таковых не имеется, тогда доступ в панель хостинга, чтобы мы самостоятельно для себя создали доступы к серверу или сменили имеющиеся.

3. Настройки для VPN, если необходимо, или добавить наш офисный IP в список разрешенных для доступа к серверу: 85.30.248.226

4. Вся/любая документация, которую составляли для проекта: первичное ТЗ на проект, структура данных/связи/индексы, программная документация или даже просто заметки от разработчиков. Всё, чем вы располагаете. Поговорите с вашими программистами и сисадминами, они точно что-то подскажут!

5. Перечислите все интеграции, которые есть на вашем проекте и дайте к ним доступы. К интеграциям относятся: бухгалтерия, касса, товароучет, скидочные сервисы, sms-сервисы, почтовые сервисы, товарные фиды, импорт каких-то данных на сайт и прочее. Они понадобятся на случай, если потребуется перенос проекта на другой хостинг.

Готовим базу под работу

Вероятно, для этих действий придется побеспокоить вашего IT-специалиста, сидеть без дела ему не придется.

Сначала необходимо настроить тестовую среду, для этого потребуются следующие шаги:

1. Подготовить набор тестовых доменов  — preprod, dev1, dev2, dev3. Все необходимые копии проекта мы развернем самостоятельно.
   

2. Подготовить тестовую базу данных MySQL, с которой будут работать тестовые домены.
   

3. Настроить можно на сервере рядом с работающим проектом. Сообщите, если это неудобно по каким-то причинам.

Если у вас нет своего ITшника или по каким-то причинам ничего настроить не вышло, то всем может заняться наш специалист.

Далее мы настраиваем ежедневный бэкап (базы данных, файлов). Если разрешено, то копируем в собственное удалённое хранилище или в предоставленное вами. Сообщите, если это недопустимо или невозможно по каким-то причинам. Может быть, у вас уже есть работающий механизм бэкапирования, тогда расскажите нам о нем.

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

Если Git есть, то проверим состояние и примем решение: оставить и продолжить или поступить как-то иначе. К внешнему Git необходимо предоставить доступ.

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

Как действуем, если в проекте «пока» работает предыдущий подрядчик

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

Далее процесс идет так:

1. Совместная работа строго через Git/Задачи делаются в отдельных «ветках».
2. С «уходящим подрядчиком» договариваемся, кто во время переходного периода выпускает релизы.

На самом деле, в бОльшем количестве случаев проще подождать, пока прошлая команда закончит работу, а потом приступим и мы.