Let's take a quick tour of the yaks I shaved in my tiny nascent repo that's currently all framework with 0 actual behavior. For context: this is a Rails 7 app bootstrapped with JumpstartPro. So there's lots of behavior courtesy of the framework choice I made. Oh, yes, and tests too!

Yak #1.

Why is my build failing?

Oh, sweet! JumpstartPro has a ci.yml specifying a github workflow set up for ci out of the box. But it's failing. Why?

Oh (forehead slap). Standardrb violations. I can fix that. Done. Green now, right? Wrong.

Yak #2.

Why is my build still failing?

Ah, there's an image file I referenced on a static page but forgot to add. Whoops.

I don't actually care about the image file right now but fine, in the name of a green build I'll go find it and commit it.

So, green now, yes? No. Dang.

Yak #3.

Why is my build STILL failing?

Ah. I put the file in ./app/assets/images but it's being served by a static file so it should go in ./public/images. Someday I will get all of the asset pipeline stuff straight in my head. Today is not that day.

So. Green now? Yes? Yes. But I have questions...

Yak #4.

First question: can I run the same commands locally that I ran in CI?

Nope. Getting a mysterious error. Oh, I recognize this one. It's because I'm running the wrong version of Node. Didn't I upgrade already? This should work? OK FINE NODE YOU WIN.

brew upgrade node

Run now please, yes? No. Denied. Same mysterious error. Why?

Yak #5.

What version of node am I running? 14? WHAT? How. Just...how? OH. Dang.

nvm use 18.13.0

So, it will run now, right?

No, now I'm getting postgres connection errors. Ugh.

Yak #6.

What's up with postgres? Oh, somehow something I did in the last hour killed my local server. OK fine, restart.

pg_ctl start

And now run. TADA! But wait...what are all those errors?

Yak #7.

The errors are from opentelemetry. I configured Honeycomb yesterday. Super easy! Super fast! Very cool! But I only configured things for prod, not my local env. And while I can imagine wanting to see traces on my local env, that's not a yak I want to shave right now.

So how do I only load opentelemetry in prod? (this is not nearly as irresponsible as it sounds...my prod is only used by me).

Ah, got it. Only config the sdk if Rails.env.production?

All green and clean now, right? No.

Yak #8.

The system tests have a failure:

Could not open library 'vips.42'

WTF is a vips? Ah got it. Imagemagick replacement. Do I have vips? No. Simple enough:

brew install vips

Everything is now green and clean right? No. CI is failing again. I left some trailing spaces that standardrb caught.

I really should add a pre-commit hook to run stardardrb --fix...but that's a yak for another day.

Putting down my razor. For now.

I believe that one difference between a junior & senior dev is knowing which yaks to shave.

Personally, I prioritize yaks related to:

1. Having automated tests that run on checkin.

2. Keeping that CI build green & clean so when it fails you know it's for a good reason, and it's (relatively) easy to figure out why.

3. Being able to run that same set of tests locally.

Shaving these yaks wasn't the most gratifying use of time, but it's super important.

Two more yaks that are important to prioritize:

1) Find a way to test locally. It's a complicated system and setting it all up locally is too hard? That's nice. Find a way. Otherwise a single experiment can burn half a day or more.

2) Speed up those test cycles. (Finding a way to test locally is a specific example of the more general speed yak.)

I struggled with the Local Test yak today trying to test my ci config. Got there tho. (yay ssh-add -D)

@testobsessed Amen on local testing. I've spent a day in the shadowlands between local pass and Jenkins fail, with much frustration.
@testobsessed Yes! Also yaks that make any of those faster are always good too. Shaving a few minutes of something you run multiple times a day is always worth it.
@testobsessed If I have users I tend to shave yaks related to whether I can see what is going on and debug user problems. This can be observability as conventionally defined, but can also be things like admin web pages.