Things with code

 A few weeks ago, working for a new customer, I was asked to create a custom task. Having done this before (a couple of times) I started up Visual Studio Code and then immediately got a feeling of déjà-vu. Yes, there is documentation and some examples of how to create a custom pipeline task and there are some simple explanations of how to use the mock runner to unit-test your code, but it is spread all over the place, some documentation is several years old so things have changed slightly and even in the standard Microsoft GitHub repository for Azure DevOps pipeline-tasks , not every task is set up the same way. So, since I was going to set up a complete pipeline for building, testing and packaging a custom task I decided that this time, I would at least capture all the basics so that a next time, I have everything ready out of the box and can focus on implementing the functionality instead of setting up all the plumbing. TLDR, here: https://github.com/fgiele/AzureDevOpsTasks ...

Intro Although a lot of companies are moving towards the cloud, for many the on premise data centers are still important, either as an isolated, secure environment for data and work that should not leave the intranet, or as hybrid solutions (for example, data on premise, processing in the cloud). This doesn't prevent modern software development, it means that in most cases new software is written for containers. Data centers run a docker management layer like Kubernetes or OpenShift, enabling not just running containers but also maintaining the entire virtual infrastructure with load balancing and network provisioning capacity. For in house development, this might also mean that you will want to run your own Azure DevOps pipeline agents. For Kubernetes , this is simple, but for OpenShift there are a couple of things you need to take into account. Disclaimer I am not in any way or form an OpenShift specialist, the following observations came because I needed a build agent on an Ope...

One of the big improvements that came with NuGet is the ability to easily work with third party libraries and, because of proper versioning, using them with relative safety in your software development projects. With rise of dependency injection, nowadays libraries are not just third party pieces of software, they also become an important part of your own software projects. And this means that you need to have a way to store and share them within your team, but also have a sensible way of versioning them. Using Semantic Versioning is the best approach, since it gives a clean and easy way for your team to use versions and have everyone understand the same thing when talking about major, minor and patch version numbers. Now you need to make this a part of your CI/CD pipeline. Pre-Release version, aka the feature build While creating a new version of the library, you will also want to test the changes to your library in the code that consumes said library. For this you need to hav...

Using queryServiceEndpoint Intro So, this is the reason for creating this blog. My frustration with not being able to find any documentation on how to use this feature. Checking the Azure DevOps REST API documentation , I can see this option is available, but there didn't seem to be anyone on the internet who had a working implementation. And the documents from Microsoft didn't help either. So in the end, after some trial and error, I figured this out and decided it might be useful for others to have an example to work from. Why this setup is needed Normally, you could connect the widget, which is running in the browser, directly to a REST API, have it consume the information and then show the values you extracted. However, this means you expose that REST connection and all details necessary to access that API in source code that is run in the browser. If this can be safely done, the party you are consuming your data from will have to set your domain as a valid locat...