Экспорт исходного кода из vibe-coding платформы: как собрать проект локально, настроить CI, хранить секреты и подготовить репозиторий для передачи.
Владеть проектом - это не просто «видеть код» в интерфейсе платформы. Это значит, что исходники, история изменений и настройки живут в вашем репозитории, а сборка и запуск не требуют доступа к конкретному сервису.
При экспорте исходного кода из vibe-coding платформы легко попасть в ловушку: файлы вроде бы на месте, но проект не собирается, потому что часть конфигурации осталась в настройках платформы, а секреты подставлялись автоматически.
Зависимость от платформы обычно проявляется в четырех точках: сборка, секреты, деплой и доступы. Сборка может опираться на «магические» шаги, которые были настроены один раз и забыты. Секреты (ключи, токены, пароли) могут храниться только внутри платформы. Деплой часто завязан на встроенный хостинг и домены. А доступы - на учетные записи, которые нельзя передать новому владельцу.
Перенос можно считать успешным, если выполняются два условия:
Важно заранее договориться о ролях. Автор проекта помогает восстановить контекст (что где лежит и почему так сделано). Тимлид принимает структуру репозитория и качество handoff. DevOps настраивает окружения, CI и хранение секретов. Новый владелец репозитория подтверждает, что может повторить запуск у себя и дальше развивать проект без доступа к исходной платформе.
Если вы работали в TakProsto, заранее зафиксируйте, что именно экспортируется (веб на React, бэкенд на Go, база PostgreSQL, иногда мобильное приложение на Flutter) и какие настройки раньше жили внутри проекта платформы. Тогда «владение» будет означать реальную самостоятельность, а не папку с файлами.
Экспорт - это не кнопка «скачать», а смена ответственности. До того как вы начнете экспорт исходного кода из vibe-coding платформы, разберите проект на зависимости от окружений, внешних сервисов и настроек платформы.
Сначала разложите проект по окружениям. Обычно это dev для разработки, stage для проверки перед релизом и prod для пользователей. Запишите, кто и зачем использует каждое окружение, где находится база, какие домены привязаны и что считается «успешной проверкой» перед выкладкой в прод.
Дальше проверьте доступы: есть ли у вас право на экспорт кода и сможете ли вы забрать не только текущий результат, но и контекст изменений. Если платформа поддерживает снимки и откат (в TakProsto это есть), зафиксируйте рабочее состояние: создайте снимок и запишите номер версии или дату. Это «якорь», к которому можно вернуться, если после переноса что-то пойдет не так.
Перед экспортом удобно закрыть самые частые пробелы:
Внешние зависимости часто «всплывают» только после переезда. Типичный пример: регистрация есть, а письма уходят через SMTP, который был настроен в платформе. Пока все работает, это незаметно, но после экспорта авторизация ломается. Поэтому заранее соберите список провайдеров и поймите, где лежат учетные данные.
Отдельно решите, как будет жить код: один репозиторий или несколько (frontend, backend, инфраструктура отдельно). И назначьте ответственного за перенос. Даже если перенос делает один человек, лучше, чтобы это было явно: тогда вопросы по доступам и правкам не зависнут в чате.
Экспорт - момент, когда проект перестает быть «где-то в платформе» и становится обычным репозиторием, который можно развивать в любой среде. Цель простая: забрать все части, убрать мусор и зафиксировать понятную базовую точку.
Сначала убедитесь, что экспорт полный. В TakProsto это обычно означает, что у вас на руках есть исходники фронтенда (React), бэкенда (Go), миграции и схема для PostgreSQL, а если делали мобильное приложение - еще и Flutter-проект. «Папка с инфраструктурой» полезна, но важнее другое: чтобы в экспорте были конфиги, миграции, примеры переменных окружения и все, что нужно для локального запуска.
Перед первым коммитом проверьте права на ресурсы. Часто проблемы не с кодом, а с тем, что внутри лежат шрифты, картинки, иконки, платные UI-киты или SDK с ограничениями. Убедитесь, что ассеты можно хранить в нужном типе репозитория, лицензия разрешает использование в продакшене, а ключи SDK не зашиты в код и не попали в экспорт.
Затем создайте новый репозиторий и залейте экспорт одним понятным коммитом. Один коммит лучше десятка «initial import 1/10»: его проще ревьюить и откатывать. Сообщение может быть в духе: «Initial import: frontend + backend + db migrations». Черновики и экспериментальные ветки лучше удалить сразу, иначе они станут «вечными».
Отдельно пройдитесь по артефактам сборки и временным файлам. Репозиторий должен хранить только то, что нужно для разработки и сборки. Проверьте .gitignore: обычно туда попадают node_modules, dist/build, временные файлы IDE, логи, локальные базы, .env и любые файлы с секретами. Если в экспорте уже лежат готовые сборки фронтенда или бинарники бэкенда, удалите их и оставьте только исходники.
И добавьте короткий README (без «полотна»): какие версии нужны (Node.js/Go/PostgreSQL), как поставить зависимости, как запустить фронт и бэк, где лежат миграции, где пример переменных окружения (например, .env.example). Это сильно экономит время при передаче.
После экспорта важно быстро доказать одну вещь: проект живет вне платформы и запускается на обычном ноутбуке. Если это получается с первого раза, значит экспорт исходного кода из vibe-coding платформы прошел без скрытых зависимостей.
Структура репозитория должна читаться с первого взгляда. Часто удобно держать примерно так:
frontend/ - веб-клиент на Reactbackend/ - сервер на Gomobile/ - мобильное приложение на Flutter (если оно есть)db/ или migrations/ - миграции, сиды, утилиты для базыДальше обычно всплывают версии инструментов. Зафиксируйте минимально нужные версии Go и Node (а для Flutter - канал/версию SDK) в README или в отдельном файле вроде tool-versions. Если команда использует разные менеджеры пакетов, договоритесь об одном (например, npm или pnpm) и храните lock-файл, чтобы зависимости ставились одинаково у всех.
С PostgreSQL лучше не импровизировать. Подготовьте локальный сценарий: создать базу, прогнать миграции, заполнить базовыми данными. Не опирайтесь на ручные действия в стиле «создай таблицы как-нибудь». Если приложению нужен минимум (например, роли пользователей и тестовый админ), пусть сид создает это автоматически. Иначе часть страниц будет падать, а вы потратите время на поиск причины.
Переменные окружения разделите на две группы: обязательные для старта и необязательные (интеграции). Для локального режима по возможности отключайте внешние сервисы флагом (например, отправку почты или платежи), чтобы можно было поднять проект без ключей от продакшена.
Чтобы запуск был одинаковым у всех, сведите команды к короткому набору через Makefile или скрипты. Например: make install, make db-up, make migrate, make dev, make test. При переносе из TakProsto это особенно важно: на платформе многое работает «само», а локально эту «магию» нужно заменить явными командами и понятным README.
После экспорта кода отделите «настройки» от «секретов». Настройки можно хранить в репозитории (например, порт сервера или имя сервиса). Секреты (ключи, токены, пароли) - нет. Ошибка на этом шаге чаще всего и приводит к утечкам: секреты случайно попадают в коммит, логи или историю CI.
Начните с инвентаризации. Для стека Go API + React + PostgreSQL это обычно строка подключения к базе, секрет подписи JWT, ключи OAuth, SMTP-учетка, токены сторонних сервисов, ключи для файлового хранилища. Если вы переносите проект из vibe-coding платформы (например, TakProsto), отдельно проверьте: не были ли значения «вшиты» в настройки деплоя и не лежат ли они только в интерфейсе платформы.
Дальше заведите понятный шаблон конфигурации: в репозитории храните только пример, а реальные значения - отдельно.
# .env.example
APP_ENV=local
APP_PORT=8080
DATABASE_URL=postgres://USER:PASSWORD@localhost:5432/app?sslmode=disable
JWT_SECRET=change_me
OAUTH_CLIENT_ID=change_me
OAUTH_CLIENT_SECRET=change_me
SMTP_HOST=smtp.example
SMTP_USER=change_me
SMTP_PASSWORD=change_me
Реальные секреты храните в безопасном месте, в зависимости от того, где живет проект: в переменных окружения CI, в переменных окружения на сервере, в секрет-хранилище (vault/аналог), в принятом в компании менеджере секретов. В маленьких командах иногда используют зашифрованный файл, но тогда нужен дисциплинированный процесс расшифровки и контроль доступа.
Продумайте ротацию заранее. Минимальный план: у каждого секрета есть владелец, место хранения и способ замены. Там, где возможно, поддерживайте «два ключа» (старый и новый): выкатываете поддержку, меняете секрет, затем удаляете старый. Если утечка уже случилась, действуйте быстро: отзывайте токены, меняйте пароли, пересоздавайте ключи, и отдельно проверяйте, не остались ли секреты в истории git и артефактах сборки.
И проверьте логи. Не печатайте целиком переменные окружения или строку подключения при старте сервиса «для отладки». Логируйте только безопасные части (например, хост и имя базы без пользователя и пароля) и придерживайтесь простого правила: значения с именами вроде SECRET, TOKEN, PASSWORD в лог не выводятся. На фронтенде (React) секретов быть не должно вовсе, иначе они окажутся в сборке и будут видны в браузере.
После экспорта репозитория стоит быстро поставить базовую защиту от поломок. Это особенно полезно, если вы делаете экспорт исходного кода из vibe-coding платформы и дальше команда живет в обычном Git-репозитории без подсказок платформы. Хороший CI не обязан быть сложным: он должен повторять самые частые действия разработчика и падать раньше, чем ошибка попадет в прод.
Начните с трех задач: привести код к единому виду, собрать проект и прогнать тесты. Если есть миграции базы, проверяйте их тоже, иначе самые неприятные баги всплывают уже при деплое.
Практичный минимум обычно выглядит так: на фронтенде установка зависимостей по lock-файлу, линт и сборка; на бэкенде форматирование, линт, тесты и сборка; в части базы - поднять временный PostgreSQL в CI и применить миграции на чистую базу. Плюс базовая дисциплина артефактов: фиксированные версии инструментов, обязательные lock-файлы (package-lock.json или аналог, go.sum), а кеши только там, где они не ломают повторяемость.
После этого зафиксируйте версии Node.js и Go прямо в конфиге CI и договоритесь, что обновление версий делается отдельным небольшим PR. Так вы избавитесь от истории «локально работает, в CI нет».
Секреты должны жить не в репозитории, а в настройках CI и в менеджере окружения. В репо оставьте только пример конфигурации (например, .env.example) без реальных значений. Для защиты добавьте проверку коммитов на строки, похожие на токены, и запрет на файлы крупнее разумного лимита (чтобы не утащили дамп базы или сборки).
По веткам достаточно простых правил: защищенный main только через PR, короткие feature-ветки под одну задачу, минимум ревью (хотя бы один человек) и обязательный зеленый CI. Хотфиксы тоже через PR, иначе вы быстро потеряете воспроизводимость.
После экспорта исходников важно не просто «запустить на сервере», а сделать повторяемый деплой. Это тот момент, когда экспорт исходного кода из vibe-coding платформы превращается в самостоятельный продукт: с доменом, HTTPS, базой, бэкапами и планом отката.
Зафиксируйте базовые ответы в README или в отдельном DEPLOY.md: где будет жить приложение (VPS, корпоративный сервер, облако), какой домен нужен, какие порты открываются наружу, и что должно быть доступно только внутри сети. Для типового стека React + Go + PostgreSQL обычно наружу выходит только 80/443, а API и база остаются за reverse-proxy.
Даже для небольшого проекта лучше иметь хотя бы два окружения: staging (проверка) и production (боевое). Тогда обновления не превращаются в «лотерею».
Чтобы выкладка была независимой от платформы, обычно достаточно: Dockerfile для backend и frontend, docker-compose для локального и staging, шаблон конфигурации (.env.example) и отдельные переменные для staging/prod, reverse-proxy (например, Nginx) с маршрутизацией, простого health-check эндпоинта и документации по портам и доменам.
По домену и HTTPS проверьте, что вы можете выпустить сертификат и настроить автообновление без «магии платформы». На практике это значит: DNS под вашим контролем, reverse-proxy настроен, а сертификаты хранятся и обновляются на вашем сервере.
База данных чаще ломается не из-за кода, а из-за миграций. Договоритесь о простом правиле: миграции запускаются только в одном месте (в деплой-скрипте или отдельной CI-задаче) и только после бэкапа.
Минимальный план выглядит так: перед релизом делается резервная копия БД, деплой выкатывает версию по тегу (например, v1.4.2), затем применяются миграции с логом. Если что-то пошло не так, откат идет на предыдущий тег, а БД восстанавливается из бэкапа или откатывается обратной миграцией (если вы их ведете).
Если вы привыкли к снапшотам и rollback внутри TakProsto, воспроизведите эту идею в репозитории: теги, релизы, журнал изменений, бэкапы и четкое описание «как откатиться за 10 минут».
Главная ловушка при экспорте исходного кода из vibe-coding платформы - думать, что раз проект скачался, значит он уже полностью ваш. На практике проект часто держится на мелочах: настройках окружения, фоновых задачах, миграциях и правилах релизов.
Файл .env или конфиг с паролями попадает в репозиторий, потому что так было удобно во время разработки. Потом его либо случайно коммитят, либо пересылают подрядчику вместе с кодом.
Правило простое: конфиги, которые можно публиковать, живут рядом с кодом; секреты - только в менеджере секретов, переменных окружения или в закрытом хранилище. Оставьте в репозитории пример файла (например, .env.example) без ключей и паролей.
После экспорта проект запускается на вашем ноутбуке, но ломается у другого разработчика. Обычно причина в версиях Node.js, Go, PostgreSQL, npm/pnpm, а иногда и в утилитах вокруг.
Чтобы не гадать, зафиксируйте версии в простых файлах и инструкциях и добавьте команду быстрой проверки. Если проект из TakProsto, не полагайтесь на то, что платформа всегда поднимет окружение так же, как у вас локально.
Новый владелец клонирует репозиторий, запускает сервер, а дальше тупик: таблиц нет, тестовые данные отсутствуют, непонятно, как создать первого пользователя.
Проверьте три вещи: миграции лежат в репозитории и запускаются одной командой; есть понятный минимум сидов (хотя бы админ-пользователь и справочники); описано, как поднять чистую базу и проверить, что все ожило.
Самые неприятные - «невидимые» вещи: вебхуки, планировщики, фоновые задачи, отправка писем, обработка очередей. На платформе это могло работать автоматически, а после переезда пропадает без ошибок.
Быстрый тест: выпишите все события, которые происходят без участия пользователя (ежедневные отчеты, синхронизация, напоминания, обработка платежей). Для каждого события должно быть ясно, кто его запускает теперь: cron на сервере, отдельный воркер, внешний сервис или встроенный планировщик в вашем деплое.
После ухода с платформы часто теряются привычные «снимки» и быстрый rollback. И начинается опасная практика: правки сразу в main, без тегов, релизов и истории изменений.
Сделайте минимальную дисциплину релизов: теги версий, короткие заметки к релизу и правило, что в main попадает только то, что прошло сборку и проверки. Тогда откат - это возврат на предыдущий тег, а не паника.
Если проект уходит из vibe-coding платформы (например, после экспорта из TakProsto) к другой команде или в вашу инфраструктуру, главный тест простой: новый человек должен поднять приложение с нуля и понять, как оно живет, без переписок в мессенджере.
Самый полезный контрольный замер - «чистый старт» на свежем ноутбуке или в чистом контейнере. Цель: за 15-30 минут собрать и запустить React фронтенд, Go бэкенд и PostgreSQL, получить первый успешный запрос к API и открыть интерфейс.
В репозитории должны быть ответы на два вопроса: «как запустить» и «что сломается при обновлении». Минимум обычно такой:
.env.example или config.example с описанием переменных (что это и где используется).Проверьте жизненный цикл: что происходит при пуше и что происходит при выкладке.
CI-пайплайн должен хотя бы собирать проект, запускать тесты (если они есть) и линтер. Добавьте проверку на утечки секретов и убедитесь, что в репозитории нет реальных ключей, токенов, паролей и дампов. Для окружений (dev/stage/prod) должны быть описаны переменные окружения и понятные значения по умолчанию для локальной разработки.
По PostgreSQL нужен план бэкапов и проверенный способ восстановления. По домену и SSL - кто владеет доменом, где лежат записи DNS, кто сможет обновлять сертификаты и менять конфигурацию.
Вместе с кодом передайте «пакет доступа»: список нужных аккаунтов и ролей, где хранятся секреты, контакты ответственных и короткую заметку «что самое хрупкое» (платежи, интеграции, фоновые задачи). Это занимает 20 минут, а экономит дни.
Частый сценарий: небольшая команда собрала MVP в vibe-coding платформе (лендинг, личный кабинет и простое API). Продукт показали пользователям, нашли fit, и теперь проект нужно передать в инхаус-разработку, чтобы дальше жить по внутренним правилам компании. На этом этапе цель одна: после экспорта исходного кода из vibe-coding платформы новая команда должна запускать проект у себя и выпускать обновления без «магии» платформы.
Чтобы передача не растянулась на месяц, заранее договоритесь, что считается готовым результатом, и разбейте работу на 1-2 недели.
Обычно хватает такого темпа: в первые 1-2 дня - экспорт кода, локальный запуск, фиксация версий (Node/Go/PostgreSQL) и первый чистый коммит; затем - привести структуру и команды запуска к привычным для команды и договориться про dev/stage/prod; дальше - настроить минимальный CI (сборка, линтеры, тесты где есть, миграции на чистую базу); на второй неделе - подготовить деплой в выбранной инфраструктуре и прогнать «репетицию релиза» по инструкции с нуля. Финал - короткая сессия handoff (1-2 часа) и список открытых рисков с владельцами.
Перед стартом задайте новой команде несколько вопросов: какой стандарт для веток и релизов, чем они управляют секретами, где будут жить базы, какой формат конфигов принят (env-файлы, vault, переменные окружения в CI). Это экономит дни на переделках.
Помимо кода, приложите то, без чего проект «не оживет»: список секретов и переменных окружения (без значений), схему базы и порядок накатывания миграций, короткое описание модулей (что в React-части, что в Go-сервисе, какие внешние интеграции), минимальные примеры запросов для проверки, известные ограничения и тонкие места.
Если вы собираете MVP в TakProsto, полезно заранее продумать экспорт, хранение снапшотов и сценарии отката, чтобы передача была предсказуемой. А когда понадобится ускорить следующую итерацию, TakProsto (takprosto.ai) можно использовать как удобный способ быстро собрать прототип и затем снова вывести проект в «обычный» репозиторий по тем же правилам владения.
Владение начинается с воспроизводимости: проект должен подниматься из чистого клона без ручных правок и без доступа к платформе. Минимум — понятная структура репозитория, инструкции запуска, миграции БД, шаблон конфигов и рабочий пайплайн сборки в CI.
Проверьте четыре зоны зависимости: сборка, секреты, деплой, доступы. Если сборка опиралась на скрытые шаги, секреты жили только в интерфейсе, деплой был завязан на встроенный хостинг/домены, а доступы нельзя передать — это и есть основные точки привязки.
Сделайте инвентаризацию окружений (dev/stage/prod): где база, какие домены, кто владелец доступов, что считается успешной проверкой перед продом. Зафиксируйте «якорь» состояния (версию/снимок), и соберите список внешних провайдеров (почта, SMS, платежи, хранилища, аналитика), чтобы не искать их уже после переезда.
Ожидаемый минимум: исходники фронтенда (React), бэкенда (Go), миграции/схема PostgreSQL, и при наличии — мобильный проект (Flutter). Дополнительно нужны файлы конфигурации, пример переменных окружения и скрипты/команды, которые позволяют запустить проект локально.
Сделайте один понятный коммит с импортом и сразу вычистите артефакты сборки. Обязательно настройте .gitignore (например, node_modules, dist/build, логи, локальные базы, .env). Добавьте короткий README: версии инструментов, команды запуска, где миграции и где лежит пример конфига.
Зафиксируйте версии Node.js/Go/PostgreSQL и договоритесь об одном менеджере пакетов с lock-файлом. Поднимайте БД скриптом (создание базы → миграции → минимальные сиды). В идеале свести всё к нескольким командам через Makefile или скрипты: установка, запуск БД, миграции, dev-режим, тесты.
Разделите настройки и секреты: настройки можно хранить в репозитории, секреты — нет. В репо держите только .env.example/пример конфига без значений. Реальные секреты храните в переменных окружения CI/сервера или в менеджере секретов, а также продумайте ротацию и запрет на логирование значений с именами вроде TOKEN/SECRET/PASSWORD.
Начните с минимума: форматирование/линт, сборка и тесты для фронта и бэка. Для базы — поднять временный PostgreSQL в CI и прогнать миграции на чистую базу. Зафиксируйте версии Node и Go в CI, используйте lock-файлы (go.sum, lock для JS) и не тащите секреты в репозиторий.
Сделайте деплой повторяемым: понятный документ (например, DEPLOY.md) с доменом, портами, переменными окружения, health-check и правилами доступа (что наружу, что внутри сети). Минимально удобно иметь staging и prod. Договоритесь, где и как запускаются миграции, и обязательно делайте бэкап БД перед релизом.
Передача считается успешной, если новый человек может за 15–30 минут поднять проект «с нуля» и понять базовый цикл разработки и релиза. Подготовьте пакет: README, команды build/test/migrate/seed, список переменных (без значений), описание интеграций и фоновых задач, план бэкапов/восстановления и простой откат через теги версий (а не правки напрямую в main).