Hello! This is the first in what will probably be an on-going topic around how to “Do The DevOps” right. And it’s going to be on-going because there is no ‘right way’ of doing things. I’m going to focus initially on what people most likely first think about when they hear the phrase DevOps, and that is pipelines. More specifically, I want to talk about tasks that are available out of the box or via the marketplace.
Hello! I have a pipeline that builds and publishes a wheel to Azure Artifacts in Azure DevOps, but I also wanted to take the wheel and publish it to some Azure Databricks workspaces. I could have made this one pipeline, but as there could be potentially a large number of workspaces to publish to I thought it best to write the terrafrom that will publish to the DBFS in a separate repo and make the publishing to workspaces a separate pipeline.
Hello! Since the time that Microsoft declared that they heart open source, and also the move the Azure, there has been a massive increase in the what and how to do something. For example, off the top of my head, Azure Functions support PowerShell, C#, Python, and many more languages. This increase in choice is great; far better to have many resources/services that are specifically designed to do one thing really well rather than add a feature onto an already existing product.
Hello! I’ve been working with Terraform on and off for about 3 years now. In fact I first heard about terraform way back in 2016, whilst I was busy cursing ARM templates and their verboseness. It was around this time that Microsoft and Terraform announced their working partnership (this was also around the time that Microsoft announced that they hearted Open Source). I’m not going to go into ARM template bashing though; all Infrastructure as Code solutions have their advantages and drawbacks.
Hello! Last month I posted how to run the Azure PowerShell Task on a Self-Hosted Build Agent but because using self-hosted agents is something I’m not that interested in anymore here is an alternative to use the Hosted Build Agents. There’s two steps to this: first you need to use the [email protected] task. This has an option to include the spn details, or in other words the login details of the Azure Resource Manager subscription you have specified in the azureSubscription parameter.
Hello! And Happy New Year! I’m going to preface this post with the fact that I am not sure if this is the intended way to get different versions of the Azure Powershell module running on a self-hosted nuild agent. It just feels wrong and contradicts the best practice of having modules in the $Env:PSModulePath. I’m sure there’s a very good reason that the hosted build agents have been set up this way, I’m just not privy to it.
Hello! The terraform 0.14 release includes a long awaited feature: the ability to mark input and output variables as sensitive. This is big news, and I want to try doing this ASAP. But as it is in beta I will have to install it on the ubuntu hosted agents, which come to find out is very straightforward: - task:[email protected]:script:| sudo apt-get install wget unzip -y sudo wget https://releases.hashicorp.com/terraform/0.14.0-beta2/terraform_0.14.0-beta2_linux_amd64.zip sudo unzip terraform_0.
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?