PI Branch-Out & Artifact Shipping Automation

Two complementary Python tools automating the start and end of the PI release cycle across 80+ repositories: one creates branches and triggers builds automatically, publishing every result as a release candidate; the other promotes exactly the modules QA has verified from release-candidate to stable, driven by an auditable Excel workbook.

I researched, designed, and built both tools entirely on my own, using the Azure DevOps REST API directly for repository, pipeline, and release operations, with Excel-driven bulk processing, idempotent operations, and a full audit trail as the core design goals for both.

At the end of every PI, a DevOps engineer had to create a new branch from main for each of the organization's 80+ repositories, then manually trigger the corresponding build pipeline for every one of them. Once QA verified the artifacts on those branches, the same manual process repeated in reverse: triggering the Product Library (PL) publish stage on each release pipeline individually.

Both steps were repetitive and purely mechanical, but at 80+ repositories the time cost added up every single PI. The real risk wasn't the time, though; it was that forgetting to publish even one or two repositories out of 80+ could have a significant effect on the released product version, and a manual, repetitive process is exactly where that kind of mistake happens.

1. Analyzed the full end-of-PI workflow and split it into two independent problems: getting new branches built and validated automatically, and getting QA-verified artifacts published automatically, then designed a separate Python project for each rather than one monolithic tool.

2. Researched the Azure DevOps REST API and found it covered nearly everything both tools needed: repository and branch operations, pipeline triggering, and release inspection.

3. Built the first tool, a branch creator and pipeline runner, supporting three modes: a single targeted repository, all repositories in the project, or an Excel-driven bulk mode reading repository, base branch, and new branch per row, which is what's actually used at PI end across 80+ repositories.

4. Had the tool validate that the source branch exists and the target branch doesn't already exist before attempting creation, and made source-branch locking idempotent, so re-running against a branch that's already locked is treated as success instead of failing the run.

5. Wired pipeline triggering directly into branch creation: once a branch is created, the tool automatically runs the pipeline whose name matches the repository, with that behavior configurable on or off.

6. From there, the release pipeline itself takes over automatically, with no manual step: it deploys the new branch to Dev, deploys to the QA Automation environment, and triggers the RC (release candidate) stage, publishing the build as a release candidate into Product Library.

7. Made the Excel-driven mode idempotent and resumable: branch status and pipeline status are written back to the same workbook after every row (created/exists/failed/skipped, triggered/failed/skipped), so a partially-completed run across 80+ repositories can be re-run safely without repeating work that already succeeded.

8. Designed error handling so one repository's failure doesn't stop the batch: the tool logs the failure with detail and continues processing the rest of the repositories, rather than aborting the whole run.

9. Built the second tool, an artifact release tool, to handle the other end of the PI cycle: once QA has verified the release candidates against a dedicated QA environment sourced from Product Library, this tool promotes exactly the modules QA cleared from release-candidate to stable.

10. Drove this tool from the same kind of Excel input: a row per repository and branch, with a PL Status column that reflects what QA has actually verified, values like ready, new, or yes trigger promotion, anything else, including a blank cell, is deliberately skipped rather than assumed.

11. For each row the tool finds the matching release definition, fetches releases filtered by that branch, and only proceeds if the most recent one has a succeeded RC stage, so nothing gets promoted to stable off a release candidate that never actually passed.

12. Extracted the Build ID directly from the release artifacts rather than trusting a value typed into Excel, so what gets promoted is verified against Azure DevOps itself, and wrote the Build ID, release name, release ID, and target environment ID back to the workbook alongside the final status, so there's a full audit trail of exactly what was published and when.

13. Built both tools with the same security discipline: PATs are never hardcoded, loaded from environment variables or a gitignored .env file instead, scoped to the minimum permissions each tool actually needs, and documented with a short-expiry, regular-rotation recommendation.

14. Added an optional FastAPI wrapper around the artifact release tool alongside its CLI, so the same promotion logic can be triggered as an API call instead of a manual script run, for teams that want it wired into other tooling later.