A step template is a step type you define once and reuse across projects. It has typed inputs, a body (usually PowerShell), and a version number. Projects use the template by selecting it in the step picker and filling in the inputs.
When you actually want one
The trigger is simple: when the same script has been pasted into three projects, or when a new project asks "how do you deploy a Windows service here?" and the answer involves opening another project's deployment process to copy from. That's the moment to promote it to a template.
What a `Deploy-WindowsService` template looks like
The inputs become form fields when a project uses the template.
# Inputs:
# ServiceName (string, required)
# PackageName (package, required)
# StopTimeoutSec (number, default 30)
# RunAsUser (string, optional, sensitive)
param($ServiceName, $PackagePath, $StopTimeoutSec, $RunAsUser)
Stop-Service $ServiceName -Force -Timeout $StopTimeoutSec
Expand-Archive -Path $PackagePath -DestinationPath "C:\Services\$ServiceName" -Force
if ($RunAsUser) {
sc.exe config $ServiceName obj= $RunAsUser
}
Start-Service $ServiceNameThe cultural part
Step templates live or die on ownership. A template without a maintainer becomes the source of "I don't know why this fails on Prod but works on Staging" outages. Pick an owner per template. Document the inputs in the help text - that's what the consumer sees. Treat shared deployment code as production code: review, test, changelog.