Developer Tools and DevOps

Each toolkit authenticates the same way the CLI does — an interactive Entra ID sign-in cached locally, or a service principal/managed identity for headless use — rather than a separate credential store; see Identity and Access for how that authentication maps onto DefaultAzureCredential once the code itself needs a token.

References: Visual Studio Code — Azure extensions, Install Azure development workloads for Visual Studio, Azure Toolkit for IntelliJ documentation.

Every current Azure SDK (azure-sdk-for-java, azure-sdk-for-net, azure-sdk-for-python, azure-sdk-for-js, azure-sdk-for-go) is built to the same four cross-language design pillars published by the Azure SDK team:

Underneath those pillars, every SDK is built on a shared low-level package (azure-core for Java, Azure.Core for .NET, azure-core for Python) that supplies the same three building blocks regardless of which service client sits on top: an HttpPipeline of composable policies (retry, logging, telemetry, authentication) wrapping a pluggable HTTP transport; the TokenCredential abstraction that DefaultAzureCredential implements (see Identity and Access) so every client authenticates the same way whether it runs on a developer’s machine, in a Container App, or on an AKS pod with workload identity; and a Pageable/PagedIterable return type for any operation that lists a collection, so catalog-api iterates a container listing or a Cosmos DB query the same way it iterates any other paged Azure result. Long-running operations (a Key Vault certificate creation, an ACR build) follow the same poller pattern across services rather than each client inventing its own "is it done yet" loop.

References: Azure SDK design guidelines — introduction, Java Azure SDK design guidelines, .NET Azure SDK design guidelines, HTTP clients and pipelines in the Azure SDK for Java, Authenticate .NET apps to Azure services.

Running Bookshelf’s data-plane dependencies locally, without provisioning anything in rg-bookshelf, keeps the inner dev loop fast and free. Each emulator below is a container or CLI tool that speaks the same wire protocol as its Azure service, so catalog-api/orders-api connect with the same SDK client, just pointed at localhost; running one locally in Docker creates no durable Azure resource, so none of them needs a == Clean up step.

Identity and Access sets up the identity side of this pipeline — the bookshelf-github-actions-deploy app registration, its role assignment, and the federated credential subject that lets azure/login exchange GitHub’s own OIDC token for an Entra ID access token with no stored client secret — and Docker CI/CD with GitHub Actions covers the workflow mechanics common to any image build: setup-buildx-action, metadata-action tags, build-push-action, test-before-push and caching. This section picks up exactly where those two leave off: the deploy step(s) that take an image already built and pushed to acrbookshelf and roll it out to a running Container App or AKS deployment.

Azure DevOps is Microsoft’s own alternative to GitHub for the same end-to-end flow, organized as four services under one project: Boards (work items, sprints, Kanban boards), Repos (Git repositories, pull requests, branch policies), Pipelines (YAML-based CI/CD, conceptually equivalent to a GitHub Actions workflow but with its own task marketplace, including an AzureCLI@2 task and Azure service-connection-based OIDC federation for the same passwordless deploy pattern shown above), and Artifacts (package feeds for Maven, npm, NuGet and Python, playing the same role GitHub Packages/GHCR plays for this section’s Bookshelf examples). An organization already invested in GitHub for Bookshelf has no reason to add Azure DevOps alongside it — the two are alternatives, not complements — but a team migrating an existing Azure DevOps estate keeps its Boards and Pipelines while still deploying to the same Container Apps/AKS resources this section covers.

References: What is Azure DevOps?, Create your first pipeline, Create an Azure Resource Manager service connection with workload identity federation.

References: Microsoft Dev Box retirement guide, Microsoft Dev Box overview, Azure Deployment Environments retirement guide, What is Azure Deployment Environments?, Azure Lab Services retirement guide.

GitHub Codespaces provisions a container-based, browser- or VS-Code-reachable development environment straight from a repository, configured by a .devcontainer/devcontainer.json that pins the base image, installed tools (the Azure CLI, kubectl, azd) and VS Code extensions (including the Azure Tools pack from earlier on this page) so every contributor to Bookshelf’s repositories opens an identical, disposable environment instead of reproducing one by hand:

A codespace authenticates to Azure the same way a local machine does — az login interactively, or a federated workload identity when a codespace itself needs to run CI-like automation — and Docker-in-Docker inside it can run the Azurite/Cosmos DB/Service Bus emulators from earlier on this page exactly as a local machine would, making a codespace a viable substitute for a local dev box for Bookshelf’s contributors who prefer not to install the toolchain locally at all.

References: GitHub Docs — GitHub Codespaces overview, GitHub Docs — Introduction to dev containers, Development Containers specification.

Shifting security left in Bookshelf’s pipeline means catching a leaked secret, a vulnerable dependency, or a misconfigured template before it merges, not after it deploys — three practices cover most of that surface:

References: GitHub Docs — About secret scanning, GitHub Docs — Protecting pushes with secret scanning (push protection), GitHub Docs — About Dependabot alerts, GitHub Docs — About dependency review, Overview of Microsoft Defender for Cloud DevOps security, Reference table for DevOps security recommendations.