Контроль версій веб-сайту: файли розробки / випуску

Я намагаюся придумати кращий спосіб контролю версій на наших веб-сайтах. Майте на увазі, що я лише передовий розробник, тому я не маю глибоких знань VCS.

Робочі процеси змінюються, а звички контролю версій минулих версій застарівають. Основна проблема полягає у тому, що для кожного веб-сайту є 2 масиви файлів, що працюють на першому рівні.

Середовище розробок (менше файлів, нестиснений js, зображення тощо). Навколишнє середовище, «скупчене» (усе стиснене і не читабельне людьми).

Але ви не можете продати веб-сайт із його вихідними файлами. Ну, це відчувається не зовсім правильно.

Існує рішення мати 2 репости: одна збірка, одна розробка, з gulp надсилає dev файли для створення каталогу. Але клопоту підтримувати, з малими компаніями я не думаю, що це так здорово. Це створює багато репостів, і людям доводиться керувати кількома репостами, іноді навіть з одним svn repo виникають проблеми.

Тож є також рішення мати 1 репо: вихідні файли та файли prod у тому ж svn. Але тоді потрібно видалити вихідні файли, коли веб-сайт переходить з локального сервера розробки на виробничий сервер (тому в одному сховищі є різні файли, залежно від його розташування, розробника чи виробництва ..) З того, що я чув, це не добре

Який правильний спосіб керувати робочим процесом із заглибленням відносно системи управління версіями?

Одне основне правило управління джерелами полягає в тому, що вам потрібно лише помістити вручну написані артефакти в репо (оригінальні файли вихідних файлів), все, що можна "скласти" або "генерувати", не потрібно зберігати там, оскільки це призведе до надмірності . Один може (необов'язково) зберігання проміжних результатів / частини процесу складання в репозиторії (іноді також звані артефакти), коли кроки , щоб відтворити їх не повністю автоматично, або для кешування цілей, коли кроки збірки для відтворення на виході буде повільним .

Отже, якщо у вас є повністю автоматизований процес для генерування виробничих файлів із вихідних файлів розробників, вам потрібно лише поставити файли dev у керування джерелами (разом із сценаріями для створення виробничих файлів). Якщо ні, встановіть такий процес. Переконайтесь, що після створення файлів із джерела ніхто не повинен вручну поводитися з виробничими файлами. Якщо ви хочете розгорнути "безпосередньо" зі свого VCS, переконайтеся, що у вас є сценарій розгортання, який витягує файли вихідних файлів із вихідного контролю, робить "gulpification" та передає отримані файли на виробництво за один крок.

Звичайно, якщо ви хочете використовувати джерело управління також як "бідне резервне копіювання файлів mans" або як кеш для ваших виробничих файлів, ви можете встановити для цієї мети друге репо і помістити туди копію виробничої структури файлів після покоління. Цей репо не буде служити для розробки, і після його налаштування вам не доведеться підтримувати його вручну. Тому переконайтесь, що в цьому "prod repo" не буде виконано жодних вручну кроків для створення резервних копій - включіть необхідні кроки до сценарію розгортання, який робить резервну копію автоматично. Подумайте над тим, щоб додати окремий скрипт резервного копіювання, якщо ви не можете заборонити вручну змінювати виробництво після розгортання. Таким чином, ви можете тримати процес бездоганним, навіть якщо у вас є обмежені ресурси.

І так, це має бути суворо відокремлене, друге репо, тому що воно має зовсім інше призначення та інший життєвий цикл, ніж ти, дев репо. Ви використовуєте його лише для резервного копіювання, а не для управління джерелом, що є іншим процесом.