GitHub is one of my passion areas. You may have realised that already, with the amount of content that I’ve written about it. That’s only going to continue, because I’ve recently been hired there as an Enterprise Advocate. I’ve been supporting customers in their DevOps journey for the past 9 years or so. Interestingly, there are some reoccurring themes that I’ve found that are common. One of those themes is that DevOps is an App Development concept. In fact, it’s something that can be applied across domains (e.g. Infrastructure, Data, etc.) This is the start of a new blog series that will address those common themes, particularly in the context of GitHub.
GitHub is one of my passion areas. You may have realised that already, with the amount of content that I’ve written about it. That’s only going to continue, because I’ve recently been hired there as an Enterprise Advocate.
I’ve been supporting customers in their DevOps journey for the past 9 years or so. Interestingly, there are some reoccurring themes that I’ve found that are common. One of those themes is that DevOps is an App Development concept. In fact, it’s something that can be applied across domains (e.g. Infrastructure, Data, etc.)
This is the start of a new blog series that will address those common themes, particularly in the context of GitHub, regardless of your background. Whether you’re a DevOps professional, a DevOps enthusiast, brand new to the concepts, an app developer or not, this is the place to be.
What is DevOps?
Let’s start by defining DevOps. Donovan Brown once said “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” This has been adopted as the definition of DevOps by Microsoft.
I’m sure that if you asked several people for their own definition of DevOps, you’d get a lot of different answers. However, I think that Donovan’s definition incorporates the core aspects nicely.
DevOps is not a tool. It combines a set of practices, removes tools, removes silos and builds upon effective processes. While you can keep improving in each of these aspects, you need to keep yourself grounded.
But, grounded in what? Your guiding focus should be making sure that you are delivering what your end users want. For me, this is the core of DevOps.
- What if you are delivering a product that is not what your end users want?
- What if you automate your end-to-end processes, but don’t check for quality and deliver several production-breaking issues?
- What if your end users have a hard time using the core functionality of your system, while you’re fire-fighting the bugs?
All of these examples indicate that you are not delivering what your end users want.
What is GitHub?
This is where GitHub comes in. GitHub is commonly used in the Open Source community. It was initially created to help developers collaborate on code, using the Git version control system (don’t worry - we’ll explore that in a future blog post).
GitHub is a platform that allows you to share code with the world. But, you’re not limited to committing code in the open. You can also create private repositories, which are only visible to you or those you’ve explicitly granted access.
GitHub is much more than a place to store code. It has several capabilities, including:
- GitHub Enterprise SKU to enable inner-sourcing and collaboration across an enterprise
- GitHub Projects (based upon GitHub issues)
- GitHub Actions
- GitHub Advanced Security
- GitHub Codespaces
- GitHub Copilot
This might seem like a lot to think about, but we’ll break these all down in separate blog posts.
In terms of getting started, I’d recommend taking a look at the GitHub Skills page. It contains some great hands-on courses, including -
- Introduction to GitHub
- Communicate using Markdown
- Review Pull Requests
- Resolve Merge Conflicts
- Hello GitHub Actions
- Continuous Integration
I’ll make sure to link relevant resources as I create those future blog posts.
For the time being, get in touch if there’s anything you’d like to see added to this series. I have some of my personal thoughts on the topic, and ideas for content. I particularly want to hear from you if you’re not from a development background, so I can help make these concepts easier to learn.
Let me know your thoughts in the comments below.
Back in November, GitHub announced its OpenID Connect capability for cloud deployments was generally available. This has been on my list to try out, and I finally managed to get around to it! With scenarios like this, I prefer to do something real and hands-on, rather than mocked, or a proof of concept. I decided to refactor my GitHub Action workflows for cloudwithchris.com, removing the need for secrets stored in GitHub. In this post, I outline my journey through this.
If you’re using GitHub as your source control provider, then I’d encourage you to using Branch Protection Rules if you’re not already doing so! In this blog post, we’ll cover what Branch Protection Rules are and how they can increase your code quality.
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.