#release-engineering - December 2020

I have an interesting issue, and would love to get some input on how to continue to troubleshoot:
We have a jenkins pipeline that runs hourly, at the top of the hour, and without fail for a while now, it fails each job it starts at midnight and recovers the following run. The reason for failing also differs from time to time. One time "docker login" failed, another time the "helm" command timed out, or an error regarding forwarding of ports. The failurs are not seen during the rest of the day, but only during that one execution at midnight. Any pointers would be wonderful!

I’m wondering what best practices of managing a version of an app as a whole in a microservices world are if any. Say, we have tens or a hundred of microservices and a monolith. Back then we versioned this monolith and that was the version of the app. Dead simple. Now every microservice gets its own version since each of them has its own lifecycle. And still, by inertia, people tend to consider a version of a monolith as a version of the whole system which is only partially true now.

What are your thoughts on this?

One thing that came to my mind is the following. Since we define all deployed releases via some tooling (helmfile for example) and store this in git we can make a reference to a snapshot of a repo with helmfile values (commit hash or a tag) which represents a set of services of certain versions. And we can prepend this by a good old version of a monolith which everybody is aware of or a calendar version.

"why does the version matter to anyone?" is usually the question i would start with to figure out what make sense as a version

that's not a rhetorical question either; why do people look at the version and what do they want to learn when they do?

Mm, we thought it was too hard to version everything and couldn't see value so we only version microservices themselves and it's by git sha.
If dev wants to run everything as is typically the case for local dev, then they use latest tag in docker-compose and similar. They can obviously pin as need be.

I've been pushing for services to have a 'version' only in the sense that it helps them say 'deploy based on this commit ref'. System 'version' is meaningless and just serves as a talking point for Product when dealing with the clients. Product was very concerned about knowing what 'release' we're on and I told them they could just make something up

Yes it’s mostly for POs and clients. They want to differentiate a “state” of a whole system, especially when it’s an enterprise and the system is deployed per client.

Semver is nice, and in theory tells you if anything has changed that you should be concerned about... in reality it doesn't get abided so... for our services we moved to tagging images with the short hash of the git commit that produced them:

Anybody using the GitHub actions deployment feature? I use azure devops but I'm the only one on the team that uses actively. Was thinking about leveraging for some more controlled pull requests terraform deployments. Curious if anybody's evaluated the pros and cons. I think the deploys been there but now they have the new visual feature of it I guess.

I'm not sure if this has been discussed before but couldn't really find anything when searching... Preview environments, branch based environments, ephemeral environments... call them what you will, is anybody doing it? It's always the dream that a developer can create a branch and some bot pings them on Slack to say to visit the magic url...

anyone know of tooling for managing select files across numerous github repositories? mostly thinking about a handful of files that are often identical (or nearly), like .editorconfig, LICENSE, or maybe a github actions yaml... i did find one github action, curious if anyone has experience with it or any other options... https://github.com/kbrashears5/github-action-file-sync