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

Разработчики создают сценарии, которые помогут в их работе. Например, чтобы запустить Maven с определенными параметрами, убить ненужные фоновые задачи, которые возникают в процессе разработки, или подключиться к определенному серверу. Эти сценарии не являются основными сценариями сборки и не используются на нашем сервере непрерывной интеграции.

Как лучше всего управлять ими? Поместить их в каталог (может быть /scripts) и проверить их в Git? Поддерживать их отдельно на каком-то файловом сервере?

Аргументом для их обработки в качестве исходного кода является то, что они являются исходными и могут измениться. Аргументом за то, что он этого не делает, является то, что они являются просто вспомогательными инструментами, и что не всем разработчикам нужен какой-либо конкретный скрипт (например, скрипты для Linux, где некоторые разработчики работают на Windows).

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

Если эти сценарии версионированы, они также должны работать для всех разработчиков, чтобы каждый разработчик не писал свой собственный набор сценариев, что превращается в адское обслуживание.

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

В дополнение к ответу @ Саймона.

Не все в программной инженерии - это программирование, проектирование или моделирование. Существует множество задач, которые мы постоянно выполняем в течение рабочего дня. Вы уже упомянули один - создание проекта вне IDE - но есть еще много.

Опытные / активные разработчики, как правило, автоматизируют эти задачи. Некоторые даже создают инструменты, когда эти задачи становятся частью SDLC и они утомительны - и подвержены ошибкам - делать вручную. Программы хороши в выполнении повторяющихся работ, какими бы скучными они ни были. Мы - люди - не так хороши.

Эти инструменты / сценарии имеют другие положительные побочные эффекты

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

Итак, да, сценарии должны быть в SCM, и они должны быть еще одним инструментом в наборе инструментов разработчика.

Что касается папки, /scriptsя бы сказал, что это не имеет значения. Для простоты я оставляю их в корневом каталоге проекта, чтобы все маршруты, объявленные в сценариях, относились к папке проекта. Если мне нужен доступ к внешним папкам или файлам, я создаю программные ссылки .

Что нужно учесть, прежде чем проверять скрипты в SCM.

• В целях безопасности убедитесь, что сценарии не имеют жестко закодированных учетных данных - в идеале сценарии должны быть хорошо параметризованы -

• Убедитесь, что сценарии не делают странных вещей с системой, например, для выполнения команд, которые нельзя отменить (наиболее типичные rm -rf).

• Поскольку они становятся частью источника проекта, документация высоко ценится.

• Сценарии не ракетостроение. Сделайте сценарии краткими. Вместо того, чтобы править ими всеми ... и в темноте свяжи их , сделай больше, поменьше и лаконичнее. Как будто вы применяли SRP.

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

Однако я бы установил высокую планку для входа в сценарии. Сценарии - это код, как и само программное обеспечение. Это означает, что они должны обрабатываться аналогично другим частям кода:

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

Существует ряд дополнительных соображений, которые относятся больше к сценариям, чем к самому программному обеспечению:

• Прежде всего, гораздо сложнее убедить свою организацию и заинтересованные стороны вкладывать средства в поддержку сценариев, облегчающих жизнь разработчикам. Это означает, что труднее найти время для соответствия вышеуказанным критериям - легко написать сценарий, который работает для вас в вашей среде, но его параметризация, обеспечение стабильности, документирование требует гораздо больше времени. Это означает, что сценарии могут и станут мертвым кодом, если разработчик не сможет оправдать поддержание актуальности сценария.
• Гораздо менее вероятно, что несколько разработчиков будут достаточно знакомы со сложным сценарием для его обслуживания или что несколько разработчиков будут чувствовать себя владельцем кода. Когда оригинальный разработчик уходит, найти кого-то еще, кто может стать владельцем, может быть трудно (а найти и оправдать время, чтобы он узнал, как работает скрипт, может быть еще сложнее).
• Гораздо более вероятно, что скрипт каким-то образом будет взаимодействовать с машиной разработчика и создавать среду. Также очень вероятно, что у вас будет несколько разработчиков в разных средах. Если сценарий портит среду из-за того, что он не поддерживается должным образом или не рассматривается случайный случай, вы не просто нарушаете ночную сборку своего программного обеспечения, вы потенциально платите разработчику день или больше работы, чтобы получить их среда возвращается к нормальной жизни. Это может привести к падению крови и потере доверия.
• Поскольку сценарии часто являются внешними по отношению к самому программному обеспечению, их поддержка может быть проблемой. Если сценарии не запускаются с помощью автоматики, им легко устареть или быть забытыми, и в этот момент они превратились в мертвый код и стали просто технологическим долгом, который кому-то понадобится для очистки.

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