Of course it is always a personal preference but for developing separate Cmdlets the Git Feature Branch Workflow seems quite well suited. Git defines several workflows that facilitate developement (based on Vincent Driessen’ article A successful Git branching model). See the GitHub .System.Utilities repository for the actual files and their contents (or check the sameple repository .Testing.Example1 I created for this blog post). With this approach we can easily work on the same module ond separate Cmdlets (and thus files) with multiple developers. # main module file used for module initialisationĬonvertFrom-Base64.ps1 # contains ConvertFrom-Base64 CmdletĬonvertFrom-CmdletHelp.ps1 # contains ConvertFrom-CmdletHelp CmdletĬonvertFrom-Hashtable.ps1 # contains ConvertFrom-Hashtable Cmdlet # script file that will be executed prior to module loading So with .System.Utilities as an example the file structure would look like this (every exported Cmdlet is defined in a single PS1 file with the same name): To facilitate module developement we will have our exported Cmdlets and functions (or groups thereof) defined in separate PS1 files. Script .Rapid.Utilities ĮxportedVariables : biz_dfch_PS_Rapid_Utilities For more information on module manifests see How to Write a Module Manifest.Īs you can see from the following listing the manifest based module .System.Utilities has defined a version number and NestedModule (in contrast to the PSM1 based module .Rapid.Utilities): With a PSD1 you have much more fine-grained control over how your module is versioned and what will essentially be exported and advertised.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |