DEV Community: Brendan O'Leary 👨🏻‍💻

A guide to Git for beginners

Brendan O'Leary 👨🏻‍💻 — Mon, 13 Apr 2020 15:57:46 +0000

What is source code management?

Before you start in software engineering it's important to understand the concept of source code management. In its simplest form software is a bunch of text files and if I'm using those by myself it's not a big deal. But when multiple people use multiple files it gets out of hand and you need some way to manage it all. Humans can't necessarily manage all of that easily: If you're working with files A and C and I'm working with C and D, you need a way to bring all the changes we've made together without overriding anything or causing any conflict. A computer can more easily figure that out, and in a nutshell, that's what source code management is.

Why the term Git?

There are several different urban legends about this. Linus Torvalds who wrote it is a pretty gruff person with some acknowledged sharp edges. And so the story suggests he actually named it after himself, as in the British slang word, “git”. That may be apocryphal. Also, it's a three-letter combo, meaning it's short and didn't conflict with any existing Unix commands. Now people say it stands for “Global Information Tracker” or “GD Idiot Truckload of...” if you're mad at it.

But wait. Who is Linus Torvalds?

Linus Torvalds is a Finnish-American software engineer who developed the Linux kernel and then invented Git 15 years ago. Torvalds has been quoted as saying he's more "famous" for Linux but that over time, Git will end up being more important. Torvalds is also widely seen as the godfather of the open source movement.

Can you explain the rationale behind the cult following of open source?

Torvalds himself has a cult following and open source has been around for a very long time, long before Git was invented. But open source wasn't widely accepted and in some cases, companies were actively hostile to the concept. Torvalds wanted to create a project everyone could contribute to and Git was born (literally developed by Torvalds over a weekend 15 years ago). Git solved a problem that was common across all types of software development and it not only welcomed contributions from users, but it also needed contributions to grow. The idea of a practical solution everyone could contribute to created a kind of zeitgeist, and today open source is widely embraced as a result.

How could I explain Git to my neighbor?

We tend to talk about Git as a tree but I really don't know if that is the best analogy for it. It's a tree in the sense that it makes branches, but then those branches come back together and that doesn't happen in a tree.

Instead, I'd say Git is like a time machine. The whole history of everything that happened on any branch in alternate timelines is brought back together magically. Nothing is lost or changed and you can look backward and move forward. It's magic.

What's the most important thing I should know about Git?

That's easy: You can't break it!

Because it's a magical time machine you really can't do anything to it that can't be fixed. So I always tell beginners to relax and play around with your copy. No matter how many mistakes you make you can't break it in a way that's not fixable.

Have no fear.

This was originally published on the GitLab Blog

My next move at GitLab

Brendan O'Leary 👨🏻‍💻 — Thu, 12 Mar 2020 12:31:22 +0000

I’m coming up on my third year at GitLab. Or as some people like to put it — I’ve been at GitLab for 1,049+ hires. GitLab has been growing rapidly, and I’ve been lucky enough to be there for three separate funding rounds.

All of that growth has been incredible to watch and be a part of. And even before I worked at GitLab, I was a large proponent of GitLab and the concept of bringing CI and CD right next to the code. Having worked as both an Engineering Manager and a Product Manager in the past, I’ve lived the pain of having a team have to spend more time fixing the tools than actually coding solutions to customer problems.

Always an Evangelist

Given that background, and previous lives spent wrestling with various DevOps tool chains, I’ve always, always been an evangelist for GitLab and GitLab CI/CD. Ever since I wrote my first pipeline for my side project — listMe, a Slack app for managing lists I knew GitLab CI/CD was something special.

From there, I went on to evangelize GitLab in my role at the time as the director of DevOps at a small federal government contractor. Their environments were vastly different — production was bare metal, the customer’s test environment one virtualization platform, and our DEV environment yet another platform. Bringing GitLab CI/CD to that problem allowed me to control those variables that we could, and eliminate mistakes by reducing complexity.

In late 2017, I was given the opportunity to get “on the bus” at GitLab. After a friend was recruited to GitLab, they recommended I take a look. “Oh…it’s a company, not just a tool,” I thought. And later that month, on a rainy beach vacation, I had enough time to read and fall in love with the GitLab handbook and values. From that day on, I was an evangelist for GitLab, the company, too. Much to the chagrin of my wife and family that week.

At GitLab

At GitLab, I was able to help start our professional services group, run product management for a time for the CI product I loved, and contribute in a lot of other ways. True to our Everyone Can Contribute mission, I was able to pitch into the product itself, various functions, and help onboard lots of new team members.

That whole time, I have been fortunate enough to be able to talk, write, and tweet about GitLab, the company, and the product to anyone that would listen. So I’m excited that now as we scale, I’ve been given the opportunity to become a Developer Evangelist full time. My new boss, Priyanka Sharma, is building a fantastic team. We plan to focus on doubling down on our open source roots, evangelize DevOps and simplified tools chains and ensure that we can make GitLab as amazing for everyone as it was for me in those early days.

I can’t wait to see where we’ll go next, and I know that I will be a GitLabber for the rest of my life. For now, I’m excited that sharing my passion for DevOps tooling, #AllRemote, and the GitLab values is now officially my full-time job!

Follow Along

If you’d like to follow what my team and I are doing — we’re, of course, public by default. I would love it if folks took a look at my 2020 Technical Evangelism plan, which outlines at a high level what I plan to focus on this year. You can also check out our issue board here to see all of the tactical things we have in the pipeline. And of course, follow me on Twitter to see the day-to-day work it takes for me to realize this dream and evangelize GitLab.

This article was originally published here: https://boleary.dev/blog/2020-03-11-my-next-step-at-gitlab.html

CI/CD all the things: PiHole

Brendan O'Leary 👨🏻‍💻 — Fri, 11 Jan 2019 00:01:12 +0000

Photo by rawpixel on Unsplash

CI/CD all the things: Pi-hole

I’ve spent some time exploring how to apply the concepts of CI/CD to everyday life. In my first post, I went all in — making breakfast with GitLab CI/CD as the orchestrator. In this post, I’ll tell you about a home project I undertook over the holidays: getting a Pi-hole up and running at my house. (mmmm 🥧)

Pi-hole is a great little open source tool that lets you run your own DNS server on your network and send advertisement and tracking requests to a “black hole” of 0.0.0.0, providing network-level ad blocking…rather than installing ad blockers on every device, browser, and IoT item in the house.

Pi-hole even ships with a great dashboard and has a number of extension points to customize it. I added an hourly speed test — just to keep my ISP honest 😉.

PiHole Dashboard with Speedtest plugin

Installing Pi-hole

Installing Pi-hole is relatively simple, with straightforward instructions, and the only thing I had to watch out for was DHCP. Since my router provides Circle from Disney for parental controls, it has to retain the DNS/DHCP server but I could still map its upstream DNS to Pi-hole. This means I lost some of the granularity in the logs as most requests come from my router rather than the individual devices, but once I had it all set up Pi-Hole worked as designed.

Source control for Pi-hole

There are a lot of great resources out there for Pi-hole, including things like commonly whitelisted domains to make sure some general services aren’t negatively impacted by it. There are also many additional blacklists available on the internet, depending on what you’re concerned about. And, since FTL is extensible, it is even possible to use it as a lightweight local DNS server.

Because all of those elements are presented in a fashion that says, “Here’s how you can run a command in the terminal,” or “Here’s how you add it in the UI,” my internal “must source control all things” tick was activated…and so I created a repository on GitLab.

I added a couple of scripts to automate the whitelisting for common and custom domains as well as a file to contain the hosts on my network. But this still meant I had to manually check out the repository on my Raspberry Pi and manually run the scripts. That’s where GitLab CI/CD comes to the rescue! Luckily, it’s available on our free tier, because I was using my personal account for all of this, while I was on holiday.

Enabling CI/CD to Pi-hole

Now that I had a repository ready to go, I just had two steps until I had access to all the CI/CD goodness my little heart would ever desire.

Make my Raspberry Pi a GitLab Runner so that GitLab.com changes could get into my home network with no holes poked in my firewall.
Set up a .gitlab-ci.yml to run updates when changes are made.

Installing GitLab Runner on my Raspberry Pi

Installing GitLab Runner is easy on any platform that supports Golang, including Linux, OSX, Windows, FreeBSD, Kubernetes and (soon) even z/OS.

The Raspberry Pi has an ARM chip, so I used the ARM binary to install it with:

sudo wget -O /usr/local/bin/gitlab-runner [https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm](https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm)

Then I made the gitlab-runner binary executable with:

sudo chmod +x /usr/local/bin/gitlab-runner

After that, I installed it as a service with these commands:

sudo gitlab-runner install --user=pi
sudo gitlab-runner start

Once it was installed, registering the runnerto be a private runner on my project was easy. I also added a tag of prod to make sure it only ran code I tagged to run on “production” aka actually on my home network. I’m hoping this protects me from someone I like to call “future Brendan” who may or may not have the best memory when it comes to breaking things.

Registering the GitLab runner

I chose a shell executor so that it was simple to understand. Basically, the runner would just execute the commands I put in the script: section of my YAML. Just as if I had logged in and ran them myself.

Setting up the .gitlab-ci.yml

I had a few thoughts in mind when it came to setting up my pipeline for deployments. Some of the scripts required restarts of the DNS services on the Pi-hole, so I didn’t want them to be running all of the time. To prevent that, I used a number of GitLab CI/CD features:

only:refs: Ensures we only run this on master — so if I’m on a branch trying something out (*shakes fist at future Brendan*) I don’t break anything.
only:changes: This allows me to limit the scope of the run to only the changes needed. For instance, a change to the whitelist won’t trigger an update to the local DNS list and vice versa.
tags: I mentioned this tag before, but this also means that any job I add must have the prod tag before it will run in production (aka the live Pi-hole).

As an example, let’s look at automating the whitelist. I already created a script (whitelistme.sh) that automates it when ran. So getting that to run in GitLab CI/CD is as simple as this script:

whitelist:
  stage: deploy-prod
  script: 
    - echo "Run whitelist.sh"
    - ./whitelistme.sh
  only:
    refs:
      - master
    changes:
      - whitelistme.sh
  tags:
    - prod

Let’s break down each section of that script:

For the stage, I created my own custom stage called deploy-prod.
The script is very simple and echoes what it is about to do and runs the script at the root of the checkout with ./whitelistme.sh.
The only section implements the two controls I was talking about earlier. refs: — master means this will only run on the master branch of the repository. changes: — whitelistme.sh means this will only run on a change to the whitelistme.sh script and not on every change to the repository. This ensures that script only runs when it needs to.
“Tags” ensures that it runs on a tagged runner — in this case, the Pi-hole at home.

Success! Running my jobs on my Pi-hole in my home network — orchestrated all from GitLab. 😺

DNS as Code

Since FTL is mostly just dnsmasq with some customizations for Pi-hole, it is relatively easy to customize. In fact, by default, it includes an additional local file (and hostnames for the Pi-hole itself) in /etc/pihole/local.list like this:

10.0.0.xx pihole
10.0.0.xx pi.hole

Again, I wanted to make sure this was source controlled — and the dream of source controlled DNS is now a reality for me. The way I implemented it was to:

Create a localDNS file that would contain all of the local DNS entries I wanted:

10.0.0.xx pihole
10.0.0.xx pi.hole

10.0.0.1 orbi.local

10.0.0.xx pirack0.local

Then I used GitLab CI/CD to automate replacing the /etc/pihole/local.list file with this one anytime it changed:

local-DNS:
  stage: deploy-prod
  script: 
    - echo "Copy localDNS to /etc/pihole/local.list"
    - sudo cp ./localDNS /etc/pihole/local.list
    - echo "Restart Pi-hole DNS"
    - pihole restartdns
  only:
    refs:
      - master
    changes:
      - localDNS
  tags:
    - prod

And Voilà! Source controlled and automated DNS-as-code (DaaS (tm) (r) (c))

Frequently Asked Questions

Anticipating the questions you’ll have, I’ve prepared a short primer below:

Yes, I did bring down the internet in the whole house for about 20 minutes while I was tinkering away. Yes, this was while all my in-laws were here on their phones. Yes, I got a lot of grief for it
Yes, this will restart DNS as it is running, thus I wanted to only run the jobs as restricted above
What is this business about pirack0 in the DNS entry?! That will just have to wait for another post 😉

CI/CD All the things: Introducing Auto Breakfast from GitLab (sort of)

Brendan O'Leary 👨🏻‍💻 — Fri, 29 Jun 2018 00:00:00 +0000

A big part of GitLab’s culture is saying thanks to one another for doing a great job. That can be anything from helping with a tough technical problem to simply sharing a nice coffee break call to break up the work day. One day a Sales team member thanked someone from Customer Success for a great demo of GitLab CI/CD. The customer commented afterwards, “Okay, what doesn’t GitLab do?”

Plenty of heart-themed emoji reactions followed. We’ve seen users do some pretty amazing things with GitLab CI/CD, from ramping up to weekly mobile releases to automating boring Git operations, to saving 90 percent on EC2 costs. However, there was one thing we hadn’t seen. So in addition to this love, the question also garnered a semi-sarcastic answer:

It won’t make breakfast for you, unfortunately.

Never one to let a Slack conversation go unnoticed, I replied with one of my favorite phrases:

I have to admit that the fact that my status was :coffee_parrot: could have been related to my enthusiastic reply…

The challenge

At the time I had only a vague idea of how I would accomplish this. Many suggestions about Internet of Things devices followed my comment. And while a toaster with a version of Linux that will never be patched was intriguing, I wanted to do something bigger.

A few years ago some friends got together and bought me an Anova Sous Vide, knowing that I loved to cook. What they failed to calculate was that having four kids in eight years was counterproductive to learning the time-tested French cooking method of sous-vide. As such, the tool has not had a whole lot of use in its time.

However, at this point I thought of two things:

I love a new sous-vide egg bite offering from a well-known coffee shop
The Anova Sous Vide uses bluetooth low energy (BLE) to allow you to control it through an app

The recipe (culinary)

While I did like the egg bites from a coffee shop that shall remain nameless, I don’t have them all the time. I would give them a 5- star rating, but they cost a few more bucks then I’d like to spend 😉 So I found a sous-vide egg bite recipe on Anova’s website.

The recipe (technology)

Once I had the recipe, all I needed was to reverse engineer the BLE connection, figure out how to get that to work from the command line, set up a project and get it integrated with GitLab CI/CD… no big deal. Luckily I found a fantastic project called PyCirculate that had already worked out a lot of the BLE connection issues with the Anova. It made me wonder if someone else had automated breakfast before… but I’ve yet to find them!

Now that I had both recipes and all the ingredients, it was time to *git* crackin’… (I can’t tell you how happy I was when I thought of that joke. Did I mention I’m a dad?)

Setting up the breakfast pipeline

Once I had that project installed and working on my laptop, I uploaded the code to GitLab in the public repository in the auto-breakfast group. Next, I installed GitLab Runner on a RaspberryPi. I registered the Pi as a specific runner for my project. I used a runner tag so that I could ensure the cooking job only ran on a device with a Bluetooth connection.

When I run a pipeline on auto-breakfast/eggs it uses the RaspberryPi to execute and thus can create the BLE connection to the Anova. With the click of a button in GitLab, my breakfast pipeline was running. All I had to do was sit back, relax, and let GitLab CI/CD do all the work.

The results

The egg bites were great! I even modified the recipe with some great Kerrygold Irish whiskey cheddar cheese. However, I would say that it did take a little more effort to get things set up. However, now that it’s done, I have a repeatable, single-button way to cook the recipe again (minus the egg cracking and food processing). Just like CI/CD with a .gitlab-ci.yml can help make software build and deployment more reliable and repeatable, it can also make a fantastic breakfast 😎

Not pictured: A very messy kitchen and a very perplexed wife.

Photo by Leti Kugler on Unsplash

Originally published at about.gitlab.com on June 29, 2018.

Using GitLab to project manage home renovation priorities

Brendan O'Leary 👨🏻‍💻 — Thu, 08 Feb 2018 20:35:35 +0000

Last summer my wife and I bought a new house for our ever-growing family. Before we moved in, we had a couple of improvements made — wood floors to replace the aging carpet in the master bedroom, some required structural fixes. However, when we bought the house, we knew there would be a lot more we wanted to do over the years. When it came to organizing those ideas into things that need to happen sooner rather than later and those that could wait, however, we found ourselves struggling to keep all of the plans in order.

Trying to get organized

I’ve been able to complete a few other projects since we moved in — but most were small in scale. A built-in shelf wall for my wife’s office, painting and staining the new deck, and of course a DIY standing desk to use in my new office kitchen (which is also the house’s kitchen… working from home for the win!). These projects were great, but we needed a way to organize and prioritize larger renovation projects.

Clockwise, from left: built-in shelf wall, painted and stained deck, DIY standing desk

I was a GitLab user for years before I even became a GitLabber. I’ve always hosted my side-project code in GitLab.com since GitLab offers unlimited private repositories for free. For project management in my “day job” I’ve used dozens of other tools outside of GitLab, so when I joined it was the first time I saw the full breadth of what GitLab offers in issue management.

In thinking about the other tools I’ve used in the past, they didn’t seem to meet the full bar of what I was looking for to solve our problem. As a mother of four young children, my wife is always on the go… but I’m on a computer all day long. So we needed something that worked seamlessly between platforms. We also needed to be able to easily re-arrange and re-prioritize items. Also, I fancy myself a bit of a DIY-er, so I wanted to be able to label some items as at least possible for me to maybe complete myself. All of these requirements had me wondering what tool would be best for my wife and me to collaborate on.

Enter GitLab Issue Boards

With these requirements, and my newfound GitLab knowledge, I was able to come up with a novel solution to the problem we were having: why not use a GitLab Issue Board to manage our ever-changing home renovation priorities?

With Issue Boards, we would have a fantastic solution for mobile and desktop (shout out to the GitLab UX team!). With labels, I could organize and group issues however we wanted. And the customizable columns would allow us to prioritize, track and manage the various issues and ideas.

How the board works

To start, I created a new group on GitLab.com to house (pun intended) everything for our family. I made a project in that group called priorities to be the central place to collect all the renovation ideas we had. In the future, I may have a project for a specific renovation, managing purchases, and contractors, etc.

As with every GitLab project, issues and issue boards were baked right in. I started adding issues right away — beginning with those that were at the top of mind, like the water heater that is at the end of its usable life, repairs to our front entryway, and window replacement. My wife didn’t have a GitLab.com account yet, but it was easy to add her to the project as a member just by putting her email address in on the member’s page, allowing her to sign up and get access to the project in one step.

To get organized, I created a few labels: P1 for top priority items, DIY Possibility for those I might be able to tackle on my own, and Furniture for those that involved furnishing various rooms. The labels will help filter issues so that if I find a free weekend, I can search for DIY Possibility issues to maybe get started on. Or if we go to a furniture store, we could filter to those issues to get an idea of cost while we are there.

For the board columns, I decided to use P1 as the first column after Backlog to highlight those issues. From there, it’s a matter of agreeing on an organization of priority 😃

Where to go next

Now it’s time to execute! One thing we didn’t account for in the first iteration was the scope of issues. Some things were relatively minor regarding time and investment. Others (like replacing all 27 windows!) are larger projects for which we need to budget. For this, we will be using issue weight to understand how different projects align with budget and time investment to pull off.

It’s been an exciting experience using GitLab Issue Boards for something outside of the development space. We’d love to hear from you too about “non-standard” uses for GitLab’s features. Feel free to comment on this post or tweet us @GitLab.

This post was originally published by GitLab.