CICD with PSADT packages repository

The Toolkit General Discussion
1

Hello there !

I have some questions regarding CI CD : are you using Azure, Git (GitLab/GitHub) to maintain a repository of your PSADT packages and applications ? If yes, would you mind sharing how you are using this repo to perform Code Linting, unit testing, and deployment on your SCCM server ?

Thanks you very much for your feedback on this :slight_smile:

2

I’ve used PSADT in 2 work environments.
The first environments used Vault to transfer completed packages to QA. It wasn’t to keep integrity of the packages but more as a chain of custody tracking thing. The sections didn’t trust each other. The code repository system caused loads of overhead and red-tape.

The second environments doesn’t use any code repository for the packages. We use the file system on the Primary SCCM server and that’s it.

Using a code repository for packages is usually not needed since usually only ONE packager will work on the package.

Changes to the code will happen to the files in \AppDeployToolkit\ folder but they won’t affect deployed packages in PROD unless you create such a system. Each package should have their own copy of PSADT since it is known to be good.

3

Hello and thanks for your feedback :slight_smile:

Firstly, I see the use of some CI CD pipeline as a way to enforce some coding styles and guidelines for packages. This could be very helpful to increase the code quality an consistence, because in my company, packages are built by several teams and most of the packagers don’t use PSADT functions :

  • Newcomers without knowledge of psadt functions
  • Guys who’d rather google some piece of crappy PS code and copy/paste it, instead of just reading the PSADT documentation
  • Some others are reinventing the wheel “hey look ! i’ve built this awesome reboot popup ! Duh i wasn’t aware there were one already…”

I agree that building a package is a task that doesn’t require collaborative work : as you mentioned it : a package is done by a single packager. But i think that version control could help with two things :

  • Knowing why a change was made in a package
  • Listing the diff between two releases.

This would be helpful when you need to re-open a package you did some years ago (or a package made by someone else) to make a new version or to find what went wrong between a working package in version N-1 and the last buggy package version N.