{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Богдан Стефанюк: дописи з тегом перевод", "_rss_description": "Всім привіт! Я — Богдан, фулстек розробник з Києва. Пишу в основному про програмування та штуки які вивчаю. Час від часу публікую підбірки фоток, зроблених на плівку, розказую про подорожі та цікаві речі, що оточують мене.", "_rss_language": "uk", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/stefaniuk.website\/tags\/perevod\/", "feed_url": "https:\/\/stefaniuk.website\/tags\/perevod\/json\/", "icon": "https:\/\/stefaniuk.website\/pictures\/userpic\/userpic@2x.jpg?1565716580", "authors": [ { "name": "Bohdan Stefaniuk", "url": "https:\/\/stefaniuk.website\/", "avatar": "https:\/\/stefaniuk.website\/pictures\/userpic\/userpic@2x.jpg?1565716580" } ], "items": [ { "id": "60", "url": "https:\/\/stefaniuk.website\/all\/best-practices-for-using-powershell-with-teamcity\/", "title": "Лучшие практики использования PowerShell c TeamCity", "content_html": "

Данная статья является переводом. Оригинальная статья<\/a>.<\/p>\n

Правильная обработка ошибок<\/h2>\n

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

\n\"\"\n<\/div>\n

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

\n\"\"\n<\/div>\n

Теперь все ошибки буду корректно обрабатываться и влиять на статус билда.<\/p>\n

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

    \n
  1. Завершающие (зачастую синтаксические ошибки).<\/li>\n
  2. Не завершающие.<\/li>\n<\/ol>\n

    Если возникло не завершающее исключение, то выполнение скрипта продолжится. Этот эффект может быть крайне нежелательным для сценариев, выполняющих взаимосвязанные операции, зависящие друг от друга. Конечно, мы можем изменить это поведение и превратить все «не завершающиеся» ошибки в «завершающиеся», установив переменную $ErrorActionPreference в начале наших скриптов:<\/p>\n

    #Error Action Preference:\r\n#\r\n# SilentlyContinue – error messages are suppressed and execution continues.\r\n# Stop – forces execution to stop, behaving like a terminating error.\r\n# Continue - the default option. Errors will display and execution will continue.\r\n# Inquire – prompt the user for input to see if we should proceed.\r\n# Ignore – (new in v3) – the error is ignored and not logged to the error stream. Has very restricted usage scenarios.\r\n\r\n$ErrorActionPreference = "Stop"<\/code><\/pre>
    Защита от случайных ошибок<\/h2>\n
    Для начала необходимо превратить все наши функции в настоящие командлеты. Для этого нужно определять входящие параметры с помощью блока param()<\/i> и пометить его атрибутом [CmdletBinding()]<\/i>:<\/p>\n
    function Verb-Noun {\r\n    [CmdletBinding()]\r\n    param (\r\n     #parameters go here   \r\n    )    \r\n}<\/code><\/pre>
    Этот атрибут защищает вызов метода с не определенными параметрами. Каждый раз как кто-то использует не определенный\/удаленный параметр или делает ошибку в его названии, PowerShell выбросит ошибку. Если метод не помечен атрибутов, имена параметров не проверяются, что затрудняет обнаружение проблемы.<\/p>\n
    Также можно обнаружить потенциальные ошибки, вызванные нарушением лучших практик и правил кодирования, включив строгий режим. Чтобы сделать это, добавьте следующий код в начале вашего скрипта:<\/p>\n
    Set-StrictMode -Version Latest<\/code><\/pre>
    Детальнее можно почитать тут<\/a>.<\/p>\n
    Вообще советую использовать VS Core и плагином PowerShell. Он превращает вашу в IDE в аналог PowerShell ISE. Также этот плагин поставляется с PSScriptAnalyzer, что позволяет обнаруживать разные ошибки.<\/p>\n
    Использование скриптов<\/h2>\n
    Teamcity дает возможность запускать скрипты не только из файла, но и из встроенного редактора. Но лучшей практикой считается использование файлов. Это позволит держать скрипты в системе контроля версий, вместе с вашим проектом.<\/p>\n
    Всегда помните о чистом коде.<\/h2>\n
    Ваши скрипты как и код вашего проекта должен лежать в системе контроля версий, покрыт тестами и пройти ревью. Здесь<\/a> вы можете найти лучшие практики и стили кодирования для PowerShell. Для тестирования кода можете использовать — Pester<\/a>.<\/p>\n
    Итог<\/h2>\n
    Связка PowerShell и Teamcity позволяет создать действительно мощный CI\/CD. Но без понимания базовых принципов и механизмов вы не достигните максимального профита. Настройки по умолчанию часто могут приводить к непредвиденным ошибкам.<\/p>\n
    Ссылки<\/h2>\n
      \n
    1. Практики и стили кодирования для PowerShell скриптов.<\/a><\/li>\n
    2. ((https:\/\/github.com\/pester\/Pester<\/a> Pester — тест и мок фреймворк для PowerShell.)<\/li>\n
    3. PowerShell strict mode<\/a>.<\/li>\n<\/ol>\n",
            "date_published": "2019-05-12T13:57:44-04:00",
            "date_modified": "2020-12-26T16:42:06-04:00",
            "tags": [
                "powershell",
                "перевод"
            ],
            "image": "https:\/\/stefaniuk.website\/pictures\/error_handling_for_ps.jpg",
            "_date_published_rfc2822": "Sun, 12 May 2019 13:57:44 -0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "60",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/stefaniuk.website\/pictures\/error_handling_for_ps.jpg",
                    "https:\/\/stefaniuk.website\/pictures\/teamcity_failure_condition.jpg"
                ]
            }
        },
        {
            "id": "4",
            "url": "https:\/\/stefaniuk.website\/all\/debug-vs-release-builds-when-debbuging\/",
            "title": "C# Debug vs Release. Сборки и дебаг",
            "content_html": "
      Оригинальная статья: тык<\/a>.<\/p>\n
      Из коробки в C# нам доступны 2 способа сборки проекта release и debug.<\/p>\n
      О компиляции C# кода<\/h2>\n
      Исходный код C # проходит через 2 этапа компиляции, чтобы стать инструкциями CPU, которые могут быть выполнены.<\/p>\n
      \n\"\"\n<\/div>\n
      Обычно первый этап происходит на вашем CI сервере, а второй шаг происходит позже, во время работы самого приложения. Когда же мы работаем локально в Visual Studio, то она все эти шаги выполняет перед запуском приложения из меню Debug.<\/p>\n
      Шаг первый. Компиляция приложения<\/b>
      \nВаш код превращается в Common Intermediate Language (CIL), который уже может быть выполнен в любом окружении, которое поддерживает CIL. Обратите внимание, что собранная сборка не является читаемым текстом IL, а фактически метаданными и байтовым кодом в виде двоичных данных.<\/p>\n
      На данном шаге будет выполнена некоторая оптимизация кода (будет описано дальше).<\/p>\n
      Шаг второй. JIT компилятор<\/b>
      \nJIT компилятор конвертирует IL код в инструкции процессора, которые можно выполнить на вашей машине. Однако не вся компиляция происходит заранее — в нормальном режиме, код компилируется, только тогда когда его вызывают в первый раз, после чего он кэшируется.<\/p>\n
      Компилятор JIT — это всего лишь один из целого ряда сервисов, которые составляют Common Language Runtime (CLR), позволяя ему выполнять код .NET.<\/p>\n
      Основная часть оптимизации кода будет проведена на этом шаге.<\/p>\n
      Что такое оптимизация кода в одном предложении?<\/h2>\n
      Это процесс улучшения таких факторов, как скорость выполнения, размер кода, энергопотребление, а в случае .NET — время, которое требуется для компилятора JIT — без изменения функциональности.<\/p>\n
      Почему мы заинтересованы в оптимизации в этой статье?<\/h2>\n
      На обоих этапах компиляции ваш код будет оптимизирован компиляторами. Одно из ключевых различий между конфигурациями сборки Debug и Release заключается в том, отключены ли оптимизации или нет, поэтому нам нужно понять последствия данных оптимизации.<\/p>\n
      Оптимизация компилятора C#<\/h2>\n
      C# компилятор на самом деле делает очень мало оптимизаций. На самом деле большенство оптимизаций производит JIT компилятор во время генерирования машинного кода. Тем не менее это все равно ухудшит работу по отладке.<\/p>\n
      Инструкция nop в IL<\/b>
      \nКоманда nop имеет ряд применений при программировании на низком уровне, например, для включения небольших предсказуемых задержек или инструкции по перезаписи, которые вы хотите удалить. В IL коде данные конструкции помогают при использовании точек останова (breakpoints) для того чтобы они вели себя предсказуемо.<\/p>\n
      Если мы посмотрим на IL код, который сгенерирован с отключенными оптимизациями:<\/p>\n
      \n\"\"\n<\/div>\n
      Эта инструкция мапиться с фигурной скобкой, для того чтобы мы могли поставить на нее точку остановки:<\/p>\n
      \n\"\"\n<\/div>\n
      Даная инструкция была бы удалена если у нас включены оптимизации, что повлияло бы на отладку приложения.<\/p>\n
      Более подробное обсуждение оптимизаций компилятора C#  в статье Эрика Липперта: Что делает переключатель оптимизации?<\/a>. Существует также хороший комментарий о IL до и после оптимизации здесь<\/a>.<\/p>\n
      Оптимизация JIT компилятора<\/h2>\n
      Несмотря на то, что он быстро выполняет свою работу во время выполнения, компилятор JIT также выполняет множество оптимизаций. О его внутренних деталях мало информации. Даже во время работы вашего приложения он производит профилирование и, возможно, перекомпилирование кода для повышения производительности.
      \nХорошие примеры оптимизации с помощью JIT компилятора можете посмотреть       здесь<\/a>.<\/p>\n
      Я рассмотрю один пример, чтобы проиллюстрировать влияние оптимизации на отладку.
      \nВстраивание методов<\/b><\/p>\n
      Для реальной оптимизации, сделанной компилятором JIT, я буду показывать инструкции по сборке. Это всего лишь макет на C #, чтобы дать вам общую идею.<\/p>\n
      Предположим, что у меня есть:<\/p>\n
      private long Add(int a, int b)\r\n{\r\n    return a + b;\r\n}\r\npublic void MethodA()\r\n{\r\n    var r = Add(a, b);\r\n}<\/code><\/pre>
      Компилятор JIT, скорее всего, выполнит встроенное расширение. Он заменит вызов метода Add() телом данного метода:<\/p>\n
      public void MethodA()\r\n{\r\n    var r = a + b;\r\n}<\/code><\/pre>
      Конфигурации сборки по умолчанию<\/h2>\n
      Итак, теперь, когда мы обновили понимание компиляции .NET и двух «слоев» оптимизации, давайте взглянем на 2 конфигурации сборки, доступные «из коробки»:<\/p>\n
      \n\"\"\n<\/div>\n
      Довольно просто — релиз полностью оптимизирован, отладка совсем отсутствует, что, как вы сейчас знаете, имеет фундаментальное значение для того, насколько легко отлаживать ваш код. Но это просто поверхностное представление о возможностях аргументов отладки и оптимизации.<\/p>\n
      Внутренности аргументов оптимизации и отладки<\/h2>\n
      Я попытался продемонстрировать данные аргументы из кода Roslyn и mscorlib. Теперь мы имеем следующие классы:<\/p>\n
        \n
      1. CSharpCommandLineParser<\/a><\/li>\n
      2. CodeGenerator<\/a><\/li>\n
      3. ILEmitStyle<\/a><\/li>\n
      4. debuggerattributes<\/a><\/li>\n
      5. Optimizer<\/a><\/li>\n
      6. OptimizationLevel<\/a><\/li>\n<\/ol>\n
        Синие элементы обозначаю аргументы командной строки, а зеленые их представление в коде.<\/p>\n
        \n\"\"\n<\/div>\n
        Перечисление OptimizationLevel<\/h2>\n
        OptimizationLevel.Debug<\/b> отключает все оптимизации для C# и JIT компилятора с помощью DebuggableAttribute.DebuggingModes, который с помощью ildasm, мы можем видеть:<\/p>\n
        \n\"\"\n<\/div>\n
        OptimizationLevel.Release<\/b> включает все оптимизации (DebuggableAttribute.DebuggingModes = ( 01 00 02 00 00 00 00 00 )) что в свою очередь соответсвует DebuggingModes.IgnoreSymbolStoreSequencePoints<\/p>\n
        При этом уровне оптимизации точки останова могут быть оптимизированы. Что приведет к тому что мы не сможем их поставить и остановиться.<\/p>\n
        Типы IL<\/h2>\n
        Типы IL кода описаны в классе ILEmitStyle<\/a>.<\/p>\n
        На диаграмме выше показано, что тип генерируемого IL кода C# компилятором зависит от OptimizationLevel.
        \nАргумент debug<\/i> не меняет его, за исключение аргумента debug+<\/i> когда OptimizationLevel установлен в Release.<\/p>\n