Technology

Ten years and more passed since Patrick Debois coined the term DevOps, in 2009. In the IT world, nothing is definitive. All the technologies and techniques continue to evolve following an innovation trend that we cannot stop. We cannot merely say: ‘I’m tired of changing; please give me a rest.’ The only option is to be ready for the change. In DevOps, there is a significant change because of the rise of the cloud and the market, always more demanding. The DevOps philosophy was adopted by most companies and bring essential improvements to quality and cost-saving. Anyway, the DevOps scenario is continuously evolving and adapting to the new market requirements. In this speech, we will analyze the new frontiers of DevOps and what to know to keep up with the times. Let’s see in this article what are the latest trends to follow.

For some time now, I’ve been using Windows Terminal as my local terminal for interacting with my command-line tools for quite some time now. Whenever I’m demonstrating Kubernetes concepts or working with the Azure CLI, I’ll likely have had the Windows Terminal open at some point. I always get questioned about which terminal that is, and how people can get access to it. I recently put together a Cloud Drop on How Windows Terminal can make YOU productive with Azure, so I figured it’s time to also write up a blog post on the same! Whether you’re a Developer, DevOps Engineer, Infrastructure Operations or Data Scientist, you’ve probably had to interact with a command-line terminal / shell at some point, so I hope this will be useful for you!

I’ve recently released a few Cloud Drops episodes on Git related content. The Git Behind the Scenes video was incredibly well received. I’m also aware from my day-to-day discussions that there’s a mix of experiences with Git, so also made a Git 101 Video. In this Cloud World that we live in, version control is an important concept beyond the ’traditional’ developers. Infrastructure Engineers can now version control their Infrastructure as Code, or maintenance scripts. Data Scientists can version control their experiments and tests. And of course, developers can version control the code for their software. I also consider version control as a gateway or first step into the world of DevOps. Typically when you think about build and release pipelines, you are triggering based upon some version control event (e.g. a commit to a particular branch, a merge of a pull request, etc.). Over the past few years, I’ve seen a trend where organisations are looking to automate quickly, rather than relying on the traditional hands-on-keyboard approach which can be error-prone and time consuming. Whether we’re talking in this context about Infrastructure as Code, Application Code, database schemas as code, data science experiments or any other representation as code, it doesn’t matter. Typically the roads lead back to the same place, to version control. So in this blog post, I’ll be covering the fundamentals of Git and how to get started. For anyone that is particularly inclined, there will also be some information on what’s happening behind the scenes when you work through these fundamental concepts.

For some time, I’ve been using GitHub actions to update the content of my site (i.e. pages, descriptions, metadata, etc.). Through Hugo, these content updates automatically update the RSS feeds. This then makes the episodes appear in podcast services such as Apple Podcasts, Google Podcasts and Spotify. However, throughout that time I have been manually uploading the podcast files to my storage account. It wasn’t a significant overhead, but I kept thinking that there must be a better way to do this. And, there is - I’ve implemented it! This blog post will walk you through why I’ve made these changes, how I made them and what the result is.

Part 4 - The final part (at least for now, until I find somewhere else that we can expand on with this)! This part will focus on porting the keys that we have recently generated onto our YubiKey device. I own a YubiKey NEO, so i’ll be using that.

Okay, part 3! At this point, I’m assuming that you have already familiarised yourself with part 1 and part 2 of the series. As a quick recap, part 1 focused on why we would consider using GPG Keys in general. Part 2 focused on how to generate GPG keys along with some recommended practices on splitting out our master (Certification) key, from our specific purpose-driven keys. This post (part 3) focuses on using those keys as part of our usual development workflow using Git. We’ll be assuming that GitHub is our end target, as GitHub supports commit signature verification using GPG Keys.

Hopefully by now you’ve had a chance to read part 1 of this series, which explains why you may be interested in using GPG keys to sign your commits. Congratulations on getting to the second part! In part two, we’re going to focus on how I worked through setting up GPG in my Windows environment, and generating a set of keys for use. There were some challenges/hurdles along the way, and we’ll talk through those too!

For a while now, I’ve been using GPG Keys to sign my Git Commits to prove that my commits on GitHub are genuine and from me. Over the last few weeks, I’ve been inspired by a couple of colleagues (Kudos to Adrian and Julie if you’re reading this) to dig out my YubiKey and use these for my key signing activities. While there are several blog posts on the topic already, I encountered a number of roadblocks along the way. The intent of this blog post is to be the first of a series, where we’ll explore what GPG is, why it may be valuable to you and how you can get going using them. We’ll then take this forwards an additional step, and show how you can use YubiKeys as a second factor of verification and the benefits of this approach. By no means am I the world’s expert in cryptography, and some of these topics, but I wanted to document my own understanding for posterity, as I’ll inevitably need to repeat/review the process in the future. I hope that this may be useful to you.

For the past four years, I’ve been part of a team at Microsoft called FastTrack for Azure. FastTrack for Azure is part of Azure Engineering’s Customer Experience Team, focused on successfully on boarding customers on a project-by-project basis as they bring production workloads online. There is never a perfect time to say goodbye, but for me - now is the time. From Monday, I’ll be taking on a new role within Microsoft as a Senior Cloud Solution Architect within Microsoft UK’s Customer Success Unit, focusing on the Manufacturing & Resources Industries. Career changes can be big moments of change, and a good opportunity to reflect.

A few people have recently been asking about my setup, so I figured it may be a good time to start writing about it! This is the second part of the series, where I’ll focus on the Lights, Recording Equipment and my overall setup. If you’re interested in the PC setup, then take a look at my previous blog post!