CI/CD build pipeline with VSTS

This topic contains 5 replies, has 4 voices, and was last updated by  Chris Gardner 1 week, 5 days ago.

  • Author
    Posts
  • #101947

    Kevin Greer
    Participant

    I'm very new to the idea of CI/CD using VSTS. I am also very new to Git source control. I have developed a couple of modules and collaborate with a colleague but up until now we just shared files. We publish our modules to a network share and set that location as a repository for our clients. I did some research and looked at examples for setting up an automated build and deployment process using VSTS, but I'm not grasping the process completely. My Git repos in VSTS are PS modules and I want the build process to update the module version and run publish-module to a network share. Is anyone deploying modules through VSTS who can point me in the right direction?

  • #102073

    Don Jones
    Keymaster
  • #102076

    Chris Gardner
    Participant

    I use it quite a lot and publish a few modules from it to our internal repos (using ProGet as our nuget server). We mostly handle version updates manually but I'm transitioning to using Jaykul's Configuration module as it has a very nice Update-Metadata function that will update version numbers very easily without screwing with the rest of the file.

    I'd strongly suggest breaking this process into two stages, you've got a build which does; the version number changing, pester tests, PSSA, code signing (at least on master), and anything else you want to do (we add in some checking against our coding guidelines here), then packages it all up into a build artifact (containing just the psd1, psm1 and any other required files but not tests etc).

    The build artifact is then published to VSTS and can be pulled down directly from the build if you want to test things manually, but more importantly this can then trigger a release which does the publishing to a your package feed. You can break this down into two stages as well, have the first environment (as VSTS calls them) publish to a Dev/Test/something feed for a few select users to try out and then another which pushes to the main feed. I'd make sure to set the last one up so that it will only ever trigger for builds that originated on the master branch.

    Rob Sewell has a few talks on YouTube for where he's talked about similar processes.

    If you've got any questions then feel free to ask, I work with VSTS a lot, I'm usually around on Slack or Twitter more but I'll check back in here regularly.

  • #102082

    Joshua Corrick
    Participant

    I recently read a good blog by Rob Sewell (@sqldbawithbeard same guy in the video) on deploying modules to the gallery using VSTS. One difference from your situation is that he is using GitHub rather than VSTS for his repo, but he is doing all of his Unit tests, Module version increments and eventually release through VSTS. Hope this helps!

  • #102109

    Kevin Greer
    Participant

    Thank you all, these resources are helpful. Through reading a lot of blogs and watching videos I'm seeing a trend of best practices I would like to run by you.

    First a question on modules. I have not used Plaster yet, but I think I will use it as my tool to stage modules. My current modules were created using ISE Steroids. Each function is a sperate file which is dot sourced by the Module PSM1. Considering future collaboration and having multiple developers work on a module, is it best practices to use separate PS1 files for each function, or should they be combined into the PSM1 file?

    My end goal is to host my companies PowerShell development source using Git with VSTS corporate account and build and release to a local repository. Our current repository is a DFS share on our network (not technically a repository I think).

    Here are the steps and prerequisites I think I need to implement in order for a successful build pipeline. I would like your input on this if you don't mind.

    1. source control branching off of the master for development. The master branch is used for CD whenever a branch is merged to the master. CURRENTLY LEARNING

    2. VS Code as the primary application for PowerShell development with required extensions (PowerShell, Visual Studio Team Services, vscode-icons, TODO Highlight, (any others you recommend?)). CURRENTLY USING

    3. Plaster for module design and scaffolding. This will standardize our module structure and Plaster can do the heavy lifting for us once we have it configured. NEED TO LEARN

    4. Using Playps for external help. CURRENTLY USE

    5. Using Pester test functions and modules. NEED TO LEARN

    6. Nuget repository. This might be a better than using a DFS share. NEED TO LEARN

    7. VSTS for source control management and collaboration. CURRENTLY USING and LEARNING

    8. Using VSTS for Build and Release of modules. NEED TO LEARN

  • #102131

    Chris Gardner
    Participant

    I'd recommend keeping the functions in their own ps1 files during development and then in your build process pull them all together into a single psm1 file. This has a number of benefits (I'm working on a blog post about it right now) but the major one is speed of import and command discovery.

    There is a nice module being developed by a few community folk to help enable this workflow called ModuleBuilder but it isn't on the gallery yet. A cut down version of what it does for compiling the function files into a psm1 is available on this github issue: https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/102#issuecomment-354805205 along with some discussion about why you should avoid dot sourcing in the psm1. That snippet also his a few lines at the bottom which run pester and PSSA but they can be removed and run as separate tasks in your build process (and should target the compiled psm1).

You must be logged in to reply to this topic.