Mga Reusable PowerShell Module na may Pester: Isang Kumpletong Gabay

Kung araw-araw kang gumagamit ng PowerShell, maya-maya ay mapapagod ka rin sa paulit-ulit na pagkopya at pag-paste ng parehong mga function. Doon talaga makatuwiran na pag-usapan ang mga magagamit muli na PowerShell module at kung paano seryosong subukan ang mga ito gamit ang Pester , tulad ng gagawin mo sa anumang "seryosong" proyekto sa pag-develop.

Bagama't isinilang ang PowerShell bilang isang kasangkapan para sa mga administrador, ngayon ito ay isang kumpletong wika ng automation, cross-platform at may napakalaking ecosystem : mga module, advanced scripting, automated testing, CI/CD… at kung alam mo kung paano i-package ang iyong mga function sa mga mahusay na binuong module na sakop ng Pester, maaari kang mag-version, magbahagi, mag-publish sa PowerShell Gallery at mag-deploy nang may kumpiyansa nang hindi nagpapawis sa tuwing nagpapalit ka ng linya.

Ano nga ba ang PowerShell module at paano ito naiiba sa isang script?

Ang isang PowerShell module ay, sa madaling salita, isang pakete ng mga magagamit muli na utos : mga function, cmdlet, alias, variable, klase, o mga DSC resource . Ang nagpapaespesyal sa isang module ay ang kakayahan ng PowerShell na i-load at i-unload ito, kontrolin kung ano ang ipinapakita sa user, magtalaga dito ng bersyon, awtor, mga dependency, at iba pa.

Mula sa perspektibo ng isang file, ang isang tipikal na module ay binubuo ng kahit isang .psm1 file (code) at, halos palaging, isang .psd1 manifest file na naglalaman ng metadata . Maaari rin itong magsama ng iba pang mga script, resources, help files, data, atbp. Kapag na-import gamit ang Import-Module o sa pamamagitan ng awtomatikong paglo-load, ang mga command nito ay magiging available na parang native ang mga ito.

Sa kabaligtaran, ang isang PowerShell script ay isang .ps1 file lamang na tumatakbo nang "lahat nang sabay-sabay ." Maaari itong maglaman ng mga function, ngunit ang mga function na ito ay karaniwang nasa loob ng saklaw ng script. Kung hindi ka gumagamit ng dot-sources o isinasama ang mga ito sa isang module, nawawala ang mga ito sa sandaling matapos ang pagpapatupad.

Malaki ang praktikal na pagkakaiba: ang mga script ay karaniwang "mga gawaing inilulunsad ," habang ang mga module ay "mga muling magagamit na library" na maaari mong gamitin mula sa ibang mga script, mula sa console, o kahit mula sa mga CI/CD pipeline nang hindi dinoble ang code.

Mga script vs mga module: kailan gagamitin ang bawat isa

Ang isang script (.ps1) ay mainam kapag kailangan mong magsagawa ng mga partikular na gawain: isang backup , isang ulat, isang naka-iskedyul na paglilinis, atbp. Patakbuhin mo ito, gagawin nito ang trabaho nito, at matatapos ito. Kung magtatakda ka ng mga function sa loob ng script na iyon, ang mga function na iyon ay mananatili sa saklaw ng script ; kapag natapos na ito, ang saklaw ay itatapon, at kasama nito, ang iyong mga function.

Sa kabilang banda, ang script module (.psm1) ay dinisenyo upang isama ang mga function na magagamit mo muli nang maraming beses, sa iba't ibang makina, at maging sa iba't ibang proyekto. Sa pamamagitan ng pag-save sa mga ito sa isang module, ikinakarga ang mga ito sa isang module scope, at maaari mo lamang i-export ang kailangan mo bilang isang pampublikong API.

Maraming admin ang nagsisimula sa isang napakalaking script na gumagawa ng lahat, at sa paglipas ng panahon , napagtanto nila na palagi nilang ibinabahagi ang mga bahagi ng code na iyon. Ang natural na susunod na hakbang ay ang pagkuha ng mga paulit-ulit na function na iyon sa isang module , subukan ang mga ito gamit ang Pester, at pagkatapos ay gamitin ang module na iyon bilang pundasyon para sa mas maliliit at mas malinis na mga script.

Bukod pa rito, ang mga module ay nagbibigay-daan sa isang bagay na mahalaga para sa mga koponan: pag-bersyon, pag-publish, at pamamahagi . Maaari kang mag-install ng mga module mula sa PowerShell Gallery, mula sa mga pribadong repositoryo, mula sa mga lokal na repositoryo, o kahit na i-embed ang mga ito sa mga system image upang maging available ang mga ito bilang default.

Dot-sourcing: ang "mabilis na trick" bago lumipat sa mga module

Bago mo ilagay ang iyong mga function sa isang module, maaaring nasa isang simpleng .ps1 script ang mga ito na gusto mong gamitin muli . Kung ganoon, ang tanging disenteng paraan para magamit ang mga ito sa iyong session ay ang paggamit ng dot-sourcing.

Kapag nagpatakbo ka ng script gamit ang `.MyScript.ps1` , ang nilalaman ay pinoproseso sa loob ng saklaw ng script. Kung may mga function sa file na iyon, nawawala ang mga ito kapag natapos na ang script. Gayunpaman, kung gagamitin mo ito gamit ang tuldok at espasyo (dot-sourcing) , isasagawa ito ng PowerShell sa pandaigdigang saklaw, at ang mga function ay nilo-load.

Mga halimbawa ng dot-sourcing para mag-load ng mga function sa memorya:

• Mag-load gamit ang relatibong landas: . .\Get-MrPSVersion.ps1
• Magkarga nang may buong ruta: . C:\Demo\Get-MrPSVersion.ps1
• Mag-load gamit ang variable ng path: $Path = 'C:\'; . $Path\Get-MrPSVersion.ps1

Pagkatapos ng dot-sourcing, maaari mong i-verify na umiiral ang function sa unit Tungkulin: na may Get-ChildItem -Path Function:\Get-MrPSVersionBilang ngayon ay bahagi na ito ng pandaigdigang saklaw.

Ang problema ay hindi maayos na nasusukat ang pamamaraang ito: kailangan mong tandaan na gumawa ng dot-sourcing, wala kang version control, wala kang manifest, at walang pagkakaiba sa pagitan ng public at private . Isa itong kapaki-pakinabang na shortcut, ngunit para sa isang bagay na seryoso at maibabahagi, mas mainam na tumalon sa mga script module.

Paglikha ng mga script module at awtomatikong paglo-load

Sa PowerShell, ang isang script module ay diretso lamang: Ito ay isang .psm1 file na naglalaman ng iyong mga functionHalimbawa, kung gagawa ka ng isang file MyScriptModule.psm1 na may katulad na:

function Get-MrPSVersion { $PSVersionTable }
function Get-MrComputerName { $env:COMPUTERNAME }

at pagkatapos ay susubukan mong gamitin Get-MrComputerName, makikita mo yan Hindi ito matatagpuan hangga't hindi mo na-import ang moduleMaaari mo itong gawin nang manu-mano gamit ang:

Import-Module C:\MyScriptModule.psm1

Ipinakilala ng PowerShell 3 ang mahika ng mga autoloading module . Para gumana ito, kailangan mong:

• I-save ang iyong module sa isang folder na ang base name ay tumutugma sa module, halimbawa MyScriptModule\MyScriptModule.psm1.
• Ilagay ang folder na iyon sa ilang landas ng $env:PSModulePath.

Ang halaga ng $env:PSModulePath ay isang listahan ng mga path na pinaghihiwalay ng semicolon . Maaari mo itong tingnan sa format na nababasa ng tao gamit ang:

$env:PSModulePath -split ';'

Kasama sa mga karaniwang path ang modules folder ng user, ang global modules folder sa Program Files , at ang system module folder sa System32 . Karaniwang kasanayan ang pag-install ng sarili mong mga module sa "AllUsers" (Program Files) path at ireserba ang System32 folder para lamang sa mga system module.

Kapag nailagay na ang module, kapag ginamit mo ang isa sa mga command nito sa unang pagkakataon, awtomatikong ilo-load ito ng PowerShell nang hindi na kailangang manu-manong tawagin ang Import-Module, na napaka-maginhawa sa mga script at interactive session.

Mga manifest ng module: metadata, bersyon, at pag-export ng function

Para maging maayos ang pagkakatukoy ng isang module, hindi sapat ang .psm1 file: kailangan nito ng .psd1 manifest , na isa lamang PowerShell data file na may metadata ng module (pangalan, bersyon, awtor, deskripsyon, mga dependency, mga na-export na function, atbp.).

Ang karaniwang paraan para gawin ito ay ang paggamit ng New-ModuleManifest , na ipinapasa ang kahit man lang path papunta sa .psd1 file at ang RootModule parameter na nakaturo sa .psm1 file. Bukod pa rito, kung plano mong i-publish ang module sa isang repository tulad ng PowerShell Gallery, kinakailangan ang mga field tulad ng Author, Description, at CompanyName.

Isang palatandaan na ang iyong module ay may kulang na manifest ay ang pagsuri sa bersyon nito gamit ang Get-Module -Name MyScriptModule at makita ang a bersyon numero 0.0, isang malinaw na sintomas na mayroon lamang isang maluwag na .psm1 file na walang nauugnay na .psd1 file.

Ang isang karaniwang padron para sa pagbuo ng isang manifesto ay magiging ganito ang hitsura:

$moduleManifestParams = @{
Path = "$env:ProgramFiles\WindowsPowerShell\Modules\MyScriptModule\MyScriptModule.psd1"
RootModule = 'MyScriptModule'
Author = 'Autor del módulo'
Description = 'Funciones reutilizables para administración'
CompanyName = 'MiEmpresa'
}
New-ModuleManifest @moduleManifestParams

Sa susunod, kung kailangan mong baguhin ang anumang datos, sa halip na muling likhain ang manifest (na bubuo ng isang bagong GUID at maaaring masira ang mga dependency ), ang tamang gawin ay gamitin ang Update-ModuleManifest upang baguhin lamang ang kinakailangan.

Kasama rin sa manifest ang mga pangunahing seksyon tulad ng FunctionsToExport , kung saan maaari mong ilista nang eksakto kung aling mga function ng module ang nakalantad sa user, na iniiwan ang iba bilang mga pribadong function na panloob ng module.

Mga pampubliko at pribadong tungkulin sa iyong mga modyul

Sa isang totoong modyul, hindi mo gugustuhing ilantad ang lahat. Normal lang na magkaroon ng mga internal helper function na ginagamit lang ng isa't isa at ayaw mong direktang tumawag ang mga user. May dalawang pangunahing paraan para kontrolin kung ano ang lumalabas sa "labas":

Kung wala kang manifest (isang simpleng module na may .psm1 lamang), maaari mong kontrolin ang visibility gamit ang Export-ModuleMember sa loob mismo ng .psm1 file. Halimbawa:

function Get-MrPSVersion { $PSVersionTable }
function Get-MrComputerName { $env:COMPUTERNAME }
Export-ModuleMember -Function Get-MrPSVersion

Sa ganitong kaso, tanging ang Get-MrPSVersion ang makikita bilang isang module command , habang ang Get-MrComputerName ay maa-access pa rin mula sa iba pang mga function ng module ngunit hindi ito ie-export sa publiko . Maaari mong suriin kung aling mga command ang naka-expose gamit ang:

Get-Command -Module MyScriptModule

Kung mayroon kang manifest, ang pinakamalinis na paraan ay tukuyin ang listahang iyon sa FunctionsToExport key ng .psd1 file, halimbawa:

FunctionsToExport = 'Get-MrPSVersion'

Hindi na kailangang doblehin ang lohika gamit ang parehong Export-ModuleMember sa .psm1 at FunctionsToExport sa .psd1 ; sapat na ang isa sa dalawang mekanismo. Ang manifest-based na pamamaraan ay karaniwang mas malinaw sa katagalan.

PowerShell Gallery, mga kinakailangan at paglalathala ng mga module at script

La Gallery ng PowerShell Ito ang pangunahing pampublikong imbakan para sa mga module at script. Mula doon, i-install mo ang mga dependency gamit ang Install-Module, mag-update ka gamit ang Update-Module at inilalathala mo ang sarili mong mga pakete gamit ang Publish-Module o Publish-Script.

Para makapaglathala ng isang modyul, may ilang minimum na kinakailangan na dapat mong malaman: isang natatanging pangalan, isang semantikong bersyon, isang tamang manifest, kumpletong pangunahing metadata, at, kung gagamit ka ng mga dependency, na magagamit din ang mga ito. Gayundin, ang mga script na gusto mong i-publish bilang ganito ay nangangailangan ng header na may metadata sa format ng script file (may-akda, paglalarawan, bersyon, atbp.).

Ang koneksyon sa pagitan ng PowerShellGet, Pamamahala ng Package at NuGet Ganito halos ang paggana nito: Ang PowerShellGet ay ang module na gagamitin mo (Install-Module, Publish-Module…), ang PackageManagement ay ang generic package management layer, at sa ilalim ng lahat ng ito, para sa Gallery, gagamitin mo NuGet bilang isang tagapagbigay ng serbisyoIbig sabihin, kahit na ang backend ay NuGet, hindi ito pareho ang paggamit nuget.exe na gumagamit ka ng PowerShellGet; para sa karamihan ng mga gawain sa module ng PowerShell, palagi mong gagamitin ang mga cmdlet ng PowerShellGet.

Para mailathala, kailangan mo ng Susi ng API ng NuGet (NUGET_KEY) na ginagamit bilang isang kredensyal. Sa mga kapaligirang CI/CD, ito ay iniimbak bilang isang sikreto at inilalantad sa oras ng pagbuo upang maisagawa ang isang Publish-Module -NuGetApiKey. Maaari mo rin mag-angkin ng pagmamay-ari ng isang pakete, mga pangalan ng reserba, o mag-ulat ng mga paglabag sa lisensya direkta sa Gallery, kasunod ng mga daloy ng suporta nito.

Ano ang Pester at bakit mo ito dapat gamitin sa iyong mga module?

Ang Pester ay ang karaniwang unit at integration testing framework para sa PowerShell . Ito ay isang PowerShell module na tumutukoy sa isang madaling basahin na testing language batay sa mga block tulad ng Describe, Context, It, BeforeAll, AfterAll , at mga assertion tulad ng Should-Be, Shouldn-Not-Be , atbp.

Ang layunin ni Pester ay pahintulutan kang magpatakbo ng isang hanay ng mga awtomatikong pagsubok sa bawat oras na babaguhin mo ang iyong code, tinitiyak na patuloy mong nakakamit ang inaasahang pag-uugali. Pinipigilan nito ang maraming karaniwang mga patibong: pag-aayos ng isang bagay sa produksyon ngunit may nasisira pang iba sa proseso, o ang pagkakaroon ng pagbabago sa pagpapatotoo sa isang malaking proyekto na hindi inaasahang makakasira sa kalahati ng platform.

Sa pagsasagawa, pinapayagan ka ng Pester na masakop ang parehong mga unit test (mga nakahiwalay na function, na may mga mock kung kinakailangan) at mga integration test (ang iyong module ay nakikipag-ugnayan sa SharePoint , Azure, SQL, atbp.). Para sa maraming organisasyon, ang pagkakaroon ng mga pagsubok gamit ang Pester ay isang minimum na pamantayan ng kalidad , kahit na para sa mga "simpleng" administrative script.

Bukod sa mga assertion, nag-aalok ang Pester ng logical test grouping, external command mocking, at code coverage measurement , na nagbibigay sa iyo ng maraming visibility kung aling mga bahagi ng modyul ang sakop at alin ang hindi.

Pag-install at pangunahing paggamit ng Pester na may mga module

Ang mga modernong bersyon ng Windows ay kadalasang may kasamang mas lumang bersyon ng Pester (v3) na naka-install na . Ang karaniwang gawain ngayon ay ang pag-install ng na-update na bersyon mula sa Gallery gamit ang:

Install-Module -Name Pester -Force

Gumagana ang Pester sa Windows, Linux , at macOS at tugma sa PowerShell 3, 4, 5, 6, at 7, kaya wala kang magiging problema sa magkahalong kapaligiran. Kapag na-install na, ang kailangan mo lang gawin ay gumawa ng mga test file na may hulaping .Tests.ps1 o .Test.ps1 na naglalarawan sa gawi ng iyong mga module.

Ang karaniwang istruktura ng isang test file ay kinabibilangan ng mga bloke tulad ng:

• Bago ang LahatIto ay isinasagawa nang isang beses bago ang lahat ng mga pagsubok (mainam para sa pag-import ng modyul o pagtukoy ng mga karaniwang datos).
• Ilarawan: nagpapangkat ng mga pagsubok para sa isang tungkulin o larangan ng tungkulin.
• Kaugnay na kahulugan: hinahati ang mga senaryo (“kapag tama ang mga parameter”, “kapag may error sa kredensyal”…).
• ItAng bawat bloke ng It ay isang indibidwal na patunay kasama ang hanay ng mga assertion gamit ang Dapat.
• Pagkatapos ng lahat: paglilinis sa dulo ng lahat ng pagsubok (pagsasara ng mga koneksyon, pagbura ng mga pansamantalang file, atbp.).

Para patakbuhin ang mga pagsubok, tawagan lamang ang Invoke-Pester na nakaturo sa tests file o folder, at makakakuha ka ng buod ng bilang ng mga matagumpay at nabigong assertion, kasama ang oras ng pagpapatupad at, kung gusto mo, detalyadong output gamit ang -Output Detailed.

Praktikal na halimbawa: pagsubok sa isang function ng pag-login gamit ang Pester

Isipin ang isang function ng PowerShell na tinatawag na LoginSP na sumasaklaw sa pag-log in sa SharePoint Online gamit ang Plug and Play o CSOM, at nagbabalik ng konteksto ng SharePoint. Ang function na ito ay nasa iyong module o sa isang .ps1 file na ginagamit mo sa maraming automation script.

Kung dose-dosenang mga tungkulin ng negosyo ang nakasalalay dito, Hindi mo kayang bayaran ang pagbabago sa implementasyon (halimbawa, ang paglipat mula sa PnP patungong CSOM) para masira ang lahat.Ang makatwirang gawin ay ang pagsulat ng mga unit test gamit ang Pester sa isang file LoginSharePoint.Test.ps1 o katulad.

Sa test file na iyon, sa BeforeAll block , karaniwan mong nilalagay ang dot-source o ini-import ang module gamit ang LoginSP function. Pagkatapos, gagawa ka ng isa o higit pang Describe "Testing LoginSP" blocks at sa loob ng mga ito ay may mga konteksto para sa iba't ibang senaryo: tamang parameter, maling parameter, maling credentials, atbp.

Ang bawat bloke ng `It` ay naglalaman ng isang partikular na pagsubok, halimbawa: "hindi dapat magbalik ng null" o "ang URL ng ibinalik na konteksto ay tumutugma sa input na URL." Sa isang pagsubok, maaari mong tawagin ang function nang direkta sa loob ng pipe na `Should`; sa isa pa, maaari mong iimbak ang resulta sa isang variable upang siyasatin ang mga katangian at magsulat ng karagdagang impormasyon gamit ang `Write-Host` kung kinakailangan.

Ang pagpapatupad ay isinasagawa gamit ang Invoke-Pester ".\LoginSharePoint.Test.ps1" At kung gusto mo ng mas detalyadong impormasyon, idagdag mo -Output DetailedBukod sa agarang output, maaaring isama ang Pester sa saklaw ng code para makita kung aling mga bahagi ng modyul ang naisagawa habang isinasagawa ang pagsubok.

Mga parameter ng input sa mga pagsubok sa Pester at paggamit ng lalagyan

Ang direktang paglalagay ng mga kredensyal o URL sa bawat pagsubok ay isang bangungot sa pagpapanatili at, bukod pa rito, mahirap i-automate. Ang eleganteng pamamaraan gamit ang Pester ay ang pagdedeklara ng mga parameter sa mismong test file , katulad ng gagawin mo sa isang PowerShell script:

Param (
[Parameter(Mandatory=$true)] [string]$UserAccount,
[Parameter(Mandatory=$true)] [string]$UserPW,
[Parameter(Mandatory=$true)] [string]$SiteCollUrl
)

Gamit ito, magagamit mo ang $UserAccount, $UserPW, at $SiteCollUrl sa lahat ng pagsubok sa loob ng pagsubok, nang hindi inuulit ang mga ito. Para maipasa ang mga halagang ito kapag pinapatakbo ang mga pagsubok, ibinibigay ng Pester ang PesterContainer :

$myContainer = New-PesterContainer -Path 'LoginSharePoint.Test.ps1' -Data @{
UserAccount = '[email protected]';
UserPw = 'MiMuySeguraPW';
SiteCollUrl = 'https://tenant.sharepoint.com/sites/TeamSite'
}
Invoke-Pester -Container $myContainer -Output Detailed

Sa ganitong paraan, maaari kang magpasok ng iba't ibang test data nang hindi naaapektuhan ang test code , na perpekto para sa mga CI pipeline kung saan nagbabago ang mga credential, URL, o tenant depende sa environment (development, pre, production) at ibinibigay bilang mga secret o protektadong variable.

Pagsubok sa yunit at integrasyon: kung ano ang sakop ng bawat isa

Sa mundo ng Pester, mahalagang makilala ang pagkakaiba sa pagitan ng mga unit test at integration test . Ang mga unit test ay nakatuon sa maliliit na bloke ng code nang hiwalay , karaniwang gumagamit ng mga mock ng mga external dependencies. Halimbawa, ang isang function na tinatawag na "New-Drawer" ay dapat magbalik ng isang drawer object na may apat na sulok, dalawang riles, isang hawakan, tamang kulay, at tamang sukat.

Sa kabilang banda, pinatutunayan ng Integration Testing na ang lahat ng indibidwal na bahaging ito ay gumagana nang tama kapag nakakonekta sa mga totoong sistema : SharePoint, mga database , mga panlabas na serbisyo, atbp. Maaari mong maipasa ang lahat ng indibidwal na bahagi at ang integrasyon ay magiging isang sakuna pa rin kung hindi mo ito tahasang susubukan (halimbawa, kung ang kapaligiran kung saan naka-set up ang "kahon" ay hindi akma).

Sa PowerShell, karaniwan para sa iyong mga module na isama ang lahat ng business logic na iyon, at para sa Pester na tulungan kang matiyak na ginagawa ng bawat function ang dapat nitong gawin (mga function ng unit) at na ang kumbinasyon ng mga function, module, at mga external service ay nagtutulungan (integration).

Ang malaking bentahe ay, kapag na-set up mo na ang test suite, ang bawat pagbabago ng code ay nagiging isang simpleng bagay lamang ng pagpapatakbo ng Pester at pagsuri sa mga resulta , na nagpoprotekta sa iyo laban sa mga regresyon sa malalaki at live na mga proyekto.

PowerShell, mga module, at Pester sa mga pipeline ng CI/CD

Sa kasalukuyan, karaniwan nang i-integrate ang PowerShell at Pester sa mga continuous integration at delivery pipeline, halimbawa sa GitHub Actions . Ang mga hosted runner ng GitHub ay may pre-installed na PowerShell 7 at Pester, at nag-aalok din ng opsyon na mag-install ng mga karagdagang module mula sa Gallery gamit ang ` Install-Module`.

Ang isang karaniwang daloy ng trabaho ay nagsisimula sa isang test job na, sa bawat push, ay nagpapatakbo ng Pester sa iyong module . Ang isang pinasimpleng halimbawa sa YAML ay maaaring magsama ng mga hakbang tulad ng:

• Pag-checkout ng bodega (actions/checkout@v5).
• Pagpapatakbo ng isang simpleng pagsubok gamit ang Test-Path resultsfile.log | Should -Be $true upang mapatunayan na may nabuo nang resulta.
• Pagpapatakbo ng isang kumpletong test file gamit ang Invoke-Pester Unit.Tests.ps1 -Passthru.

Bukod sa pagpapatakbo ng Pester, karaniwan din ito I-install ang mga dependency mula sa Gallery (halimbawa, SqlServer o PSScriptAnalyzer), i-configure ang PSGallery repository bilang pinagkakatiwalaan at i-cache ang mga module para mapabilis descargas paggamit mga aksyon/cacheSa Linux, halimbawa, ang karaniwang module cache ay matatagpuan sa ~/.local/share/powershell/Modules, habang sa Windows nagbabago ang path.

Isa pang kapaki-pakinabang na pattern ay ang paggamit ng PSScriptAnalyzer na nasa pipeline upang i-lint ang lahat ng .ps1 file , na kumukuha ng listahan ng mga isyu ayon sa kalubhaan at pagkabigo sa trabaho kung may mga malubhang error. Pinipilit ka nitong mapanatili ang isang pare-parehong istilo ng pag-coding at maiwasan ang mga halatang error bago pa man lumipat sa functional testing gamit ang Pester.

Paglalathala ng mga module sa PowerShell Gallery mula sa CI

Kapag nakapasa na ang iyong mga Pester test sa CI, ang lohikal na susunod na hakbang ay i-automate ang pag-publish ng iyong module sa Gallery kapag lumikha ka ng isang bagong release. Sa GitHub Actions, karaniwang ginagawa ito gamit ang isang workflow na nati-trigger ng release:created events.

Ang kaukulang trabaho ay karaniwang:

• Tingnan ang kodigo.
• Magpatakbo ng build script (halimbawa ./build.ps1 -Path /tmp/samplemodule) na siyang bubuo ng pangwakas na istruktura ng modyul, kasama ang .psm1, .psd1 at anumang karagdagang mapagkukunan.
• Basahin ang sikreto NUGET_KEY ng mga sikreto ng repositoryo at ilantad ito bilang isang environment variable.
• Tumawag kay Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose para i-upload ang bagong bersyon sa Gallery.

Sa daloy ng trabahong ito, ang mga sikreto ng paglabas ay hindi kailanman isinusulat sa plaintext sa mga script ; ang mga ito ay pinamamahalaan lamang ng CI provider, at ang module ay inilalabas lamang kung dati na itong nakapasa sa mga pagsubok sa Pester . Ito ang pinakamalinis na paraan upang maiwasan ang pagkasira ng mga downstream na user na may mga "sirang" bersyon.

Bilang pangwakas na hakbang, karaniwang idinaragdag ang isang hakbang para sa i-upload ang mga artifact ng pagsubok ginawa ni Invoke-Pester (halimbawa, isang XML o CliXml file na may mga resulta) gamit ang aksyon upload-artifactNagbibigay-daan ito sa iyong suriin kung ano ang naging mali kahit na ang trabaho ay minarkahan bilang nabigo, salamat sa mga kundisyon tulad ng if: ${{ always() }} na ginagarantiyahan ang pag-upload kahit na magbalik ng mga error si Pester.

Sa huli, ang pagsasama-sama ng mahusay na pagkakabalot ng mga PowerShell module, masusing pagsubok gamit ang Pester, at mga CI/CD pipeline na awtomatikong tumatakbo, nagsusuri, at nagpa-publish ay nagbibigay-daan sa iyong lumipat mula sa maluwag at marupok na mga script patungo sa isang ecosystem ng magagamit muli, may bersyon, at maaasahang mga tool, na ginagawang mas komportable at mahuhulaan ang pang-araw-araw na trabaho.