The art of simplicity

At one of my customers, everything is still on premise hosted on multiple IIS web servers. To deploy web applications, we are using Web Deploy . This works quite nicely and allows us to deploy web application in an automated way. Last week, a colleague contacted me after configuring the deployment pipeline in Azure DevOps. When the pipeline tried to deploy the application, it failed with the following error message: "System.Exception: Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of (Environment)" Here is a more complete build log to get some extra context: Starting deployment of IIS Web Deploy Package : \DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\\<servername>\DevDrop\BOSS.Intern.Web.zip Performing deployment in parallel on all the machines. Deployment started for machine: <servername> with port...

One of the nice features of Application Insights, is the Application Map. This gives you a visual clue of all the parts of your application and their dependencies. I blogged before on how you could tweak this application map through a custom TelemetryInitializer: In your C# backend In your Angular SPA Today I want to share another option when you are using the Javascript snippet inside your web frontend. Inside the snippet you should use the onInit callback to inject a TelemetryInitializer: Here is the full snippet as well:

Microsoft transitioned from a large enterprise software business to a cloud company. In that sense, they are like most compagnies out there who struggle to move from an existing business model to a new cloud first service model. This also means that there are a lot of useful lessons that are relevant for all of us. Through the Microsoft Dojo for customers program, they started to show the way they work, the way they learn, and the way they experiment. Here are some of the topics they already covered: Dojo – People & Teams Dojo – Experiential Learning Dojo – Customers & Trust Dojo – Culture & Mindset Dojo – Product Centric Model – Part 1 Dojo – Product Centric Model – Part 2 Dojo – Product Centric Model – Part 3 Dojo – OKRs (Objectives and Key Results) Interested to learn more? Check out Microsoft Learn and start your DevOps Dojo journey .

From the documentation : When using Visual Studio, it is easy to find out whether newer versions of the NuGet packages used by your project are available, by using the NuGet Package Manager. However, the .NET Core command-line tools do not provide a built-in way for you to report on outdated NuGet packages. dotnet-outdated is a .NET Core Global tool that allows you to quickly report on any outdated NuGet packages in your .NET Core and .NET Standard projects. This is a great way to keep your applications up-to-date and can easily be integrated as part of your DevOps processes. Install dotnet-outdated as a global tool: dotnet tool install --global dotnet-outdated-tool Now you can invoke it from your project or solution folder: dotnet outdated This is how the output looks like for one of my projects: The colors make it very clear. Here is the related legend: You can automatically upgrade packages by passing the ‘-u’ parameter: dotnet outdated -u

One of the techniques that you see in bigger organizations that struggle to move to an Agile mindset, is the introduction of Release trains: A release train tries to align the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product. It is especially used in SAFe(Scaled Agile Framework) organizations. Their definition of a release train is: Agile Release Trains align teams to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together. ARTs are organized around the Enterprise’s significant Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end-user. Based on the definitions above you would think that a release train is something you should aim for, an end goal you shoul...

Just a quick tip for today. Willy-Peter Schaub shared a nice set of quick reference posters about Azure and DevOps on Github : One I especially liked is the DevOps approach @ Microsoft:

2 days ago Microsoft announced Azure DevOps, the new incarnation of VSTS and TFS. Instead of one big mothership, we’ll get 5 smaller vessels that integrate perfectly with each other(of course!) but also with other tools and products. Here are the 5 building blocks: Azure Pipelines CI/CD that works with any language, platform, and cloud. Connect to GitHub or any Git repository and deploy continuously. Learn More > Azure Boards Powerful work tracking with Kanban boards, backlogs, team dashboards, and custom reporting. Learn more > Azure Artifacts Maven, npm, and NuGet package feeds from public and private sources. Learn more > Azure Repos Unlimited cloud-hosted private Git repos for your project. Collaborative pull requests, advanced file management, and more. Learn more > Azure Test Plans All in one planned and exploratory testing solution. Learn more > More information about the Azure DevOps launch can be found on Channel 9; https://channel9.msd...

Microsoft created a consolidated resource site with all kinds of information related to DevOps. It not only contains learning material about DevOps practices but also about Agile Methods, Git version control. You can also see how Microsoft is applying DevOps for their own products and assess you own DevOps maturity.

With the release of Team Foundation Server 2018, Microsoft announced they would no longer support the ‘old’ XAML based builds. Last week with the introduction of Team Foundation Server 2018 Update 2 RC2 (pfew), they confirmed that XAML Builds will be re-enabled for legacy purposes. A lot of customers were blocked from upgrading as XAML builds were no longer supported. With Update 2,  XAML builds are re-enabled but deprecated, meaning there will be no further investment in this area. That is great news because a lot of my customers were postponing an update because they didn’t had time to migrate away from the XAML builds (yet).

While browsing through Channel 9 , I discovered a great new show with a topic that is near to my heart; DevOps! Launched in December 2017, The DevOps Lab is a new Channel 9 show that focuses on everything DevOps at Microsoft. As they are stating themselves, the show goes beyond the buzzword to solve real DevOps problems using a range of tools and techniques. Here is the most recent one:

A colleague mentioned to me he was the following warning on our build server: Agent 'AgentName' is using a deprecated version '1.105.7'. You will not be able to use this version of agent with the next major version of Team Foundation Server. Migrate to the latest 2.x version of agent. For more information, see https://go.microsoft.com/fwlink/?linkid=851067 . I was suprised to see this as I recently updated all agents . Still I’m stuck with version 1 agents… It turns out that there are 2 types of agents: Windows specific agents having number 1.x cross platform agents having number 2.x The thing is that the Update All Agents button will only upgrade to a more recent minor version but will not do an upgrade to a new major version. If you want to upgrade to a new major version of the agent, you’ll have to uninstall the old agent and install the new one yourself.

By default when you configure Application Insights, the Instrumentation key is hardcoded in the JavaScript snippet and the ApplicationInsights.config: This makes it very hard to integrate your application into your devops pipeline and use different instrumentation keys for different environments(development, test, production). Let’s see how we can fix this: Start by commenting out the InstrumentationKey setting in the ApplicationInsights.config: Instead add an extra appsetting to your web. config. By using the web.config you can use the web.config transformations to inject different instrumentation keys for different environments. Now we have to tell Application Insights to use the key specified in our web.config. Therefore add the following line of code to the Application_Start method of the global.asax: As a last step we also have to fix this for the JavaScript snippet injected into our page:

Interested to learn how Google runs it production systems? You should be! O’Reilly published a book created by some people of the SRE team at Google. In this book they explain how Google builds, deploys, monitor and maintain some of the largest software systems in the world. Remark: You can read the book for free online; https://landing.google.com/sre/book/index.html