Hello! Argh! Yaml! OK, let’s get something totally clear: I really don’t care for YAML pipelines. I get that the idea behind them is so that the pipelines to take the code from source and deploy up to produciton is stored with the source control. And as someone who places a great deal of importance in source-controlling as much as possible, this dislike of yaml-based pipelines might seem something of a surprise.
Hello! I recently published a new PowerShell module to help check that environment variables have been created for variables in an Azure DevOps Variable Group. And I called it Dreepy. How Does It Work? Dreepy is a PowerShell module to verify Environment variables exist for all variables in a variable group that are attached to running build. It can be run outside of a build pipeline, providing you specify the organisation, project, and build variables.
Hello! Artefacts play a very important part of build and release pipelines. For builds they contribute to the “build once, deploy many” process as an artefact is published at the end of the build and then consumed by a release at each satage/environment deployment. So in the context of an SSDT project, you compile the sqlproj and grab the resulting dacpac as a build artefact. Then for each release to dev/preprod/prod etc, you use the same dacpac that generates the deployment.
Hello! I’ve been using Azure DevOps to build a library I have sourced in GitHub. I really should learn about GitHub Actions, but my main focus has been 1) learning Python and 2) how to build a pipeline to publish to PyPi, and so the quickest way for me to learn the second point was to stick to the tool I know the best. Anyway, in Azure DevOps you need to create a service conection to an external source in able to communicate with it in a pipeline.
Hello! Last week I published a post about publishing a PowerShell module to the artifacts section of Azure DevOps. It was basically an amendment to a script that someone else had written. But what I really want to do is write a bit more of an in-depth post on the pipelines I have used to publish a PowerShell module as an artifact. I have created a repo on GitHub so that people can follow from home if they really want to or take scripts and stick them in their own repos.
Hello! I’ve been writing a PowerShell module that I want other developers to be able to use, so I decided to use the artifacts part of Azure DevOps as I’ve set up a build to run some tests and run PsScriptAnalyzer prior to publishing the module at the end of the build as an artifact. I figured that using the Artifacts to store my artifacts was sensible instead of leaving them hanging around old builds.
Hello! The past few months I’ve been improving the pipeline I use to build and publish a Visual Studio Extension that basically updates the module version number and publishes it to the PowerShell gallery. You can see the status of the pipeline here! The build and release pipeline are publicly available to view here. I use a single pipeline because once I’ve run the tests there’s no need to fret about whether or not I hold off from pushing a later version.
Hello! One of my Visual Studio plugins uses the build badge on it’s overview page in the Marketplace. I quite like using these status badges because it shows there’s some form of automation in place to deliver the extension. However the other day I was looking at the page in the marketplace and was surprised to see that the status of the build was “never built.” So looking into it it is because the build retention policy is set to a number of days, and after that everything is deleted.
Hello! This post will, if for nothing else, encourage teams to seriously consider using KeyVault for storing secrets that you want to use in a build (this walkthrough is a good guide.) Despite the fact that despite that they are encrypted, it is possible to get the value of a secret variable with one simple trick. This means it is very important who has permissions to edit your pipelines. So, how do we go about getting the value of a secret parameter?