BAILEY FITCHETT

NEW YORK, NY · AZURE / TERRAFORM / GITHUB

Bailey
Fitchett.

Practical engineering. Smarter automation.

Senior DevOps / Platform Engineer

I turn complex infrastructure and delivery workflows into systems teams can understand, maintain and trust.

Explore my work Download résumé

Open to Senior DevOps & Platform Engineering opportunities

Bailey Fitchett with blue hair and black glasses
ENGINEER. AUTOMATE. EVOLVE.
Azure cloud deliveryInfrastructure as CodeSecure developer workflowsAI-assisted engineering

START HERE

Find the work that
fits your team.

Start with the responsibilities
you’re hiring for.

SELECTED CAREER IMPACT

Engineering that changes
the working day.

Read the full résumé

>50%

Less provisioning time

Automated VM provisioning, Puppet installation, certificate management, node classification and initial configuration.

Bottomline Technologies · DevOps Engineer Lead
2015–2016

~95%

Fewer deployment errors

Standardized Linux configuration, middleware, security baselines and Puppet-driven provisioning workflows.

Bottomline Technologies · DevOps Engineer Lead
2015–2016

6

Applications migrated to Azure

Led planning and execution across approximately 18–21 services and 4–6 environments, meeting target release dates.

IntegraConnect · Cloud Modernization Lead
2016–2021

01 / SELECTED WORK

Built to be examined.

Runnable demonstrations. Clear tradeoffs.
Evidence you can inspect.

FEATURED PROJECT01 — AZURE PLATFORM FOUNDATION

AI review with
engineering guardrails.

A local language model selects Terraform review questions from a fixed catalogue. Python validates every response against the plan evidence; a deterministic policy keeps control of the decision.

The case study follows two real model failures through stricter prompts and response schemas, then preserves the measured local results.

Explore the AI walkthrough Explore repository
  • Terraform
  • Python
  • Ollama
  • Azure

OBSERVED LOCAL EVALUATION

12/12

Synthetic evaluation cases passed
in one Qwen 2.5 3B run

13/13

Separately constructed adversarial
validator probes rejected

A separate four-resource capture recorded 60.203 seconds of CLI wall time and 1,688 tokens.

Read results & limitations
Read the complete AI case studyProblem · Architecture · Failures & fixes · Recorded evidence

02 / GITHUB MIGRATION READINESS

Know what made
the move.

Assess migration readiness and verify branches and tags, including changed tag annotations. A real local Git rehearsal makes migration gaps visible.

50 testsper extracted release package
on Windows and Linux

Azure DevOps collection uses simulated responses; Git reference rehearsals use real local repositories.

Watch the walkthrough Explore release
Read the engineering case study Readiness / acceptance evidence

The problem

A repository copy can look complete while branches, tag objects or required ownership information differ. A migration needs explicit acceptance evidence and a way to represent what is still unknown.

What I built

An offline Python assessment tool, a read-only Azure DevOps collector and a disposable local Git rehearsal. Reports connect findings to evidence, accountable roles and next actions.

Decisions & tradeoffs

Compare annotated-tag objects separately from their target commits, and retain unknowns when collection cannot establish a fact. Keep the rehearsal local so it is repeatable without credentials.

Observed result

The altered rehearsal copy exposed one missing ref, one unexpected ref and two mismatches, including a changed tag annotation. Windows and Linux produced identical release ZIPs; each extracted package passed 50 tests.

What remains outside the check

Matching refs is one acceptance check. LFS, permissions and platform metadata need separate verification. The collector’s live mode has not been exercised against a real organization.

Inspect the Git verification method

03 / SECURE DELIVERY REFERENCE

Verify the build.
Rehearse recovery.

Check signed artifact provenance before promotion, then verify service recovery over HTTP. The case study documents a verifier failure, the fix and release evidence.

29 testsplus a real-signature check
and signed-build rehearsal

Recovery runs on disposable loopback services. No production deployment is claimed.

Explore the reliability lab Read the signed-build evidence Explore repository
Read the full delivery case study Signed releases · Verifier failure & fix · Recovery evidence

These are independent portfolio demonstrations. Azure configuration is mock-tested, and infrastructure rehearsals use disposable local resources. The AI results establish contract compliance on a small synthetic corpus; broader model quality and reviewer time savings remain unmeasured.

02 / ARCHITECTURE EXPLORER

See how the pieces fit.

Explore the boundaries.
Inspect the decisions behind them.

Choose a view, then a component to read its purpose, design tradeoff and source code.

Azure foundationAI reviewSecure deliveryReliability lab

TERRAFORM CONFIGURATION

One allocation. Reusable boundaries.

A hub and Team A spoke share a resource group. Team B is an optional second spoke; every network uses the same module.

RESOURCE BOUNDARYFoundation resource groupShared location and platform ownership
PLATFORMHub networkAllocation 0 · /20 network EXISTING SPOKETeam A spokeAllocation 1 · /20 network OPTIONAL · OFF BY DEFAULTTeam B spokeAllocation 2–15 · /20 network

Bidirectional peerings · routing subject to subnet NSGs

USED BY EVERY NETWORKReusable network moduleVNet + workload subnet + subnet NSG
The hub has separate peering resources in both directions with each enabled spoke. There is no direct spoke-to-spoke peering, forwarded traffic or gateway transit. The subnet NSGs still deny inbound traffic.

COMPONENT NOTES

Foundation resource group

Purpose
Place the hub, spoke networks and peerings in one foundation resource group, with environment, owner and Terraform-management tags.
Tradeoff
One group keeps this lab small. Team owner tags record accountability; they do not create separate subscriptions, resource groups or RBAC isolation.
Resource group configuration
Back to component

Hub network

Purpose
Reserve the first /20 from the base /16 for the hub. Root-managed peerings connect it to Team A and, when enabled, Team B.
Tradeoff
This hub demonstrates network structure. It does not provide a firewall, gateway or shared-service workload; peering alone does not approve application access.
Hub and peering definitions
Back to component

Team A spoke

Purpose
Give Team A its own network and workload subnet while retaining the existing module.spoke address. An optional tag override records the team owner.
Tradeoff
Keeping the original Terraform address avoids an unnecessary state-address migration. Team ownership remains tagging rather than a separate access-control boundary.
Existing spoke module
Back to component

Team B spoke

Purpose
Enable a second spoke only when team_b is configured. A stable team_b key identifies the module and its two peerings; a validated allocation index reserves its /20.
Tradeoff
Separating instance identity from the address slot preserves stable Terraform addresses. Changing the allocation can still cause network changes and requires plan review.
Optional spoke and peerings Team B input validation
Back to component

Reusable network module

Purpose
Build each VNet, a /24 workload subnet from its /20 allocation, an NSG and the subnet association. A priority-4096 deny rule explicitly blocks all inbound traffic.
Tradeoff
Future workloads need narrowly scoped allow rules with lower priority numbers. Outbound traffic still uses Azure defaults; this module does not implement egress filtering.
Network module and inbound rule
Back to component

Configuration only · mock-tested; no Azure deployment recorded.Source revision 1c24b17 · links open the inspected implementation.

Explore the AI plan review

LOCAL OLLAMA REVIEW

Two paths. Python keeps the decision.

The plan supplies deterministic policy evidence and a bounded model request. Only a validated response reaches the advisory report.

LOCAL INPUTSaved plan JSONValidated Terraform plan contract PYTHON PREPARATIONBounded evidenceAliases, action order and fixed enums PYTHON DECISIONDeterministic policyDestructive actions and plan completeness OLLAMALocal Qwen modelSelect catalogue question IDs LOCAL OUTPUTAdvisory reportPolicy result + validated questions PYTHON CHECKResponse validationCoverage, facts and question rules
The plan feeds policy → report and bounded evidence → local model → response validation → report. The model path cannot change the policy decision; invalid responses stop the review with exit 2.

COMPONENT NOTES

Saved plan JSON

Purpose
Read saved-plan JSON locally, validate the consumed fields and preserve a hash of the input bytes. The AI review accepts at most 20 resource objects without truncation.
Tradeoff
The contract rejects unsupported actions and malformed plans. This is action-level evidence, so a passing check does not establish that a change is safe or authenticate the input.
Input preparation Plan input contract
Back to component

Bounded evidence

Purpose
Send generated evidence IDs, mode, actions, category and unknown-value status, plus the question catalogue and per-resource constraints. Addresses, before/after values, variables and arbitrary plan strings stay out of the request.
Tradeoff
Limiting the outbound evidence makes the contract inspectable. It deliberately prevents the model from performing attribute-level or dependency analysis.
Provider-safe projection Local request construction
Back to component

Deterministic policy

Purpose
Classify known action combinations and flag deletion, replacement, incomplete plans and deferred changes for human review. Carry that result unchanged into the final report.
Tradeoff
An explicit rule is repeatable and testable. The no_destructive_changes result only describes this policy; it is not deployment approval or a full risk assessment.
Action policy Unchanged gate in the result
Back to component

Local Qwen model

Purpose
Call the installed Qwen model through the loopback Ollama API using a schema keyed by every evidence ID. Each resource gets its own allowed and required question IDs.
Tradeoff
A small local model can still return omissions or irrelevant questions. Constrained generation narrows those failures but does not replace application validation.
Complete-resource response schema Ollama provider
Back to component

Advisory report

Purpose
Join accepted findings to the local evidence map, render catalogue text and save JSON and Markdown in a fresh directory. Exit 1 means human review is required; exit 0 means this policy found no destructive changes.
Tradeoff
The saved report preserves an inspectable result, not authorization to apply Terraform. Its hashes identify bytes without proving who produced them.
Report assembly and rendering CLI outputs and exit codes
Back to component

Response validation

Purpose
Require every evidence ID exactly once, unchanged category and unknown flags, one to four distinct allowed questions, and every required question. Reject extra fields and missing coverage before rendering.
Tradeoff
Failing closed makes a bad answer visible and can require another attempt. The validator does not silently fill omissions, repair facts or establish broader model quality.
Response validator Wire-response coverage check
Back to component

Advisory CLI flow · no apply execution, attribute analysis or live dependency graph.Source revision 1c24b17 · links open the inspected implementation.

Explore the AI walkthrough

SIGNED RELEASE REFERENCE

Bind the bytes to the approved build.

A manually dispatched main-branch release builds and attests the package. The promotion gate checks those bytes against an independently approved source commit.

BUILDReproducible packageapp.py + commit/version manifest SIGNGitHub attestationExact ZIP digest · Actions identity OPERATOR INPUTApproved source commitIndependent 40-character commit PRESERVERetained release filesZIP, checksum and original Sigstore bundle ACCEPTLocal promotion stateActive + retained previous package VERIFY BEFORE PROMOTIONProvenance gateBytes, manifest, signature and identity
Package → attestation → retained release files → provenance gate. The gate also requires the approved commit; only successful verification allows the local active/previous state to change.

COMPONENT NOTES

Reproducible package

Purpose
Create an allowlisted ZIP with fixed member metadata and a SHA-256 sidecar. The release job requires passing test and CodeQL jobs, workflow_dispatch and the main ref before it builds.
Tradeoff
A small package is easy to inspect and reproduce. A checksum detects changed bytes but does not authenticate their origin; signing is a separate step.
ZIP construction Release job conditions
Back to component

GitHub attestation

Purpose
Use the release job’s GitHub Actions identity to attest the exact ZIP digest. Signing permissions are scoped to that release job; pull requests cannot reach it.
Tradeoff
Provenance binds an artifact to a build identity. It does not certify that the application is free of defects or suitable for every environment.
Signing permissions and attestation
Back to component

Approved source commit

Purpose
Supply the expected commit independently of the package. The verifier requires the manifest, source digest and signer digest to agree with it under the fixed repository/workflow/main identity.
Tradeoff
The operator must choose the intended build. Reading an expected commit from the untrusted package would remove this independent acceptance check.
Approved commit comparison Fixed verifier policy
Back to component

Retained release files

Purpose
Keep the signed bytes and copy the original attestation bundle to provenance.jsonl. The release workflow also retains the verifier’s demonstration evidence alongside them.
Tradeoff
Co-locating files makes later inspection easier, but JSON claims alone are not signature proof. Verification still depends on the GitHub CLI and its trust checks.
Bundle preservation and evidence upload
Back to component

Local promotion state

Purpose
Call the full provenance gate before atomically changing local state. Public CLI rollback reauthorizes the retained previous package with its own approved commit and provenance.
Tradeoff
This records a local release choice. It does not deploy a service, switch live traffic or provide a transaction against a hostile filesystem.
Promotion and rollback gates Local state primitive
Back to component

Provenance gate

Purpose
Check the hash and ZIP structure, match the approved commit, then call gh attestation verify. Require the exact workflow/main certificate identity, GitHub OIDC issuer, source and signer digests, SLSA v1 predicate and a hosted runner. Rehash after the external verifier.
Tradeoff
Rejected signatures, missing tooling, timeouts and verifier failures all block promotion. The real-CLI regression check covers a boundary that mocked wrapper tests previously missed.
Complete release gate GitHub CLI identity policy
Back to component

Local, single-operator promotion reference · no cloud rollout or traffic switching.Source revision 3cc9d33 · links open the inspected implementation.

Read the verifier failure case study

DISPOSABLE LOOPBACK REHEARSAL

Observe. Recover. Verify the result.

Real HTTP samples drive a small alert state machine. An explicit harness runbook restores the previous package and checks that recovery holds.

SYNTHETIC SERVICEOwned local workerHealthy baseline → injected HTTP 503 MEASUREHTTP probesStatus, response body and duration HARNESS ACTIONRecovery runbookStop candidate · restore previous package OBSERVEAlert state machineFive requests · two breached windows CHECKRecovery verificationHealth, version, traffic and alert clearing RECORDRetained evidenceRaw samples, incident report and metrics
Owned worker → HTTP probes → monitor. The harness reacts to the alert by executing the runbook; recovery checks and monitor transitions are retained as evidence. The monitoring class never performs rollback.

COMPONENT NOTES

Owned local worker

Purpose
Run verified fixture packages as disposable loopback workers. The harness deliberately configures the candidate to return HTTP 503, after confirming its version and failed health response.
Tradeoff
The fault is injected behavior, not an application defect. Sequential workers use different local ports and do not measure traffic during startup or shutdown gaps.
Worker lifecycle and fault injection
Back to component

HTTP probes

Purpose
Request /health on the owned loopback endpoint, bypass inherited proxies and measure through the response-body read. HTTP errors, transport failures and invalid bodies remain unsuccessful observations.
Tradeoff
Keeping failed requests in the denominator exposes fast failures. The sample excludes readiness/version checks and worker-transition gaps, so it is not a production SLO.
Measured HTTP probe
Back to component

Recovery runbook

Purpose
After observing the alert, stop the owned candidate, reverify the previous package with the local checksum helper, restore it and confirm its expected identity before starting the replacement worker.
Tradeoff
This explicit rehearsal action is separate from the monitor. It tests local package recovery; persistent data, production traffic and signature verification are outside this lab.
Explicit recovery sequence Checksum-only rollback helper
Back to component

Alert state machine

Purpose
Evaluate a rolling five-request window. Two consecutive windows with at least 60% errors or p95 of at least 500 ms fire one alert; two full zero-error windows below the latency threshold clear it.
Tradeoff
Short windows keep the lab quick and repeatable. They are demonstration thresholds, not tuned production objectives; the class emits state transitions without paging or changing releases.
Alert policy Monitoring state transitions
Back to component

Recovery verification

Purpose
Require the restored 1.0.0 package identity, healthy /health and /version responses, twelve successful measured requests and a cleared alert. Check health/version again before declaring recovery verified.
Tradeoff
Multiple checks provide more evidence than a successful restart. This remains one local rehearsal and does not establish aggregate MTTR or production recovery targets.
Restored-service verification
Back to component

Retained evidence

Purpose
Save samples.jsonl, incident.json, incident.md and a final metrics.prom snapshot in a fresh directory. Retain policy, timeline, phase metrics and source/file hashes; stop all owned workers and remove temporary state.
Tradeoff
The capture is unsigned: hashes identify bytes without authenticating execution. A saved Prometheus-text snapshot is inspectable evidence, not live monitoring infrastructure.
Report metadata Metrics snapshot and retained files
Back to component

Unsigned local rehearsal · checksum-only package helpers; metrics.prom is a final snapshot, not a live endpoint.Source revision 3cc9d33 · links open the inspected implementation.

Inspect the recorded incident

03 / GUIDED AI DEMONSTRATION

One plan. Four resources.
A review you can inspect.

Captured September 11, 2026
Local Qwen 2.5 3B · Synthetic plan

Replacement order changes the review question. Step through the saved findings, then inspect the decision. The guided walkthrough uses an edited presentation timeline; the original recording is available separately.

Walk through the saved review

GUIDED

STEP 1 OF 6

One plan. Four resources.

An edited walkthrough of the saved synthetic plan and review. Each resource has its own action order and review questions.

  • R001 · Create → delete
  • R002 · No action
  • R003 · Delete
  • R004 · Delete → create
Inspect the saved findings below

The saved findings and original transcript are available below.

The 30-second guided walkthrough is an edited reading sequence. Original recording preserves all 60.375 seconds, including the model’s wait and buffered CLI output. The measured review time remains 60.203 seconds. Neither view autoplays.

Read the full transcript Download recording Inspect the synthetic plan

SAVED & VALIDATED RESULT

Human review required.

review_requiredReview exit 1

The response covered all four resources. Exit 1 is the expected review decision for this destructive plan. The report is advisory and does not authorize an apply.

R001 Create → delete

Virtual network peering · azurerm_virtual_network_peering.hub_to_team_b["team_b"]

  • How will cutover and temporary capacity be verified before the old object is removed?
  • Which dependent services need verification before and after this change?
  • What tested recovery procedure and retained data are available if this change fails?
  • Which functional and monitoring checks will confirm the intended result?
R002 No action

Hub virtual network · module.hub.azurerm_virtual_network.this

  • Which dependent services need verification before and after this change?
  • Which functional and monitoring checks will confirm the intended result?
R003 Delete

Workload subnet · module.team_b["team_b"].azurerm_subnet.workload

  • Which dependent services need verification before and after this change?
  • What tested recovery procedure and retained data are available if this change fails?
  • Which functional and monitoring checks will confirm the intended result?
R004 Delete → create

Team virtual network · module.team_b["team_b"].azurerm_virtual_network.this

  • Which dependent services need verification before and after this change?
  • What interruption window is acceptable when destruction precedes creation?
  • What tested recovery procedure and retained data are available if this change fails?
  • Which functional and monitoring checks will confirm the intended result?
Inspect the saved JSON response
Complete review CLI time
60.203 seconds
Reported token use
1,688 total tokens
Recorded policy result
Human review required

This is one saved run, separate from the 12-case evaluation. The unsigned capture and matching file hashes establish internal consistency; they do not independently attest execution. Azure deployment, broad model quality and reviewer time savings are outside the measured scope. Read the capture notes and reproduction details.

Inspect results and limitations Read the complete case study

04 / SERVICE RELIABILITY LAB

Detect the failure.
Verify the recovery.

A recorded local rehearsal follows an injected HTTP 503 failure through an alert, an explicit recovery runbook and twelve healthy recovery requests. The dedicated case study brings the incident timeline, source and evidence together.

Explore the recovery evidence Read the verifier failure and fix Read the full delivery case study

05 / EXPERIENCE & APPROACH

Built on experience.
Driven by curiosity.

20+ years across software engineering, infrastructure and enterprise delivery. I bring application context to platform work—and a practical focus on what makes a team’s day better.

How I work

Make changes reproducible. Give failures useful explanations. Keep credentials away from untrusted code. Document recovery before it is needed.

Outside engineering, I’m a songwriter and fiction writer. Structure and imagination have a place in both kinds of work.

2023 — 2026

Senior DevOps Consultant

Xebia

Designed Terraform automation and Azure Landing Zone deployments. Migrated TFS, Azure DevOps and Bitbucket repositories, implemented GitHub Advanced Security, and developed agentic solutions in GitHub.

2021 — 2023

DevOps / Platform Engineering Consultant

Cognizant

Led platform modernization, delivery automation and developer enablement. Mentored a remote team of five technical resources.

2016 — 2021

Software Architect / Cloud Modernization Lead

IntegraConnect

Led Azure modernization for healthcare applications, infrastructure automation, observability and disaster recovery planning.

View full résumé

PEOPLE / PRACTICES / DELIVERY

Leadership in practice.

Mentor distributed teams

Led and mentored a remote team of five technical resources, coordinating delivery across distributed workstreams. Provided hands-on architecture guidance and technical training for cloud delivery, Infrastructure as Code and automated deployments.

Cognizant · 2021–2023

Establish reusable standards

Designed and implemented Terraform automation and Azure Landing Zone deployments to standardize provisioning. Integrated GitHub Advanced Security into developer workflows and led migrations from TFS and Azure DevOps to GitHub.

Xebia · 2023–2026

Coordinate complex change

Led Azure migration planning and execution for six applications across multiple services and environments, meeting target release dates. Designed, tested and documented disaster recovery procedures aligned with recovery time and data-loss objectives.

IntegraConnect · 2016–2021

06 / TECHNICAL FOUNDATION

Tools with purpose.

Cloud & infrastructure

Azure · Terraform · Azure Landing Zones · ARM Templates · Linux · Windows Server

Delivery & security

Azure DevOps · GitHub Actions · GitHub Advanced Security · GitOps · Repository migrations

Automation & insight

Python · PowerShell · Bash · Puppet · Dynatrace · Grafana

GITHUBFoundations
AZ-900Azure Fundamentals
DP-900Azure Data Fundamentals
AI-900Azure AI Fundamentals

07 / LET’S TALK

Bring me the
interesting problems.

I’m looking for Senior DevOps and Platform Engineering opportunities where I can improve cloud delivery, build useful automation and help teams do their best work.

LinkedIn GitHub Download résumé