Bicep + Azure DevOps

Goal and scope

This implementation will deliver the shared AKS application environment with Bicep + Azure DevOps. It is planned, not deployed. The application, acceptance criteria, and failure exercise will match the other implementation, while all live Azure resources remain separately managed.

Planned implementation

I will start with a small application and a reproducible development target, then add delivery automation, monitoring, and recovery checks. DEV and TEST will be configurable targets. Only the target needed for the current exercise needs to run.

Infrastructure structure and environment parameters

The proposed repository will keep application code, Kubernetes manifests, Bicep infrastructure, and pipeline definitions in separate folders. Bicep modules will describe AKS, the registry, and supporting monitoring resources. Environment parameter files will select names, location, sizing, and the DEV or TEST target.

Resources will have an implementation-specific naming prefix and resource groups. This implementation will not modify resources or state belonging to Terraform. Module boundaries and exact folder names will be refined while building the first working deployment.

Azure DevOps pipeline stages

The code and YAML pipeline definitions will live in their own public GitHub repository. Azure DevOps Pipelines will connect to that repository and run the build and deployment pipeline.

Proposed workflow, subject to refinement:

1. Validate infrastructure — check Bicep and parameters.
2. Preview changes — produce a what-if result for review.
3. Approve infrastructure deployment — require an explicit decision before changes are applied.
4. Deploy infrastructure — deploy the reviewed configuration to the selected target.
5. Test and build application — run tests and build the container image.
6. Publish image — publish a traceable version to ACR.
7. Deploy application — update the Kubernetes workload to that image version.
8. Verify — wait for readiness and run the smoke test.

The approval control is an intended requirement. Its implementation and availability in the eventual Azure DevOps organization will be checked before choosing a mechanism. No configured gate or paid feature is assumed here.

Authentication and permissions

I plan to use an Azure Resource Manager service connection with workload identity federation rather than a stored Azure client secret. Trust will be restricted to the intended pipeline connection. Infrastructure changes, image publishing, and Kubernetes deployment will receive only the permissions they need; Azure resource permissions and Kubernetes authorization will be checked separately.

Initial identity setup and role assignment will be documented as a bootstrap step, separate from routine application releases. Credentials and tokens must not appear in pipeline logs or published evidence.

Deployment and rollback

The application will use readiness and liveness probes, a rolling-update strategy, and identifiable image versions. A release will be accepted only after rollout checks and a smoke test pass. A failed rollout must make the pipeline failure visible.

The rollback procedure will explicitly select the previously verified image or deployment revision, restore it, and rerun the smoke test. It will be exercised with a deliberately broken release. Rolling updates do not guarantee zero failed requests, and an application rollback does not undo database changes. Automatic rollback is not assumed.

Monitoring and troubleshooting

I plan to collect application logs and relevant AKS/application metrics, then configure one alert tied to the controlled failure scenario. A small investigation guide will connect the alert to pipeline output, Pod events, health probes, and application logs. The exact alert signal and threshold will be chosen during implementation and recorded with evidence.

Verification evidence

Results will be added after implementation. The shared acceptance criteria cover infrastructure validation and preview, deployment and smoke test, an application update, a broken release and explicit recovery, monitoring of that failure, and cleanup. Each recorded result should identify the environment, code revision, pipeline run, and observation. Screenshots will be added only when they document real runs.

Decisions and trade-offs

Bicep keeps the infrastructure definition close to Azure. Hosting both repositories on GitHub makes the implementations easy to browse together, while Azure DevOps runs this implementation’s pipeline. The GitHub-to-Azure-DevOps connection adds an integration to configure and maintain. I will document its permissions, change review, and troubleshooting alongside the GitHub Actions workflow used by Terraform.

The project favors a small, explainable environment over production-platform breadth. Both toolchains will be judged against equivalent requirements; conclusions will follow the evidence.

Costs, limitations, and cleanup

No measured costs are available yet. Running AKS nodes, registry storage, networking, monitoring ingestion, and any pipeline usage may contribute to cost. The implementation will document selected sizes, runtime duration, retained resources, and actual charges where available.

DEV and TEST will be created on demand. Cleanup will remove only resources owned by this implementation and check for leftover disks, public IPs, registry images, and monitoring resources. Deployment history is not a cleanup plan; the resource inventory will define what must be removed.

This is a portfolio lab, not a production availability or security claim. Operating limits and lessons will be recorded once they are observed.