Welcome to Designing for Quality and Security with Azure DevOps. This course covers topics to help you learn how to design a quality strategy in Azure DevOps. It shows you how to analyze an existing quality environment and how to identify and recommend quality metrics, as well as what feature flags are and how to manage the feature flag lifecycle.
The course then moves onto technical debt and how to manage it, how to choose a team structure that optimizes quality and how to handle performance testing. You'll look at some strategies for designing a secure development process and the steps you can take to inspect and validate both your codebase and infrastructure for compliance.
We'll wrap things up by covering strategies you can use to secure your development and coding environment, as well as recommended tools and practices that you can use to integrate infrastructure security validation.
If you have any questions, comments, or feedback relating to this course, feel free to contact us at firstname.lastname@example.org.
By the time you complete this course, you should have a good understanding of how to design for quality and security with Azure DevOps.
This course is intended for:
- IT professionals who are interested in earning the Microsoft Azure DevOps Solutions certification
- DevOps professionals that work with Azure on a daily basis
To get the most from this course, you should have at least a basic understanding DevOps concepts and of Microsoft Azure.
Welcome to technical debt. In this lecture, we're going to talk a little bit about what technical debt is and how to manage it.
Technical debt refers to the future costs that will be incurred when you decide to deploy an easy solution rather than one that's grounded in best practices. it's essentially the price you pay for bypassing best practices because deploying them takes longer to complete.
The term technical debt is used because of its similarity to financial debt. Think about it. A person who is in debt is often in debt because he often makes decisions that only consider the now. However, over time, interest accrues. As that interest accrues it gets harder and harder for that person to manage that debt in the future. Fewer and fewer options are then available to him. This snowball effect isn't much different from the snowball effect that occurs when developers make decisions without any regard for the future. Just like financial debt, technical debt will snowball to the point where developers wind up spending most of their time troubleshooting problems and doing rework. This prevents them from adding much value to the project and to the organization in general.
Increased technical debt is often blamed on tight deadlines because if a developer is forced to throw together code quickly he's often going to take shortcuts, it's only natural. For example, a developer who is under the gun to add new features to an application might simply make a copy of a specific piece of code and then edit it rather than refactoring the original method to include the new functionality. This faster way of completing the task allows the developer to only have to test the new code. He can also avoid the more stringent testing that would probably be required if he refactored the original method because it's going to be used by other parts of the code.
While this strategy does meet the deadline, it results in a longer-term problem because there are now two different copies of the same code that will need to be managed and maintained going forward. This increases the risk of the app logic diverging.
Other causes of technical debt include a lack of technical skills, a lack of product direction or ownership, or maybe an organization with no defined coding standards at all. Regardless, at the end of the day, technical debt is a main cause of projects that fail to meet their deadlines.
Because of the impact that technical debt has on delivery and maintenance of solutions, it's critical that you integrate the assessment and measurement of technical debt and of code quality as part of your continuous integration and deployment pipelines in Azure DevOps.
By building in support for things like Sonar Cloud to an Azure DevOps pipeline, you can leverage it to analyze your code. This allows you to drill down into issues that are identified. As a result, you can see what the issues are along with suggested remedies. You can even view estimates of the time that's required to apply each remedy.
By building in support for things like Sonar Cloud to an Azure DevOps pipeline, you can leverage it to analyze your code. This will allow you to drill down into issues that are identified. As a result, you can see what the issues are along with suggested remedies. You can even view estimates of the time that's required to apply each remedy, this ultimately helps you minimize your technical debt.
Introduction - Identifying & Recommending Quality Metrics - Feature Flags - Technical Debt - Team Structures - Performance Testing - Inspecting & Validating Code Base for Compliance - Inspecting & Validating Infrastructure for Compliance - Secure Development & Coding - Infrastructure Security Validation Tools & Practices - Conclusion
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.