devops
Лучшие практики использования PowerShell c TeamCity
Данная статья является переводом. Оригинальная статья.
Правильная обработка ошибок
Наиболее распространенная проблема заключается в том, что TeamCity игнорирует ошибки Powershell, по крайней мере, в конфигурации по умолчанию. Если шаг со сценарием PowerShell завершится неудачно, TeamCity по-прежнему считает билд успешным. Это может привести к серьезным ошибкам, которые могут быть незаметны длительное время. Это происходит потому что значение настройки Format stderr output as установлено в warning. Для того чтобы TeamCity видел ошибки, необходимо переключить настройку в error.

Но это еще не все. Может возникнуть ситуация что шаг PowerShell упал но весь пайплайн признан успешным. Для этого нужно перейти в раздел Failure Conditions и установить флаг error message is logged by build runner.

Теперь все ошибки буду корректно обрабатываться и влиять на статус билда.
Также надо понимать модель ошибок в PowerShell. Они могут поделятся на 2 группы:
- Завершающие (зачастую синтаксические ошибки).
- Не завершающие.
Если возникло не завершающее исключение, то выполнение скрипта продолжится. Этот эффект может быть крайне нежелательным для сценариев, выполняющих взаимосвязанные операции, зависящие друг от друга. Конечно, мы можем изменить это поведение и превратить все «не завершающиеся» ошибки в «завершающиеся», установив переменную $ErrorActionPreference в начале наших скриптов:
#Error Action Preference:
#
# SilentlyContinue – error messages are suppressed and execution continues.
# Stop – forces execution to stop, behaving like a terminating error.
# Continue - the default option. Errors will display and execution will continue.
# Inquire – prompt the user for input to see if we should proceed.
# Ignore – (new in v3) – the error is ignored and not logged to the error stream. Has very restricted usage scenarios.
$ErrorActionPreference = "Stop"
Защита от случайных ошибок
Для начала необходимо превратить все наши функции в настоящие командлеты. Для этого нужно определять входящие параметры с помощью блока param() и пометить его атрибутом [CmdletBinding()]:
function Verb-Noun {
[CmdletBinding()]
param (
#parameters go here
)
}
Этот атрибут защищает вызов метода с не определенными параметрами. Каждый раз как кто-то использует не определенный/удаленный параметр или делает ошибку в его названии, PowerShell выбросит ошибку. Если метод не помечен атрибутов, имена параметров не проверяются, что затрудняет обнаружение проблемы.
Также можно обнаружить потенциальные ошибки, вызванные нарушением лучших практик и правил кодирования, включив строгий режим. Чтобы сделать это, добавьте следующий код в начале вашего скрипта:
Set-StrictMode -Version Latest
Детальнее можно почитать тут.
Вообще советую использовать VS Core и плагином PowerShell. Он превращает вашу в IDE в аналог PowerShell ISE. Также этот плагин поставляется с PSScriptAnalyzer, что позволяет обнаруживать разные ошибки.
Использование скриптов
Teamcity дает возможность запускать скрипты не только из файла, но и из встроенного редактора. Но лучшей практикой считается использование файлов. Это позволит держать скрипты в системе контроля версий, вместе с вашим проектом.
Всегда помните о чистом коде.
Ваши скрипты как и код вашего проекта должен лежать в системе контроля версий, покрыт тестами и пройти ревью. Здесь вы можете найти лучшие практики и стили кодирования для PowerShell. Для тестирования кода можете использовать — Pester.
Итог
Связка PowerShell и Teamcity позволяет создать действительно мощный CI/CD. Но без понимания базовых принципов и механизмов вы не достигните максимального профита. Настройки по умолчанию часто могут приводить к непредвиденным ошибкам.
Ссылки
- Практики и стили кодирования для PowerShell скриптов.
- ((https://github.com/pester/Pester Pester — тест и мок фреймворк для PowerShell.)
- PowerShell strict mode.