Jump to Using gorelease below.
I’m neither a lover nor a hater when it comes to Go and its ecosystem. Generally things Go are a bit rudimentary but very open and accessible. You may have to do some work yourself, but you’ll be able to get results.
There are simple best practices around versioning and releasing software in general, regardless of language or tool:
Do those two things and you’ve got an orderly, identifiable, reproducible product.
I wanted to really understand the flow of Go code to production at my work. I looked at all the IaC code they had in place and was overwhelmed — so many tools involved, so much configuration. So I did the code monkey thing, and went off to a dark corner and implemented the bare minimum myself to learn.
This is a long post, but stick with it, look in the associated repository, and you’ll be able to create a program and deploy it into a Kubernetes cluster all on your own machine — not too shabby.
The overall lesson…
In cognitive science, you’ll come across discussions of the two modes of neural activity, focused and scattered. In focused you’re working with a relatively small set of related chunks of information, for example solving a problem. In scattered your brain is ping-ponging around seemingly unrelated pieces of information and making neural connections between them, dreaming would be one example of this.
In meditation, you’ll come across types of meditation that are geared towards focusing your mind, and those that specifically strive to unfocus your mind. This isn’t coincidental, the meditation is targeting one or the other cognitive state.
Go 1.16 added the embed package. Theoretically, it offered a better solution to how I’d previously implemented some things so I gave it a try.
So, I had a large string template that I use to generate some output from. Previously I did the following:
TemplateStr = `blah blah blah some big string contents goes here ... Mauris mollis neque nisl, sit amet facilisis nulla finibus ut. Aliquam massa metus, imperdiet a finibus accumsan, interdum vitae felis. Ut et dapibus purus, sed mattis nunc. Mauris dui nunc, suscipit consectetur vulputate sit amet, luctus feugiat leo. Quisque fermentum…
I believe in keeping software dependencies up to date in a timely fashion. I’ve never liked the if it ain't broke, don't update it approach. I’ve written about this before. With Go projects I periodically run:
$ go get -u the/module/name
To update the dependencies in a project using the/module/name of the current project. Usually, this just grinds against the go.mod file and does the right thing, updating all the modules and their dependencies to the latest and greatest. Sometimes, when you run this, if a dependency introduced a breaking change, your code won’t build, or your tests fail. …
I’ve been working with Go professionally for a bit, and I’m still not convinced it's the enterprise language it’s touted as, at least not to a software craftsman. It’s too nuts and bolts. The underdeveloped support for things like encapsulation, composition, and code reuse leads to too much code rot.
That said, looking at its origin at Google, as a response to a growing plague of production Python and Bash scripting, Go is a great nail and hammer for that problem. You can produce decent code that you won’t regret next week pretty damn quickly.
I think this scenario will be familiar to many developers. A project with database requirements is moving fast which puts pressure on testing. No strategy for testing persistence is agreed upon in advance and three anti-patterns emerge. For simple tests, people mock the data. Others, without a database, defer the persistence tests to integration testing. Finally, someone spins up a “test” database instance somewhere and starts using that. These solutions very quickly become entrenched and add to the technical debt pile.
I’m not going to address the fundamental position that “database access and persistence are by definition part of integration…
To learn and test new things in Kubernetes, I like to do it in a local cluster. Being able to spin things up on your laptop is simply a win. This article won’t address the “why Istio” at all, just the “how”. Previously I wrote on getting a local Kubernetes cluster going with Docker Desktop and Helm. Continuing down that path I added Istio into the mix. The work was done in a branch of the same repository.
You might want to grab the repository to follow along.
You’ll need only two things in place for all this, Docker Desktop…
Remember when everything was configured using XML? Seemed good, but the contents meaning were mysterious and once you encountered that first error it was downhill from there. They solved that with scheme support right? No. That added more work to implement and barely addressed syntax issues doing almost nothing for larger issue of semantics.
Thank goodness YAML came along! I’m being sarcastic. The name alone, Yet Another Markup Language, should have set expectations, and proving we just don’t learn, YAML configurations went through the same evolution as XML. When the things starting getting out of control people added “API Versions”…
Graybeard code monkey, started on an Apple IIe, got a CS degree in the 80’s, and coded my way through C, C++, Objective-C, Java, Kotlin — and now Go.