Руководство по сценариям и автоматизации оболочки

Question

В настоящее время я работаю над некоторыми сценариями, которые автоматизируют множество вещей и имеют довольно средний размер.Я начал следовать определенным вещам, чтобы сделать мои сценарии общими и переносимыми, например:

• логин администратора для планирования сценариев
• использование абсолютных путей
• использование файлов конфигурации
• использовать write-host при разработке и переключаться на ведение журнала при развертывании (отладке)

Мне было бы очень интересно узнать, существуют ли какие-либо стандартные методы и рекомендации по написанию сценариев, которые нацеленысделать жизнь разработчиков сценариев простой.Я работаю как с Perl, так и с PowerShell, поэтому более обобщенный совет был бы весьма желателен и оценен.

Спасибо за любую помощь заранее.
steeluser

Answer 1

Это довольно широко, и я уверен, что субъективно. Тем не менее, я выполнил некоторые скриптовые работы и могу предложить кое-что, чему я научился из опыта.

1. Сделайте ваши скрипты управляемыми данными. Жесткий код как можно меньше вещей. Все вещи, такие как пути, расположение ресурсов и т. Д. Должны изменяться из файла конфигурации, а не путем редактирования основного скрипта. Это связано с вашей точкой зрения об абсолютных путях. Жесткое кодирование всех путей это нет, нет. Создание всего относительного накладывает слишком много ограничений. Было бы неплохо иметь одну переменную с именем, например, DATA_ROOT, которую вы можете изменить, а затем все подпрограммы ссылаются на такие вещи, как ${DATA_ROOT}/resources/images и т. Д. Также будет полезен $ {PROGRAM_ROOT}, чтобы вы могли иметь несколько установок вашего пакета для тестирования и т. д.
2. Ошибка проверки. Языки сценариев часто динамически набираются, поэтому обязательно проверяйте возвращаемое значение для каждой вещи, которую вы делаете. Возможно, даже имеет смысл создать библиотеку, с помощью которой вы можете делать такие вещи, как call_safely(fn, arg0, arg1,.. ) и call_and_abort_on_failure(fn, arg0, arg1,...).
3. Комментарий и документ свободно. Скрипты легче модифицировать скомпилированными программами, поэтому они часто исправляются неправильно, когда люди хотят их расширять. Убедитесь, что ваши API хорошо документированы, поэтому, когда люди хотят, например, добавить новый параметр командной строки, они знают, как это сделать, а не пишут скрипт-оболочку поверх вашего.
4. Сделайте так, чтобы один скрипт делал одно, и пишите агрегаторы, если вам нужно. сценарии с if(FLAG) {do_something} else {do_something_completely_different} убьют вас. Сделайте так, чтобы ваши скрипты делали одно, и делали это хорошо, и, если хотите, вы можете написать оболочки, которые делегируют эти скрипты по мере необходимости (для лучшего взаимодействия с пользователем).
5. Используйте инструменты сторонних производителей свободно, а не изобретайте свои собственные. Разбор командной строки, обработка текста и т. Д. - все это старые области, и есть много библиотек, которые делают это хорошо. Используйте их, а не переопределять. Самая безглючная программа - та, которая никогда не написана.
6. Сделайте ваши каркасы логирования и тестирования надежными. Когда случается что-то плохое, вы должны знать все без перезапуска сценариев. Используйте некоторую стандартную структуру ведения журнала с первого дня и сделайте ее настраиваемой из файла, который может быть перезагружен по требованию. Убедитесь, что ваш код протестирован модульно, чтобы при внесении новых изменений ошибки регрессии не появлялись. Кроме того, регистрируйте метрики синхронизации, чтобы вы со временем знали, где замедляются ваши сценарии. Это будет полезно в будущем.
7. Сделайте ваши скрипты как можно более бесплатными. Это сложно описать, но я могу привести пример. У меня было несколько скриптов для отслеживания различных метрик в сборках для разных веток и их переноса в каталог. Я написал это так, что если вы хотите, чтобы отслеживалась ветка foo, все, что вам нужно было сделать, это создать каталог с именем foo в определенном месте, и он бы это отслеживал. Вам не нужно было возиться с большим количеством вещей, и менеджеры, которые на самом деле хотели отслеживать метрики, могли создавать каталоги так, как им это нужно.

Это те моменты, о которых я могу подумать с макушки головы.

Answer 2

только несколько практик, которые я считаю хорошими :

• Использование абсолютных путей - это нормально, если вы ловите их во время выполнения.См. Этот вопрос .
• Используйте для файлов конфигурации некоторый легко обрабатываемый формат, такой как xml или yaml .
• НЕ делайтеиспользуйте write-host, используйте лучше write-output или write-log или, лучше, реализуйте пользовательскую функцию, которая позволяет переключаться между консолью / журналом в соответствии с настройкой в ​​ваших файлах конфигурации.См. Мой ответ на этот вопрос для получения более подробной информации.

Это всего лишь несколько предложений, основанных на ваших баллах.

---

РЕДАКТИРОВАТЬ Примечание о принятии XML-файла конфигурации

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

---

Надеюсь, что этоhelp

Cheers