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.
Welcome to team structures. In this brief lecture, we're going to look at the differences between horizontal teams and vertical teams. Reorganizing to be agile is often difficult for organizations. Doing so often requires a shift in culture that runs counter to many existing policies and processes that may already be in place within the organization.
This often occurs because governance requirements within these organizations, especially the larger ones, usually result in lots of rigid rules and operating structures. Delegation of authority is usually very narrow as well because most large organizations haven't yet moved to an agile structure they often have difficulty coping with change. To avoid being disrupted by startups, established organizations must rethink their team structures.
More traditional horizontal team structures split teams up according to the software architecture. For example, an organization's teams might be organized into user interface, service-oriented architecture, and data. By contrast, this same organization could also be broken up into a vertical team structure. This vertical structure could span the architecture and it could be aligned with product outcomes instead. Generally speaking, a vertical team structure such as the one you see in this example often results in better outcomes in agile projects. In such a structure it's critical that each project have a clearly identified owner. The vertical team structure also allows for easier scaling. This is made possible because to scale, all an organization needs to do is add teams. In this example you see on your screen additional feature teams have been created to scale out. The key takeaway here is that vertical teams are often a better strategy versus horizontal teams when trying to become agile.
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.