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.
Hi there, welcome back. In this lecture, we're going to look at strategies for inspecting and validating your infrastructure for compliance. More specifically we'll take a look at PowerShell desired state configuration, Azure Automation State Configuration, and InSpec.
Some time ago automating the creation of resources was done largely through procedural code that was written in languages like PowerShell. While this methodology does work, it doesn't make it easy for developers to write idempotent code which is code that produces the same outcome no matter how many times you run it.
When PowerShell desired state configuration became available it was a huge improvement. Using DSC you could define a desired outcome instead of creating the process for achieving that outcome. DSC was a declarative way to automate the configuration and compliance of resources rather than a procedural way.
There are now several tools available that allow you to define infrastructure as code. These tools provide lots of benefits to DevOps teams because the tools allow those DevOps teams to now build reliable environments on demand and in a repeatable way. Such environments can even include operating systems and services. Teams can run the same code over and over again to ensure that the target state is not only present to begin with but to also remove any drift from that desired state.
Now all that being said in addition to configuration of environments there is also a need to validate those environments.
Azure Automation State Configuration is a validation tool that builds on PowerShell DSC. It makes management easier by allowing you to author and manage DSC configurations and to import DSC resources. You can also use Azure Automation State Configuration to generate DSC node configurations or MOF documents. These DSC configurations and MOF documents are then placed on an automation server. Target nodes which can be located in the cloud or on-prem can retrieve them from the automation server. The target nodes will then automatically conform to the desired state and report their compliance state back to that automation server.
InSpec is another validation tool. It's an open-source testing framework for infrastructure. It features a language for specifying compliance, security, and other policy requirements. InSpec compares the current state of a system with the desired state that you define within the InSpec code. The tool will then go out and identify violations, displaying its findings in a report.
However, unlike Azure Automation State Configuration, remediations of issues identified by InSpec is performed by the administrator.
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.