S.Gromov
1a14df9366
- добавлены каноны и VitePress-сайт стратегии обновления шаблонов - подключена карточка документации на главной странице - добавлены сборочные скрипты, Caddy-маршрут и Docker-сборка - добавлена git-иконка для карточки и сгенерированы публичные артефакты
2 lines
4.8 KiB
JavaScript
2 lines
4.8 KiB
JavaScript
import{_ as a,o as t,c as i,ae as l}from"./chunks/framework.B1nRs-GM.js";const u=JSON.parse('{"title":"Зачем это нужно","description":"Почему шаблону нужен процесс обновления, а не только быстрый старт нового проекта.","frontmatter":{"title":"Зачем это нужно","description":"Почему шаблону нужен процесс обновления, а не только быстрый старт нового проекта."},"headers":[],"relativePath":"concepts/why.md","filePath":"concepts/why.md"}'),o={name:"concepts/why.md"};function r(n,e,p,c,d,s){return t(),i("div",null,[...e[0]||(e[0]=[l('<div style="display:none;" hidden="true" aria-hidden="true">Are you an LLM? You can read better optimized documentation at /template-sync-strategy/concepts/why.md for this page in Markdown format</div><h1 id="зачем-это-нужно" tabindex="-1">Зачем это нужно <a class="header-anchor" href="#зачем-это-нужно" aria-label="Permalink to "Зачем это нужно""></a></h1><p>Шаблон закрывает повторяющуюся техническую базу проекта: CI/CD, Dockerfile, зависимости, lint, build, структуру каталогов и базовую документацию.</p><p>Это снимает рутину на старте. Команде не нужно каждый раз заново собирать одинаковый технический каркас.</p><h2 id="проблема-после-старта" tabindex="-1">Проблема после старта <a class="header-anchor" href="#проблема-после-старта" aria-label="Permalink to "Проблема после старта""></a></h2><p>Создать проект легко. Поддерживать 10-20 проектов сложнее.</p><p>Сначала проекты похожи. Потом они начинают расходиться:</p><ul><li>В одном проекте обновили CI, в другом забыли.</li><li>В одном проекте Dockerfile остался из шаблона, в другом его локально поправили.</li><li>В одном проекте зависимости уже свежие, в другом остались старые версии.</li><li>В одном проекте изменения шаблона перенесли руками, в другом потеряли.</li></ul><p>Без процесса обновления шаблон перестаёт быть общей основой. Он остаётся только способом быстро создать первый коммит.</p><h2 id="что-ломается-без-стратегии" tabindex="-1">Что ломается без стратегии <a class="header-anchor" href="#что-ломается-без-стратегии" aria-label="Permalink to "Что ломается без стратегии""></a></h2><p>Когда шаблон нельзя нормально обновлять:</p><ul><li>проекты начинают жить своей жизнью;</li><li>граница между шаблоном и приложением теряется;</li><li>обновления превращаются в ручное копирование;</li><li>конфликты решаются прямо в рабочих ветках;</li><li>становится непонятно, какой проект на какой версии шаблона;</li><li>Git-история перестаёт быть источником правды.</li></ul><p>Это особенно больно, когда приложений много. Для одного проекта ручной перенос ещё можно пережить. Для набора проектов нужен единый маршрут обновления.</p><h2 id="цель-стратегии" tabindex="-1">Цель стратегии <a class="header-anchor" href="#цель-стратегии" aria-label="Permalink to "Цель стратегии""></a></h2><p>Стратегия не пытается убрать конфликты полностью. Она делает так, чтобы конфликты возникали в предсказуемом месте, проходили review и не ломали чистую ветку шаблона.</p><p>Главная формулировка:</p><blockquote><p>Шаблон должен обновляться так же контролируемо, как обычная фича: через ветку, проверку и PR/MR.</p></blockquote>',17)])])}const _=a(o,[["render",r]]);export{u as __pageData,_ as default};
|