Build, Run, Repeat - page 5
-
What the Hell is a Pipeline?
Mostly I’ve been taking things fairly chill this week on my personal projects - however what I have been spending a lot of time working on is my build pipelines. Off of this, I thought it’d be interesting to do a really basic, practical guide on exactly what a pipeline is, and what their value is. For the entirety of this post, I’ll be talking about Azure DevOps pipelines specifically - but other options are available!
-
Pretending I Have Production
I’ve mentioned previously that I have a small personal dashboard I maintain for displaying my fitness data. My main usecase is displaying it on an old TV - I think it’s important to keep your goals and progress visible, and I’ve done it for a long time (mostly with whiteboards). One of the decisions I made recently was to establish some form of “production” that wasn’t hacked together on a Raspberry Pi.
-
Not My Job
When I first moved into being a full time software developer, one of the first things I had to familiarise myself with was release processes. My background was as a designer, and part of that in my previous role had been building and maintaining the company website. It was how I got a taste for code, building WordPress and Drupal components. This included getting the code for the website up onto the webserver. Even before really understanding development, I managed to get away from just FTP-ing files around and instead pulling down from a git repository to do my “releases” - even if I was doing it manually, directly SSH’ed into the server.
-
Handle with Care
I’ve recently had the pleasure of reading “The Phoenix Project”, which is a phenominal little book. It did a lot to really make me think about how I approach my working process - both in the office and on my side projects. It’s sister book, “The Unicorn Project”, is on my list for later, but one thing that I’ve recently been dealing with at work a lot is the idea of risk. Fundamentally, good software development practices seem to fly in the face of “common sense” approaches to risk - and often the worse failings seem to happen when people try and minimise risk instead of confronting it.
-
Do or do not
This week, the thing I’ve experienced the most is a defense of just getting on with the thing, instead of worrying about doing the thing. I find sometimes developers tend to approach things from a risk adverse, cautious position. Usually the focus is on how to minimise changes done and disruption caused - especially when you’re dealing with legacy products (and who isn’t). I think where this can cause problems is working on personal projects and proving a concept. Getting wrapped up on whether it’ll work, rather than just seeing if it will.
subscribe via RSS