Как принимать код от аутсорс-команды: чек-лист приемки

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

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

Правило №1: Гайд развертывания (README)

Это священный документ. Без него проект — «черный ящик».

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

Что должно быть обязательно:

  • Системные требования: версия ОС, Node.js/Python/PHP, Docker, базы данных.

  • Пошаговая инструкция: от клонирования репозитория до работающего приложения на localhost.

  • Примеры конфигурации: файл .env.example со всеми переменными окружения и комментариями, зачем каждая нужна.

  • Скрипты запуска: для дев-среды, для продакшена, для тестов.

  • Работа с данными: как накатить миграции, как заполнить тестовыми данными, как сделать бэкап.

  • Устранение типичных проблем: что делать, если порт занят, если контейнер не поднимается, если не подключается база.

Тест на приемке: вы или ваш разработчик берут чистый ноутбук, клонируют репозиторий и следуют инструкции. Если приложение не завелось с первого раза — гайд не принят.

Правило №2: Репозиторий и Git-гигиена

Код должен лежать в репозитории, переданном вам, а не на диске у аутсорсера.

  • Ветки: мастер/мейн — только стабильный код. Дев — для разработки. Фича-ветки — для конкретных задач.

  • Коммиты: должны быть осмысленными, с человеческими сообщениями, а не «fix», «fix2», «final_fix».

  • Теги: каждая переданная версия должна быть отмечена тегом (v1.0.0, v1.0.1).

  • История: полная, с момента начала проекта. Никаких склеенных или вычищенных коммитов.

Что еще проверить:

  • .gitignore — туда должно попадать всё, что не должно быть в репозитории (логи, конфиги с паролями, зависимости).

  • Нет закоммиченных паролей, ключей, токенов. Если есть — считать скомпрометированными.

  • Размер репозитория — не больше разумного (например, бинарники должны храниться отдельно).

Правило №3: Документация по коду и архитектуре

Код должен быть читаемым, но комментарии не заменят документацию.

Минимальный набор:

  • Архитектурная схема — какие сервисы/модули есть, как они общаются, какие внешние API используются.

  • Схема базы данных — ER-диаграмма или хотя бы описание таблиц и связей.

  • API документация — для бэкенда: эндпоинты, методы, параметры, ответы, коды ошибок. Лучше всего — спецификация OpenAPI (Swagger) в формате YAML/JSON.

  • Описание очередей, воркеров, cron-задач — если есть фоновые процессы, должно быть понятно, что и когда запускается.

  • Логирование и мониторинг — куда пишутся логи, как их смотреть.

Правило №4: Зависимости и сторонний код

В современной разработке проект на 90% состоит из чужих библиотек.

  • Полный список зависимостей: package.json, composer.json, requirements.txt, go.mod — должны быть актуальны.

  • Лицензии: никакой GPL-кода в коммерческом закрытом проекте, если вы не готовы открыть свой код.

  • Фиксация версий: никаких «последней версии на момент сборки». Все зависимости должны быть зафиксированы с конкретными номерами версий.

  • Собственный код: вся бизнес-логика — только в ваших репозиториях. Никакого «кода, который лежит на диске у Васи и нигде больше».

Правило №5: Автотесты и их проходимость

Проект без тестов — это не проект, это лотерея.

  • Юнит-тесты: покрытие критических модулей. Не 100%, но ключевые сценарии должны быть проверены.

  • Интеграционные тесты: проверка связи между модулями.

  • Тесты API: эндпоинты работают так, как заявлено.

  • Тестовая среда: аутсорсер должен предоставить доступ к среде, где все тесты проходят.

  • Доля прохождения: 100% тестов должны быть зелеными.

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

Правило №6: Миграции баз данных

Ошибка здесь стоит дорого — потеря данных или несовместимость версий.

  • Все изменения схемы БД должны быть в виде миграций (файлов, которые можно накатить и откатить).

  • Миграции должны быть идемпотентными (можно запустить несколько раз — не сломается).

  • Есть четкая инструкция: как накатить на пустую БД, как обновить существующую, как откатить при ошибке.

  • Данные для начальной загрузки (справочники, роли) — в виде seed-файлов.

Правило №7: CI/CD пайплайн

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

Принимая проект, вы должны получить:

  • Конфигурацию для CI/CD (GitHub Actions, GitLab CI, Jenkinsfile и т.д.).

  • Описание окружений: dev, staging, production.

  • Автоматическую проверку (linting, тесты, сборка) при пуше в репозиторий.

  • Процесс деплоя: что запускается, как обновляется, есть ли downtime.

Если CI/CD нет — вы получите проект, который разворачивается копипастой команд с листочка. Это боль.

Правило №8: Доступы и учетные записи

Всё, что нужно для работы проекта, должно быть передано по акту.

  • Доступы к репозиторию и документации.

  • Аккаунты в облачных сервисах (AWS, Google Cloud, DigitalOcean), базах данных, CDN, платных API.

  • Аккаунты администратора приложения (с возможностью сбросить пароль).

  • Доступ к системе мониторинга и логов.

  • Доступ к домену и DNS-настройкам.

Золотое правило: через сутки после приемки доступы аутсорсера должны быть отозваны. Если они могут зайти — проект не принят.

Правило №9: Бэкапы и восстановление

Проверьте, сможете ли вы откатиться.

  • Есть ли автоматические бэкапы базы данных и файлов?

  • Как часто они делаются?

  • Где хранятся? (не на том же сервере, что и сам проект)

  • Как восстановиться из бэкапа за 15 минут? Инструкция должна быть.

  • Проведите учебную тревогу: попросите аутсорсера удалить одну таблицу и восстановить её из бэкапа на тестовой среде.

Правило №10: Последняя миля — живой демо-прогон

Самый важный пункт.

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

Что проверять:

  • Ключевой бизнес-сценарий (регистрация → оплата → получение услуги).

  • Обработка ошибок (что будет, если отключить интернет, ввести неверные данные, оплатить картой с недостатком средств).

  • Производительность (не тормозит ли под нагрузкой?).

Если на этом этапе всплывают баги — они исправляются до подписания акта.

Резюме: чек-лист одной строкой

№ Правило Кратко
1 Гайд развертывания берем чистый комп → запускаем → работает
2 Git осмысленные коммиты, теги, нет секретов
3 Документация схема БД, API, архитектура, cron
4 Зависимости список, лицензии, фиксированные версии
5 Автотесты 100% проходят, запускаются локально
6 Миграции БД идемпотентные, накат и откат
7 CI/CD автоматическая проверка и деплой
8 Доступы всё передано, доступы аутсорсера отозваны
9 Бэкапы есть, проверены, инструкция по восстановлению
10 Живой демо-прогон вы сами проверяете, что всё работает

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