Azure DevOps Flashcards
What is IaC (Infrastructure of Code)
Infrastructure as Code (IaC) is a practice that enables the automation and validation of the creation and teardown of environments to help with delivering secure and stable application hosting platforms.
What is Continuous Integration (CD) in DevOps
Continuous Integration drives the ongoing merging and testing of code, which leads to finding defects early.
What are greenfield and brownfield projects
A greenfield project is one done on a green field, undeveloped land. A brownfield project is done on the used ground for other purposes.
The same terms are routinely applied to software projects and commonly describe DevOps Projects. On the surface, it can seem that a greenfield DevOps project would be easier to manage and to achieve success:
- There was no existing codebase.
- No existing team dynamics of politics. Possibly no current, rigid processes.
A common misconception is that DevOps is only for greenfield projects and suits startups best. However, DevOps can also succeed with brownfield projects.
Usually, brownfield projects come with:
- The baggage of existing codebases.
- Existing teams.
- A significant amount of technical debt.
But, they can still be ideal projects for DevOps transformations.
The beauty of these projects is that there’s often a large gap between customer expectations and delivery.
The teams involved may well realize that the status quo needs to change. They’ve lived the challenges and the limitations associated with what they’re currently doing.
When selecting systems as candidates for starting a DevOps transformation, it is necessary to consider the types of systems that you operate.
Some researchers suggest that organizations often use Bimodal IT, a practice of managing two separate, coherent modes of IT delivery - one focused on stability and predictability and the other on agility.
Systems of record
Systems that provide the truth about data elements are often-called systems of record. These systems have historically evolved slowly and carefully. For example, it is crucial that a banking system accurately reflects your bank balance. Systems of record emphasize accuracy and security.
Systems of engagement
Many organizations have other systems that are more exploratory. These often use experimentation to solve new problems. Systems of engagement are modified regularly. Usually, it is a priority to make quick changes over ensuring that the changes are correct.
There is a perception that DevOps suits systems of engagement more than systems of record. The lessons from high-performing companies show that is not the case.
Sometimes, the criticality of doing things right with a system of record is an excuse for not implementing DevOps practices.
Worse, given the way that applications are interconnected, an issue in a system of engagement might end up causing a problem in a system of record anyway.
Both types of systems are great. At the same time, it might be easier to start with a system of engagement when first beginning a DevOps Transformation.
DevOps practices apply to both types of systems. The most significant outcomes often come from transforming systems of record.
Some Junk about Dev Ops Transformation
Not all staff members within an organization will be receptive to the change required for a DevOps transformation.
In discussions around continuous delivery, we usually categorize users into three general buckets:
Canary users voluntarily test bleeding edge features as soon as they’re available.
Early adopters who voluntarily preview releases, considered more refined than the code that exposes canary users.
Users who consume the products after passing through canary and early adopters.
It’s essential to find staff members keen to see new features as soon as they’re available and highly tolerant of issues when choosing Canary.
It’s also important to roll out changes incrementally. There is an old saying in the industry that any successful large IT system was previously a successful small IT system.
It allows constant learning from rapid feedback and recovering from mistakes quickly.
Goals are specific, measurable, and time-bound. It is essential to establish (and agree upon) appropriate metrics and Key Performance Indicators (KPIs) to ensure these goals are measurable.
Development Practices (Agile vs Waterfall)
Waterfall
Traditional software development practices involve:
- Determining a problem.
- Analyzing the requirements.
- Building and testing the required code.
- The delivery outcome to users.
Usually, all refer to as a waterfall approach. The waterfall model follows a sequential order. A project development team only moves to the next development phase or testing if the previous step is completed successfully. It’s what an engineer would do when building a bridge or a building. So, it might seem appropriate for software projects as well. However, the waterfall methodology has some drawbacks. One relates to the customer requirements. For example, It doesn’t matter if the customer requirements are defined accurately at the start of a project. Usually, the project takes a long time, and the outcome may no longer match the customer’s needs. There’s a real challenge with gathering customer requirements in the first place. Taking a long time to deliver something would often be different from what the customer needs, even if you built exactly what the customer asked. Customers often don’t know what they want until they see it or can’t explain what they need.
Agile
By comparison, Agile methodology constantly emphasizes adaptive planning and early delivery with continual improvement. Rather than restricting development to rigid specifications, it encourages rapid and flexible responses to changes as they occur.
Agile software development methods are based on releases and iterations:
- One release might consist of several iterations.
- Each iteration is like a small independent project.
- After being estimated and prioritization:
- Features, bug fixes, enhancements, and refactoring width are assigned to a release.
- And then assigned again to a specific iteration within the release, generally on a priority basis.
- At the end of each iteration, there should be tested working code.
- In each iteration, the team must focus on the outcomes of the previous iteration and learn from them.
Having teams focused on shorter-term outcomes is that teams are also less likely to waste time over-engineering features. Or allowing unnecessary scope creep to occur. Agile software development helps teams keep focused on business outcomes.
Note: check screenshot attached to this slide
What are the principles of Agile Development
From Agile Alliance (https://www.agilealliance.org/agile101/the-agile-manifesto/):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Businesspeople and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity - the art of maximizing the amount of work not done - is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
What is the organizational structure for Agile Practices
For most organizations, reorganizing to be agile is difficult. It requires a mind-shift and a culture-shift that challenges many existing policies and processes within the organization.
Good governance in organizations, particularly in large organizations,* often leads to* many relatively rigid rules, operating structures, and methods. It also tends to avoid a broad delegation of authority.
Horizontal vs Vertical Teams
Traditionally, horizontal team structures divide teams according to the software architecture. In this example, the teams have been divided into the user interface, service-oriented architecture, and data teams:
https://learn.microsoft.com/en-us/training/wwl-azure/describe-team-structures/media/devops-ds-image-101-cd10ac81.png
By comparison, vertical team structures span the architecture and are aligned with skillsets or disciplines:
https://learn.microsoft.com/en-us/training/wwl-azure/describe-team-structures/media/devops-ds-image-103-b26487ac.png
Vertical teams have been shown to provide more good outcomes in Agile projects. Each product must have an identified owner. Another key benefit of the vertical team structure is that scaling can occur by adding teams. In this example, feature teams have been created rather than just project teams:
https://learn.microsoft.com/en-us/training/wwl-azure/describe-team-structures/media/devops-ds-image-102-2a966b63.png
What is a kanban board
A Kanban Board lets you visualize the flow of work and constrain the amount of work in progress. Your Kanban board turns your backlog into an interactive signboard, providing a visual flow of work. A kanban board is one of the tools that can be used to implement kanban to manage work at a personal or organizational level.
Kanban boards visually depict work at various stages of a process using cards to represent work items and columns to represent each stage of the process. Cards are moved from left to right to show progress and to help coordinate teams performing the work. A kanban board may be divided into horizontal “swimlanes” representing different kinds of work or different teams performing the work.[1]
Kanban boards can be used in knowledge work or for manufacturing processes.[2]
Simple boards have columns for “waiting”, “in progress” and “completed” or “to-do”, “doing”, and “done”. Complex kanban boards can be created that subdivide “in progress” work into multiple columns to visualise the flow of work across a whole value stream map.
Kanban board for software development team: A popular example of a kanban board for agile or lean software development consists of: Backlog, Ready, Coding, Testing, Approval, and Done columns. It is also a common practice to name columns in a different way, for example: Next, In Development, Done, Customer Acceptance, Live.[5]
https://upload.wikimedia.org/wikipedia/commons/f/f5/Kanban_board_example.jpg
What is Azure DevOps
Azure DevOps is a Software as a service (SaaS) platform from Microsoft that provides an end-to-end DevOps toolchain for developing and deploying software.
Azure DevOps includes a range of services covering the complete development life cycle:
- Azure Boards: agile planning, work item tracking, visualization, and reporting tool.
- Azure Pipelines: a language, platform, and cloud-agnostic CI/CD platform-supporting containers or Kubernetes.
- Azure Repos: provides cloud-hosted private git repos.
- Azure Artifacts: provides integrated package management with support for Maven, npm, Python, and NuGet package feeds from public or private sources.
- Azure Test Plans: provides an integrated planned and exploratory testing solution.
What is GitHub
GitHub is a Software as a service (SaaS) platform from Microsoft that provides Git-based repositories and DevOps tooling for developing and deploying software.
GitHub provides a range of services for software development and deployment:
- Codespaces: Provides a cloud-hosted development environment (based on Visual Studio Code) that can be operated from within a browser or external tools. Eases cross-platform development.
- Repos: Public and private repositories based upon industry-standard Git commands.
- Actions: Allows for the creation of automation workflows. These workflows can include environment variables and customized scripts.
- Packages: The majority of the world’s open-source projects are already contained in GitHub repositories. GitHub makes it easy to integrate with this code and with other third-party offerings.
- Security: Provides detailed code scanning and review features, including automated code review assignment.
J
What is JIRA
JIRA is a commonly used work management tool.
In the Visual Studio Marketplace, Solidify offers a tool for Jira to Azure DevOps migration. It migrates in two phases. Jira issues are exported to files, and then the files are imported to Azure DevOps.
What are the Azure DevOps/GitHub On-permise and Cloud Versions
Azure DevOps provides both on-premises and cloud options, named Azure DevOps Server (on-premises) and Azure DevOps Services (SaaS). Also, the same applies to GitHub with GitHub (SaaS) and GitHub Enterprise (On-premises and Cloud).
What are Project Boards (in Azure DevOps). List different types of Project Boards.
During the application or project lifecycle, it’s crucial to plan and prioritize work. With Project boards, you can control specific feature work, roadmaps, release plans, etc.
Project boards are made up of issues, pull requests, and notes categorized as cards that you can drag and drop into your chosen columns. The cards contain relevant metadata for issues and pull requests, like labels, assignees, the status, and who opened it.
To create a project board for your organization, you must be an organization member. It’s possible to use templates to set up a new project board that will include columns and cards with tips. The templates can be automated and already configured (see list below):
Basic kanban: Track your tasks with: To do, In progress, and Done columns.
Automated kanban: Cards automatically move between: To do, In progress, and Done columns.
Automated kanban with review: Cards automatically moves between: To do, In progress, and Done columns, with extra triggers for pull request review status.
Bug triage: Triage and prioritize bugs with: To do, High priority, Low priority, and Closed columns.
There are different types of project boards:
User-owned project boards: Can contain issues and pull requests from any personal repository.
Organization-wide project boards: Can contain issues and pull requests from any repository that belongs to an organization.
**Repository project boards: **Are scoped to issues and pull requests within a single repository.
What are Projects in Azure DevOps
Projects (beta) are a new, customizable and flexible tool version of projects for planning and tracking work on GitHub.
A project is a customizable spreadsheet that you can configure the layout by filtering, sorting, and grouping your issues and PRs, and adding custom fields to track metadata. You can use different views such as Board or spreadsheet/table.
If you make changes in your pull request or issue, your project reflects that change.
You can use custom fields in your tasks. For example:
* A date field to track target ship dates.
* A number field to track the complexity of a task.
* A single select field to track whether a task is Low, Medium, or High priority.
* A text field to add a quick note.
* An iteration field to plan work week-by-week, including support for breaks.
What are Delivery Plans within Azure Boards
Delivery plans
It’s possible to create another view with deliverables and track dependencies across several teams in a calendar view using Delivery Plans.
Delivery plans are fully interactive, supporting the following tasks:
* View up to 15 team backlogs, including a mix of backlogs and teams from different projects.
* View custom portfolio backlogs and epics.
* View work that spans several iterations.
* Add backlog items from a plan.
* View rollup progress of features, epics, and other portfolio items.
* View dependencies that exist between work items.
