My Portfolio¶

*Due to non-disclosure agreements I have signed pertaining to my current employment, I will not divulge any details related to certain work deliverables. For each item in this portfolio, I will clearly indicate whether this is a personal or work deliverable and then give the appropriate amount of detail to adhere to the agreement I signed.

Professional Portfolio¶

Configuration CI/CD Pipeline (Professional) *¶

A brand new network and security configuration installation CI/CD pipeline was designed, developed and implemented by me. Multiple ops teams were involved during the design phase and continual improvement of the pipeline itself has led to multiple enhancements following go-live. Safeguards have been built to help force full rollouts to fail early and often if errors are found.

Demonstrated Skills¶

Benefits¶

Provides a framework to safely install configuration changes made by humans and automation, opening the door for countless additional automation deliverables related to the in-scope equipment.
Eliminates manual configuration installation labor and errors.
Allows for a predictable installation pattern, improving consistency and avoiding mistaken rushed installs or skipped steps.
Adheres to a strict installation schedule where all affected parties know when to expect possible configuration changes.

Lessons Learned¶

Involve owning ops teams as early as possible in the design process.
Communicate, communicate, communicate! Follow up with written communication. Have meetings if it seems like the message is not being received.
Seek knowledgeable buy-in from management early and keep these sponsors in the loop at all stages of development and implementation.
Provide objective feedback on design options to ensure maximally informed decisions are made.

Push-Button Network Task Automation (Professional)¶

Within my first year at Menards, I was given an opportunity to build an automation framework for push-button task-focused network automation to empower our tier 1 and 2 support staff to perform certain troubleshooting and steps and problem resolution without requiring tier 2 and 3 support, respectively. I led the platform research, implemented our choice platform, built role-based access control, created all the supporting automation software, created the documentation, and became a maintainer of our framework once it was implemented. I also identified and fixed a bug with task scheduling that was found with the platform that was chosen. I accomplished all this within two weeks. This framework has proven to be immensely popular, with over 50,000 unique uses since its debut in 2022.

Demonstrated Skills¶

Benefits¶

Reduces lag time between teams and gets tools in the hands of team members.
Improves consistency by transforming uncertain troubleshooting patterns into consistent automated troubleshooting steps.
Opens up new troubleshooting opportunities previously considered financially infeasible, saving many hundreds of thousands of dollars in unnecessary hardware replacements as a result.
Allowed support tiers 2 and 3 more time to focus on other pressing matters.

Lessons Learned¶

This solution came at a time when other ops teams were also working on their own automation platforms in their own silos. We now work closely together to avoid siloing and needing to support a variety of platforms.
Opening a clear line of communication between myself as a maintainer and the level 1 and 2 support staff using this allowed for massively improved behavior and new functionality. For this solution, this communication came later on during the maintenance period of this sol I keep myself agile and willing to learn whatever I need to do my job exceptionally well.ution, far too late. Now, this type of communication comes before a single line of code is written. I prioritize feedback during early design and keep ops teams involved during every step.
Being a maintainer of a solution proved much harder over the years compared to the initial flurry of work setting this up. Some of that was due to my own inexperience. Any automation solution I create has this in mind from the design beginnings.

Personal Portfolio¶

This Website (Personal)¶

The development and hosting of this website is a worthy addition to my portfolio! I demonstrate some pretty neat hosting and git automation skills with this site.

Demonstrated Skills¶

Design¶

graph LR
  A[Git Commit Push] --> B;
  B[Post-Receive Git Hook] --> C;
  C[MKDocs Build] --> D;
  D[Update Site Files] --> E;
  D --> F;
  E[Build Container] --> G;
  F[Push Files to Web Server];
  G[Push Container to Registry];

Hosting¶

I host this on my home network, and this website lives on a server located in a DMZ. Access to this site passes through Cloudflare. Additionally, my firewall serves as an additional stopgap to help control for unlikely attacks that make it through Cloudflare.

I also have the option of hosting this on GCP as needed using Google Kubernetes Engine.

Git Hooks¶

I use the post-receive Git hook on my remote Git server to automatically git pull, build the mkdocs site, push the site files to my web server, and build a container image with Docker using the httpd image as a base. This allows the website to instantly reflect the current state of the master branch of my git repository the moment that I push to my remote. This allows for rapid iteration during development and ensures this website you are viewing right now is up to date without me needing to perform any additional actions aside from just pushing using git.

Design Thought Process¶

I found it burdensome to see changes I made to the website's source make it onto my website. I decided to tackle this by leveraging a server-side Git hook. Git hooks were something that were still somewhat fresh in the mind after reading about them in the git-scm book. Reading through the list of server-side hooks, the post-receive hook felt the most correct to leverage, especially due to the list of example actions that can be taken by that script.

Knowing that I wanted to use the post-receive server-side hook, I needed to next build the post-receive script that would do exactly what I want in the simplest manner possible. It only rebuilds the website and uses rsync to push the files to a separate web server. The script cares not about what branch is being pushed to, as I only use master here. The simplicity helps this remain easy to maintain.

I chose to copy the site files both to a traditional web server and creating a container image so that I could continue using existing infrastucture I own and have set up (the traditional web server) while also having a container image on-hand locally and in a cloud container registry. This cloud image registry can directly be used by my GKE cluster and host the exact same website in the cloud with minimal configuration.

I chose MKDocs as the platform, which may seem strange, considering it is known for its clean documentation. I chose this due to my prior experience with the platform and markdown as well as my appreciation of the clean output. There are limitations of the platform, but it allowed for fast buildout and iteration and I stand by the choice.