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

Розробники створюють сценарії, щоб допомогти в їх роботі. Наприклад, запустити Maven з певними параметрами, знищити непотрібні фонові завдання, які з'являються в процесі розробки, або підключитися до певного сервера. Сценарії не є основними сценаріями побудови, ні вони не використовуються на нашому сервері безперервної інтеграції.

Який найкращий спосіб управління ними? Щоб помістити їх у каталог (можливо /scripts) і перевірити їх у Git? Щоб підтримувати їх окремо на якомусь файловому сервері?

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

Сценарії розробників переходять також до контролю версій, оскільки зазвичай ці сценарії також залежать від елементів керування версіями, наприклад, шляхів до файлів.

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

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

Окрім відповіді @ simon.

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

Досвідчені / ініціативні розробники прагнуть автоматизувати ці завдання. Деякі навіть будують інструменти, коли ці завдання стають частиною SDLC і вони втомлюють - і схильні до помилок - робити вручну. Програми добре виконувати багаторазові завдання, якими б вони не були стомлювальними. Ми - люди - не такі добрі.

Ці інструменти / сценарії мають і інші позитивні ефекти

1. Продуктивність
2. Передача знань
3. Автономія (для новачків)

Отже, так, сценарії повинні бути в СКМ, і вони повинні бути ще одним інструментом у панелі інструментів розробника.

Щодо папки, /scriptsя б сказав, що це не має значення. Для простоти я залишаю їх у кореневому каталозі проекту, щоб усі маршрути, задекларовані в сценаріях, були відносно папки проекту. Якщо мені потрібен доступ до зовнішніх папок або файлів, я створюю м'які посилання .

Речі, які слід врахувати, перш ніж перевірити сценарії в СКМ.

• В цілях безпеки переконайтеся, що в скриптах відсутні жорсткі кодові дані - в ідеалі сценарії повинні бути добре налаштовані -

• Переконайтеся, що сценарії не роблять незвичайних речей у системі, як, наприклад, для виконання команд, які неможливо відмінити (найбільш типові rm -rf).

• Оскільки вони стають частиною джерела проекту, документація високо цінується.

• Сценарій - це не ракетна наука. Зробіть сценарії лаконічними. Замість того, щоб один керував ними всіма ... і в темряві пов'язував їх , роби більше, менше і стисліше. Ніби ви застосовуєте SRP.

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

Однак я б встановив високу планку для запису на виконання сценаріїв. Сценарії є кодовими, як і саме програмне забезпечення. Це означає, що до них потрібно ставитися аналогічно до інших фрагментів коду:

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

Є ряд додаткових міркувань, які стосуються більше сценаріїв, ніж самого програмного забезпечення:

• Перш за все, набагато складніше переконати організацію та зацікавлених сторін інвестувати у підтримання сценаріїв, що полегшують життя розробників. Це означає, що важче знайти час для виконання вищезазначених критеріїв - легко написати сценарій, який працює для вас у вашому оточенні, але параметризувати його, зробити його стабільним, документування вимагає набагато більше часу. Це означає, що сценарії можуть і стануть мертвим кодом, якщо розробник не може виправдати збереження сценарію поточним.
• Набагато менше ймовірність того, що кілька розробників будуть достатньо знайомі зі складним сценарієм для його підтримання, або кілька розробників відчують право власності на код. Коли оригінальний розробник виїжджає, знайти когось іншого, щоб взяти право власності, може бути важко (а пошук та обґрунтування часу, коли вони дізнаються, як працює сценарій, може бути ще складніше).
• Набагато ймовірніше, що сценарій якимось чином буде взаємодіяти з машиною розробників і створювати середовище. Також велика ймовірність, що у вас буде кілька розробників із кількома різними середовищами. Якщо сценарій заплутав середовище, оскільки він не підтримувався належним чином, або кутовий випадок не розглядався, ви не просто порушуєте нічну складову свого програмного забезпечення, ви потенційно коштуєте розробнику в день або більше роботи, щоб отримати його навколишнє середовище в норму. Це може спричинити забиття крові та втрату довіри.
• Оскільки сценарії часто є зовнішніми для самого програмного забезпечення, збереження їх може бути проблемою. Якщо сценарії не виконуються за допомогою автоматики, їм легко стати застарілими або забутими, після чого вони стали мертвим кодом і є лише технічним боргом, який комусь знадобиться витратити час на очищення.

Підводячи підсумок, сценарії можуть бути дуже корисними для окремого розробника, але обмін даними як частина кодової бази може бути набагато складнішим завданням і потенційно може спричинити більше проблем, ніж вирішено.