![]() ![]() This means you will create a feature branch for each Cmdlet (or group of Cmdlets) we create and commit that to the development branch via an intermediate feature branch. 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. Create a manifest based module with a PSD1 file describing the module and the actual functions and Cmdlets in separate source files.Create a module with all script code in a large PSM1 file.Here we will only focus on PowerShell script based modules (as opposed to C# based modules). your favourite text editor like Notepad++ to create some scriptsĪs written before PowerShell modules can be created in different ways.A GitHub account and repository (this will essentially work with any Git repository but SourceTree natively only supports BitBucket, Stash and GitHub).Atlassian SourceTree v1.6.14+ (or any command line git client like Git for Windows, but then you have to type the commands manually).Here is a brief overview of what is covered:įor this article to follow you would need the following tools and resources I will describe how you can use the ‘Feature Branch GitFlow’ from SourceTree in combination with manifest based NestedModules to facilitate PowerShell module developing. And if you care about versioning that is a little bit more sophisticated than just creating directories with semi-sequential version numbers this blog post might be something for you. ![]() And depending on your environment chances are high you are not the only developer contributing to a module. There are several ways on how to create a PowerShell (script) module. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |