#DeliveryConf @MrThomasRayner: Messy PowerShell behaviors: A lack of tests, no signed code (not good!), a lack of linting, no peer review (this is a big one!), lack of difference between artifacts in source and prod, no approval, and no dev env.
#DeliveryConf @MrThomasRayner: The same concepts from #CICD that we heard in the keynote earlier are applicable to PowerShell!
#DeliveryConf @MrThomasRayner: A lot of the people doing PowerShell might not have the background in development to provide the basics like storing prod code in source control, having peer reviews to avoid blinders and edge cases, and approval workflows.
#DeliveryConf @MrThomasRayner: In PowerShell, you can build stuff like modules with deployable artifacts. Remember performance matters; importing happens at load time, but importing it in one file all at once will be faster. Consider these even though it's not compiled.
#DeliveryConf @MrThomasRayner: Test your PowerShell scripts! Try stuff like PSScriptAnalyzer to break down and check your code. It can help to avoid passwords in code, aliases in prod scripts. Also you can write your own rules and enforce style rules across teams.
#DeliveryConf @MrThomasRayner: Another tool: #VSCode PowerShell extension. It will help standardize behaviors and help you as you're writing your code. Check it out!
#DeliveryConf @MrThomasRayner: And the big one: Pester, a testing and mock framework for testing your PowerShell scripts. You can add unit tests, integration tests, #TDD, etc.
#DeliveryConf @MrThomasRayner: Pester helps you understand and test your edge cases and ensure you can get more performance out of your PowerShell code. You can use them for health checks, etc., too! It can also feed conveniently into any larger #CICD frameworks.
#DeliveryConf @MrThomasRayner: Regarding signing your code, you can use the `Set-AuthenticodeSignature` built-in to add a cert. This helps you know if a power user might have modified the code on a local system!
#DeliveryConf @MrThomasRayner: PowerShell runs in so many different places; it may end up all over the place. So deployment places might be file shares, nuget feeds (public or internal), and cloud providers. It can be anywhere!
#DeliveryConf @MrThomasRayner: Helpful things include stuff like Invoke-Build and Psake (test and build runners to make code-defined pipelines), Plaster (to template your projects), Platyps (for help docs), Configuration and PSDepend (to make sure deps/configs are in place)
#DeliveryConf @MrThomasRayner: So how do you avoid the mess? Cover your basics, build things (even though it's interpreted, be aware of prod vs dev), test and lint your code, deploy your PowerShell code (you have so many options!), and use helpers to make your life easier.
