Багато невеликих сценаріїв, одне сховище чи кілька?


16

Співробітник і я зіткнулися з проблемою, про яку ми маємо багато думок.

В даний час у нас є сховище git, в якому ми зберігаємо всі наші чіткі, є близько 20 крон, і вони насправді не пов'язані, за винятком того, що всі вони є маленькими сценаріями пітона і необхідні для певної діяльності. Ми використовуємо fabric.pyфайл для розгортання таrequirements.txt файл для управління вимогами до всіх сценаріїв.

Наша проблема полягає в основному, чи зберігаємо ми всі ці сценарії в одному сховищі git або ми повинні розділяти їх у свої власні сховища? Зберігаючи їх в одному сховищі, їх легше розмістити на одному сервері. Ми можемо використовувати лише один файл cron для всіх сценаріїв.

Однак це відчуває себе неправильно, оскільки 20 крайових завдань не є логічно пов'язаними. Крім того, при використанні одного requirements.txtфайлу для всіх сценаріїв важко зрозуміти, які залежності існують для певного сценарію, і всі вони повинні використовувати однакові версії пакетів.

Ми могли розділити всі сценарії у свої власні сховища, але це створює 20 різних сховищ, які потрібно запам’ятати та мати справу з ними. Більшість із цих сценаріїв не дуже великі, і таке рішення здається непосильним.

Питання пов'язане з тим, чи використовуємо ми один великий файл crontab для всіх кронштейнів, або окремий файл для кожного? Якщо у кожного є свій, як установка одного crontab уникає перезапису інших 19? Це також здається болем, як тоді було б 20 різних файлів cron для відстеження.

Коротше кажучи, наше головне питання полягає в тому, чи зберігаємо ми їх усі в сукупності як одне сховище чи ми їх відокремлюємо у своє сховище зі своїми вимогами.txt та fabfile.py? Ми відчуваємо, що ми, ймовірно, переглядаємо якесь дійсно просте рішення. Чи є простіший спосіб вирішити це питання?


Чи пов'язані ці сценарії із завданнями cron з іншими програмами, або буквально просто звалища скриптів утиліти?
Грег Бургхардт

Я не розумію, чому розміщення їх у одному сховищі означатиме, що їм потрібно мати спільні вимоги.txt? У кожного з них можуть бути різні вимоги.txt, якщо ви помістите їх в окремі підкаталоги сховища ...
Шон Бертон

Відповіді:


16

Якщо не існує конкретної причини, щоб ви думали, що кожен з них заслуговує невидимого репо (чи багато вони виростуть? Мабуть, ні!), Здається більш розумним розмістити їх усіх в одне репо, і врятувати себе від клонування всіх з них від 20 репостів.

Тримати кожного в окремому репо, схоже, шлях створення проблеми там, де проблеми не існує.

Не створюйте зайвих робіт для себе (та інших).


2
Погоджено - доки сценарії будуть названі добре, а дублювання між ними зберігається низько (тобто загальнодоступні бібліотечні речі), щоб грізні пошукові запити не були занадто захаращеними, я думаю, це працює.
Danny Staple

1

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.