📘 DevOps Fundamentals – Section 1: Introduction to DevOps

and Azure DevOps Setup

🎓 Instructor: Brian from Like A Boss Learning
🔧 Course: Azure DevOps Fundamentals

🧠 Lecture 1: Course Overview

 Instructor Introduction: Brian – 20+ years of experience in
teaching, writing, admin for both large and small
companies.
 Course Objective:
o Designed for DevOps beginners or those who want
hands-on experience in Azure.
o Includes hands-on labs and project deployment.
o Can help prepare for the AZ-400 certification.
 Learning Method:
1. Friendly for newcomers — terms and concepts
explained as they appear.
2. Focus on hands-on learning — deploy a game in a
web browser.
3. Real-world Azure DevOps tools used throughout.
🧠 Lecture 2: Setting Up Azure DevOps Environment
🌐 Azure DevOps Organization Setup:
 Go to: dev.azure.com
 Sign in using Microsoft or GitHub account.
 Choose “Start for free” or “Start with GitHub”.
 Use a private/incognito browser window if necessary.
🔧 Steps to Set Up Lab Environment:
1. Log in to dev.azure.com.
2. Use your Microsoft Account or GitHub account to sign up.
3. Create a new organization (e.g., likeaboss-devops).
4. Choose region for project hosting (e.g., Central US).
5. Create a new project within that organization.
To delete an organization:
 Go to Organization Settings → Scroll down → Delete
organization.

🧠 Lecture 3: What is DevOps?

✅ Definition:
DevOps is a framework of practices and tools designed to
reduce the time between a software change and its deployment
to production — while maintaining high quality.
❌ What DevOps is NOT:
 Pre-DevOps Flow:
o Devs write code → commit to Source Control → QA
tests → Ops deploys → Bug? → Rollback → Fix &
Repeat.
o Teams worked in silos, leading to delays and blame
culture.
✅ What DevOps IS:
 Merge of Development & Operations:
o Focus on collaboration, automation, and continuous
deployment.
o Improves time-to-market, code quality, and team
culture.
💡 DevOps Goals:
 Speed up delivery.
 Catch issues early.
 Promote teamwork and reduce burnout.
🔧 Azure DevOps Tools You'll Use:
Tool Purpose
Azure Boards Planning and tracking work (tasks, bugs).
Azure Repos Source code version control (Git).
Azure Pipelines CI/CD automation.
Azure Test Plans Manual and exploratory testing.
Azure Artifacts Package management (NuGet, npm, etc).
🧠 Lecture 4: Why DevOps Matters – Real Business Value
🔎 DevOps = Real Impact, Not Just a Buzzword
 DevOps provides quantifiable technical and business
benefits.
 It's not hype — it’s backed by real-world case studies and
performance metrics.
📊 Key DevOps Advantages:
Benefit Description
Adaptive releases instead of centralized
Shorter Dev Cycles
releases.
Increased Deployment
Deployments up to 30x more frequent.
Rate
Faster Time to Market New features and fixes reach users
Benefit Description
quickly.
Sometimes 100x faster from commit to
Lower Lead Times
production.
Less Unplanned Work Reduces firefighting and downtime.
Better Team
Breaks silos between dev and ops.
Collaboration
Lower Stress & More predictability and reliability in
Burnout workflows.

💼 Why You Should Care:

1. ✅ Proven Results:
o Industry-wide studies show dramatic improvements
with DevOps.
o Used by tech giants and enterprises to gain
competitive edge.
2. 😌 Improves Work Environment:
o Reduces pressure and chaos in high-stakes
environments.
o Enhances collaboration and job satisfaction.
3. 🚀 Career Growth:
 o DevOps is a high-demand skill.
o Used by major tech companies and becoming an
industry standard.

🏢 Real-World Examples of DevOps Success:

Company Impact of DevOps
Deploys code every 12 seconds using DevOps +
Amazon
Agile + AWS tools.
Ensures streaming stability and uptime, saving
Netflix
millions in revenue.
Went from 2-year app deployments to monthly
Nordstrom
releases.

🧰 Azure DevOps Core Services Overview

Azure DevOps offers integrated tools for the full DevOps
lifecycle:
Service Purpose
Boards Track and plan work (e.g., user stories, tasks).
Repos Source control with Git.
Pipelines CI/CD: Automate build, test, and deployment.
Test Plans Manual & exploratory testing.
Service Purpose
Artifacts Package management (NuGet, npm, etc.).

🔌 Integrations & Extensibility

Azure DevOps supports hundreds of integrations, including:
 Slack
 Trello
 GitHub
 Campfire
 On-premise deployments (if needed)
🔎 Note: Azure DevOps evolved from Visual Studio Team
Services (VSTS) (pre-2018).

Create Your First Azure DevOps Project

🔄 Steps Recap:
1. Go to dev.azure.com.
2. Log in with a Microsoft or GitHub account.
3. Create an Organization (e.g., my-devops-org).
4. Click Create Project:
o Name: MacGuffin (example)
 o Description: Anything short and relevant.
o Visibility: Private (only invited users can access).
o Version Control: Git preferred over TFVC.
o Work Item Process: Basic (Agile/Scrum/CMMI also
available).
🎉 After creation, you'll land on the project dashboard with
access to:
 Boards
 Repos
 Pipelines
 Test Plans
 Artifacts

✅ End of Section 1 Summary

You now:
 Understand the business value and necessity of DevOps.
 Have insight into how real companies benefit from
DevOps.
 Set up your Azure DevOps environment with a first
project.
 Are ready to dive into Azure Boards in Section 2.
🧠 DevOps Fundamentals – Section 1 Flashcards

❓ What does DevOps stand for?

Development + Operations

❓ Is DevOps just a buzzword?

No. It offers quantifiable technical and business benefits,
supported by real-world case studies.

❓ What are the main goals of DevOps?

 Shorter development cycles
 Increased deployment frequency
 Faster time to market
 Better collaboration
 Lower lead times

❓ How does DevOps benefit businesses?

 Faster and more reliable software delivery
 Improved system stability and uptime
 Reduced unplanned work and stress
 Stronger collaboration between teams
❓ Name three companies that saw major success using
DevOps.
 Amazon – Deploys new code every 12 seconds
 Netflix – Ensures streaming stability with DevOps
 Nordstrom – Improved from 2-year to monthly app
releases

❓ What are the core services offered by Azure DevOps?

 Boards – Track and plan work
 Repos – Source code management with Git
 Pipelines – CI/CD automation
 Test Plans – Testing infrastructure
 Artifacts – Package management

❓ What tools can Azure DevOps integrate with?

 GitHub
 Slack
 Trello
 Campfire
 On-premise deployment tools
❓ What is TFVC in Azure DevOps?
Team Foundation Version Control – An older version control
system (less commonly used today).

❓ What is the modern replacement for VSTS?

Azure DevOps Services (Rebranded from Visual Studio Team
Services in 2018)

❓ What are the project visibility options in Azure DevOps?

 Public – Anyone can view
 Private – Only invited users can view

❓ Which version control options are available in Azure

DevOps?
 Git (recommended)
 TFVC (only in private projects)

❓ What are the work item process options in Azure DevOps?

 Basic
 Agile
  Scrum
 CMMI
Section 2: Azure Boards – Notes

🔹 What are Azure Boards?

 A tool in Azure DevOps used to plan and track work.
 Essentially a fancy prioritized to-do list.
 Commonly used with Agile and Scrum frameworks.
 Similar to tools like Jira, Trello, or Ravetree.

🔹 Key Components of Azure Boards

1. Work Items
o Individual tasks or units of work (often called stories).
o Each item can include details, discussions,
attachments, links.
2. Boards
o Visual representation (Kanban style) of work item
status:
 To Do → Doing → Done
3. Backlogs
 o Ordered lists of work items not yet assigned to
sprints.
4. Sprints
o Time-boxed iterations in which a set of tasks are
completed.
5. Dashboards
o Visual summaries and reports of progress and
performance.

🔹 Work Item Processes (Templates)

When creating a project, choose one of the following:
Process Description
Simple: To Do, Doing, Done. Ideal for beginners. (used
Basic
in this course)
Agile Includes User Stories, Tasks, Bugs.
Scrum Uses Sprints, Backlogs, Bugs. Ideal for Scrum teams.
Formal process for capability maturity. Suited for
CMMI
enterprises.
📝 You can change the default process under Project Settings →
Boards → Process.
🔹 Setting Up a Team in Azure DevOps
 Go to your project summary → Click Invite.
 Search and add users/groups from Azure AD.
 For external users, type email → They’ll receive an invite
link.
 You can manage team members and permissions in the
Project Settings.

🔹 Creating Your First Azure Board

1. Go to Boards → Boards in the side menu.
2. You'll see To Do / Doing / Done columns (Kanban layout).
3. Click New Item to create a new work item.
o Example: “Create Git Workflow”
o Hit Enter to add it to the board.
4. Click ellipses (⋯) on an item → Add details like:
o Description
o Attachments
o Discussion
o History
o Links
 5. Move work items across the board as they progress (drag-
and-drop).

🔹 What is a Kanban Board?

 A visual tool to manage workflow.
 Columns represent stages of work (e.g., To Do, Doing,
Done).
 Items (cards) represent tasks/stories.
 Helps track progress, spot bottlenecks, and prioritize
work.
Azure DevOps Boards - Key Concepts & Terminology
📌 Intersection of Disciplines
 Azure DevOps combines:
o Development
o Operations
o Project/Product Management
 Boards are heavily focused on project management tasks
like tracking work, timelines, and deliverables.

Sprints
  Definition: A time-boxed period during which a planned
set of work is completed.
 Typical Duration: 1 to 3 weeks (commonly 2 weeks).
 Purpose:
o Break down large projects into smaller, manageable
pieces.
o Track deadlines and deliverables more effectively.
🛠 Sprint Setup in Azure DevOps
 Sprints are organizational containers for work items.
 Defined by:
o Name
o Start/End Date
o Associated Project
 Can plan for future sprints even if they’re months away.

Work Item Processes

 Three Main Process Types:
1. Basic
2. Agile
3. Scrum
  Each defines different work item types.
ℹ️You can change the work item process at the organization
level via organization settings.

Agile vs Scrum
 Agile: Philosophy for iterative and collaborative software
development.
 Scrum: A framework under Agile with defined roles (Scrum
Master, Product Owner), ceremonies (Sprints, Stand-ups),
and artifacts (Backlogs, Sprint Goals).

Work Item Types in Agile/Scrum

1. Epic
o High-level initiative (e.g., Deploy mobile app)
o Roll-up container for features
2. Feature
o A product capability (e.g., Add mobile shopping cart)
o Roll-up container for user stories
3. User Story
o Represents a user need or requirement
o Includes:
  Description
 Acceptance Criteria
4. Task
o Actionable step within a user story
5. Bug
o Defect or issue in the product
6. Issue, Blocker, Impediment
o Additional item types in Scrum workflows

Working with Boards

 Creating Work Items:
o Use the Work Items section to create stories, features,
tasks, epics, bugs, etc.
 Modifying Work Items:
o Change the type using the dropdown (e.g., from Story
→ Feature).
 Backlogs & Prioritization:
o View and manage all items in the backlog.
o Drag and drop items to assign them to a sprint (e.g.,
Sprint 2).
Additional Tips
 Agile Boards = Kanban-like visuals
 Scrum Boards = Look similar to Kanban but follow Scrum
rules
 Don’t worry about learning all terms at once; get familiar
over time
 There is a separate course available to deep dive into Agile
& Scrum
📌 Azure Boards and GitHub Integration
 Purpose: Allows linking GitHub commits and pull requests
to Azure work items.
 Use Case: Manage code in GitHub while planning and
tracking in Azure Boards.
🔗 Steps to Link GitHub to Azure Boards:
1. Go to Project Settings → Boards → GitHub Connections.
2. Connect GitHub Account using username/password or
personal access token.
3. Select GitHub Repositories to connect with your Azure
project.
4. Review, approve, and authorize the connection.
✅ Linking Work Items to GitHub:
 Open a work item → go to the Development section.
 Click Add link → choose type (e.g., commit or pull
request).
 Paste the URL of the GitHub commit/PR.

📌 Queries in Azure Boards

 Used to search, filter, and analyze work items.
 Create custom filters like:
o Work items assigned to a specific user.
o Items not completed.
o Stories with high effort/points.
Features:
 Editor tab: Build and edit the query.
 Results tab: View filtered work items.
 Save query: For reuse, dynamic updates.
 Export to CSV: For reports or data sharing.
 Bulk Update: Reassign items, change statuses, etc.
 Email query results to team members.
📌 Use Cases for Boards Features
🔹 Work Items:
 Track tasks, bugs, stories assigned to you.
 View items where you're:
o Assigned
o Mentioned
o A follower
🔹 Boards (Kanban):
 Visualize workflow and progress (To Do → Doing → Done).
 Add items to backlog quickly.
 Great for teams following Agile or Kanban processes.
🔹 Backlogs:
 Helps plan sprints, prioritize features.
 Product Owners/Scrum Masters often work here.
 Groom backlog, set priorities, and filter/tag items for
upcoming sprints.
🔹 Sprints:
 Implement Scrum framework:
o Define sprint name, duration (timebox).
o Assign tasks to backlog items.
 o Set team capacity.
o Monitor burn down charts.

📌 Key Takeaways
 Azure DevOps Boards is a powerful planning and tracking
tool.
 Integration with GitHub adds value for teams using both
platforms.
 Use queries for reporting and tracking status.
 Boards, Backlogs, and Sprints provide full Agile/Scrum
support.
 You’ll likely use a small portion of Azure DevOps – focus on
tools relevant to your workflow.
 🎴 Flashcards – Azure Boards & GitHub Integration
 Q1: What is the main benefit of linking GitHub to
Azure Boards?
A1: It allows you to link commits and pull requests from
GitHub to Azure work items for better tracking and
collaboration.
 Q2: Where do you go to connect GitHub to your Azure
Boards project?
A2: Project Settings → Boards → GitHub Connections
 Q3: What types of GitHub links can be added to Azure
Boards work items?
A3: GitHub commits and pull requests.
 Q4: What information is needed to link a GitHub
commit to a work item?
A4: The URL of the GitHub commit or pull request.


 🎴 Flashcards – Queries
 Q5: What is the purpose of queries in Azure Boards?
A5: To filter and retrieve specific sets of work items based
on conditions like assigned user, status, etc.
 Q6: Can query results be exported?
A6: Yes, query results can be exported as CSV files.
 Q7: What are two main tabs in the Queries section?
A7: Editor (to build queries) and Results (to view
outcomes).
 Q8: What can you do with saved queries?
A8: Reuse them later, email results, or perform bulk
updates.


 🎴 Flashcards – Work Items

 Q9: What can you track with work items in Azure
Boards?
A9: Tasks, bugs, features, user stories, and issues.
 Q10: Who can a work item be assigned to?
A10: A user or a group within the project.
 Q11: What can you see in the “Development” section of
a work item?
A11: Links to GitHub commits and pull requests.


 🎴 Flashcards – Boards (Kanban)

  Q12: What is the primary purpose of the Boards view?
A12: To visualize the flow of work using Kanban-style
columns (To Do, Doing, Done).
 Q13: Can you add work items directly from the Board?
A13: Yes, by clicking “New” and typing a title.


 🎴 Flashcards – Backlogs
 Q14: What is backlog grooming?
A14: The process of reviewing, refining, and prioritizing
backlog items for upcoming sprints.
 Q15: Who typically manages the backlog?
A15: Scrum Masters and Product Owners.


 🎴 Flashcards – Sprints
 Q16: What is a sprint in Azure Boards?
A16: A time-boxed iteration where planned work is
completed.
 Q17: What can you configure within a sprint?
A17: Sprint name, duration, team capacity, tasks, and burn
down chart.
 Q18: What chart helps track progress during a sprint?
A18: The burn down chart.
📘 Section 3 Notes – Azure Repos, Git, GitHub & Build
Environment Setup

🔹 1. Introduction to Azure Repos

  Azure Repos: A place to store, manage, and collaborate on
code.
 It provides unlimited cloud-hosted private Git repos.
 Supports version control, collaboration via pull requests,
and advanced file management.
☑️Key Concepts:
 Azure Repo = Code Collaboration Space
 Used for tracking, editing, and rolling back code changes.
 Conceptually similar to a shared Excel file on SharePoint:
collaborative, versioned, and accessible.
🔧 Version Control Types:
1. Git (Distributed) – Most common, allows offline work with
local repositories.
2. TFVC (Team Foundation Version Control) – Centralized
version control system.

🔹 2. Git vs GitHub
🔁 Git:
 Open-source distributed version control system.
 Created by Linus Torvalds (Linux creator).
 Installed locally on your machine.
  You interact with Git mainly through the command line.
 Tracks changes to your code, allowing commits and
rollbacks.
🌐 GitHub:
 A web-based platform that hosts Git repositories.
 Adds a UI layer on top of Git.
 Allows code hosting, collaboration (forks, pull requests),
issue tracking, and project management.
 GitHub relies on Git under the hood.
🔄 Git + GitHub Workflow:
1. Fork a repo from GitHub (make a personal copy).
2. Work on it locally using Git.
3. Commit changes locally.
4. Push changes back to GitHub.
5. Open a Pull Request (PR) to merge your changes into the
original codebase.

🔹 3. Setting Up the Build Environment

To follow along with exercises in the course, you’ll need a
proper development setup:
✅ Checklist:
1. Install Node.js
o JavaScript runtime environment.
o Required to run sample JavaScript applications in the
course.
o Website: https://nodejs.org
2. Install Git
o Enables you to work with Git-based repositories.
o Install from https://git-scm.com or through your OS’s
package manager.
o Supports Linux, macOS, and Windows.
3. Install an IDE
o IDE = Integrated Development Environment.
o Recommended: Visual Studio Code (VS Code) –
lightweight, powerful, and open source.
o Alternative: Full Visual Studio, JetBrains Rider, etc.
4. Create a GitHub Account
o URL: https://github.com/join
o Needed to fork repos, push/pull code, and submit
PRs.
o You'll connect Azure DevOps to GitHub for real-world
CI/CD integration.
🧠 Bonus Concepts
 Even non-coders can benefit from understanding
Git/GitHub in DevOps.
 Azure Repos and GitHub can work together – e.g., link
commits from GitHub to Azure Boards.
 Understanding version control is more important than
knowing how to code.
Section 3: Repository Creation, Branching, Committing, and
Pull Requests

Creating a GitHub Repository:

1. Setting Up the GitHub Account:
o Start by logging into GitHub.
o Create a repository called "Hello World" (or similar)
for practice.
2. Forking the Repository:
o Fork the Flatris repository by searching for "Flatris" in
GitHub and selecting the repository (from user
Javascript Skidding).
o Forking means creating a personal copy of the
repository in your account to work on.
 o After forking, the repository will appear under your
GitHub account.
3. Cloning the Repository:
o Clone the forked repository into your local
environment or into Azure DevOps.
o Copy the URL from GitHub for cloning, then navigate
to Azure DevOps.
o In Azure DevOps, open the Repos section and choose
to import a repository using the URL copied from
GitHub.
4. Setting Up in Azure DevOps:
o In Azure DevOps, create a repository in the Repos
section. You can choose the Git repository type.
o Add a README file when initializing the repository to
set it up easily.
o Import the forked GitHub repository by pasting the
Git clone URL into Azure DevOps, which imports the
repo into Azure DevOps.

Branching, Committing, and Pull Requests:

1. Branching:
 o A branch represents a unique set of code changes,
typically used for feature development or bug fixes.
o Creating a branch keeps the master branch stable
while allowing changes to be made in parallel.
o Example: Create a branch from the master branch
(often called main in newer repositories).
2. Committing Changes:
o Once changes are made (such as updating a README
file), you commit those changes.
o Committing in Git is like saving changes to a
document. It creates a snapshot of your code at a
specific point in time.
o Add a meaningful commit message to describe what
has been changed, for example, "Updated README
file."
3. Creating Pull Requests:
o A pull request is a request to merge changes from one
branch (e.g., a feature branch) into another branch
(e.g., master or main).
o You can create a pull request directly after committing
the changes in Azure DevOps.
 o Pull requests allow other team members to review
changes before they are merged into the main
codebase.
4. Reviewing and Merging Pull Requests:
o After creating the pull request, team members (or
yourself, if working solo) review the changes.
o Changes can be reviewed using the side-by-side view
of the original and modified files.
o The reviewer can approve, suggest edits, or reject the
pull request.
o Once approved, the pull request can be merged into
the main branch, completing the workflow.

Other Concepts:
 Git Ignore File:
o A .gitignore file is used to tell Git which files or
directories to ignore, ensuring that unnecessary or
sensitive files aren’t tracked by Git (e.g., system files
like .DS_Store).
 Naming Conventions for Branches:
o It's important to use clear naming conventions for
branches, often including the type of task (e.g.,
 feature/, bugfix/) and the team or developer
responsible for the change.
 Visual Indicators for Pull Requests:
o Azure DevOps provides visual indicators, showing
whether the pull request is open, being reviewed, or
merged.
o Upon completing a merge, Azure DevOps allows for
easy navigation back to the updated files, showing the
changes that have been applied.

Final Steps:
1. Commit and Merge:
o Once the branch is reviewed and approved, complete
the pull request by merging the changes into the main
branch.
o This concludes the process of creating a branch,
making changes, and merging them via a pull request.
2. Cloning a Repository Locally:
o Instead of working directly in the web interface, a

more common scenario involves working with a local

copy of a repository in an Integrated Development
Environment (IDE).
o You can clone the repository in two ways:
 1. Graphical Interface: You can clone using a
supported IDE like VS Code by clicking on the
"Clone" button.
2. Command Line: Alternatively, you can use the
URL provided by Azure DevOps and clone the
repository using Git commands.
3. Working with the Repository Locally:
o Once the repo is cloned locally, you can work with it

in your IDE.
o For example, in VS Code, you can open the local

repository, create a new branch (e.g., "change1"), and

start making changes.
o You can modify files, like the README file, and use

Source Control in VS Code to track these changes.

4. Committing Changes:
o After making changes, you commit them in VS Code.

o You'll see the changes under Source Control, and

after adding a commit message, you can commit them

to the branch.
5. Pushing Changes to Azure DevOps:
o After committing the changes locally, you need to

publish them to Azure DevOps.

o This is done by clicking the "Publish Changes" button

in VS Code to sync your local branch with the remote

repository.
6. Creating a Pull Request (PR):
o Once the changes are published to Azure DevOps, a

pull request can be created to merge the changes into

the main branch (e.g., master).
 o The PR process can include reviews (even if it's just
your own review), and once approved, you can merge
the changes.
7. Viewing Commit History:
o Azure DevOps allows you to view the commit history

of both individual files and the entire repository.

o You can investigate specific commits and see what

changes were made by clicking on them.

o If necessary, you can revert a commit, which will

create a new branch and a new PR to undo the

changes.
8. Deleting Branches After Merge:
o After completing a merge, it's a good practice to delete

the branch to keep the repository clean and organized.

o Azure DevOps offers an option to automatically delete

the branch after the merge, which keeps your list of

branches neat and tidy.
9. Associating Pull Requests with Work Items:
o A PR can also be linked to specific work items. After

merging the PR, you can close or complete the

associated work items, which is helpful in real-world
project management.
10. Best Practices:
o Always delete branches after merging to maintain a

clean repository.
o Use the commit history to roll back any changes if

issues arise after a merge.

o Regularly sync your local repository with Azure

DevOps to avoid conflicts.

This process mimics real-world scenarios where developers
work in their local IDEs, commit changes, and then sync those
changes back to Azure DevOps, ensuring version control and
collaboration are managed effectively.
Flashcard 1:
Q: What is the main difference between editing code in the
browser and working with code locally in Azure DevOps?
A: Editing code in the browser is a simple, quick way to make
changes, while working locally involves cloning the repository,
editing code in an IDE, and committing/pushing changes using
Git.

Flashcard 2:
Q: How do you clone a repository locally in Azure DevOps?
A: You can clone a repository using:
 The graphical interface in an IDE like Visual Studio Code.
 Git commands using the URL provided in Azure DevOps
(via the command line).

Flashcard 3:
Q: What is the first step after cloning a repository to your local
machine?
A: The first step is to create a new branch in your IDE where you
will make changes to the code.

Flashcard 4:
Q: In VS Code, how can you track the changes you've made to a
file?
A: You can use the Source Control tab in VS Code to track
changes. It shows you the files that have been modified and
allows you to commit them.

Flashcard 5:
Q: How do you commit changes to a repository in VS Code?
A: After editing files, you can:
1. Add a commit message in the Source Control tab.
2. Click the Commit button to save your changes to the local
branch.

Flashcard 6:
Q: After committing changes in VS Code, what is the next step?
A: The next step is to publish the changes to Azure DevOps by
clicking on the Publish Changes button in VS Code to sync your
local branch with the remote repository.
Flashcard 7:
Q: What is a pull request (PR) in Azure DevOps?
A: A pull request is a request to merge your changes from one
branch (e.g., a feature branch) into another branch (e.g., the
main branch). It is used to review and approve changes before
merging.

Flashcard 8:
Q: What can you do if you need to roll back a change made in a
commit?
A: You can revert the commit, which creates a new branch with
the reverted changes and then creates a new pull request to
undo the previous changes.

Flashcard 9:
Q: Why is it good practice to delete branches after merging in
Azure DevOps?
A: Deleting branches after merging keeps the repository clean
and organized, preventing unnecessary branches from
cluttering the branch list.

Flashcard 10:
Q: How can you associate a pull request with a work item in
Azure DevOps?
A: You can attach a pull request to a work item by linking them
during the pull request creation process. This helps track the
work associated with the changes made.

Flashcard 11:
Q: What are the two views you can use to investigate the
commit history in Azure DevOps?
A: You can use:
1. File History View: To investigate changes to a specific file.
2. Commits View: To see the entire commit history of the
repository.

Flashcard 12:
Q: What happens when you revert a commit in Azure DevOps?
A: Reverting a commit creates a new branch with the reversed
changes, and you then create a new pull request to merge the
reversed changes back into the main branch.
✅ Section 4: Azure Pipelines — CI/CD, Build and Release
Pipelines

🔁 CI/CD (Continuous Integration / Continuous Deployment)

  CI/CD is the goal of DevOps practices: automate building,
testing, and deploying code.
 Continuous Integration (CI): Automatically build and test
code whenever changes are pushed.
 Continuous Deployment (CD): Automatically deploy code
to production or environments after passing tests.

🧩 Azure Pipelines Overview

 Azure Pipelines is the execution environment for CI/CD.
 It works with any language, platform, or cloud, and
supports integration with GitHub, Bitbucket, Azure Repos,
etc.
 Pipelines automate tasks like:
o Building code
o Testing code
o Creating artifacts
o Deploying code

Two Types of Pipelines

1. Build Pipeline:
o Focuses on what gets built.
 o Pulls code from source control (e.g., Azure Repo,
GitHub).
o Runs build tasks (compilation, packaging).
o Outputs a build artifact.
o Triggered usually when code is pushed or merged.
2. Release Pipeline:
o Focuses on where the artifact gets deployed.
o Takes the artifact and deploys it through
environments:
 Test
 Acceptance
 Production
o Can be automated or manual.

⚙️Pipeline Components
 Phases: Grouping of steps (logical division in the pipeline).
 Tasks: The actual steps performed (e.g., build, test,
deploy).
 Agents: Execute tasks in a pipeline.
o Microsoft-hosted Agents: No need to install;
maintained by Microsoft.
 o Self-hosted Agents: You manage and configure.
 Agent Pools: Collection of agents for task execution.

📦 Build Artifacts
 Final output of a build pipeline — the deployable unit.
 Examples:
o .zip file (Java/.NET app)
o .dll or .jar files
o Docker image
o VM image

📜 YAML in Pipelines
 Azure Pipelines use YAML files to define CI/CD steps.
 YAML is a human-readable configuration as code format.
 Stored in the same repo as your code.
 Enables version control of pipeline configuration.
YAML = Configuration as Code
 Reproducible
 Portable
 Easy to audit changes
Creating a Build Pipeline (Button-Click Flow)
1. Go to Pipelines > New Pipeline
2. Choose source code location (Azure Repos Git, GitHub,
Bitbucket, etc.)
3. Choose Starter Pipeline or existing YAML
4. Define trigger (trigger: master)
5. Define build VM (vmImage: ubuntu-latest)
6. Save and run — commits YAML to repo
7. Monitor job logs and build status

📌 Key Benefits of Azure Pipelines

 Fully integrated with Azure DevOps
 Scales to any language or platform
 Detailed logging & traceability
 Identifies problematic commits
 Automates repetitive tasks
 Confidence in tested, validated builds
🔧 Build Pipeline (CI - Continuous Integration)
1. Repository Source Selection:
 o Select GitHub (code source).
o Establish a connection between Azure DevOps and
GitHub using the Azure Pipelines GitHub App.
2. Choose Repository:
o Select the repo (e.g., fletters-lab) from your GitHub
account.
3. Select Template:
o Choose a suitable template (e.g., Node.js with React).
o Azure DevOps auto-generates a YAML pipeline file
(e.g., .azure-pipelines.yml).
4. Build Steps in YAML:
o npm install, npm run build, etc., typical of
Node.js/React projects.
o Trigger on master branch by default.
5. Save & Run:
o Commit message: e.g., "fletters GitHub CI with Azure
Pipelines".
o This executes the build pipeline and verifies if the
code builds successfully.

🚀 Release Pipeline (CD - Continuous Deployment)

1. Go to Releases Section in Azure DevOps and click New
Pipeline.
2. Template Selection:
o Use Azure App Service Deployment template (or start
with an empty job).
o This guides the process to deploy to Azure App
Service.
3. Configure Stages:
o Stage = logical group of deployment tasks (e.g.,
Deploy).
o You can rename it for clarity.
4. Configure Tasks:
o Select the Azure subscription (linked via a service
connection).
o Choose App Type (e.g., Web App on Linux).
o Select or type the App Service name you created in
Azure.
5. Create Web App on Azure (in portal.azure.com):
o Resource group, name, stack (e.g., Node.js), and
region.
o This is the target environment for deployment.
 6. Add Artifact (the "What" to deploy):
o Select the Build Pipeline created earlier.
o Choose the default source alias and latest version.
7. Save and Create Release:
o After everything is configured, save the pipeline.
o Trigger a release (manual or automatic).

✅ Results
 You should now have:
o A build pipeline that compiles the code whenever
changes are pushed.
o A release pipeline that deploys the build to Azure App
Service.
This forms a basic but complete CI/CD flow for deploying a web
app using Azure DevOps and GitHub.
📌 Problem in Deployment (Initial Release Pipeline Failure)
 The release pipeline failed during deployment due to
symbolic links created by Babel.
 These symbolic links were absolute paths referring to
locations in Azure DevOps build agents, which broke once
deployed to Azure Web App.
🔧 Root Cause
 The file babel.config.js in the repo caused the compiler to
generate absolute symlinks at build time.
 These references failed in production because they
pointed to DevOps servers, not Azure Web App
environments.

Solution Overview
To fix the issue and deploy successfully, three key steps were
done:
1. Create the Azure Web App
2. Create a Service Connection
3. Use a custom YAML pipeline with build and release
combined

Step 1: Create Azure Web App

 Go to Azure Portal > Create Resource > Web App
 Settings to choose:
o Subscription
o Resource Group
 o Unique App Name
o Runtime Stack: Node 12 LTS (Node 10 also works, but
LTS recommended)
o Region: Based on user location
o App Service Plan: Free or Basic Tier (Basic preferred)
🔹 You can always scale up or change the tier later using the
"Scale Up" option in the Web App settings.

Step 2: Create a Service Connection in Azure DevOps

 Go to Project Settings > Service Connections
 Select Azure Resource Manager > Next
 Choose Service principal (automatic) for auth
 Choose:
o Subscription
o Resource Group
o Service Connection Name (you’ll use this in YAML)

Step 3: Create a Combined Build + Release YAML Pipeline

 Go to Pipelines > Pipelines > New Pipeline
 Choose Azure Repos Git
  Select your repo (e.g., Flatris)
 Choose a template (any) — you'll replace the YAML
anyway
 Replace with provided custom YAML (copy-paste)
✍️Modify These 4 Variables in the YAML:
yaml
CopyEdit
variables:
azureSubscription: '<YOUR_SERVICE_CONNECTION_NAME>'
linuxAppName: '<YOUR_WEB_APP_NAME>'
resourceGroupName: '<YOUR_RESOURCE_GROUP>'
environmentName: '<YOUR_ENVIRONMENT_NAME>'

🧾 What the Custom YAML Does

 Two stages:
1. Archive Stage:
 Builds the app
 Creates a .zip file as an artifact
2. Deploy Stage:
 Uploads the zip to the Azure Web App
  Installs dependencies after transfer
 Key instruction in YAML:
o A specific app setting flag delays build until after files
are transferred
⚠️This avoids the symbolic link issue by building in Azure App
Service, not on DevOps agent.

🧪 After Running the Pipeline

 Pipeline has two nodes/stages: Archive and Deploy
 You can click on each node to view detailed logs
o Archive: Shows .zip created (e.g., 17 MB)
o Deploy: Shows install logs (might show harmless
warning: “Failed to update deployment history”)
 Final check: visit the web app URL to test the Flatris game
o If home screen doesn’t show, try navigating via Home
link

🎯 Key Learnings
 Every repo has its quirks; DevOps often requires custom
handling per application.
  Combine build + deploy into one YAML file when needed
(Microsoft supports this approach now).
 Learn to debug pipeline failures by checking logs and
understanding build environments.
 The pipeline setup becomes repeatable once configured —
just tweak for new repos.
✅ Steps for CI/CD Pipeline Setup (High-Level)
1. Import the Updated Repo:
o Use the new Flatter repo (with symbolic link issues
fixed) from the “Like A Boss Learning” GitHub
account.
o Use Azure DevOps > Repos > Import Repository to
bring it in.
2. Verify/Create Azure App Service:
o Confirm the Linux App Service in Azure portal (e.g.,
Flatter Gen).
o Note: App Service plan is Linux-based — critical for
later YAML settings.
3. Configure Service Connection in Azure DevOps:
o Go to Project Settings > Pipelines > Service
connections.
 o Create a new one for Azure Resource Manager
(Service principal - automatic).
o Select your subscription and resource group.
o Save it with a meaningful name (e.g., Linux Service
Connection).
4. Create/Edit Build Pipeline (YAML):
o Create a new build pipeline.
o Select your imported repo and use a Node.js
template.
o Replace the auto-generated YAML with a custom one
(provided in the lesson).
o Edit these placeholders in the YAML:
 subscription
 webAppName
 resourceGroupName
 environmentName
5. Run Pipeline:
o Click Run, and it will trigger both build and release
stages.
o Even if there’s a warning (e.g., symbolic link issues or
deployment history failure), the app should deploy.
 6. Verify Deployment:
o Visit the provided App Service URL.
o Confirm the game/web app is live.

🛠 Symbolic Link Issue (Background)

Older deployments failed because of how Azure DevOps
handled symbolic links during code transfer to App Service.
Microsoft patched the process, and this updated repo/YAML
solves that.

🧠 Takeaway
You’ve now seen how a fully integrated CI/CD pipeline can:
 Pull code from repo
 Build it
 Deploy it to Azure App Service All from within Azure
DevOps using only a few clicks and YAML edits.
✅ Method 1: Deploying from Azure Portal using Azure DevOps
(CI/CD pipeline)
Steps Summary:
1. Log in to Azure Portal:
Go to portal.azure.com and sign in.
2. Create a New DevOps Project:
o Go to "Create a resource" → Search for and select
DevOps Project.
o Choose a technology stack (e.g., ASP.NET Core with
SQL Database).
o Select a deployment target (e.g., Azure Web App for
Windows).
3. Configure Resources:
o Set project name, region, and database settings.
o Link to an existing DevOps organization (or create a
new one at dev.azure.com).
4. Azure Automatically Sets Up:
o A sample .NET MVC app.
o Build pipeline (CI): Automatically builds when
changes are made to the main branch.
o Release pipeline (CD): Automatically deploys new
builds.
5. Verify Deployment:
o Access the live site using the app’s endpoint.
o Make a small code change (e.g., in Index.cshtml) via
Azure DevOps Repos.
 o Commit the change to trigger CI/CD.
o View updates on the site after deployment.

✅ Method 2: Deploying from Visual Studio Code using Azure

Extensions
Steps Summary:
1. Set Up Your Local Codebase:
o Open your app in VS Code (e.g., a game like Flatris
cloned from GitHub).
2. Install Azure Extensions in VS Code:
o Azure Account
o Azure App Service
3. Sign in to Azure from VS Code:
o Connect your Azure subscription.
4. Verify App Locally:
o Run using terminal:
bash
CopyEdit
npm install
npm run build
npm start
o Confirm it's running at http://localhost:3000.
5. Modify Configuration for Azure:
o Change port handling from hardcoded 3000 to:
js
CopyEdit
process.env.PORT
6. Deploy from VS Code:
o Use Command Palette → Azure: Deploy to Web App
o Select your folder and web app instance (or create a
new one).
o Confirm deployment and view the app live in Azure.

💡 Key Differences:
Method 1 (Azure
Feature Method 2 (VS Code)
Portal)
Beginners / learning Developers working within
Ideal for
CI/CD basics an IDE
Deployment One-click manual deploy
Full CI/CD pipeline
style from IDE
 Method 1 (Azure
Feature Method 2 (VS Code)
Portal)
Works with any language
Language Supports .NET,
supported by Azure Web
flexibility Node.js, Java, etc.
Apps
Extension Yes (Azure extensions in VS
No
needed Code)
Code change Manual deployment
Auto build/release
trigger needed after local change
🧠 Flashcards for Section 4 – Azure Pipelines (CI/CD)
Question Answer
A cloud service that enables CI/CD for
What is Azure Pipeline? building, testing, and deploying code
automatically.
Continuous Integration –
What does CI stand for? automatically building and testing
code when developers push changes.
Continuous Delivery or Deployment –
What does CD stand for? automatically releasing code to
staging or production environments.
What are the two types Build Pipeline (CI) and Release
of pipelines in Azure Pipeline (CD).
Question Answer
DevOps?
What is an Agent in Azure A compute resource (VM) that runs
Pipelines? one job at a time in the pipeline.
An agent that you configure and
What is a Self-hosted
maintain on your own machine or
Agent?
VM.
An agent maintained by Microsoft
What is a Microsoft-
that runs your pipeline jobs on
hosted Agent?
demand.
A compiled output (e.g., binaries,
What is an Artifact in
packages, files) produced by a build
Azure Pipelines?
pipeline.
What is the default
YAML (Yet Another Markup
format for configuring
Language).
pipelines?
What is the syntax to
trigger a pipeline on main trigger: - main
branch in YAML?
What does the pool Which agent pool to use (e.g.,
keyword specify in YAML? vmImage: 'ubuntu-latest').
How can you deploy a Use the Azure App Service extension
Question Answer
local app to Azure App
and run the deploy command.
Service from VS Code?
Logical sections in a pipeline such as
What are pipeline stages?
Build, Test, Deploy.
How do you view pipeline
Go to Pipelines → Click on the
run history in Azure
pipeline → See past runs.
DevOps?

💬 Interview Questions (With Suggested Answers)

🔹 Basic-Level
1. What is the difference between CI and CD?
CI is about automatically building and testing code,
whereas CD focuses on automatically deploying tested
code to environments like staging or production.
2. What tools does Azure DevOps provide for implementing
CI/CD?
Azure DevOps provides Azure Pipelines for both CI (Build)
and CD (Release), along with repositories, test plans, and
artifact storage.
3. Can you explain what a pipeline agent is?
An agent is a machine (hosted or self-hosted) that
 performs the steps defined in a pipeline like building code,
running tests, or deploying.
🔹 Intermediate-Level
4. What is the role of artifacts in Azure Pipelines?
Artifacts are outputs from the build process that are
passed to the release pipeline for deployment.
5. What is the advantage of using YAML for pipeline
configuration?
YAML allows versioning the pipeline definition along with
source code and supports infrastructure-as-code practices.
6. How does the pipeline get triggered automatically?
Using the trigger keyword in YAML or setting up
continuous integration triggers in the classic editor.
7. What happens if a build fails in the CI pipeline?
The pipeline stops, and the failed step is highlighted.
Developers can review logs and fix the issue before
retrying.
🔹 Advanced-Level
8. How do you secure secrets like API keys in Azure
Pipelines?
Use Azure Key Vault or pipeline secrets/variables with
secret permissions.
 9. Have you used any deployment strategies in Azure
Pipelines (e.g., blue-green, canary)?
Yes, Azure Pipelines supports strategies like canary releases
using deployment jobs, environments, and approvals.
10. What’s the difference between a pipeline stage, job,
and step?
Stage: major phase (e.g., Build, Deploy). Job: runs on one
agent. Step: individual task within a job.
✅ Azure Test Plans in Azure DevOps – Summary
🧪 Types of Tests in DevOps
1. Unit Test:
o Written by developers.
o Verifies individual functions/methods.
o Fast and low-cost to automate.
o Forms the base of the testing pyramid.
2. Integration Test:
o Ensures different components/modules work
together.
o Requires parts of the app to be up and running.
3. API Test:
o Validates API endpoints in a functional app.
 4. Automated UI Test (End-to-End Test):
o Simulates real user interactions.
o E.g., login, payment flow, email triggers.
5. Manual Test:
o Written and executed manually.
o Time-consuming, used sparingly.
6. Performance Test:
o Tests scalability, load handling, system reliability
under stress.
o Useful for events like Black Friday or product
launches.

🧱 The Testing Pyramid

 🟩 Base: Unit Tests (most frequent, fastest).
 🟨 Integration Tests.
 🟧 Automated UI Tests.
 🟥 Manual Tests (least frequent, most effort).

🧭 Azure DevOps Test Plans Overview

 Not included by default – requires a Test Plans license.
  Offers a 30-day trial.
 Navigate to: Organization Settings > Billing > Basic + Test
Plans to start a trial.

🔧 Test Plan Components

 Test Case: The smallest test unit (validates one feature).
 Test Suite: A group of related test cases.
 Test Plan: Container for one or more test suites and/or test
cases.

🧪 Creating a Manual Test Plan (Demo Summary)

1. Navigate to the Test Plans section.
2. Create a new Test Plan → name it.
3. Define a Test Suite and add a Test Case.
4. Test Cases include:
o Title
o Action steps
o Expected result
5. Assign test cases to testers via UI.
6. Optional: Run load tests (deprecated but still visible).
 o Requires Visual Studio Enterprise subscription.

📌 Final Tips
 Testing is code—a vital part of CI/CD workflows.
 Use tools and test types suited for your team’s structure
and project size.
 Test Plans in Azure DevOps are especially useful if you
have:
o Dedicated QA engineers
o Need structured manual and automated test tracking

🚀 Next Steps & Recommendations

 Explore further tools: Docker, Jenkins, Kubernetes, Ansible,
Terraform, etc.
 Consider certification: e.g., Azure DevOps Engineer Expert
(AZ-400).
 Leverage your current foundation to explore CI/CD
integrations.
 🧠 Flashcards: Azure DevOps Test Plans
 Flashcard 1
 Q: What is the purpose of Unit Testing?
A: To verify individual units/functions of code written by
developers. Fast and low-cost.


 Flashcard 2
 Q: What does Integration Testing validate?
A: It ensures different modules/components of an
application work together correctly.


 Flashcard 3
 Q: What kind of tests validate REST endpoints?
A: API Tests.


 Flashcard 4
 Q: What type of test simulates real user interactions in the
app?
A: Automated UI (End-to-End) Tests.


 Flashcard 5
 Q: What is the most time-consuming type of test in the
testing pyramid?
A: Manual Test.


 Flashcard 6
 Q: What test checks how the system behaves under high
load or stress?
A: Performance Test.


 Flashcard 7
 Q: What is the Testing Pyramid?
A: A concept that shows test types arranged by speed,
 reliability, and effort—from unit tests (bottom) to manual
tests (top).


 Flashcard 8
 Q: What are the three components in Azure Test Plans?
A: Test Plan, Test Suite, and Test Case.


 Flashcard 9
 Q: Are Azure Test Plans available by default in Azure
DevOps?
A: No, they require a separate Test Plans license or a 30-
day trial.


 Flashcard 10
 Q: Where can you start a free trial for Azure Test Plans?
A: Azure DevOps > Organization Settings > Billing >
Basic + Test Plans.


 Interview Questions: Azure Test Plans & Testing Types

 1. What is the difference between unit testing and
integration testing?
 Expected Answer:
Unit testing focuses on individual functions/methods,
usually written by developers.
Integration testing verifies that multiple components work
together as expected.


 2. Explain the Testing Pyramid. Why is it important?

 Expected Answer:
It organizes test types by frequency and complexity. Unit
tests form the base (most frequent), followed by integration
and UI tests. Manual tests are rare due to cost and time.


 3. How does Azure DevOps help in managing manual

test cases?
 Expected Answer:
Through Azure Test Plans, which let you create test plans,
suites, and test cases. You can assign tests, log outcomes,
and track coverage.


 4. What are the prerequisites for using Azure Test

Plans?
 Expected Answer:
You need a separate Test Plans license or a 30-day trial.
Access is through Azure DevOps > Organization Settings >
Billing.


 5. How would you manage automated and manual tests

in a CI/CD pipeline?
 Expected Answer:
Automated tests run in pipelines using build/release tasks.
Manual tests can be tracked and assigned through Azure
Test Plans, especially for exploratory or edge-case testing.


 6. When would you use performance testing in a

DevOps lifecycle?
 Expected Answer:
Before major product launches or during scaling events
(e.g., Black Friday), to ensure systems handle expected user
loads.