Writings on building software delivery capabilities and delivering digital & technology outcomes for ambitious organisations.
Just as digital service teams are measuring the performance of their products, it’s important also for technology departments and development teams to decide on what good technology looks like so that we can ensure the choices and practices we’re implementing are having a positive outcome for our users.
Now that we know what Kubernetes is, let’s see what options we have to create our own Kubernetes cluster.
In an ideal world, ideas are transformed through discovery and development into desired outcomes and impact. In practice, balancing discovery and development isn’t always easy or a priority.
This is the start of a blog post series that will discuss the various aspects of Kubernetes. We’ll try to guide you through the myriad of choices when choosing the type of Kubernetes installation, setting up a continuous pipeline to deploy your application to a Kubernetes cluster and how to secure said cluster.
At the time of writing this, I’m in the latter half of the Made Tech academy process, so I figured I would write about the experience so far and why the scheme is invaluable for people who have some technical skills but are trying to get started within the tech industry.
Some dos and don’ts for supporting and coaching less experienced engineers
At Made Tech, our company mission is “to improve software delivery in every organisation” and recently while using Azure DevOps, I’ve been feeling that currently, these two things are mutually exclusive.
The evidence is all around us: there is a shortage of digital skills. You only need to look at the ever inflating tech salaries and the array of benefits companies offer employees. Such offers are made in an attempt to get access to the limited supply of tech talent available in the market. We’ve got a problem and it’s only going to increase unless we do something about it.
So you’ve read part one. You see the point of building Extremely Fast Feedback Loops and you want to understand what it costs to have such a test suite. Let’s explore some problems…
When we deliver software, we need to ensure it meets the needs of end-users. The slowest feedback-loop is a “big-bang” release – this is essentially shipping all the features at once after developing for weeks, months or even years. We know this to lead to failure far more often than not… Yet, many teams release software this way, and no we don’t recommend it.