Processes and communications

Flow of work

DevOps is about shortening the path from idea to production and getting feedback back quickly. The exam uses a few terms for this, and you need to tell them apart.

• Flow of work: how items move through states (New, Active, Resolved, Closed, or To Do, Doing, Done) from request to release. Good flow means small batches, limited work in progress and few hand-offs.
• Kanban: visualise work as cards on columns, and set a WIP limit per column so the team finishes work before starting more. Azure Boards Kanban boards support columns, split columns (Doing/Done), swimlanes, WIP limits and card styles and rules.
• Scrum: fixed-length sprints with a backlog, sprint planning, capacity, a task board and a burndown. Azure Boards has Sprints with capacity per person and per team.
• Process templates in Azure DevOps: Basic (Epic, Issue, Task), Agile (Epic, Feature, User Story, Task, Bug), Scrum (Epic, Feature, Product Backlog Item, Task, Bug, Impediment) and CMMI (adds Requirement, Change Request, Risk, Review). Inherited processes let you customise an existing process, such as adding a field or a state. You can’t edit the system processes directly.

GitHub Flow

GitHub Flow is the lightweight branching model that GitHub itself recommends, and the exam names it.

1. main is always deployable.
2. Create a short-lived branch from main with a descriptive name.
3. Commit to the branch and push it regularly.
4. Open a pull request early to start discussion. Draft pull requests signal that work is in progress.
5. Review, run checks, and fix feedback.
6. Merge to main once approved and green.
7. Deploy from main (or deploy from the branch for verification first, then merge).

Compare with GitFlow (long-lived develop and release branches), which is heavier and suited to scheduled releases. Branching strategies are covered in the source control notes.

Feedback cycles

A feedback cycle is how quickly someone learns that a change is wrong or unwanted. The design goal is short loops at each stage.

Notifications

• Azure DevOps: personal, team and project notification settings. Subscriptions use event types (work item changed, build completed, pull request created, release deployment approval pending), filters and delivery by email or to a group. Admins create custom subscriptions and team subscriptions; individuals manage their own under user settings. Service hooks push events to other services (Teams, Slack, webhooks, Azure Service Bus, Azure Storage queues, Jenkins).
• GitHub: users choose Watch levels per repository (participating and @mentions, all activity, custom events, ignore). Notification settings control web, email and mobile. Slack and Teams apps subscribe a channel to repository events.
• Approvals are a feedback mechanism too: an Azure Pipelines environment approval or a GitHub environment required reviewer sends a request to named people.

GitHub Issues

GitHub Issues track bugs, features and tasks inside the repository. Know these features:

• Issue templates and issue forms (YAML in .github/ISSUE_TEMPLATE/) standardise what reporters supply.
• Labels, milestones, assignees and sub-issues organise work. Issue types and custom fields exist at organisation level.
• Linking: reference with #123, GH-123, or owner/repo#123. Closing keywords in a pull request description or commit message close the issue on merge into the default branch: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved followed by the reference (Fixes #42).
• Discussions are for open-ended questions, not tracked work.

Tracking work

GitHub Projects

GitHub Projects is a table, board and roadmap view over issues and pull requests, across repositories. Key points:

• Views: Table, Board (Kanban) and Roadmap (timeline). Each view has its own filters, grouping and sort.
• Custom fields: text, number, date, single select, iteration.
• Iterations give sprint-like planning.
• Built-in workflows (for example “item closed sets status to Done”) and GitHub Actions automate status changes. Projects can add items automatically with an auto-add workflow.
• Projects live at user or organisation level, not inside one repository.

Azure Boards

Azure Boards is the work tracking service in Azure DevOps. The hierarchy is Epic > Feature > User Story (or PBI) > Task, with Bugs alongside.

• Backlogs (product, portfolio), boards, sprints, queries, delivery plans (cross-team calendar view) and analytics widgets.
• Queries: flat list, tree of work items, or direct links. Query by area path, iteration path, state, tags, assigned to. Saved queries can be shared and pinned to dashboards, and can drive charts.
• Area paths split work by team or component, iteration paths by sprint.
• Tags add free-form labels.

Connecting Azure Boards to GitHub

You can keep code on GitHub and work items in Azure Boards. The tie is the Azure Boards app for GitHub.

1. Install the Azure Boards GitHub App from the Marketplace, or connect from Project settings > GitHub connections in Azure DevOps. Authentication uses a GitHub login or a PAT for older setups.
2. Select the repositories to link.
3. Mention a work item in a commit message, pull request title or description using AB#123. The link appears on the work item as a GitHub commit or pull request.
4. Use a closing keyword with it, such as Fixes AB#123, to move the work item to a completed state when the pull request merges.

Other direction: in a GitHub repository, links to Azure Boards show up through the app. A work item can be linked to a pull request from the work item’s Development section.

Connecting Azure Boards to Azure Repos

Inside Azure DevOps, mention #123 in a commit or pull request, or link a work item to a branch, commit or pull request from the work item form. You can also create a branch directly from a work item. Branch policies can require that pull requests have linked work items.

Traceability

Traceability means you can follow a requirement through code, build, release and production, and back again. Questions describe an audit or incident (“which change introduced this bug?”, “which work items shipped in this release?”) and ask which feature gives the link.

Source, bug and quality traceability

• Source: every commit references a work item. Enforce it with a branch policy (check for linked work items) or a pull request template that asks for a link.
• Bug: a failing test run in Azure Pipelines can create a bug automatically, linked to the build and the test case. Test Plans bugs carry repro steps, screenshots and links to the test.
• Quality: code coverage, test pass rate, SonarQube/SonarCloud quality gate and Advanced Security alerts are attached to the pull request and the build. Required status checks block merging when quality drops.

Metrics and dashboards

The exam asks which metric answers which problem. Use the DORA metrics as the backbone.

Do not mix lead time and cycle time. Lead time includes the wait in the backlog before work began; cycle time starts when work starts.

Azure DevOps dashboards and analytics

• Dashboards are made of widgets. Team dashboards belong to a team, project dashboards are not tied to a team (these have their own permissions).
• Useful widgets: Lead time, Cycle time, Cumulative flow diagram (CFD), Velocity, Burndown, Sprint burndown, Query results, Query tile, Chart for work items, Build history, Test results trend, Deployment status, Pull request and Code tile.
• Cumulative flow diagram: bands show how many items sit in each state over time. Widening bands expose bottlenecks. Use it with WIP limits.
• Velocity: story points completed per sprint, used to forecast.
• Analytics (the Analytics service) and Power BI with OData feeds let you build custom reports on work items, pipelines and tests. Use the Analytics views for Power BI. For ad-hoc questions, OData queries against https://analytics.dev.azure.com/{org}/{project}/_odata/.
• Azure Monitor workbooks and Grafana can mix pipeline and production metrics.

Metrics by area

You may be asked what to measure in a specific area. Use these as defaults.

GitHub insights

GitHub has Insights on a repository: pulse, contributors, traffic, commits, code frequency, dependency graph, forks. Projects has charts (insights) built from fields. Actions has usage metrics (minutes, runs). Instrumentation coverage is in the instrumentation notes.

Documentation and collaboration

Wikis

Azure DevOps offers two wiki types:

• Pages are Markdown. Hierarchy comes from folders and the .order file that sets page order.
• Mermaid diagrams are supported in wiki pages with the fenced block ::: mermaid … ::: in Azure DevOps wikis. GitHub renders a standard fenced code block with the mermaid language tag in Markdown files, issues and pull requests.
• GitHub has the repository wiki (a separate Git repo .wiki.git) and also renders README.md, docs/ folders and GitHub Pages sites.

Example Mermaid flowchart:

flowchart LR
  A[Commit] --> B[Build] --> C[Test] --> D[Deploy]

Mermaid supports flowcharts, sequence diagrams, Gantt charts, class diagrams, state diagrams and Git graphs. Because it is text, diagrams are diffable and reviewable.

Release notes

• GitHub: Releases are built on tags. Generate release notes automatically from merged pull requests, grouped by labels using .github/release.yml categories. Release notes can also be attached to a Marketplace publication.
• Azure Pipelines: release notes can be produced by tasks and extensions (for example a generator that pulls associated work items and commits from the build and writes Markdown to the wiki or an artifact). The built-in Releases history lists associated work items and commits too.
• Use conventional commits (feat:, fix:, BREAKING CHANGE:) so tooling can classify changes and infer a version bump.

API documentation

• OpenAPI/Swagger definitions describe a REST API. Generate them from code (Swashbuckle, NSwag, Microsoft.AspNetCore.OpenApi) in the build and publish them as an artifact.
• Azure API Management developer portal publishes documentation and a try-it console from imported OpenAPI definitions.
• Static site generators (DocFX, MkDocs, Docusaurus) build docs in a pipeline and deploy to GitHub Pages or Azure Static Web Apps.
• XML doc comments or docstrings in code feed generated reference docs.

Documentation from Git history

Git history is a data source for generated docs:

• git log --pretty=format:"%h %s" v1.0..v1.1 lists commits between two tags. A pipeline can turn that into a changelog.
• Conventional commits plus tools like release-please, semantic-release or git-cliff produce CHANGELOG.md and the next version.
• GitHub’s auto-generated release notes use merged pull requests between tags.
• Pipeline tasks can read the associated commits and work items of a build through the REST API.
• Wiki content kept in the repo is versioned with the code and changed by pull request.

Webhooks and integrations

A webhook is an HTTP POST sent to a URL when an event happens. The receiver is a service you own or a SaaS tool.

In Azure Pipelines, a webhook resource lets YAML pipelines trigger when an external service posts to a named webhook endpoint:

resources:
  webhooks:
    - webhook: MyHook
      connection: MyIncomingWebhookConnection

The webhook resource can also define filters on the JSON payload so the pipeline only runs for matching events, and payload values are available to the run through the resource alias.

Microsoft Teams integration

• Azure Pipelines app for Teams: subscribe a channel to pipeline events (build completed, release deployment completed, approval pending), and approve or reject a deployment from the channel. Use @azure pipelines subscribe <pipeline URL>.
• Azure Boards app for Teams: create work items from a message, get notifications on work item changes, and search.
• Azure Repos app for Teams: pull request and push notifications with @azure repos subscribe.
• GitHub app for Teams: @github subscribe owner/repo brings issues, pull requests, commits, releases and deployment reviews into a channel. Commands such as @github unsubscribe and @github subscribe owner/repo issues pulls commits tune what you get.
• Alternative: a Teams incoming webhook or a Workflows (Power Automate) webhook URL, called from a pipeline step or a service hook.
• Slack has equivalent apps for Azure Pipelines, Azure Boards and GitHub.

Prefer the official app over hand-written webhooks when you need approvals from chat. Use a raw webhook when the integration target has no app.