IntegrationWorkz

It has been years ago I started applying continuous integration (CI) and continuous deployment (CD) principles at work. Around 2005, it was the time of Visual Studio 2005 Team System, we started using a build server in our daily development process. From then on it was no longer more: "it works on my machine". With every check-in of code changes a CI build was started which compiled your code and run unit tests which verified the quality of your code.  Deployment was in the beginning still a process of manually copying build artifacts and script files to servers and doing the installation process based on the instructions from the deployment manual (if available). Gradually it migrated to scripts (mix of batch/PowerShell/VBScript files) that our release automatically ran from the build server. In 2016 we migrated from our on-premise TFS 2008 based environment to the cloud solution nowadays known as Azure DevOps . We upgraded our MSBuild driven CI/CD pipelines to the new vis

When updating some network related ARM templates I stumbled on the concept of subnet delegation. What is subnet delegation? Subnet delegation enables you to designate a specific subnet for an Azure PaaS service of your choice that needs to be injected into your virtual network. When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner. One of the advantages is that the service can configure for example routing policies or network security groups.  Subnet delegation and API Management When I was updating our virtual network/subnet templates I stumbled on the delegation section. "delegations": [ { "id": "string", "properties": { "serviceName": "string" }, "name": "string" } ] After doing some research about the concept I opened

 Today I received the Windows 10 version 20H2 update on my corporate Microsoft Surface. After rebooting I had screen resolution issues on my external Dell Ultrasharp 3419W  ultrawide monitor which was connected to the Surface Dock . Instead of the 3440x1440 resolution my monitor started with a 1024x768 resolution. When I tried to change the resolution back to the 3440x1440 setting I noticed that the highest supported resolution was 1280x1024. When I connected the monitor directly to the Surface the native resolution of 3440x1440 was back. Updating and removing the general monitor driver did not help either. When I downgraded back to Window 10 2004 the problem was gone and support for 3440x1440 was back on the Surface dock. I finally figured out how to solve the issue between the Surface dock and Windows 10 20H2. I downloaded the official Dell driver for my monitor and changed the generic driver to this Dell U3419W driver . Then I reinstalled the Windows 10 20H2 feature update and when