Данная статья является переводом. Оригинальная статья.

Правильная обработка ошибок

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

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

Теперь все ошибки буду корректно обрабатываться и влиять на статус билда.

Также надо понимать модель ошибок в PowerShell. Они могут поделятся на 2 группы:

1. Завершающие (зачастую синтаксические ошибки).
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. Но без понимания базовых принципов и механизмов вы не достигните максимального профита. Настройки по умолчанию часто могут приводить к непредвиденным ошибкам.

Ссылки

1. Практики и стили кодирования для PowerShell скриптов.
2. ((https://github.com/pester/Pester Pester — тест и мок фреймворк для PowerShell.)
3. PowerShell strict mode.