Designing a Quality Strategy
Designing a Secure Development Process
The course is part of this learning path
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 email@example.com.
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.
Hi there, let's talk a little bit about feature flags. Feature flags are used to change how things work. Instead of making significant changes to the actual code within an app, you only need to make a small configuration change, and more often than not, this configuration change will only be necessary for a small number of users.
Leveraging feature flags provides an elegant solution when you would otherwise need to deploy new code into trunk, but not yet have it functional. Feature flags are typically implemented as the value of variables which are then used to control conditional logic.
The best way to explain feature flags is to use an example. So let's imagine a scenario where your team is working in the main trunk branch of an e-commerce application. Your manager has come to you and asked if it makes more sense to have the shipping cost calculations performed in the main branch instead of dealing with the messy operations of merge later on. How do you try this out without making wholesale changes to the app or, worse yet, breaking the app altogether?
In this case, you could use a feature flag to get around this. What you could do in this case is make a small change in your code so that users without the feature flag set continue using the original shipping calculation code while your team members who are working on the new shipping calculation code and who have the feature flag set see the new code that's being created.
This scenario would be an example of how to use a business feature flag which is used to determine business logic. The other type of feature flag is known as a release flag.
Now to demonstrate the use of a release flag, let's build upon our previous example. Let's assume your team has completed its work on the shipping calculation code. While you're pretty confident in your team's work you might be a little bit apprehensive about pushing this new code out to all of your users at once. In this case you'd rather push out the changes to a group of users that's better at dealing with new code and the issues that sometimes arise from that new code. This type of group consists of users that are referred to as canaries. The term canary comes from the old use of canaries in coal mines.
What you would do in this case is change the configuration so that your canary users also have the feature flag set. As a result they can start testing the new code as well while the original code continues to function for all other users. If things go south for the canary users you can quickly disable the flag for them so they can go back to using the original code.
So now that you've been introduced to feature flags in general, let's talk a little bit about their life cycle. The minute you use a feature flag for the first time, that feature flag gets added to the overall technical debt that you need to contend with. That in mind you need to realize that the longer a particular flag hangs around as part of your code, the bigger that technical debt becomes.
As you continue to add more and more feature flags to the code, that code becomes more and more complex. Ultimately you wind up with code that's more difficult to test than it needs to be and it's harder to maintain due to its complexity. This often makes it more difficult to troubleshoot because it becomes harder and harder to duplicate problems as part of that troubleshooting process.
To avoid these types of issues, you really need to remove unneeded feature flags as soon as you can. Developing a plan for managing your feature flag life cycle helps accomplish this. As soon as a flag is added to your code you need to have a plan for when it's going to be removed.
I should also point out that you should never repurpose feature flags. This is a big no-no because it opens you up to the possibility of using a flag for a new purpose even though that flag is still part of your code for its original purpose. This can cause all kinds of serious headaches.
To effectively manage the life cycle for your feature flags, start by making sure that you know which flags exist. You should also be keeping track of which feature flags are enabled in which environments. You should also, of course, have a plan for when your flags will be used in production and when they will be removed.
Implementing a feature flag management system such as this allows you to reap the benefits of those flags while keeping your technical debt to a minimum.
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.