На заре становления нашей компании Git был чем-то непонятным и ненужным.

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

Сейчас, попадая на проект без Git, мы испытываем недоумение: как компания жила и развивала свой проект без системы контроля версий? Например, совсем недавно к нам обратился клиент с запросом на доработку e-commerce проекта. Начав разбираться, мы увидели, что изначально это был шаблонное решение, но со временем в него добавили массу кастомных решений – местами удачных, местами не очень.

Первый тревожный звоночек. Ситуация стандартная: прошлый подрядчик ушел, разобраться в коде непросто. Запросили доступы – получили админку и FTP. Зашли и ужаснулись: Git отсутствует, документации по изменениям нет, кастомных решений – огромная количество.

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

Базовый набор инструментов для работы над проектами

1. Git – это база 
Без Git сегодня никуда. Это не только система контроля версий, но и страховка от случайных ошибок и удобный инструмент командной работы. Мы используем локальный GitLab, но если у клиента уже есть свой репозиторий, работаем с ним.

2. Тестовые окружения
В идеале тестовая среда должна разворачиваться под каждую отдельную задачу, но это дорого. Поэтому стандартный минимум – три окружения:
– Прод – боевой сервер,
– Пре-прод – среда, максимально приближенная к продакшену,
– Песочница – для тестирования изменений.

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

3. CI/CD – автоматизация развертывания 
На некоторых проектах без CI/CD просто невозможно работать. Хотя не всегда он нужен в минимальном наборе, на серьезных проектах это must-have. Мы используем GitLab CI/CD для автоматизации развертывания и тестирования.

4. Документация – экономия времени в будущем
Честно говоря, мы сами не всегда вели документацию, но это неизменно приводило к проблемам. Поэтому сейчас придерживаемся правила:
– Завершил задачу – добавь описание в таск-трекер.
– Внес значительное изменение – задокументируй в базе знаний.

Для этого используем комбинацию Яндекс.Трекера и его встроенной вики. Главное – неважно, какой инструмент вы используете (хоть Google Docs), важно, чтобы документация была.

5. Резервное копирование 
Перед любыми изменениями на боевом сервере надо убедиться, что бэкапы: существуют, целостны, разворачиваются без проблем.

Кроме того, важно проверять, что резервные копии регулярно создаются и актуализируются. Идеальный вариант – хранить их на отдельном сервере, а не надеяться, что копия внутри боевого сервера спасет в случае ЧП.

6. Мониторинг – чтобы не ловить проблемы постфактум 
Даже качественный код не спасает от внешних факторов: сервер может упасть, провайдер может отключить услугу, модули могут сломаться. Чтобы не узнать о проблеме от разъяренного клиента, мы используем три инструмента:

Uptime – отслеживание доступности проекта и сбор статистики.
Zabbix – мониторинг состояния сервера (нагрузка, память, дисковое пространство).
Sentry – слежение за ошибками на фронтенде и бэкенде. Да, он потребляет 15 ГБ ОЗУ, но зато все ошибки наглядно и с алертами.

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

А какие инструменты используете вы?