Установка Decap CMS с Git-бэкендом: пошаговое руководство

Почему установка Decap CMS упирается в ручную правку контента

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

Дальше начинается ручной цикл: задача в трекере, ветка, согласование, сборка, проверка на стенде и только потом выкладка. На мелкой правке теряется день-два, на согласовании формулировок — заметно больше. За это время текст правится ещё в одном месте, и контент в git-репозитории расходится с тем, что реально видят посетители; расхождение всплывает уже на проде, когда кто-то присылает скриншот с устаревшей строкой.

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

Разбираем, как это закрывается на практике — от описания коллекций и полей до сборки, которая запускается после каждого коммита.

Что даёт Git-бэкенд: скорость правок и предсказуемые сборки

Decap CMS хранит контент не в базе, а в репозитории: каждая запись — markdown или JSON с front matter, правка редактора превращается в коммит, публикация — в слияние ветки и пересборку сайта. Такой git-бэкенд для CMS убирает прослойку «база → API → рендер», поэтому итоговый HTML остаётся статикой, а весь контент проходит через тот же ревью и те же проверки, что и код. Ниже — три эффекта, которые видно по метрикам.

Время публикации правки: минуты вместо часов

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

История версий контента и доля откатов

Каждая правка — это коммит с автором, сообщением и точным диff. Возврат к предыдущей формулировке делается одной ревизией, без восстановления резервной копии базы и без простоя. По отраслевым замерам, у команд, перенёсших редактуру в репозиторий, доля публикаций, которые приходится откатывать руками, падает в разы — потому что откат перестаёт быть операцией на данных и становится операцией в истории.

Сборка сайта после правки: ошибки видны до выхода

Сборка — это шлюз: проверка front matter, битых внутренних ссылок, дублей заголовков и сборки меню выполняется до выкладки. Упавшая сборка не публикуется, прод остаётся на предыдущей версии, а автор получает лог с указанием строки. В результате доля неудачных выкладок, доходящих до посетителей, снижается, а число «тихих» поломок навигации после контентных правок падает до единичных случаев.

Варианты подключения: локальный запуск, сервер сборки, облако

Панель с git-бэкендом — это набор статических файлов, которые читают и записывают контент прямо в репозиторий: каждое сохранение превращается в коммит в ветку. Поэтому режим подключения определяет сразу три вещи — кто получает доступ к правкам, как проверяется изменение и в какой момент оно попадает на прод. Decap CMS поддерживает все три схемы без переписывания контента: меняется секция бэкенда в конфигурации, а markdown-файлы остаются лежать там же.

Режимы не конкурируют, а закрывают разные этапы: локальный запуск — настройка схемы коллекций, сервер сборки — свой домен и приватные правила публикации, облако — командная работа нескольких редакторов. Ниже — сравнение по критериям, которые чаще всего ломают выпуск материала.

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

Установка и подключение Git-бэкенда: этапы работ

В Decap CMS git-бэкенд — самый предсказуемый вариант для контентного сайта: правки уходят в репозиторий обычными коммитами, поэтому история, согласование и откат работают теми же средствами, что и для кода. Этапы выстраиваем так, чтобы каждый заканчивался конкретной проверкой, а не надеждой.

1. Аудит структуры контента. Разбираем существующие страницы и типы записей, отмечаем повторяющиеся блоки. Проверяем: что станет коллекцией, а что — одиночным файлом.
2. Настройка коллекций контента. Описываем коллекции, поля и папку для медиафайлов. Проверяем: обязательные поля помечены, вложенные списки не ломают схему.
3. Подключение git-бэкенда. Указываем провайдера репозитория, рабочую ветку и каталог контента. Проверяем: тестовая правка создаёт коммит в нужной ветке, а не в основной.
4. Права доступа редакции. Настраиваем роли: автор работает с черновиками, старший редактор подтверждает публикацию. Проверяем: автор не может писать напрямую в основную ветку.
5. Сборка и медиа. Прогоняем сборку с реальными правками и загруженными изображениями. Проверяем: файл попадает в нужную папку, путь в контенте корректен, сборка не падает.
6. Проверка публикации. Прогоняем полный цикл: черновик → подтверждение → сборка → страница. Проверяем: изменения видны на сайте, а откат коммита возвращает прошлую версию.
7. Передача доступов редакции. Заводим учётные записи и короткую инструкцию по интерфейсу. Проверяем: новый редактор проходит путь от черновика до публикации самостоятельно.

Что передаём на руки: коллекции, роли, регламенты правок

После внедрения редакция правит сайт сама, без обращения к нам. Поэтому на руки уходит не «доступ к админке», а набор файлов в репозитории: конфигурация Decap CMS, политики прав и инструкции для авторов и редакторов.

• Схема коллекций — типы контента (страницы, новости, авторы, справочники) с полями: вид, обязательность, правило проверки. Запись с пустым заголовком или битой ссылкой на изображение просто не сохранится.
• Роли автора и редактора — автор видит и правит только свои черновики, редактор подтверждает и публикует. Разграничение держится на ветках и защите основной ветки, а не на договорённостях.
• Черновики и предпросмотр правок — сохранение уходит в отдельную ветку, предпросмотр собирается из неё же, поэтому недоделанная страница не попадает на рабочий сайт.
• Инструкция для редакции — несколько страниц с экранами: как добавить материал, прикрепить изображение, отправить на проверку и что делать, если поле не прошло проверку.
• Порядок отката — как вернуть предыдущую версию материала или снять опубликованное целиком: через историю изменений и откат нужного коммита.
• Соглашение о медиафайлах — где лежат изображения, как именуются, какой формат и вес допустимы.
• Разбор конфигурации с вашим разработчиком — доступы оформлены на ваши аккаунты, схема и роли объяснены, поддержку можно вести своими силами.

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

Кейс: правки контента без участия разработчика и без простоев

Что было до внедрения

Сайт собирался из markdown-файлов в Git, а любая правка шла через разработчика: редактор присылал текст в общий список задач, инженер вносил его в файл, коммитил и ждал сборки. Это давало 10-12 публикаций в неделю и 1-2 суток от согласованного текста до выхода на сайте — срочная новость за это время теряла смысл. Страдала и стабильность: примерно каждая третья сборка падала из-за опечатки в служебных полях материала или ссылки на несуществующую страницу, и разбирался с логами тот же разработчик.

Что изменили

Развернули Decap CMS с Git-бэкендом и описали коллекции конфигом: какие поля есть у материала, какие обязательны, в каком формате дата и обложка. Редактор работает в веб-интерфейсе — сохранить материал с пустым заголовком или битой ссылкой форма не даст, а каждое сохранение превращается в коммит с автором-редактором. Сборка отдельной ветки отдаёт предпросмотр до слияния, поэтому ошибка видна на этапе правки, а не в основной ветке.

Что стало после внедрения

Редакция сама делает 40+ правок в неделю без заявок в разработку. Сутки до публикации сократились до минут: материал выходит сразу после проверки, а не после ближайшего окна инженера. Доля упавших сборок снизилась с трети до единичных случаев, и почти все они ловятся на предпросмотре. Разработчики вернулись к задачам продукта — сопровождение контента перестало быть их работой.

Чем Git-бэкенд отличается от внешнего сервиса хранения контента?

Git-бэкенд означает, что Decap CMS не хранит контент у себя: каждая правка — коммит в репозиторий, файлы лежат в markdown/YAML рядом с кодом. Внешний сервис устроен наоборот — редактор пишет запись в базу вендора, а сайт забирает её по API. Разница проявляется не в удобстве редактирования, а в том, кому принадлежат версии и как быстро откатывается ошибка.

Практический эффект — откат перестаёт быть операцией «свяжись с подрядчиком». Испортили блок на главной: revert коммита, пересборка, выкладка — и на сайте прежняя версия. Правки нескольких редакторов сливаются как код, расхождение видно в построчном сравнении, а не всплывает на проде.

Обратная сторона честная: Git-бэкенд требует работающей сборки и доступа к репозиторию у тех, кто правит контент. Внешний сервис оправдан при большой редакции с ролями и ограничением по полям — но тогда контент живёт в чужой базе, а вы наследуете зависимость от её условий и API.

Вопросы инженеров: доступы, откат правок, миграция контента

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

Как разграничить права доступа между редакторами?

Роли выстраиваются по разделам: автор правит только свои материалы, редактор публикует, администратор управляет схемой полей. Ограничение задаётся на уровне репозитория и ветки — автор физически не может затронуть чужой раздел или основную ветку.

Что делать с уже накопленным контентом другого формата?

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

Как устроены черновики, публикация и откат неудачной правки?

Автор работает в отдельной ветке, черновик виден на предпросмотре, публикация — слияние в основную ветку. Неудачная правка откатывается обратным коммитом: сайт возвращается к предыдущему состоянию за время одной сборки, без ручного восстановления из бэкапа.

Обсудим задачу: что нужно от редакции и от разработчиков

Чтобы оценка установки Decap CMS была точной, а план внедрения — выполнимым, нам нужен вводный контекст по проекту. Со стороны редакции и со стороны разработки он разный, и собрать его лучше до старта, чем выяснять на середине работ.

• Где сейчас живёт контент: файлы в репозитории, разметка в текстовом виде или данные в другом хранилище, кто и как их правит.
• Репозиторий и модель ветвления: Git-хост, рабочая ветка, правила слияния изменений, у кого есть право на публикацию.
• Структура коллекций: какие сущности редактируются, обязательные поля, вложенные списки и связи между документами.
• Роли в редакции: кто пишет, кто согласует, кто публикует; нужна ли отдельная ветка под черновик и проверку перед выпуском.
• Сборка и публикация: генератор статики, конфигурация сборки, как сейчас выкладывается готовая версия и как откатывается неудачная.
• Доступы и безопасность: схема авторизации авторов, права на репозиторий, резервные копии, кто отвечает за восстановление.
• Требования к подрядчику: состав работ, границы ответственности, порядок согласования правок и регламент реакции на сбои.
• Передача редакции: инструкция для авторов, разбор типовых ошибок и сопровождение после запуска.

Из этого складываются три документа: оценка работ по внедрению, план внедрения по этапам и требования к подрядчику. Опишите задачу в свободной форме — вернёмся с оценкой и планом.