diff --git a/authors/martin/feed.rss b/authors/martin/feed.rss index db2469e..592ae9f 100644 --- a/authors/martin/feed.rss +++ b/authors/martin/feed.rss @@ -5,7 +5,7 @@ https://daily-devops.net/authors/martin/ Recent content from Martin Stühmer on Daily DevOps & .NET en-US - Tue, 03 Dec 2024 17:43:20 +0000 + Tue, 03 Dec 2024 19:25:34 +0000 diff --git a/feed.rss b/feed.rss index 809c9ff..2fd1b68 100644 --- a/feed.rss +++ b/feed.rss @@ -5,7 +5,7 @@ https://daily-devops.net/ Recent content on Daily DevOps & .NET en-US - Tue, 03 Dec 2024 17:43:20 +0000 + Tue, 03 Dec 2024 19:25:34 +0000 diff --git a/posts/buildinginsidevisualstudio/index.html b/posts/buildinginsidevisualstudio/index.html index a7eee7d..70596df 100644 --- a/posts/buildinginsidevisualstudio/index.html +++ b/posts/buildinginsidevisualstudio/index.html @@ -1,5 +1,5 @@ Mastering .NET Project Properties: The `BuildingInsideVisualStudio` Flag — Daily DevOps & .NET -
Mastering .NET Project Properties: The `BuildingInsideVisualStudio` Flag

Mastering .NET Project Properties: The BuildingInsideVisualStudio Flag

In the ever-evolving world of .NET development, managing project configurations effectively is crucial for maintaining a clean and efficient build process. One of the less frequently discussed but highly useful properties is BuildingInsideVisualStudio. This property, when correctly utilized, can streamline your build process and ensure that your project is configured properly depending on the build environment. In this article, we’ll explore the BuildingInsideVisualStudio property with concrete examples and discuss best practices for using it effectively.

Understanding the BuildingInsideVisualStudio Property

The BuildingInsideVisualStudio property is a conditional flag that can be used within your project files (.csproj) to apply certain settings or include/exclude packages and references based on whether the project is being built inside Visual Studio. This property is particularly useful when you need to differentiate between builds triggered from Visual Studio and those triggered from other environments such as command-line builds or CI/CD pipelines.

Example: Adding a Package Reference Conditionally

Let’s start with a practical example: adding a package reference only when the project is being built inside Visual Studio. This can be useful when you want to include certain tools or analyzers only in the development environment to keep the build lean for production.

Assuming you want to add a reference to SonarAnalyzer.CSharp, a popular static code analysis tool, but only when building the project within Visual Studio, you can use the BuildingInsideVisualStudio property to conditionally include this package reference in your .csproj file. Why would you want to do this? It’s already included in your CI/CD pipeline, so you don’t need it in your local development environment? The answer is simple: you want to have the same code analysis rules and hints in your local development environment as in your CI/CD pipeline. This way, you can fix issues early and avoid surprises when pushing your code to the repository, and executing maybe long-running CI/CD pipelines.

Here’s how you can do it:

<Project Sdk="Microsoft.NET.Sdk">
 
   <ItemGroup Condition="'$(BuildingInsideVisualStudio)' == 'true'">
@@ -27,8 +27,6 @@
 
 
 
-
 
 
diff --git a/posts/dependamerge-action/index.html b/posts/dependamerge-action/index.html
index b3a83b7..d27fdbc 100644
--- a/posts/dependamerge-action/index.html
+++ b/posts/dependamerge-action/index.html
@@ -1,5 +1,5 @@
 Master dependency management with automation: story behind `dependamerge` — Daily DevOps & .NET
-
Master dependency management with automation: story behind `dependamerge`
Master dependency management with automation: story behind dependamerge
In software development, dependencies are inevitable - any project worth its salt relies on various libraries, frameworks, or packages. However, as I found in my own work, managing these dependencies can be an onerous task. Constant updates, new vulnerabilities, and endless manual approvals were draining my time and focus. What if, I thought, these processes could be automated? This thought led to the creation of dependamerge, a GitHub Action designed to free developers from the drudgery of manual dependency maintenance and let us get back to what we do best: building great software.
The realities of manual dependency management: My journey
Like many developers, I used to spend a lot of time managing dependencies. Dependabot would helpfully create pull requests for each new release, but I still had to check and merge each one. This quickly became an endless cycle. The hassle of checking every dependency update, even minor ones, pulled me away from critical tasks.
The reality is that as teams grow in size, dependency management becomes increasingly complex. For a while, I was stuck in a manual cycle, balancing the risk of out-of-date dependencies against the time commitment of updates. This tension was a big factor that inspired dependamerge.
Why automation? Why now?
My experience echoed the frustrations faced by many developers:
  1. Unending maintenance: Keeping up with dependency updates is like an unrelenting treadmill. Without automation, it’s all too easy for obsolete packages to slip through the cracks.
  2. Disrupted flow: Each pull request interrupts the flow, forcing us to context-switch and potentially delaying real progress.
  3. Security pressure: At a time when vulnerabilities can bring down entire ecosystems, dependency maintenance is non-negotiable, but finding the time to do it can feel impossible.
  4. Productivity drain: Manual dependency management is a time sink, diverting focus from the core work of building and improving software.
  5. Technical debt: Neglected dependencies can accumulate into a significant technical debt, leading to more problems down the line.
Expand on the Benefits of Automation
Automating dependency management with dependamerge brings a range of significant benefits that streamline development and enhance code quality:
  • Time-Saving: By automating dependency updates, dependamerge saves developers from manually reviewing each pull request. This efficiency frees up hours each week, allowing teams to focus on feature development and innovation rather than getting bogged down by routine maintenance.
  • Enhanced Security: In today’s landscape, where vulnerabilities can have far-reaching impacts, timely updates are essential for maintaining a secure codebase. With dependamerge, critical updates can be applied promptly and consistently, helping to protect your projects from potential threats. Automation ensures that nothing slips through the cracks, even when time is limited.
  • Improved Code Quality and Stability: Automated dependency updates reduce the risk of errors that can occur when manually merging changes across environments. Consistent updates prevent compatibility issues that might arise from neglected dependencies, contributing to a more stable and reliable codebase.
  • Reduced Technical Debt: By keeping dependencies up-to-date, dependamerge helps prevent the buildup of technical debt that can slow down future development and create unexpected blockers. With fewer outdated dependencies, teams can avoid the last-minute scramble to upgrade critical packages or dependencies right before a major release.
  • Seamless Integration in CI/CD Workflows: dependamerge is designed to operate smoothly within a CI/CD pipeline, allowing dependency updates to be tested and validated alongside other code changes. This integration reduces interruptions to the workflow and ensures that updates don’t introduce issues at later stages in the development lifecycle.
By automating these repetitive tasks, dependamerge empowers developers to focus on what matters most: building and improving software. It’s a tool that boosts productivity, enhances security, and ultimately contributes to a more efficient and resilient development process.
Introducing dependamerge: A solution built for developers
Designed to take the reins of dependency updates, dependamerge works with Dependabot to make dependency management truly seamless. This GitHub action doesn’t just approve updates—it is adjustable to your project’s specific needs, ensuring that only the right updates are merged at the right time. Even better, dependamerge can be part of a fully automated CI/CD pipeline, ensuring that dependency updates are tested and validated alongside other code changes.
GitHub action that automatically validates, approves, and merges pull requests for branches created by dependabot[bot]
Highlights of dependamerge include:
  1. Fully compatible with Dependabot: dependamerge works seamlessly with Dependabot, extending its capabilities and streamlining the update process. To do this, dependamerge communicates with Dependabot’s comment commands to manage the pull requests.
  2. Automated merging: With the ability to define specific merge rules, updates are approved without disrupting your day. Regardless of the ecosystem, all current and future Dependabot ecosystems are supported.
  3. Customizable conditions: Tailor the automation to prioritize critical updates, such as security patches, while handling non-critical updates according to your project’s needs.
  4. Human-Free Handling: Freeing developers from dependency maintenance not only saves time, but also prevents mental fatigue from routine tasks. dependamerge ensures that updates are handled consistently and reliably, without manual intervention.
Usage example: Setting up dependamerge in a CI/CD pipeline
To start with dependamerge, you can use the following example configuration. This GitHub action is highly customizable, allowing you to adjust various parameters to suit your project’s specific requirements.
name: DependaMerge
 
 on:
@@ -21,8 +21,6 @@
 
 
 
-
 
 
diff --git a/posts/how-to-prepare-for-microsoft-certification/index.html b/posts/how-to-prepare-for-microsoft-certification/index.html
index 28cc863..6b86465 100644
--- a/posts/how-to-prepare-for-microsoft-certification/index.html
+++ b/posts/how-to-prepare-for-microsoft-certification/index.html
@@ -1,5 +1,5 @@
 How to Prepare for Microsoft Certification — Daily DevOps & .NET
-
How to Prepare for Microsoft Certification
How to Prepare for Microsoft Certification
How do I best prepare for a Microsoft certification? - this or a similar question is asked by everyone who wants to deal with the topics Microsoft, Azure, Microsoft 365, Power Platform or Dynamics 365. In this article, I would like to go into the possibilities that Microsoft offers us for preparation.
Regardless of whether you’re new to the subject or already know it, preparing for a potential exam is often a challenge. But first, let’s clarify which exams and certifications are available in the first place.
Microsoft certifications at a glance
Microsoft categorizes its entire Certification Portfolio
 by category and level. The following categories are currently provided by Microsoft:
  • Azure
  • Dynamics 365
  • Microsoft 365
  • Power Platform
  • Security, Compliance and Identity
As well as in the levels Fundamentals, Role-based and Specialty. This is very clearly presented in the overview (aka.ms/TrainCertPoster
 ) and is regularly updated by Microsoft. In addition, Microsoft offers a second, much more detailed overview (aka.ms/TrainCertDeck
@@ -10,8 +10,6 @@
 
 
 
-
 
 
diff --git a/posts/illuminate-technical-debt/index.html b/posts/illuminate-technical-debt/index.html
index 72734d4..16e083a 100644
--- a/posts/illuminate-technical-debt/index.html
+++ b/posts/illuminate-technical-debt/index.html
@@ -1,13 +1,11 @@
 Illuminate Technical Debt — Daily DevOps & .NET
-
Illuminate Technical Debt
Illuminate Technical Debt
Whatever our role, be it developer, IT professional or architect, we try to avoid technical debt. If this is not possible from the outset, or if we decide to accept this technical debt for a limited period of time, we usually lack the tools to do so. This is where this article may help.
What is technical debt?
Technical debt is a metaphor used to describe the costs and risks incurred as a result of decisions or omissions. It is important to note that this metaphor can be applied to all types of technical debt.
First, there is architectural debt, which is usually based on a decision made by an individual architect or group of architects. Then there is implementation debt, which is probably the most common in most projects, as it is also identified through source code analysis. And then there is the test and documentation debt, which is far too often neglected.
What colors is your backlog?
Phillipe Kruchten - https://pkruchten.files.wordpress.com/2012/07/kruchten-110707-what-colours-is-your-backlog-2up.pdf
Whatever the type of technical debt, the common denominator is that it tends to cause problems in projects and later in operations. In July 2011, Phillipe Kruchten described them as “invisible negative elements in the backlog”.
However, they are rarely recorded and visualised.
How can I still make them visible?
In most projects, it is individuals or a small group of individuals who are aware of individual Technical Debts. However, these projects usually have another thing in common: when these technical debts are addressed, they are postponed or even dismissed.
To avoid this, Technical Debts need to be tracked in the same way as requirements or defects. All you need is a person with administrative rights in Azure DevOps or comparable platforms.
Extension of the Azure DevOps process templates
Azure DevOps provides the ability to visualise technical debt by extending process templates. The Microsoft article [Customize a process template] (https://learn.microsoft.com/en-us/azure/devops/reference/process-templates/customize-process?view=azure-devops
 ) details how to inherit and extend a process template to achieve the following result.
Azure DevOps Prozess Templates Erweiterung
In this case, the extended process templates AgileRCDA and ScrumRCDA were simply extended by an additional WorkItem type, which will be used in the future to record and visualise technical debt. In 2011, Kruchten already used the colour black for the colour scheme of technical debt.
WorkItem Type: Technical Debt
For later prioritisation and sorting, it is advisable to pass additional parameters to the WorkItem type, such as
WorkItem-Typ: Technical Debt - Settings
This creates the technical foundation based on the process templates, and within the project only the technical debt type work items need to be recorded.
Summary
The Azure DevOps extension (or alternative platforms) presented here takes only a few minutes to extend and deploy. But it will have the desired effect by the next sprint meeting. That’s because the black work items of the “technical debt” type quickly give the impression of a tombstone and provide the necessary visibility.
Don’t be surprised if the tombstones start to pile up after a few weeks. Your colleagues and team members know about other Technical Debts that you probably haven’t noticed yet.
Comments