A changelog is a helpful addition to any mission, because it offers customers and contributors with a abstract of notable adjustments between every launch. A method to make sure you all the time replace your changelog as a part of any new launch is by making it a part of the the automated deployment course of. This weblog submit describes how I’ve applied changelog pushed deployments for the PowerShell modules I keep in GitHub.
My PowerShell modules are constructed and deployed utilizing a set of scripts that carry out the next duties each time a PR is raised or a commit is made to the Grasp department:
-
Mix the person PowerShell capabilities right into a single module file. This improves efficiency when the module is loaded.
-
Execute the Pester checks to validate the code is functioning appropriately and to replace the
README.md
with the present code protection share. -
Generate computerized PowerShell Assist documentation for every of the module’s instructions into the /Documentation folder of the repo. This provides customers the choice to browse assist on-line.
-
Deploy the module to the PowerShell Gallery, however solely if the department is Grasp and the
CHANGELOG.md
file consists of## !Deploy
. This line of the ChangeLog is then modified throughout this activity to incorporate the model variety of the module being deployed and the date of the deployment. -
Lastly the adjustments which have been made to the supply information (the updates to the README.md, CHANGELOG.md and any adjustments underneath /Documentation) are dedicated again to supply management.
You’ll be able to take a look at these duties in additional element by wanting on the /Construct folder underneath any of my PowerShell tasks in GitHub.
Word: The premise of my duties/scripts have been lifted and modified from different PowerShell group members, however sadly I can’t recall who particularly to provide them credit score.
Making the CHANGELOG.md
a part of the deployment logic has been achieved by including the next to the Deploy activity:
if (Get-Merchandise "$ProjectRoot/CHANGELOG.md") {
$ChangeLog = Get-Content material "$ProjectRoot/CHANGELOG.md"
if ($ChangeLog -contains '## !Deploy') {
$Params = @{
Path = "$ProjectRoot/Construct/deploy.psdeploy.ps1"
Power = $true
Recurse = $false
}
Invoke-PSDeploy @Verbose @Params
# Replace ChangeLog with deployment model and date
$ChangeLog = $ChangeLog -replace '## !Deploy', "## [$Version] - $(Get-Date -F 'yyyy-MM-dd')"
Set-Content material -Path "$ProjectRoot/CHANGELOG.md" -Worth $ChangeLog
}
else {
Write-Host 'CHANGELOG.md didn't comprise ## !Deploy. Skipping deployment.'
}
}
else {
Write-Host "$ProjectRoot/CHANGELOG.md not discovered. Skipping deployment."
}
You’ll be able to see that that is additionally the place the CHANGELOG.md
file is up to date with the discharge model and date.
To permit the supply file adjustments to be dedicated again to the repo it is advisable to grant Azure DevOps permissions to write down to your code repositories. This may be achieved through the use of GitHub App authentication. In my construct pipeline committing the adjustments again to the repo is accomplished within the Commit construct activity as follows:
Set-Location $ProjectRoot
$Module = $env:BHProjectName
git --version
git config --global consumer.e-mail "construct@azuredevops.com"
git config --global consumer.identify "AzureDevOps"
git checkout $env:BUILD_SOURCEBRANCHNAME
git add Documentation/*.md
git add README.md
git add CHANGELOG.md
git commit -m "[skip ci] AzureDevOps Construct $($env:BUILD_BUILDID)"
git push
You will need to embrace [skip ci]
within the commit message in any other case you danger creating an infinite loop of builds and verify ins. The [skip ci]
tag is a in-built option to inform Azure DevOps to not construct one thing you’ve dedicated.
Right here’s an instance of the ChangeLog being up to date for a current deployment of my PowerShell-Inflow module:
Right here’s the CI pipeline updating the CHANGELOG.md
to incorporate the brand new model quantity and date because the title:
And right here’s how the ultimate ChangeLog seems to be:
If you happen to determine to implement this method it’s a good suggestion to additionally embrace a CONTRIBUTING.md
file in your mission to let individuals know that updating the ChangeLog is a compulsory a part of the deployment course of:
– https://github.com/markwragg/PowerShell-Inflow/blob/grasp/CONTRIBUTING.md