Please stop building custom CD tools - 123dev #32
Posted on October 7, 2021 • 3 minutes • 499 words
Comments
Your build tools are great, but no one wants to learn them
I’ve never worked somewhere that had a completely off-the-shelf CI/CD system. In some cases the systems are just minor tweaks or wrapper scripts over common tools (usually Jenkins). In extreme cases it’s completely from scratch tooling that has syntax and behaviors I’ve never encountered before.
They’re usually hyper optimized for a majority of internal applications or specific languages, but they completely fail at being useful for the last 10-20% of internal applications. In the name of developer productivity we try to be special and I’m not sure if that says more about the state of general purpose CI/CD systems or developers desire to over optimize.
I don’t like them and prefer working around issues with common tools than streamlining with custom solutions.
Just do both
The Olympics have come a long way in 113 years. Each year what used to be impossible became possible. Congrats to all the medalists and people pushing themselves to be physically and mentally stronger.
As developers we are asked impossible tasks. “Make the API never go down, but don’t spend more than $100.” “Please make this tool as simple and opinionated as possible, but also make it flexible so anyone can use it.”
We should always ask clarifying questions to make sure we understand the request. Many times it’s our job to educate the requester why the task is impossible. Other times it’s our job to come up with the best compromise. Sometimes we need to ignore the request completely and build what we think is right.
Links
I wrote down my advice for how you can use Slack effectively in a work environment. A lot of it comes down to providing passive communication like you normally would get in an office setting. With Slack you have to be more deliberate about it.
Successful Slack — www.justingarrison.com Tips for using Slack in a work environment.
DNS has never been something I understood well. I know how to run DNS servers, how to debug DNS issues, and roughly how it works—not including DNSSEC—but if you asked me what records were used for what I’d have to look it up most of the time. I learned about a lot of record types in this post; they’re mostly old types.
(All) DNS Resource Records — www.netmeister.org Just how many weird Resource Records can you stuff into a zone file? And what do these weird RRs actually return?
I remember in the early days of Kubernetes people would say you shouldn’t use the default Kubernetes deployments because they were very limited in what they could do. I always said they provided more than what people had today and were often good enough. Kubernetes turned 7 this year and I still think that a simple rolling upgrade is good enough for a majority of users.
Deployment Strategies In Kubernetes — auth0.com Learn what are the different deployment strategies available in Kubernetes and how to use them.