Introduction

This post documents a setup for Aurora PostgreSQL express configuration with:

• AWS CDK deployment
• an AWS SDK-based custom resource (because CloudFormation support is not available yet)
• Drizzle Kit and Drizzle Studio for schema and data verification

The setup is not production-ready, but it can be used as a starting point for further development.

AWS launch post:
Announcing Amazon Aurora PostgreSQL Serverless database creation in seconds

CDK Custom Resource

Aurora express configuration currently requires calling the RDS API directly. In this setup, CDK uses AwsCustomResource with CreateDBCluster and cleanup calls.

API reference:
CreateDBClusterCommand

import { Names, Stack } from "aws-cdk-lib";
import { Effect, PolicyStatement } from "aws-cdk-lib/aws-iam";
import {
  AwsCustomResource,
  AwsCustomResourcePolicy,
  PhysicalResourceId,
} from "aws-cdk-lib/custom-resources";
import { NagSuppressions } from "cdk-nag";
import { Construct } from "constructs";

export type DbAuroraExpressDummyProps = {
  databaseName: string;
  maxCapacity: number;
  minCapacity: number;
  schemaName: string;
};

const toIdentifier = (value: string, maxLength: number): string => {
  const normalized = value.toLowerCase().replace(/[^a-z0-9-]/g, "-");
  const compacted = normalized.replace(/-+/g, "-").replace(/^-|-$/g, "");
  if (compacted.length <= maxLength) {
    return compacted;
  }
  return compacted.slice(0, maxLength).replace(/-+$/g, "");
};

export class DbAuroraExpressDummy extends Construct {
  public readonly clusterArn: string;
  public readonly databaseName: string;
  public readonly schemaName: string;

  constructor(scope: Construct, id: string, props: DbAuroraExpressDummyProps) {
    super(scope, id);

    this.databaseName = props.databaseName;
    this.schemaName = props.schemaName;
    const minCapacity = props.minCapacity;
    const maxCapacity = props.maxCapacity;

    const stack = Stack.of(this);
    const baseIdentifier = toIdentifier(`${Names.uniqueId(this)}`, 63);
    // Aurora Express creates an instance identifier from the cluster identifier
    // (suffix like "-instance-1"), so keep the cluster id shorter than 63 chars.
    const clusterIdentifier = toIdentifier(`${baseIdentifier}-aurora`, 52);

    const instanceIdentifier = `${clusterIdentifier}-instance-1`;

    const clusterResource = new AwsCustomResource(this, "ExpressClusterFallback", {
      policy: AwsCustomResourcePolicy.fromStatements([
        new PolicyStatement({
          effect: Effect.ALLOW,
          actions: [
            "ec2:DescribeAvailabilityZones",
            "iam:CreateServiceLinkedRole",
            "rds:CreateDBCluster",
            "rds:CreateDBInstance",
            "rds:DeleteDBCluster",
            "rds:DeleteDBInstance",
            "rds:DescribeDBClusters",
            "rds:EnableInternetAccessGateway",
          ],
          resources: ["*"],
        }),
      ]),
      installLatestAwsSdk: true,
      onCreate: {
        action: "createDBCluster",
        service: "RDS",
        ignoreErrorCodesMatching: "DBClusterAlreadyExistsFault",
        physicalResourceId: PhysicalResourceId.of(clusterIdentifier),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
          Engine: "aurora-postgresql",
          WithExpressConfiguration: true,
          // Keep explicit ACU limits while using Aurora express defaults.
          ServerlessV2ScalingConfiguration: {
            MinCapacity: minCapacity,
            MaxCapacity: maxCapacity,
          },
        },
      },
      onUpdate: {
        action: "describeDBClusters",
        service: "RDS",
        physicalResourceId: PhysicalResourceId.of(clusterIdentifier),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
          Engine: "aurora-postgresql",
          WithExpressConfiguration: true,
          // Keep explicit ACU limits while using Aurora express defaults.
          ServerlessV2ScalingConfiguration: {
            MinCapacity: minCapacity,
            MaxCapacity: maxCapacity,
          },
        },
      },
      onDelete: {
        action: "deleteDBCluster",
        service: "RDS",
        ignoreErrorCodesMatching: "DBClusterNotFoundFault",
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
          DeleteAutomatedBackups: true,
          SkipFinalSnapshot: true,
        },
      },
    });

    const clusterLookupResource = new AwsCustomResource(this, "ExpressClusterLookup", {
      policy: AwsCustomResourcePolicy.fromStatements([
        new PolicyStatement({
          effect: Effect.ALLOW,
          actions: ["rds:DescribeDBClusters"],
          resources: ["*"],
        }),
      ]),
      installLatestAwsSdk: true,
      onCreate: {
        action: "describeDBClusters",
        service: "RDS",
        physicalResourceId: PhysicalResourceId.of(`${clusterIdentifier}-lookup`),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
        },
      },
      onUpdate: {
        action: "describeDBClusters",
        service: "RDS",
        physicalResourceId: PhysicalResourceId.of(`${clusterIdentifier}-lookup`),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
        },
      },
    });
    clusterLookupResource.node.addDependency(clusterResource);

    const instanceCleanupResource = new AwsCustomResource(this, "ExpressInstanceCleanup", {
      policy: AwsCustomResourcePolicy.fromStatements([
        new PolicyStatement({
          effect: Effect.ALLOW,
          actions: ["rds:DeleteDBInstance", "rds:DescribeDBInstances", "rds:DescribeDBClusters"],
          resources: ["*"],
        }),
      ]),
      installLatestAwsSdk: true,
      onCreate: {
        action: "describeDBClusters",
        service: "RDS",
        physicalResourceId: PhysicalResourceId.of(`${clusterIdentifier}-instance-cleanup`),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
        },
      },
      onUpdate: {
        action: "describeDBClusters",
        service: "RDS",
        physicalResourceId: PhysicalResourceId.of(`${clusterIdentifier}-instance-cleanup`),
        parameters: {
          DBClusterIdentifier: clusterIdentifier,
        },
      },
      onDelete: {
        action: "deleteDBInstance",
        service: "RDS",
        ignoreErrorCodesMatching: "DBInstanceNotFoundFault|InvalidDBInstanceStateFault",
        parameters: {
          DBInstanceIdentifier: instanceIdentifier,
          DeleteAutomatedBackups: true,
          SkipFinalSnapshot: true,
        },
      },
    });
    instanceCleanupResource.node.addDependency(clusterResource);

    this.clusterArn = clusterLookupResource.getResponseField("DBClusters.0.DBClusterArn");
  }
}

Aurora deployment observations

From Aurora PostgreSQL express configuration documentation and deployment output:

• The cluster is created without VPC association.
• Internet access gateway is enabled for connectivity.
• IAM authentication is required for gateway-based access.
• Encryption uses an AWS/RDS managed key (a customer-managed KMS key cannot be selected at create time in this flow).
• Data API is disabled by default at create time; it can be enabled later, with authentication constraints documented by AWS (Express configuration settings, enabling, usage and auth model). I have not managed to get Data API working with this express setup yet.

Teardown behavior

The custom resource includes explicit delete calls for both cluster and instance identifiers. During stack deletion, the cluster and instance cleanup sequence is visible in the AWS console. This is useful for ephemeral feature stacks where database infrastructure should be created and removed per branch or short-lived environment.

Drizzle integration

Drizzle is used for schema push, local studio inspection, and a simple seed script. Environment variables in this setup are managed with Varlock.

Varlock documentation

Drizzle ORM documentation

This setup was tested with the Drizzle beta track, which is expected to become v1 soon.

Required packages

Install these npm packages before running the examples:

• Runtime dependencies:
  vp add @aws-sdk/rds-signer drizzle-orm pg varlock
• Dev/tooling dependencies:
  vp add -D drizzle-kit @types/pg

Note: this repository uses Vite+, so commands in this post use vp wrappers (such as vp add, vp exec, and vp run) instead of direct npm or pnpm commands.

Configuration (drizzle-kit)

import { Signer } from "@aws-sdk/rds-signer";
import { defineConfig } from "drizzle-kit";
import { ENV } from "varlock/env";

const hostname = ENV.HOSTNAME;
const port = 5432;
const username = "postgres";
const database = "postgres";

const signer = new Signer({
  region: ENV.AWS_REGION,
  hostname,
  port,
  username,
});

const password = await signer.getAuthToken();

export default defineConfig({
  dialect: "postgresql",
  schema: "dummySchema.ts",
  dbCredentials: {
    host: hostname,
    port,
    user: username,
    password,
    database,
    ssl: true,
  },
});

Schema

import { integer, pgSchema, text } from "drizzle-orm/pg-core";

export const DUMMY_SCHEMA_NAME = "dummy";
export const dummySchema = pgSchema(DUMMY_SCHEMA_NAME);

export const dummyTable = dummySchema.table("dummy_table", {
  id: integer("id").primaryKey(),
  name: text("name").notNull(),
});

Run this command to apply schema changes:
vp exec varlock run -- vp exec drizzle-kit push --config=drizzle-user-password.config.ts

Run this command to open Drizzle Studio:
vp exec varlock run -- vp exec drizzle-kit studio --config=drizzle-user-password.config.ts

Studio before seeding (table exists, no rows):

Seeding script

#!/usr/bin/env node
/* oxlint-disable no-console */

import { Signer } from "@aws-sdk/rds-signer";
import { drizzle } from "drizzle-orm/node-postgres";
import { ENV } from "varlock/env";
import { dummyTable } from "../dummySchema.ts";

const hostname = ENV.HOSTNAME;
const port = 5432;
const username = "postgres";
const database = "postgres";

const signer = new Signer({
  region: ENV.AWS_REGION,
  hostname,
  port,
  username,
});

const password = await signer.getAuthToken();

console.log(ENV.HOSTNAME);
console.log(ENV.AWS_REGION);

const db = drizzle({
  connection: {
    host: hostname,
    port,
    user: username,
    password,
    database,
    ssl: true,
  },
});

await db.delete(dummyTable);

const insertResult = await db.insert(dummyTable).values([
  { id: 1, name: "Dummy 1" },
  { id: 2, name: "Dummy 2" },
  { id: 3, name: "Dummy 3" },
]);

console.log(insertResult);

vp exec varlock run -- node scripts/seed-dummy.ts

Result

• Schema dummy.dummy_table is created successfully via Drizzle Kit.
• Seed script inserts three rows (id 1..3).
• Drizzle Studio confirms data visibility through the IAM-authenticated Aurora Express connection.

Conclusion

Aurora PostgreSQL express configuration can be integrated into a CDK workflow today by using AWS SDK custom resources for create/delete operations. Drizzle works with this setup when authentication tokens are generated through the RDS signer and passed to Drizzle tooling/runtime.

Sources and References

• AWS announcement: Announcing Amazon Aurora PostgreSQL Serverless database creation in seconds
• Aurora Express configuration docs: Creating and connecting to an Aurora PostgreSQL cluster with express configuration
• RDS Data API enablement: Enabling the Amazon RDS Data API
• RDS Data API usage/auth: Using the Amazon RDS Data API
• RDS API (SDK v3): CreateDBClusterCommand
• Varlock: varlock.dev
• Drizzle ORM: orm.drizzle.team
• Drizzle Kit: orm.drizzle.team/docs/drizzle-kit-overview

We’ve been building ForgeCMS – a Go-based CMS that pulls content from a Codeberg repo and serves it from a €1/month VPS. No database. No WordPress. No regrets.

Today we shipped a release that felt like crossing a threshold: the CMS stopped being a prototype and started feeling like a real product.

Here’s what landed.

🌍 Proper i18n – without a framework

We didn’t reach for go-i18n or any translation library. Instead, we built language resolution directly into the SML page system:

• Accept-Language header detection on first visit
• /lang switcher endpoint that sets a lang cookie
• Per-page language override via Page{lang: "es"}
• Fallback chain: atesti/es/index.sml → atesti/index.sml

The result: a visitor from Barcelona lands on the Spanish page automatically. A visitor from Cataluña sees Català. No JavaScript required.

lang-specific SML pages (atesti/es/index.sml fallback to index.sml)
Page{lang:} override for per-page content language
Markdown{src:} with lang injection and no-lang fallback

We also added a new Markdown{src:} syntax that injects the current language into the source path – so content.md becomes content-es.md when available, with silent fallback to the default.

🎨 Theme system via SML

Theming is now first-class. Two files control everything:

• theme.sml – light mode CSS custom properties
• theme-dark.sml – dark mode overrides

The entire site color palette, spacing, and typography flow from these two files. No hardcoded hex values scattered across templates. It’s the same philosophy as our SML declarative UI: declare the intent, let the system do the rest.

🔗 OG meta tags + Image path resolution

Every page now emits proper OpenGraph tags:

og:title, og:description, og:url, og:image

And Image{src:} now resolves relative paths to full Codeberg raw URLs automatically – so content authors don’t have to think about where images live on the CDN.

💀 Guru Meditation Error Pages

This is the one people will remember.

404 and 500 pages now render as Amiga-style Guru Meditation screens:

Software Failure. Press left mouse button to continue.

Guru Meditation

#00000404.DEADBEEF

← back to safety

It’s a love letter to the Amiga. It’s also completely on-brand for a CMS built by someone who learned to code from Toolbox magazine in the 80s.

🏗️ Under the hood

A few infrastructure improvements that matter:

• ETagFor() – proper cache fingerprinting for assets
• Stale cache fallback – if Codeberg is unreachable, serve the last known good content
• ErrNotFound sentinel – clean error type propagation instead of string matching
• Asset fingerprinting fix – the favicon (a sprouting seed 🌱 SVG) now busts cache correctly
• Site-wide Menu{} and Footer{} – defined once in app.sml, rendered everywhere

⚖️ Dual license

The project now ships under GPL v3 + commercial license, mirroring the Qt model.

Open source for open source. Commercial license for commercial use. Revenue funds land purchase for intentional community infrastructure – but that’s a different post.

What’s next

The live proof-of-concept is atesti.crowdware.info – the home of Atesti para Dana, a gift-first alternative currency built on the Minuto framework.

Next up: SMS/WASM search index with persistent IndexedDB, so the CMS can search its own content without a backend query.

If you’re building something small, human-scale, and weird – we’re on Codeberg.

Part of the Forge 4D ecosystem – declarative UI, native compilation, no cloud required.

Why Azure DevOps for code review

Azure DevOps remains one of the most widely used development platforms in enterprise software, and its code review capabilities are a major reason why. Microsoft reports over 100,000 organizations use Azure DevOps, with particularly strong adoption in finance, healthcare, government, and any industry where the Microsoft ecosystem is already deeply embedded. If your team runs Visual Studio, .NET, SQL Server, or Azure cloud infrastructure, Azure DevOps is the natural home for your repositories, CI/CD pipelines, and code review workflows.

Yet Azure DevOps code review is frequently misunderstood. Teams coming from GitHub assume the pull request experience will be identical. Teams evaluating platforms often dismiss Azure DevOps because they associate it with the legacy Team Foundation Server era. The reality is that Azure DevOps offers a pull request review system that is more configurable than GitHub’s in several important ways – particularly around branch policies, vote-based approvals, and work item integration – while trailing GitHub in third-party tool ecosystem size.

This guide covers everything you need to set up a production-grade code review workflow in Azure DevOps: the built-in Azure Repos features, the third-party AI and static analysis tools that integrate with the platform, step-by-step branch policy configuration, Azure Pipelines integration for automated analysis, and a detailed comparison with GitHub and GitLab so you can make an informed platform decision.

Azure Repos vs GitHub – the platform question

Before diving into configuration, it is worth addressing the most common question teams ask: should we use Azure Repos or GitHub for code review?

Both platforms are owned by Microsoft, and there is significant feature overlap. But they serve different audiences:

• Azure Repos is part of the Azure DevOps suite and integrates tightly with Azure Boards (work item tracking), Azure Pipelines (CI/CD), Azure Test Plans, and Azure Artifacts. It is designed for enterprise teams that want a single, integrated platform for the entire development lifecycle. Branch policies are more granular, and the connection between work items and pull requests is first-class.
• GitHub has a larger open-source community, a broader ecosystem of third-party integrations, GitHub Actions for CI/CD, and GitHub Copilot for AI-assisted development. It is the default choice for open-source projects and increasingly popular in enterprise settings since Microsoft’s acquisition.

If your organization is already invested in the Azure ecosystem, Azure DevOps is the path of least resistance. If you are starting fresh and want the widest range of third-party tools, GitHub has the edge. Many large enterprises use both – GitHub for open-source and community-facing projects, Azure DevOps for internal enterprise applications.

The rest of this guide assumes you are using or evaluating Azure DevOps, and focuses on getting the most out of its code review capabilities.

Azure Repos built-in code review features

Azure Repos provides a full-featured pull request workflow out of the box. Understanding what is available natively is important before layering on third-party tools, because many teams add external tools for capabilities that Azure Repos already provides.

Pull request workflow

The core pull request workflow in Azure Repos follows a familiar pattern:

1. A developer creates a feature branch and pushes changes to Azure Repos
2. The developer opens a pull request targeting the main branch (or any configured target branch)
3. Reviewers are assigned – either manually or automatically through branch policies
4. Reviewers examine the diff, leave comments, and cast votes
5. The author addresses feedback, pushes additional commits, and responds to comments
6. Once all policies are satisfied (votes, builds, work items, comment resolution), the PR is completed and the branch is merged

What distinguishes Azure Repos from other platforms is the depth of configuration available at each step. Let us walk through the key features.

Vote-based approval system

Azure DevOps uses a five-level vote system for pull request reviews, which is more nuanced than the binary approve/reject model used by GitHub:

1. Approve – The reviewer is satisfied with the changes and explicitly approves the PR
2. Approve with suggestions – The reviewer approves but has optional recommendations that the author may or may not address
3. No vote – The reviewer has not yet cast a vote (the default state)
4. Wait for author – The reviewer has concerns that need to be addressed before approval; this is a soft block that signals the PR is not ready
5. Reject – The reviewer believes the changes should not be merged; this is a hard block

This five-level system provides more flexibility than GitHub’s three-state model (approve, request changes, comment). The “approve with suggestions” vote is particularly useful – it lets a reviewer say “this is fine to merge, but consider these improvements” without blocking the PR. The “wait for author” vote creates a middle ground between approving and rejecting that GitHub does not have.

You can configure branch policies to require a specific number of approvals and to define how “reject” votes are handled. For example, you can require at least two approvals and configure the policy so that a single rejection blocks the merge regardless of how many approvals exist.

Comment resolution tracking

Every comment thread on an Azure DevOps pull request has an explicit status: Active or Resolved. This is a significant difference from GitHub, where comment resolution is informal and there is no built-in way to track whether feedback has been addressed.

In Azure DevOps, you can configure a branch policy that requires all comment threads to be resolved before a PR can be completed. This ensures that no reviewer feedback is accidentally ignored. Reviewers can mark their own comments as resolved if they are satisfied with the author’s response, or the author can resolve comments and let reviewers verify during their next review pass.

The comment resolution requirement can be set to one of three modes:

• Required – All comments must be resolved before the PR can complete
• Required for code reviewers – Only comments from designated code reviewers must be resolved
• Optional – Comment resolution is encouraged but not enforced

Auto-complete

Azure DevOps supports an auto-complete feature that GitHub does not have natively. When a PR author sets auto-complete, the pull request will automatically merge as soon as all branch policies are satisfied – required reviewers have approved, builds have passed, work items are linked, and comments are resolved.

This is particularly useful for large teams where a PR might be waiting on the final reviewer in a different time zone. Instead of the author having to come back and click “Complete” after the last approval, the merge happens automatically. The author can also configure merge strategy (merge commit, squash, rebase) and whether the source branch should be deleted on completion as part of the auto-complete settings.

Iteration tracking

Azure DevOps tracks each push to a pull request as a numbered “iteration.” Reviewers can compare any two iterations side by side, seeing exactly what changed between review rounds. This is a feature that GitHub introduced later with its “Changes since last review” option, but Azure DevOps has had it from the beginning and the implementation is more robust.

Iteration tracking is valuable because it lets reviewers focus on only the new changes in each review round, rather than re-reviewing the entire diff. For large PRs that go through multiple rounds of feedback, this saves significant reviewer time.

Draft pull requests

Like GitHub, Azure DevOps supports draft pull requests. Draft PRs do not trigger automatic reviewer assignments, do not run branch policy evaluations, and cannot be completed until they are published. They are useful for getting early feedback on work-in-progress without creating noise for the full review team.

Third-party AI and analysis tools for Azure DevOps

The built-in Azure Repos features handle the workflow and process aspects of code review. For automated code analysis – catching bugs, security vulnerabilities, code smells, and logic errors – you need third-party tools. Here are the tools that work with Azure DevOps, along with their integration methods and trade-offs.

CodeRabbit

CodeRabbit is the most widely adopted AI code review tool, with over 13 million reviews completed across GitHub, GitLab, Bitbucket, and Azure DevOps. It uses large language models to analyze pull requests and post inline review comments, walkthrough summaries, and interactive chat responses.

Azure DevOps integration method: CodeRabbit connects to Azure DevOps through a personal access token (PAT) rather than a native OAuth app. You install the CodeRabbit extension from the Azure DevOps Marketplace, generate a PAT with Code (Read) and Pull Request Threads (Read and Write) permissions, and enter it in the CodeRabbit dashboard. Once connected, CodeRabbit automatically reviews every new pull request.

What it does on Azure DevOps:

• Posts a walkthrough summary at the top of each PR describing all changes across files
• Leaves inline comments on specific lines pointing out bugs, security issues, performance problems, and logic errors
• Supports interactive chat – you can reply to CodeRabbit’s comments to ask follow-up questions
• Respects .coderabbit.yaml configuration for custom review instructions, path filters, and language settings
• Supports 30+ programming languages

Pricing: Free tier available (200 files/hour rate limit, 4 reviews/hour). Pro plan at $24/user/month removes limits and adds auto-fix suggestions.

For a detailed setup walkthrough, see our CodeRabbit Azure DevOps integration guide.

CodeAnt AI

CodeAnt AI is one of the few AI code review platforms built from the ground up with multi-platform support. It natively supports GitHub, GitLab, Bitbucket, and Azure DevOps without any platform being treated as a second-class citizen. This makes it particularly compelling for enterprises that use multiple Git platforms across different teams or divisions.

Azure DevOps integration method: CodeAnt AI connects directly to Azure DevOps through its dashboard. You authorize the connection, select your repositories, and CodeAnt AI begins reviewing PRs automatically.

What it does on Azure DevOps:

• AI-powered pull request reviews with inline comments
• Built-in SAST (Static Application Security Testing) scanning
• Secret detection to prevent credentials from being committed
• DORA metrics tracking (deployment frequency, lead time, change failure rate, mean time to recovery)
• Code quality scoring and trend tracking across repositories

Pricing: Plans range from $24 to $40 per user/month depending on features.

CodeAnt AI is a strong alternative to CodeRabbit for teams that want consolidated tooling – AI review, SAST, secret detection, and engineering metrics in a single platform – rather than stitching together separate tools.

SonarQube

SonarQube is the most established static analysis platform and has native Azure DevOps integration through its extension in the Visual Studio Marketplace. Unlike AI review tools, SonarQube uses deterministic rules – over 5,000 of them across 30+ languages – to detect bugs, vulnerabilities, code smells, and security hotspots.

Azure DevOps integration method: Install the SonarQube extension from the Visual Studio Marketplace. Add SonarQube analysis tasks to your azure-pipelines.yml file. SonarQube posts analysis results as a PR decoration (comments and status) directly on the pull request.

What it does on Azure DevOps:

• Runs rule-based analysis during Azure Pipelines builds
• Posts inline comments on new issues directly on the PR
• Enforces quality gates – configurable thresholds for code coverage, duplications, reliability, security, and maintainability ratings
• Tracks technical debt over time with a project dashboard
• Supports 30+ languages with deep rules for Java, C#, JavaScript/TypeScript, Python, and C/C++

Pipeline configuration example:

# azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: SonarQubePrepare@6
    inputs:
      SonarQube: 'SonarQubeServiceConnection'
      scannerMode: 'CLI'
      configMode: 'manual'
      cliProjectKey: 'my-project-key'
      cliProjectName: 'My Project'
      cliSources: 'src'

  - script: |
      npm install
      npm run build
    displayName: 'Build'

  - task: SonarQubeAnalyze@6
    displayName: 'Run SonarQube analysis'

  - task: SonarQubePublish@6
    inputs:
      pollingTimeoutSec: '300'

Pricing: Community Build is free and open source for self-hosted use. Developer Edition starts at $150/year. Enterprise Edition pricing is custom.

For a full SonarQube setup guide, see How to set up SonarQube.

Semgrep

Semgrep is a fast, lightweight static analysis tool focused on security and correctness. It uses a pattern-matching approach that lets you write custom rules in a syntax similar to the source code itself, making it more accessible than traditional SAST tools. Semgrep supports 25+ languages and has a community-maintained registry of over 3,000 rules.

Azure DevOps integration method: Semgrep does not have a native Azure DevOps Marketplace extension. Instead, you run it as a script task in your Azure Pipeline. The Semgrep CLI runs inside the pipeline agent, scans the code, and outputs results. You can post results as PR comments through additional scripting or by using Semgrep’s managed platform (Semgrep AppSec Platform) which has Azure DevOps support.

Pipeline configuration example:

# azure-pipelines.yml
trigger:
  - main

pr:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - script: |
      python3 -m pip install semgrep
    displayName: 'Install Semgrep'

  - script: |
      semgrep ci --config auto --json --output semgrep-results.json
    displayName: 'Run Semgrep scan'
    env:
      SEMGREP_APP_TOKEN: $(SEMGREP_APP_TOKEN)

  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: 'semgrep-results.json'
      ArtifactName: 'semgrep-results'
    condition: always()

For differential scanning (only scanning changed files in a PR), use the semgrep ci command which automatically detects the PR context in Azure Pipelines and only reports findings on changed lines.

Pricing: Free for up to 10 contributors. Team plan starts at $40/month per contributor. For details, see our Semgrep setup guide.

PR-Agent (Qodo)

PR-Agent is an open-source AI code review tool by Qodo that can be self-hosted and integrated with Azure Pipelines. Unlike CodeRabbit which runs on the vendor’s infrastructure, PR-Agent runs inside your pipeline using your own LLM API keys, meaning your code never leaves your infrastructure.

Azure DevOps integration method: PR-Agent can be deployed as a Docker container inside an Azure Pipeline task. You provide your OpenAI (or other LLM provider) API key as a pipeline secret variable, and PR-Agent analyzes the PR diff and posts comments via the Azure DevOps API.

Pipeline configuration example:

# azure-pipelines.yml
trigger: none

pr:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

steps:
  - script: |
      docker run --rm 
        -e AZURE_DEVOPS_ORG="$(System.CollectionUri)" 
        -e AZURE_DEVOPS_PROJECT="$(System.TeamProject)" 
        -e AZURE_DEVOPS_REPO="$(Build.Repository.Name)" 
        -e AZURE_DEVOPS_PR_ID="$(System.PullRequest.PullRequestId)" 
        -e AZURE_DEVOPS_TOKEN="$(AZURE_DEVOPS_PAT)" 
        -e OPENAI.KEY="$(OPENAI_API_KEY)" 
        -e CONFIG.GIT_PROVIDER="azure" 
        codiumai/pr-agent:latest 
        --pr_url "$(System.CollectionUri)$(System.TeamProject)/_git/$(Build.Repository.Name)/pullrequest/$(System.PullRequest.PullRequestId)" 
        review
    displayName: 'Run PR-Agent review'

Pricing: Open source and free (you pay for your LLM API keys, typically $0.05-$0.15 per review). Qodo Merge (the hosted version) starts at $19/user/month.

Combining tools for comprehensive coverage

The most effective approach is layering tools that serve different purposes:

• AI review (CodeRabbit or CodeAnt AI) for logic errors, missing edge cases, and context-aware suggestions
• SAST (Semgrep) for security vulnerabilities using deterministic rules
• Code quality (SonarQube) for maintainability, technical debt tracking, and quality gate enforcement

This layered approach ensures that your code review pipeline catches different categories of issues at different levels of analysis. AI tools are probabilistic and catch semantic issues that rules miss. Rule-based tools are deterministic and have zero false negatives on the patterns they are designed to detect.

Setting up branch policies in Azure DevOps

Branch policies are the enforcement mechanism that makes code review mandatory. Without branch policies, developers can push directly to main, bypass reviewers, and skip quality gates. With them, every change goes through a structured review process.

Here is how to configure branch policies step by step.

Step 1 – Navigate to branch policy settings

1. Open your Azure DevOps project
2. Go to Project Settings (gear icon in the bottom-left corner)
3. Under the Repos section, click Repositories
4. Select the repository you want to configure
5. Click the Policies tab
6. Under “Branch Policies,” select the branch you want to protect (typically main or develop)

You will see a configuration page with several policy sections. Each can be enabled and configured independently.

Step 2 – Configure minimum number of reviewers

This is the most fundamental policy. It specifies how many reviewers must approve a PR before it can be completed.

Configuration options:

• Minimum number of reviewers: Set this to at least 1 for small teams, 2 for most production branches. Do not set it higher than 3 unless you have a specific regulatory requirement – excessive reviewer requirements slow down development without proportional quality improvement.
• Allow requestors to approve their own changes: Disable this for production branches. You do not want the author of a change approving their own PR.
• Prohibit the most recent pusher from approving their own changes: Enable this. It prevents the scenario where a developer pushes a fix in response to review feedback and then immediately approves the PR themselves.
• Allow completion even if some reviewers vote “Wait for author” or “Reject”: Disable this for production branches. If a reviewer has explicitly voted to wait or rejected the changes, the PR should not be completable.
• When new changes are pushed, reset all approval votes: Consider enabling this. It forces reviewers to re-review after new changes are pushed, preventing the scenario where a developer gets an approval and then pushes additional unreviewed changes before merging.

Step 3 – Require linked work items

Enabling this policy requires that every PR has at least one linked Azure Boards work item (user story, task, bug, etc.). This creates traceability between code changes and the business requirements that drove them.

Configuration options:

• Required: The PR cannot be completed without a linked work item
• Optional: A warning is displayed but the PR can still be completed

For most teams, set this to “Required” for production branches. This ensures that every change has a documented reason and can be traced back to a specific requirement or bug report. It also enables reporting on engineering velocity and work item completion rates.

Step 4 – Configure comment resolution

Under the comment resolution policy, you specify whether comment threads must be resolved before the PR can be completed.

Recommended setting: Set this to “Required.” This is one of Azure DevOps’ strongest features compared to GitHub and GitLab. It ensures that no reviewer feedback is accidentally overlooked. Reviewers post comments, the author addresses them, and the reviewer (or author, depending on your team conventions) marks the thread as resolved.

Step 5 – Add build validation

Build validation runs your CI pipeline when a PR is created or updated and blocks the merge if the build fails. This is the Azure DevOps equivalent of GitHub’s required status checks.

To add build validation:

1. Click Add build policy
2. Select the pipeline to run (e.g., your main build and test pipeline)
3. Set the Trigger to “Automatic” to run on every push
4. Set the Policy requirement to “Required”
5. Set the Build expiration – how long a passing build remains valid before re-running. “Immediately when the source branch is updated” is the strictest and most common setting
6. Optionally set a display name for the policy

You can add multiple build validation policies. For example, one for your main build/test pipeline and another for your Semgrep security scan or SonarQube quality gate.

Example multi-pipeline validation:

Build Policy 1: "Build and Test" (required, automatic)
Build Policy 2: "SonarQube Quality Gate" (required, automatic)
Build Policy 3: "Semgrep Security Scan" (required, automatic)

Step 6 – Configure automatic reviewers

Automatic reviewers let you assign specific people or groups to review PRs based on the files changed. This is similar to GitHub’s CODEOWNERS file but configured through the Azure DevOps UI rather than a file in the repository.

To add automatic reviewers:

1. Click Add automatic reviewers
2. Enter the reviewer (person or team)
3. Set the Path filter – a regex or glob pattern that matches file paths. For example:
   • */src/security/* – any changes to security-related code
   • *.sql – any SQL file changes
   • /docs/* – any documentation changes
4. Set the Policy requirement to “Required” if this reviewer must approve, or “Optional” if they are added as a suggestion
5. Set the Minimum number of reviewers within this group who must approve

Example automatic reviewer configuration:

This configuration ensures that security-related changes are always reviewed by the security team, database changes are reviewed by a DBA, and infrastructure changes are visible to the senior architect.

Azure Pipelines integration for code review

Azure Pipelines is where automated code analysis tools run. This section provides complete, production-ready pipeline configurations for integrating review tools.

Basic review pipeline structure

A well-structured review pipeline separates concerns into distinct stages:

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main
      - develop

pr:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

stages:
  - stage: Build
    displayName: 'Build and Test'
    jobs:
      - job: BuildJob
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '20.x'
            displayName: 'Install Node.js'

          - script: |
              npm ci
              npm run build
              npm run test -- --coverage
            displayName: 'Build and test'

          - task: PublishTestResults@2
            inputs:
              testResultsFormat: 'JUnit'
              testResultsFiles: '**/junit.xml'
            condition: always()

          - task: PublishCodeCoverageResults@2
            inputs:
              summaryFileLocation: '**/coverage/cobertura-coverage.xml'

  - stage: CodeQuality
    displayName: 'Code Quality Analysis'
    dependsOn: Build
    jobs:
      - job: SonarQubeAnalysis
        displayName: 'SonarQube Scan'
        steps:
          - task: SonarQubePrepare@6
            inputs:
              SonarQube: 'SonarQubeServiceConnection'
              scannerMode: 'CLI'
              configMode: 'manual'
              cliProjectKey: 'my-project'
              cliSources: 'src'
              extraProperties: |
                sonar.javascript.lcov.reportPaths=coverage/lcov.info
                sonar.coverage.exclusions=**/*.test.ts,**/*.spec.ts

          - script: npm ci && npm run build
            displayName: 'Build for analysis'

          - task: SonarQubeAnalyze@6
            displayName: 'Run analysis'

          - task: SonarQubePublish@6
            inputs:
              pollingTimeoutSec: '300'

  - stage: SecurityScan
    displayName: 'Security Scanning'
    dependsOn: Build
    jobs:
      - job: SemgrepScan
        displayName: 'Semgrep SAST Scan'
        steps:
          - script: |
              python3 -m pip install semgrep
              semgrep ci --config auto
            displayName: 'Run Semgrep'
            env:
              SEMGREP_APP_TOKEN: $(SEMGREP_APP_TOKEN)

This pipeline runs three stages: a build/test stage that must pass first, followed by parallel code quality and security scanning stages. The pr trigger ensures this pipeline runs on every pull request targeting main or develop.

Adding PR-Agent to the pipeline

If you want AI-powered review through your pipeline rather than through a third-party service like CodeRabbit, add PR-Agent as an additional job:

  - stage: AIReview
    displayName: 'AI Code Review'
    dependsOn: []
    condition: eq(variables['Build.Reason'], 'PullRequest')
    jobs:
      - job: PrAgentReview
        displayName: 'PR-Agent Review'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - script: |
              pip install pr-agent
              python -m pr_agent.cli 
                --pr_url "$(System.CollectionUri)$(System.TeamProject)/_git/$(Build.Repository.Name)/pullrequest/$(System.PullRequest.PullRequestId)" 
                review
            displayName: 'Run PR-Agent'
            env:
              OPENAI__KEY: $(OPENAI_API_KEY)
              AZURE_DEVOPS__ORG: $(System.CollectionUri)
              AZURE_DEVOPS__PAT: $(AZURE_DEVOPS_PAT)
              CONFIG__GIT_PROVIDER: 'azure'

The condition: eq(variables['Build.Reason'], 'PullRequest') ensures the AI review only runs on pull requests, not on direct pushes to branches.

Pipeline variables and secrets

Store sensitive values as pipeline variables marked as secrets:

1. In your Azure DevOps project, go to Pipelines > Library
2. Create a new variable group (e.g., “Code Review Secrets”)
3. Add variables:
   • SONARQUBE_TOKEN (mark as secret)
   • SEMGREP_APP_TOKEN (mark as secret)
   • OPENAI_API_KEY (mark as secret, only if using PR-Agent)
   • AZURE_DEVOPS_PAT (mark as secret, only if using PR-Agent)
4. Link the variable group to your pipeline:

variables:
  - group: 'Code Review Secrets'

Never hard-code tokens, API keys, or credentials in your pipeline YAML file. Azure DevOps pipeline variables marked as secret are encrypted at rest and masked in pipeline logs.

Comparison with GitHub and GitLab

Choosing between Azure DevOps, GitHub, and GitLab for code review depends on your team’s existing infrastructure, workflow preferences, and tooling requirements. Here is a detailed comparison across the dimensions that matter most for code review.

Feature comparison table

When to choose Azure DevOps

Azure DevOps is the strongest choice when:

• Your organization is in the Microsoft ecosystem. If you run .NET, Visual Studio, Azure cloud, SQL Server, and Active Directory, Azure DevOps integrates with all of these natively. Single sign-on through Azure Active Directory, built-in Azure deployment tasks, and native Visual Studio integration make it the lowest-friction option.
• You need granular branch policies. Azure DevOps branch policies are more configurable than GitHub’s branch protection rules. The ability to require work item linking, enforce comment resolution, add path-based automatic reviewers through the UI, and configure vote requirements at a granular level is valuable for regulated industries where compliance requires documented review processes.
• You want a single platform for the full development lifecycle. Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, and Azure Artifacts are all integrated. You do not need separate tools for project management, source control, CI/CD, testing, and package management.
• You are in a regulated industry. Finance, healthcare, government, and defense organizations often choose Azure DevOps because of its compliance certifications (SOC 2, ISO 27001, FedRAMP), audit logging, and the ability to host on Azure Government cloud.

When to choose GitHub

GitHub is the stronger choice when:

• You need the widest third-party tool ecosystem. GitHub has significantly more integrations for code review, security scanning, project management, and deployment than Azure DevOps. The GitHub Marketplace has thousands of apps and actions.
• You work with open-source communities. GitHub is the default home for open-source software. If your project accepts community contributions, being on GitHub reduces friction for external contributors.
• You want GitHub Copilot integration. GitHub Copilot’s code review feature is tightly integrated with GitHub’s PR workflow and is not available on Azure DevOps.
• Your team prefers file-based configuration. GitHub’s CODEOWNERS file and .github/ directory-based configuration is version-controlled and reviewed through PRs. Azure DevOps’ UI-based policy configuration is easier to set up initially but harder to track changes over time.

When to choose GitLab

GitLab is the strongest choice when:

• You want a self-hosted, all-in-one platform. GitLab’s self-managed option gives you full control over your infrastructure, which is important for organizations with strict data sovereignty requirements.
• You need built-in security scanning. GitLab Ultimate includes SAST, DAST, dependency scanning, container scanning, and secret detection as part of the platform. On Azure DevOps and GitHub, these require third-party tools.
• You want GitLab Duo AI features. GitLab’s native AI assistant covers code review, code generation, and vulnerability explanation within the platform.

Best practices for Azure DevOps code review

After years of working with Azure DevOps across enterprise teams, here are the practices that consistently lead to effective code review workflows.

1. Start with branch policies, not process documents

Do not write a wiki page about code review rules that nobody reads. Configure branch policies that enforce the rules automatically. Required reviewers, build validation, comment resolution, and work item linking should all be set as required policies on your main and release branches. If it is important enough to be a rule, it is important enough to be enforced by the platform.

2. Use the vote system intentionally

Agree as a team on what each vote level means. A common convention:

• Approve = “I have reviewed every file and am confident this is ready to merge”
• Approve with suggestions = “This is safe to merge, but I have improvements the author should consider for follow-up work”
• Wait for author = “I have specific concerns that need to be addressed before this should merge”
• Reject = “This approach has fundamental problems and should be reworked significantly”

Without shared conventions, different reviewers use the same votes to mean different things, which creates confusion about whether a PR is actually ready.

3. Keep pull requests small

This is universal advice, but it is worth repeating because large PRs are the single biggest cause of review quality degradation. Research consistently shows that review effectiveness drops sharply beyond 200-400 lines of changes. On Azure DevOps specifically, the iteration tracking feature works best with small, focused PRs where each iteration represents a clear response to feedback.

Target 200-400 lines of meaningful changes per PR. If a feature requires more, break it into a chain of smaller PRs with clear dependencies.

4. Layer your tools

Do not rely on a single tool for all review automation. Use the layered approach:

• Layer 1: Linting – ESLint, Ruff, or your language-specific linter running as a pipeline step. This catches style and syntax issues before anyone reviews the code.
• Layer 2: Static analysis – SonarQube or Semgrep running as a pipeline step with quality gates. This catches bugs, security vulnerabilities, and code smells deterministically.
• Layer 3: AI review – CodeRabbit or CodeAnt AI reviewing every PR. This catches logic errors, missing edge cases, and provides context-aware suggestions that rule-based tools cannot.

Each layer catches different categories of issues. Together, they cover significantly more ground than any single tool alone.

5. Configure automatic reviewers by path

Use Azure DevOps’ automatic reviewer feature to ensure domain experts review changes in their area. Database changes should be reviewed by a DBA. Security-related code should be reviewed by the security team. Infrastructure-as-code changes should be reviewed by a platform engineer. This is more reliable than hoping the PR author remembers to tag the right people.

6. Require comment resolution

Enable the “Required” comment resolution policy on all protected branches. This single setting eliminates the most common code review failure mode: feedback that is posted but never addressed. It forces a completion loop on every review conversation.

7. Use auto-complete to reduce merge latency

Encourage developers to set auto-complete on their PRs after addressing all feedback. This is especially important for distributed teams across time zones. A developer in London should not have to wait until morning in San Francisco to click “Complete” after the final approval comes in at the end of the San Francisco workday.

8. Do not over-gate

It is tempting to add every possible quality gate to your branch policies. Resist this temptation. Every required check adds latency to the merge process. If a check frequently produces false positives or provides low-value feedback, it erodes developer trust in the review system and creates pressure to bypass it.

Start with the essentials: required reviewers, build validation, and comment resolution. Add additional gates (security scanning, AI review status checks) only when you have confidence that they provide consistent value with acceptable false positive rates.

9. Review your review process quarterly

Set a quarterly reminder to evaluate your code review process. Look at these metrics:

• Average time to first review – If this is growing, you may need to add reviewers or adjust workload distribution
• Average time to merge – If this is excessive, check whether policies or tool configurations are creating unnecessary friction
• Number of review iterations – High iteration counts may indicate unclear requirements or PRs that are too large
• Defect escape rate – If bugs are making it to production despite review, your review coverage may have gaps

Azure DevOps provides analytics through Azure Boards and Azure DevOps Analytics that can help track these metrics. For DORA metrics specifically, tools like CodeAnt AI provide automated tracking.

10. Document review expectations in the repository

Create a CONTRIBUTING.md file in each repository that documents your team’s review expectations: what constitutes a “complete” review, when to use each vote level, how to handle disagreements between reviewers, and what the automated tools are expected to catch so human reviewers can focus elsewhere.

Conclusion

Azure DevOps provides a code review system that is more configurable than most teams realize. The five-level vote system, enforced comment resolution, automatic reviewers by path, and tight work item integration make it particularly well-suited for enterprise teams that need structured, auditable review processes.

The built-in features handle the process and workflow side well. For automated code analysis, you need third-party tools. CodeRabbit and CodeAnt AI provide AI-powered review with Azure DevOps support. SonarQube adds deterministic quality gates. Semgrep covers security scanning. Layer these together in your Azure Pipelines configuration, enforce the results through branch policies, and you have a comprehensive code review pipeline that catches issues at every level.

The platform choice between Azure DevOps, GitHub, and GitLab is ultimately about ecosystem fit rather than code review capability. All three platforms support effective code review workflows. Azure DevOps wins for teams already in the Microsoft ecosystem. GitHub wins for ecosystem breadth and open-source workflows. GitLab wins for self-hosted, all-in-one deployments. Regardless of which platform you choose, the fundamentals remain the same: small PRs, layered tooling, enforced policies, and a team culture that values review as a quality investment rather than a bureaucratic hurdle.

Frequently Asked Questions

Does Azure DevOps have built-in code review?

Yes. Azure Repos provides pull request reviews with required reviewers, branch policies, comment resolution tracking, vote-based approvals (approve, approve with suggestions, wait for author, reject), and auto-complete options. You can also enforce build validation and linked work items before merging.

What AI code review tools work with Azure DevOps?

CodeRabbit supports Azure DevOps with PR review integration. PR-Agent can be configured with Azure Pipelines. SonarQube has native Azure DevOps integration through its extension in the Visual Studio Marketplace. Semgrep can be added as an Azure Pipeline task.

How do I set up branch policies in Azure DevOps?

Go to Project Settings > Repos > Policies, select your branch, and configure: minimum number of reviewers, linked work items requirement, comment resolution, build validation, and automatic reviewers. These policies enforce quality gates before any PR can be merged.

How does Azure DevOps code review compare to GitHub?

Azure DevOps offers more granular branch policies and tighter Jira/Azure Boards integration. GitHub has a larger ecosystem of third-party review tools and GitHub Actions. Azure DevOps uses a vote-based approval system (5 levels) vs GitHub’s simpler approve/request changes model. For enterprises in the Microsoft ecosystem, Azure DevOps is the natural choice.

Originally published at aicodereview.cc