<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Automation on GeekyRyan</title><link>https://rnemeth90.github.io/tags/automation/</link><description>Recent content in Automation on GeekyRyan</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 15 Jun 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://rnemeth90.github.io/tags/automation/index.xml" rel="self" type="application/rss+xml"/><item><title>Data Tier Architecture Modernization - Phase 1: Rethinking Legacy Orchestration</title><link>https://rnemeth90.github.io/projects/2026-06-15-data-tier-architecture-modernization-phase-1/</link><pubDate>Mon, 15 Jun 2026 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2026-06-15-data-tier-architecture-modernization-phase-1/</guid><description>&lt;p&gt;Phase 1 of modernizing a legacy application configuration orchestration system - the scripts and automation that provision databases, apply configuration, and run SQL changes across environments. The old system was a sprawl of individually-named scripts, each handling a slightly different variant of similar work. Hard to maintain, hard to onboard onto, impossible to add consistent error handling or monitoring. Often hard to understand.&lt;/p&gt;&#10;&lt;p&gt;Rewrote it around a small set of reusable, well-defined action types instead: configuration action (routing sensitive and non-sensitive config to the appropriate configuration store), database-creation action (with input validation), SQL-script-execution action (runs scripts with clear parameters), and a general-purpose command action for anything else.&lt;/p&gt;</description></item><item><title>Enabling Automated, On-Demand Lab Environments</title><link>https://rnemeth90.github.io/projects/2025-05-12-on-demand-lab-environments/</link><pubDate>Mon, 12 May 2025 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2025-05-12-on-demand-lab-environments/</guid><description>&lt;p&gt;Let people spin up lab environments on-demand, self-service, instead of having to ask an infra team and wait around.&lt;/p&gt;&#10;&lt;p&gt;It streamlines testing, experimentation, and onboarding - a new team member can provision a full application stack without waiting on manual provisioning, which removes friction on both ends: the people don&amp;rsquo;t have to wait, and the infra team doesn&amp;rsquo;t have to handle the recurring &amp;ldquo;can you build me an environment&amp;rdquo; requests.&lt;/p&gt;</description></item><item><title>Rebuilding a Lab Environment Deployment Pipeline From Scratch</title><link>https://rnemeth90.github.io/projects/2023-09-08-rebuilding-the-lab-deployment-pipeline/</link><pubDate>Fri, 08 Sep 2023 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2023-09-08-rebuilding-the-lab-deployment-pipeline/</guid><description>&lt;p&gt;Lab and test environments have a tendency to accumulate complexity over successive iterations of &amp;ldquo;just add one more special case.&amp;rdquo; By the millionth version of our lab deployment pipeline, it had grown into something that was hard to reason about and expensive to maintain - lots of administrative overhead just to keep it running, let alone extend it. Deploying the pipeline also took far too much time.&lt;/p&gt;&#10;&lt;p&gt;This project was a ground-up rebuild of that pipeline with the explicit goal of removing accumulated complexity and reducing the administrative burden of maintaining lab environments. Rather than patch the existing pipeline again, I rebuilt it with a cleaner, more streamlined deployment process - fewer special cases, more consistent conventions, and less manual intervention required to stand up or tear down a lab environment. The overall deployment time went from 45 minutes to less than 25 minutes.&lt;/p&gt;</description></item></channel></rss>