DEV Community: John Mitchell

CI and CD have two different audiences

John Mitchell — Sun, 23 Mar 2025 16:27:46 +0000

CI should be fast, and give actionable feedback to its audience: the Developers. Whatever system delivers this is fine.

CD should be predictable and reliable. Its goal is to deploy code/assets to a pre-production server so business can validate the feature changes. Again, whatever system does this is fine.

Logically a single CICD system would be simpler. The part about "failure can happen in AWS CP which is not reflected in the triggering workflow" makes me nervous. I'd expect a CI to be "smarter" than CD, so a deploy-time error should show up sooner, in CI, vs after the handoff.

The overall goal of any pipeline -- including CICD -- is to optimize fast, high-quality, reliable changes to create business value. Generally, getting code features into production so real users can see them.

The specific quality/ scope/ speed/ cost/ complexity tradeoffs vary per company and per team. That's fine.

Response to Is it ever a good idea to split CI and CD across two providers? on Reddit

Starting Tests from Zero

John Mitchell — Sun, 23 Mar 2025 16:25:58 +0000

Often developers and businesses can't see the value that testing gives. Devs see it as a "tax", an extra thing that slows them down from doing their "real job". Businesses go into magical thinking mode, that Devs are always creating flawless features that deliver whatever the Business thinks it does and fits into the system.

Tests don't slow down development, then pull the development forward. Writing "happy path" Unit Tests shows Devs what to work on next. Investing in high level End to End tests gives the Business confidence the system is working reliably and new changes aren't dangerous.

Here's how to get started with tests if you have non.

Top-down vs Bottom-up: two different Audiences

Write one or more end-to-end tests (E2E). This gives confidence that the entire app is solid, at the cost of being slow and not very detailed. The main benefit is for the Business: they can see and understand the results.

Back in the day, for a shopping site, our E2E test was "create user, add item to cart, checkout, validate there's a total cost" kind of thing. It was slow but had really obvious business value. Nowadays you'd do something like Playwright for this.

Write lots of "happy path" unit tests, generally one per non-obvious function. These are fast and give a lot of info, but for a tiny scope: one function. Generally any time I have to think, I write a test.

Also write a unit test per bug, even if it's just "this doesn't work" or "expect some sort of Exception to happen here". Tests can be vague if that gives you actionable feedback as a developer.

publish Test Coverage! This is great as you and your team -- and more importantly the Business -- can see this number and how it changes over time. New code makes number go down? Write tests for the new code (or old code, if that makes sense for your team). Bug happens? Write test -- number goes up -- then fix the bug.

The overall goal is getting into a Value Feedback Cycle. For the Business audience, they want confidence the app is functioning as expected, that a new deploy won't bring down the site. For the Dev audience, they want fast actionable feedback for them to complete the features. The two types of tests: End to End and Unit Tests, give this feedback to the two audiences.

Advanced: unit tests don't cover much code. Consider adding API-level tests like with Postman. These are cheaper in that a single test checks more code, even though at a less detailed level. They're also fun for the Business and Devs to see because a single API test makes the Test Coverage go up more than from a single Unit Test.

FP > OO

John Mitchell — Sun, 17 Nov 2024 18:46:51 +0000

I'm a fan of Object Oriented programming (OOP), but don't use it much. The challenge is that nearly always the state and functionality gets mashed together, so it's hard to modify either one. Example: OO can be harder to test because it's not obvious which sequences of init / update functions are needed before you can actually test the resulting object.

Functional Programming (FP) makes adaptation and testing much easier.

Occasionally I'll do a "class" that's just a bunch of static methods, like a mini-library of related functions. Each function accepts state, and returns it. No side effects.

Rich Hickey's classic talk

Simple Made Easy

really brought the ideas together for me.

In response to Hesitation to Write Actual OOP on Reddit.

Re: I Like Makefiles

John Mitchell — Sun, 17 Nov 2024 18:43:45 +0000

in response to I Like Makefiles on Hacker News

I adore Make. I've written one (or more) for every single task or project I've touched in the last 20 years.
No smarts. It's just a collection of snippets with a few variables. "make run", "make test", "make lint", that kind of thing.

"make recent" = lint then run the most recently modified script.

You could do the same thing with Bash or other shells, but then you get stuck into Developer Land. Things are so much more complicated, without giving extra value. Make is just a DSL saying "files like this, are made into files like that, by running this command or two". That's it.

This is incredibly powerful!