Hello and welcome to Technical Debt and Templates. In this lesson, we are going to look at what technical debt is and how to deal with it in templates.

Technical debt is a headache that is almost never-ending. It’s a concept in software development circles that refers to the cost of additional rework that often results from choosing to implement a quick and easy solution now, instead of implementing a more thought-out solution that would take longer to deploy. Technical debt is often incurred when developers are tasked with rushing a job to completion, rather than ensuring it is done right.

While technical debt doesn’t necessarily impact business functionality, it does make updating and troubleshooting more difficult. It undermines productivity because it makes code hard to understand, time-consuming to change, and difficult to validate. 

Technical debt typically starts out small and grows over time as rushed changes and features are implemented in existing code in an undisciplined manner.

The term “technical debt” refers to any tasks or work that a team must complete in order to deploy production code and to keep it running. Some examples of technical debt include performance issues that are encountered, bugs in code that are discovered, operational issues in production that must be addressed. Other examples of technical debt include changes that are made on the fly and situations where you need to switch to technologies that were not accounted for in the development process.

While technical debt is often a result of manual actions that are taken during the development process, it can also turn up in Azure Resource Manager templates, which are used to deploy and configure Azure resources.

When you think about it, during the process of deploying resources via templates, you’ll often find yourself retrieving information about the different resource providers and types. This is all well and good, but whenever a resource provider enables new features, a new version of the associated REST API is also usually released.  If you have components defined within your resource manager templates that rely on specific API versions, those components will usually need to be updated periodically. 

To address this issue with templates, what you should do is validate the API versions in those templates to ensure they are current. This should be completed as part of your general development work.

Although you are not likely to ever completely eliminate technical debt, you can manage it effectively if you take the necessary steps to do so.

To properly manage technical debt, you need to understand it and be able to locate it within your code. You should also weigh the costs of remediation versus non-remediation because, while fixing technical debt incurs costs, not fixing it also incurs costs – and the costs of not addressing that technical debt could very well be larger.

Taking proactive steps to enforce policies that specifically focus on preventing debt from becoming worse makes it easier to manage that debt.

Steps that you can take, for example, include planning for and completing periodic updates to your Microsoft Azure Resource Manager templates to account for new API versions. This should be done as part of your general development work.

You should also restrict manual configurations. Ensuring that no manual configurations are allowed goes a long way toward limiting ad-hoc changes that often result in more technical debt.

And since technical debt is virtually unavoidable, you should be sure that you track it over time to ensure that it’s shrinking, rather than growing. When you do identify technical debt, it should be remediated as quickly as possible – and as AUTOMATICALLY as possible.

You might even consider setting the priority of technical debt so that it’s just as important as the development of new application features. This ensures that it is addressed in an ongoing fashion.

Third-party tools like SonarQube can be used to quantify technical debt so that it can be addressed.

To learn more about SonarQube, visit the URL that you see on your screen: https://www.sonarqube.org/

Lectures

• Introduction
• Hosting Infrastructure
• An Intro to Infrastructure as Code
• Infrastructure as Code (IaC) Technologies
• Transient Infrastructure
• Mitigating Infrastructure State Drift
• Conclusion