Чому встановлення Decap CMS упирається в ручне редагування контенту
Сайт уже збирається з репозиторію: контент лежить поруч із шаблонами окремими файлами розмітки, а публікація запускається комітом. Поки тексти не чіпають, схема працює — збірка відтворювана, історія змін повна, відкат до будь-якої версії займає хвилини.
Але варто змінити заголовок на головній або уточнити формулювання в картці послуги, і правка потрапляє в чергу завдань до розробника.
Далі починається ручний цикл: завдання в трекері, гілка, погодження, збірка, перевірка на стенді й лише потім викладка. На дрібній правці втрачається день-два, на погодженні формулювань — помітно більше.
За цей час текст правиться ще в одному місці, і контент у git-репозиторії розходиться з тим, що реально бачать відвідувачі; розбіжність спливає вже на проді, коли хтось надсилає скриншот із застарілим рядком.
Встановлення Decap CMS закриває саме цей розрив. Панель керування контентом читає структуру полів із конфігурації та зберігає правки прямо в репозиторій окремим комітом — редактор працює з формами, а не з файлами, і не може випадково зламати шаблон.
Правки без розробника при цьому не скасовують рев’ю: гілка, історія та відкат залишаються на місці, а ручна публікація правок перетворюється на один крок замість ланцюжка погоджень.
Розбираємо, як це закривається на практиці — від опису колекцій і полів до збірки, яка запускається після кожного коміта.
Що дає Git-бекенд: швидкість правок і передбачувані збірки
Decap CMS зберігає контент не в базі, а в репозиторії: кожен запис — markdown або JSON із front matter, правка редактора перетворюється на коміт, публікація — на злиття гілки та перезбирання сайту.
Такий git-бекенд для CMS прибирає прошарок «база → API → рендер», тому підсумковий HTML залишається статикою, а весь контент проходить через те саме рев’ю й ті самі перевірки, що й код. Нижче — три ефекти, які видно за метриками.
Час публікації правки: хвилини замість годин
Контент-менеджер править текст у візуальному редакторі, правка потрапляє в окрему гілку, після злиття автоматично стартує збірка.
Інкрементальний кеш перезбирає лише зачеплені сторінки, а не весь сайт цілком, тому медіана від натискання «зберегти» до появи тексту на бойовому домені вимірюється хвилинами.
Там, де немає чернеткового середовища, гілку показують на попередньому перегляді — погодження не блокує публікацію.
Історія версій контенту та частка відкатів
Кожна правка — це коміт з автором, повідомленням і точним diff. Повернення до попереднього формулювання робиться однією ревізією, без відновлення резервної копії бази та без простою.
За галузевими вимірами, у команд, які перенесли редагування в репозиторій, частка публікацій, які доводиться відкочувати вручну, падає в рази — бо відкат перестає бути операцією над даними й стає операцією в історії.
Збірка сайту після правки: помилки видно до виходу
Збірка — це шлюз: перевірка front matter, битих внутрішніх посилань, дублів заголовків і збирання меню виконується до викладки. Збірка, що впала, не публікується, прод залишається на попередній версії, а автор отримує лог із зазначенням рядка.
У результаті частка невдалих викладок, що доходять до відвідувачів, знижується, а кількість «тихих» поломок навігації після контентних правок падає до поодиноких випадків.
Варіанти підключення: локальний запуск, сервер збірки, хмара
Панель із git-бекендом — це набір статичних файлів, які читають і записують контент прямо в репозиторій: кожне збереження перетворюється на коміт у гілку.
Тому режим підключення визначає одразу три речі — хто отримує доступ до правок, як перевіряється зміна й у який момент вона потрапляє на прод.
Decap CMS підтримує всі три схеми без переписування контенту: змінюється секція бекенда в конфігурації, а markdown-файли залишаються лежати там само.
Режими не конкурують, а закривають різні етапи: локальний запуск — налаштування схеми колекцій, сервер збірки — власний домен і приватні правила публікації, хмара — командна робота кількох редакторів. Нижче — порівняння за критеріями, які найчастіше ламають випуск матеріалу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальний запуск панелі | Первинне налаштування полів і колекцій, відлагодження схеми, разовий імпорт старого контенту | Потребує встановленого середовища та прав на запис у репозиторій; редактори без доступу до репозиторію працювати не зможуть, авторизація не перевіряється |
| Сервер збірки сайту | Власний домен, закритий контур, власні правила перевірки правок і ролі редакторів | Сервер потрібно утримувати й оновлювати, самостійно налаштовувати вхід, резервні копії та хуки на подію коміта |
| Хмарна збірка статики | Кілька редакторів, попередній перегляд окремих гілок, автоматична публікація після злиття | Налаштування живуть поза репозиторієм, діють ліміти платформи на збірку, вхід прив’язаний до її провайдера |
Практично перехід між режимами — це правка одного блока конфігурації та перенесення правил доступу. Контент, структура колекцій та історія комітів при цьому зберігаються, тому починати з локального запуску, а згодом переїжджати на сервер або в хмару безпечно.
Встановлення та підключення Git-бекенда: етапи робіт
У Decap CMS git-бекенд — найпередбачуваніший варіант для контентного сайту: правки потрапляють у репозиторій звичайними комітами, тому історія, погодження та відкат працюють тими самими засобами, що й для коду. Етапи вибудовуємо так, щоб кожен закінчувався конкретною перевіркою, а не надією.
- Аудит структури контенту. Розбираємо наявні сторінки й типи записів, позначаємо повторювані блоки. Перевіряємо: що стане колекцією, а що — одиночним файлом.
- Налаштування колекцій контенту. Описуємо колекції, поля та папку для медіафайлів. Перевіряємо: обов’язкові поля позначені, вкладені списки не ламають схему.
- Підключення git-бекенда. Указуємо провайдера репозиторію, робочу гілку та каталог контенту. Перевіряємо: тестова правка створює коміт у потрібній гілці, а не в основній.
- Права доступу редакції. Налаштовуємо ролі: автор працює з чернетками, старший редактор підтверджує публікацію. Перевіряємо: автор не може писати напряму в основну гілку.
- Збірка та медіа. Проганяємо збірку з реальними правками й завантаженими зображеннями. Перевіряємо: файл потрапляє в потрібну папку, шлях у контенті коректний, збірка не падає.
- Перевірка публікації. Проганяємо повний цикл: чернетка → підтвердження → збірка → сторінка. Перевіряємо: зміни видно на сайті, а відкат коміта повертає попередню версію.
- Передача доступів редакції. Заводимо облікові записи та коротку інструкцію з інтерфейсу. Перевіряємо: новий редактор проходить шлях від чернетки до публікації самостійно.
Що передаємо на руки: колекції, ролі, регламенти правок
Після впровадження редакція править сайт сама, без звернення до нас. Тому на руки передається не «доступ до адмінки», а набір файлів у репозиторії: конфігурація Decap CMS, політики прав та інструкції для авторів і редакторів.
- Схема колекцій — типи контенту (сторінки, новини, автори, довідники) з полями: вид, обов’язковість, правило перевірки. Запис із порожнім заголовком або битим посиланням на зображення просто не збережеться.
- Ролі автора й редактора — автор бачить і править лише свої чернетки, редактор підтверджує та публікує. Розмежування тримається на гілках і захисті основної гілки, а не на домовленостях.
- Чернетки та попередній перегляд правок — збереження потрапляє в окрему гілку, попередній перегляд збирається з неї ж, тому недороблена сторінка не потрапляє на робочий сайт.
- Інструкція для редакції — кілька сторінок зі скріншотами: як додати матеріал, прикріпити зображення, надіслати на перевірку та що робити, якщо поле не пройшло перевірку.
- Порядок відкату — як повернути попередню версію матеріалу або зняти опубліковане цілком: через історію змін і відкат потрібного коміта.
- Угода про медіафайли — де лежать зображення, як іменуються, який формат і вага допустимі.
- Розбір конфігурації з вашим розробником — доступи оформлено на ваші акаунти, схема та ролі пояснені, підтримку можна вести своїми силами.
На прийманні проходимо кожен пункт на живому завданні: заводимо тестовий матеріал, надсилаємо на перевірку, публікуємо та відкочуємо. Якщо крок потребує нашої участі — це не передача, а залежність.
Кейс: правки контенту без участі розробника та без простоїв
Що було до впровадження
Сайт збирався з markdown-файлів у Git, а будь-яка правка йшла через розробника: редактор надсилав текст до загального списку завдань, інженер вносив його у файл, комітив і чекав на збірку.
Це давало 10-12 публікацій на тиждень і 1-2 доби від погодженого тексту до виходу на сайті — термінова новина за цей час втрачала сенс.
Страждала й стабільність: приблизно кожна третя збірка падала через одруківку в службових полях матеріалу або посилання на неіснуючу сторінку, і розбирався з логами той самий розробник.
Що змінили
Розгорнули Decap CMS з Git-бекендом і описали колекції конфігом: які поля є в матеріалу, які обов’язкові, у якому форматі дата й обкладинка.
Редактор працює у веб-інтерфейсі — зберегти матеріал із порожнім заголовком або битим посиланням форма не дасть, а кожне збереження перетворюється на коміт з автором-редактором.
Збірка окремої гілки віддає попередній перегляд до злиття, тому помилка видна на етапі правки, а не в основній гілці.
Що стало після впровадження
Редакція сама робить 40+ правок на тиждень без заявок у розробку. Доба до публікації скоротилася до хвилин: матеріал виходить одразу після перевірки, а не після найближчого вікна інженера.
Частка збірок, що впали, знизилася з третини до поодиноких випадків, і майже всі вони виявляються на попередньому перегляді. Розробники повернулися до завдань продукту — супровід контенту перестав бути їхньою роботою.
Чим Git-бекенд відрізняється від зовнішнього сервісу зберігання контенту?
Git-бекенд означає, що Decap CMS не зберігає контент у себе: кожна правка — коміт у репозиторій, файли лежать у markdown/YAML поруч із кодом. Зовнішній сервіс влаштований навпаки — редактор пише запис у базу вендора, а сайт забирає його через API.
Різниця проявляється не в зручності редагування, а в тому, кому належать версії та як швидко відкочується помилка.
| Критерій | Git-бекенд | Зовнішній сервіс |
|---|---|---|
| Де лежать дані | файли в репозиторії | записи в базі вендора |
| Історія версій | коміти, гілки, авторство | журнал усередині сервісу, часто урізаний |
| Відкат правки | revert потрібного коміта | відновлення зі снапшота, глибина задається вендором |
| Чернетки | гілка + попередній перегляд збірки | чернетки в базі вендора |
| Публікація | збірка на нашій стороні | вебхук сервісу, затримка поза контролем |
| Перенесення контенту | клон репозиторію — повний зліпок | вивантаження через API і перезбирання зв’язків |
| Залежність | доступ до репозиторію | ключі, квоти та правила вендора |
Практичний ефект — відкат перестає бути операцією «зв’яжися з підрядником». Зіпсували блок на головній: revert коміта, перезбирання, викладка — і на сайті попередня версія. Правки кількох редакторів зливаються як код, розбіжність видно в порівнянні рядків, а не спливає на проді.
Зворотний бік чесний: Git-бекенд потребує робочої збірки та доступу до репозиторію в тих, хто править контент. Зовнішній сервіс виправданий за великої редакції з ролями та обмеженням за полями — але тоді контент живе в чужій базі, а ви успадковуєте залежність від її умов і API.
Питання інженерів: доступи, відкат правок, міграція контенту
Контент у такій схемі лежить не в базі застосунку, а файлами в репозиторії: кожна правка стає окремим комітом з автором і датою.
Тому питання про доступи, відкат і перенесення вирішуються не доопрацюваннями адмінки, а на рівні системи контролю версій — і відповідають на них заздалегідь.
Де фізично живуть матеріали і що буде при збої?
Тексти та зображення зберігаються в репозиторії, а не в базі одного сервера. При відмові редактора або збірки контент не губиться: статику можна зібрати з репозиторію заново, а повна копія є в кожного, хто працює з проєктом.
Як розмежувати права доступу між редакторами?
Ролі вибудовуються за розділами: автор править лише свої матеріали, редактор публікує, адміністратор керує схемою полів. Обмеження задається на рівні репозиторію та гілки — автор фізично не може зачепити чужий розділ або основну гілку.
Що робити з уже накопиченим контентом іншого формату?
Переносимо скриптом: сторінки та записи розбираються у файли зі збереженням адрес, зображення переїжджають у медіасховище. Після прогону звіряємо карту посилань і налаштовуємо редіректи, щоб накопичений пошуковий трафік не загубився.
Як влаштовані чернетки, публікація та відкат невдалої правки?
Автор працює в окремій гілці, чернетка видна на попередньому перегляді, публікація — злиття в основну гілку. Невдала правка відкочується зворотним комітом: сайт повертається до попереднього стану за час однієї збірки, без ручного відновлення з бекапу.
Обговоримо задачу: що потрібно від редакції та від розробників
Щоб оцінка встановлення Decap CMS була точною, а план впровадження — здійсненним, нам потрібен вступний контекст щодо проєкту. З боку редакції та з боку розробки він різний, і зібрати його краще до старту, ніж з’ясовувати на середині робіт.
- Де зараз живе контент: файли в репозиторії, розмітка в текстовому вигляді або дані в іншому сховищі, хто і як їх править.
- Репозиторій і модель галуження: Git-хост, робоча гілка, правила злиття змін, у кого є право на публікацію.
- Структура колекцій: які сутності редагуються, обов’язкові поля, вкладені списки та зв’язки між документами.
- Ролі в редакції: хто пише, хто погоджує, хто публікує; чи потрібна окрема гілка під чернетку та перевірку перед випуском.
- Збірка та публікація: генератор статики, конфігурація збірки, як зараз викладається готова версія і як відкочується невдала.
- Доступи та безпека: схема авторизації авторів, права на репозиторій, резервні копії, хто відповідає за відновлення.
- Вимоги до підрядника: склад робіт, межі відповідальності, порядок погодження правок і регламент реакції на збої.
- Передача редакції: інструкція для авторів, розбір типових помилок і супровід після запуску.
Із цього складаються три документи: оцінка робіт із впровадження, план впровадження за етапами та вимоги до підрядника. Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
