Открыть список
Как стать автором
Обновить

Комментарии 5

Зачем весь этот ужас с поиском исполняемого файла VS, если dotnet build можно использовать для старых проектов?


P. S. Почему просто не использовать Nuke? Он сам найдёт msbuild, есть интеграция с semver и даже можно легко накрутить логику проставления preview тегов для пакетов.

Большое спасибо за отличный вопрос!


Про портянки: здесь сложилось отсутствие в markdown оформления без переноса строк, а также моё желание "схлопнуть" весь код в с подробными комментариями в один файл (для удобства понимания).


Если открыть файл .gitlab-ci.yml в репозитории, можно убедиться, что файл без комментариев о структуре со сборкой, вызовом unit-тестов, git describe а также отправкой результатов в Telegram (упс, спойлер) занимает всего 84 строки.


Согласен, некоторые строки длинные. Тот же SonarQube требует передачи ему семи параметров с длинными мнемоническими именами (например, /d:sonar.cs.opencover.reportsPaths="$env:OPENCOVER_REPORT_FILE_PATH").


Но всё равно код достаточно простой, читаемый. И главное: его можно нарезать кусочками и добавить в любой уже рабочий Gitlab CI без подтягивания лишних зависимостей.


Теперь о Nuke: полностью с вами согласен, это отличная и динамично развивающаяся система с множеством приятных бонусов. И написана она на языке по сути нашей разработки — C#.


Почему мы её не использовали сразу? Дело в том, что для нашего проекта CI/CD создавался по моим шаблонам ещё в 2018 году, а о Nuke и его презентации на dotNext в 2017м, мы, к сожалению, услышали чуть позже.


Почему мы не переписали сборку как только узнали о Nuke? На самом деле мы не увидели явных преимуществ такого переписывания по сравнению с текущей реализацией:


  • нашим специалистам DevOps удобнее поддерживать код Powershell, чем C#,
  • существует PowerShell Gallery, в которой модно выкачать модули с очень полезными командлетами. И добавление этих модулей проще.

    Например, для того, чтобы отправлять сообщения в слак, надо:
  • один раз установить модуль командой Install-Module PSSlack
  • дописать в код проверку наличия модуля и отправку сообщений (код примерный):
    if (Get-Command "Send-SlackMessage") {
    Send-SlackMessage -Uri "$env:SLACK_URI_WEBHOOK" -Text "Сборка ветки $env:CI_COMMIT_REF_NAME.`n`nСкачать $env:CI_JOB_URL.`n`nИзменения $env:CI_PROJECT_URL/blob/$env:CI_COMMIT_REF_NAME/CHANGELOG.md""
    }

В Nuke при помощи написания своего Addon-а это также можно сделать. Но это займёт чуточку больше времени.


В этот момент мы можем свалиться в холивар "на чём удобнее писать скрипты — на C# или Powershell", поэтому я не буду продолжать эту тему)


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


Про ужас с поиском исполняемого файла VS отвечу: так Nuke точно также ищет msbuild если ему это требуется =)

И насчёт того, что у Nuke есть интеграция с semver.


Это реализовано через GitVersion. Мы пробовали его внедрить, но столкнулись с рядом неудобств. К сожалению, сейчас я уже помню каких (толи не смогли его подружить с Wix-инсталлером, толи ЭЦП у файлов слетала так как она происходила в нашем процессе раньше, чем срабатывал патч GitVersion).


Поэтому и решили остаться на текущем варианте.

И да: там важно переключить окружение в Developer Powershell не только из-за msbuild, но и чтобы другие утилиты Visual Studio стали доступны. Например, signtool для подписи файлов.

Сталкивались ли со сборкой и публикацией clickonce из гитлаба?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.