Передовая практика Jenkins Pipeline: все в отличной манере или в скрипте PowerShell - PullRequest
Новая
       7

Передовая практика Jenkins Pipeline: все в отличной манере или в скрипте PowerShell

1 голос
/ 17 июня 2019

У нас есть работа по сборке Дженкинса. Он имеет несколько шагов с PowerShell, Bat, Plungins ... звонки. Программа является приложением Windows. Я хочу изменить работу на файл конвейера, который находится в scm.

Я спрашиваю меня, какова лучшая практика: Преобразуйте все этапы сборки в скрипт Groovy конвейера или вызовите скрипт powershell (также в scm) для каждого шага. Я также хочу заменить bat-скрипты на groovy или powershell.

Ответы [ 2 ]

1 голос
/ 17 июня 2019

Просто подробно остановимся на iftimie-tudor ответ. Я хочу минимизировать вызовы внешних инструментов, таких как Jenkins или Bamboo, в нашем случае, поэтому мы включили сценарии сборки в сценарий сборки и общий сценарий. Я не буду взвешивать, следует ли вам использовать Groovy или PowerShell, так как это зависит от команды и вас. При необходимости вы можете разбить его на несколько сценариев и использовать как groovy, так и powershell. Вот как это будет выглядеть в powershell:

MyBuildScript.ps1 

[Parameter(Mandatory=$false,Position=1)]
[string] $CommonTools = '.\tools\jenkins\Common.ps1',
[Parameter(Mandatory=$false, Position=2)]
[switch] $WhatIf
# LOAD MY COMMON FUNCTIONS 
. $CommonTools
# BUILD 
## i.e MSBuild
# TEST 
## i.e NUnit
# PACK 
## i.e. OctoPack
# PUSH 

if($WhatIf) {

} else {
## i.e push to Octopus
}

Может быть полезно сделать скрипт сборки тестируемым локально.

MyBuildScript.Tests.ps1 

Import-Module .\lib\pester.x.x.x\tools\Pester.psm1 -Force

Describe "Test the Build Script" {
   It "Builds everything" { 
   }
}

Полезно также сделать тестируемые локальные инструменты обычными.

Common.Tests.ps1 

Import-Module .\lib\pester.x.x.x\tools\Pester.psm1 -Force

Describe "Test the Build Function" {
   It "Works" { 
   }
}

В идеале сценарии контролируются исходным кодом, поэтому вы можете отслеживать изменения при преобразовании каждой части сборки в filip-malczak , упомянутый в комментариях. Если кто-то нарушает сборку, он исправляет сборку. Они добавляют функцию, а она не собирается, исправьте скрипт сборки. Цикл обратной связи максимально быстро выстраивается с тестовой пирамидой . Если нужны тесты, добавьте их.

1 голос
/ 17 июня 2019

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

Итак: для трубопровода Jenkins должен быть желателен трубопровод. Я бы сделал там "оркестровку" сборки, подготовку песочницы, запуск тестовых машин и контейнеров, вызов API для внешних инструментов, таких как SONAR, Nexus, TFS, Octopus, Artifactory.

Если ваша сборка требует дополнительных шагов сборки, таких как установка вещей на компьютерах с Windows, регистрация DLL, манипуляции с IIS, powershell - мой выбор.

...