git 101 with Emma Jane Westby

Matty: [00:00:05] Hey, welcome to Arrested DevOps episode 24, Git 101. I’m your co-host Matt Stratton, @MattStratton on Twitter.

Trevor: And hey, I’m your co-host Trevor Hess, @TrevorGHess on Twitter. Arrested DevOps is brought to you by 10th Magnitude, a cloud services company that figures if you’re listening to this podcast, you’re probably pretty cool. You can find out about joining our cloud services team at 10thmagnitude.com.

Matty: This episode is also sponsored by PagerDuty. PagerDuty eliminates the noise, chaos, and manual processes across the entire incident lifecycle to decrease resolution time. PagerDuty is trusted by companies like Etsy, Nike, and GitHub. To sign up for a free 30-day trial, visit arresteddevops.com/pagerduty.

Trevor: This episode is also sponsored by Redgate Software. Redgate makes tools that bring the benefits of continuous delivery, safe releases, efficient development, and fast feedback to your database. Find out more about database lifecycle management, download free trials, and browse the database delivery learning program at arresteddevops.com/redgate.

Matty: [00:01:07] I want to point out that we’re actually going to be talking about continuous delivery of databases with some of the folks at Redgate in the beginning of December, so keep your Podcatchers subscribed for that. Also, there’s breaking news today besides the fact that we landed on a comet, which is pretty awesome.

Trevor: Oh, you jerk nozzle.

Matty: Oh my God. Okay.

Trevor: Way to blow my checkout, Matt.

Matty: Yep. We’re just going to skip to the checkouts. Sorry. Skip to the end.

Trevor: Anyway, the other breaking news is that Microsoft is open sourcing .NET and creating the OSS CLR for Mac and Linux. And that’s how you steal Matt’s thunder.

Matty: That’s right. So this was just announced. We’ll be posting the links in the show notes to Scott Hanselman’s blog where he talks about this. But a couple of things that really struck out to me are that, so .NET Core 5 is the new framework for 5. And the thing that’s kind of cool is you can ship your own private version of the framework with the app so that it’s kind of an embedded framework. And then they’re working on doing that same CLR, basically having a CLR that will work on Windows, Mac, and Linux, which is open source and supported by Microsoft. So that’s out there on GitHub. The other thing is that they’re making sure that ASP.NET 5 is available on Windows, Mac, and Linux, that this is all happening out in the open on GitHub. We’re talking a lot about GitHub, and we’re going to be talking a lot more about GitHub and Git in a little bit. The other thing that’s neat that I thought was cool is there’s a new SKU that’s free for a free version of Visual Studio for open-source developers or for students, which is called Visual Studio Community. You don’t have to buy super expensive Visual Studio if you’re a community developer, which is pretty cool. Those are the bits of that. The other thing that I wanted to point out is, so if you’re listening or watching this livestream, please share any questions or thoughts or opinions on this because this is an opinionated topic with us. You can hit us on Twitter, at Arrested DevOps, or we’re also on IRC at freenode.org on #ArrestedDevOps.

Trevor: [00:03:05] So to bastardize a Monty Python phrase, let’s get on with it. Hey, I’m entitled to bad jokes. So one of the reasons that DevOps is useful, people like it, etc., is that it kinda shortens feedback loops. We’re talking about the concept of the culture, automation, management, scaling, or commonly known as CAMS. The measurement piece is that can come into play. Anyway, in that spirit, we’re taking feedback we’ve gotten from listeners who want more detailed technical topics, and we have an episode today talking about the how with Git and a very special guest, Emma Jane Westby. Emma, can you introduce yourself and tell us a little bit about your experiences with Git?

Emma: Hey, thanks so much for having me on the show. I feel like I should be doing the, like, longtime listener, first-time speaker. So the version control stuff for me has been a pretty interesting journey. I’ve been I’ve been teaching version control for over a decade, and the first time that I taught version control was to a group of liberal arts students who were learning how to be project managers. And bless them, I don’t know how they survived my class, but we started them off with CVS because that was the system that I was most familiar with at the time. This is, remember, like 2003, 2004. And what we did was basically walked them through how to communicate with your team and how to not have your files overwritten by your team members, but they were coming from zero technical experience. And then from there, I sort of moved on to distributed systems as they became more popular. So my first one, and still my, I guess, my first love, shall we say, when it comes to distributed version control, is actually with Bazaar, because I was quite involved with the Ubuntu project at the time. And I’ve moved over to Git now, in part because it’s the most popular system. So if I want to be working with teams, and if I want to be collaborating with folks, I have to use the thing that is the most popular. I came to be a Git expert though, not through a love of Git, but through a hate of Git. I actually find it to be incredibly arrogant software. I find the built-in documentation really frustrating. I find the commands inconsistent to use. And what I wanted to do with the sort of leveling up that I’ve done with Git is make it less painful for those who come after me. And I hope that the resources that I’ve been producing make it a little bit easier for folks. But again, I’m not coming from a place of passion or I guess that’s a lie. I’m coming from a place of passion. I’m not coming from a place of love.

Matty: [00:05:32] I like that. I’m going to assume that most of our listeners have a passing familiarity with Git, but I don’t want to assume too much. I want to talk about some of the high level. One of the things that we talk about is Git differentiation from some other types of version control. I know it’s not the only one that’s like this, so you all on the internet don’t have to yell at me. I know, but we’re going to just talk about Git today. It’s distributed version control versus a centralized version control. I think that’s something that I think is kind of important to talk about. Also, as we look in this model of how people implement Git, that concept I think gets confused, that it really is distributed. What to you is the difference of a distributed version control versus a centralized one? How would you kind of 30,000-foot put that?

Emma: 30,000-foot is that in a distributed version control system, the database that contains all of the changes for the repository that I’m working on exists on my local system, and I can have multiple connections to other databases with their changes. Whereas in a centralized system, you only have one copy of that database. And I think a bit later on we’ll talk about some of the ways that GitHub or Bitbucket or those code hosting systems end up behaving in a centralized fashion, because there is one repository that we agree is sort of the canonical source for software. But again, the big difference is that I have the record of changes when I make a commit that happens on my local computer, not on a computer somewhere else.

Matty: [00:07:01] I mean, so advantage-wise of a couple things like that is that you theoretically don’t get yourself into a scenario where you’re like, oh, my Git server is down so nobody can do any work. I know is one of the things, or at least you start to remove that excuse. And then also I can work completely disconnected, right? I can have that whole history of all the stuff.

Emma: Yep, that’s right. You can have different, and also with version control, distributed version control systems, and I will sort of shorthand to, I am always thinking of Git when I say distributed version control systems in this podcast, although it will be true for other systems as well. You can have different chains of access. So if you want your trusted developers, your internal team, your senior devs, or your QA team, your quality assurance team, to have write access into the repository, but you want other folks to be going through some kind of peer review or some kind of testing suite, you can say, actually, you You don’t get write access to the main repository. You only get write access into your copy of the main repository. You can sort of chain those together as necessary.

Matty: Gotcha. Then we think about that. Why would we talk— I want to kind of talk really briefly about why that distinction of distributed version control versus centralized is relevant to DevOps, besides the fact that there’s kind of this thing, like, there are certain associations that are made with tools that they become synonymous. Like, you can’t do the DevOps if you don’t have the Jenkins, or you need to have Chef or Puppet or else you’re not doing DevOps. Ops, which is kind of bullshit. But then also there’s this kind of conflation, right, of Git and DevOps. I run into this professionally a lot too, where there’s certain, you know, we’ll go in and I’ll work with customers and they’ll be like, well, we use SVN, so I guess we can’t use Chef. And you’re like, no, that’s not true. Now it’s easy. Now, but what I do see though, and I want to know if y’all— there’s 2 pieces of this where I’d say it’s easier to do some of the DevOps with Git. So I see 2 reasons, one that’s a little more realistic than the other. One is just a lot of the tooling that people tend to do when they’re implementing this type of the automation and the measurement part of CAMs, those are tools that tend to kind of like Git better. Like they were built using that as their source control. They have better integrations with it or they’re more default to integrate with it. So to me, that’s like kind of like a possible thing, but it’s not a real reason to say, if I want to do DevOps, I have to have Git. But I do want to say that on our, I think it was on our How to F Up DevOps show, Nathan Harvey said, you can’t do DevOps if you’re not using distributed version control. And his theory, I believe, is that distributed version control is a lot more about communication and a lot more about trust than a centralized one. It’s opinionated software in that way. Right. And so part of me kind of wants to know what you guys think about the, sorry, Nathan, the validity of that statement, right? If that’s, or at least in practice, how that comes out.

Emma: [00:09:44] Can’t is a pretty strong word. As soon as you say the C word, there’s someone out there who proves you wrong. I feel like I’m kind of going to dance around this question a little bit and not come out and directly say one way or the other because I do think that it needs to be about what the team needs to use to get their job done for the specific scenario that they have entered into. If you’re working with a novice team that doesn’t have a lot of infrastructure experience, go for the thing that has the most tutorials. Go for the stuff you’re going to get the most learning resources on. Which at this point is probably going to be Git. It may be that the software that you have in place would be fine, it’s just you don’t have the expertise in-house or you can’t find the resources in order to make that specific piece of software work. So I’m, again, I’m kind of like, I’m admitting that I’m dancing around because as soon as you say that C word, there’s someone out there who’s like, oh, you totally can do it!

Matty: Well, we know that Nathan likes to use hyperbole for a fact, right? So I think that it’s, of course, there’s always the exception that proves it, right? But conceptually, I get it, right? That if I sort of have this central place, how do I, how do I have cross-function, right? How do I sit there? And to your point, it’s like, okay, I’m going to have different people picking up the different pieces through the chain, through the value stream. And if there’s this one central place that everything checks into, and then this also gets into a little bit, and we’ll talk a little bit more later about workflows and things like trunk-based development versus GitFlow and branching and merging and PRs and all that fun stuff. But to me, in a lot of ways, and I know this came up on our CI episode, which was like a long time ago, and I think it was episode 3, almost a year ago. I know. But the thing that was brought up there was that this whole idea of GitFlow and preflighting and all this stuff is operating under an assumption of not trusting your contributor. Right. And it makes sense. So to me, like kind of preflighting these things and managing them, merging in makes sense in like open source when I’m like, you know what? I actually can’t trust you. More to the fact, I can’t easily revert as much as that. But if I’m within a team, kind of having this, like, I have to put these walls in place, like we have our big central monolithic version control and only the high priests of the version control are allowed to actually, or the build are allowed to actually commit to master or allowed to actually merge stuff, that’s really sending a message. In a way, it sends a message to me that says, I don’t have to test my shit because you’ll catch it for me, right? So versus saying like, okay, merge away, but when it breaks, everyone, you know, like, it’s on you because you didn’t test right.

Trevor: [00:12:15] I don’t know.

Emma: Okay, so we get into the testing thing like right off the bat. I would suggest that perhaps some systems are not easily tested, and this for me is coming from my— most of my development experiences in Drupal these days. And Drupal as a product, if I am downloading Drupal the software, there is definitely test coverage for Drupal as a product. As soon as I start customizing things, what I’m looking at at that point is actually more on the user interaction on things, and it’s not necessarily something that I can write reliable tests for. I don’t know if you have a lot of experience working with Selenium or Behat. Sometimes it works 99.999% of the time, and then the odd time you’ll have a false positive. You begin to not trust your tests as a developer, and you begin to wonder if maybe that time is not time well spent. I find that in the Drupal communities, we love the idea of testing. It’s just that we don’t have the robust testing tools that Drupal the product has for the implementations that we are creating of Drupal. We tend to see, as a community, more sort of collated, the GitFlow side of things, branch per feature. It’s really hard to get to continuous deployment. It’s not impossible. It’s just a lot harder to get there in terms of having reliable tests. We talked about sort of untrusted developers or not trusting your devs. I wouldn’t trust me, and quite frankly, no dev out there should trust themselves because you as a person are going to make mistakes, and especially if there’s not a lot of extra eyeballs on there. If we look at even the OpenSSL bug that went through, that was what, a December 31st mistake? If we look at the Drupalgeddon SQL problem that was recently uncovered the last couple of weeks, that was a December 24th, that was a day before Christmas mistake. Mistakes happen even when you’ve got testing suites in place. I think that for the concept of untrusted, it doesn’t— I don’t know. I’m okay with QA teams, and I’m okay with people having peer reviews.

Matty: [00:14:10] Let me make sure I’m real clear. I’m not saying there’s no testing. I’m talking about just the idea that, okay, you check into some other branch, and then someone tests your code, and that’s not UAT, that’s not exploratory testing, that’s running tests that are just as easy that you could have run yourself, and then if they pass, it gets merged. My thing is, why does there have to be the high priest of Buildmaster to do that? Why— in fact, frankly, why do you trust that? That’s sort of the thing, is that’s the distinction I’m making.

Trevor: And we could probably wrap up with this. I would— I mean, yes, this will absolutely turn into a rabbit hole.

Matty: We have to be careful. Yeah, this isn’t 101 anymore. Now we’re just sharing lots of opinions.

Trevor: So I actually like having that there is a structure where that’s kind of the process. But I don’t think it should be a hard and fast rule. I don’t think there should actually be permissions in place on a team project that say, you know, if I’m the developer tier, I can’t actually make a change to master. I think that the flow should be there that I write software, that software gets tested by QA, and it moves up through our— whatever the flow we have established is, and then it winds up in the master branch. But if there’s something that I need to change, I need to change it in master, you know. Sometimes it happens with production code where you have to go And it’s not my favorite thing to do, but I don’t want to be limited to not be able to make that change.

Matty: [00:15:23] Okay. So I got some other opinions on that, but I think this is leading us actually into back to where I, where, where we should be talking about right now. So the thing was just more about the theory on that was just that when things are distributed, so certainly doesn’t mean trust people to not make mistakes, but enforce it. You’re sort of saying like, I trust you to try to be doing the right thing. And again, also like as our friend Jez Humble likes to quote someone that I don’t remember who he quotes, I should know my references, but the whole, it’s the idea of that when you give people metrics that they’re going to be measured against, they’re going to work to those metrics. One of the talks I saw Jez give, he talked about a situation where they said, okay, so in this sprint, we’re going to make sure that we have 6 tests written. But that was the metric, was to write 6 tests. They were 6 tests that were assert equals true. You’re like, great, now we have— every sprint, we’re adding more tests, but they don’t do anything because you’re chasing the wrong metric. The thing about getting into the idea of there of saying we’re trying to do the right thing, which is that the code gets tested. Even if just at unit-level type tests, whatever the stuff that can be automated. Emma, to your point, obviously not everything can be automated. Things that can’t be automated, that’s a human gate. But everywhere that we don’t— don’t introduce human gates where human gates don’t need to be is kind of my thing. And it feels to me that centralized version control manufactures human gates, right? As opposed to us deciding we want a human gate there, they start to exist by nature of their work. So that being said, though—

Trevor: [00:16:45] Hey, Matt, you didn’t check a file back in, so I can’t do anything.

Emma: Sure. Right.

Matty: So I think that’s kind of where that kind of thing goes. But so let’s say that we’ve come to an agreement that for better or for worse, distributed version control is more appropriate for the type of work that we’re doing. And for better or for worse, we’re talking about Git. So let’s talk about how we’re going to do that. So this is getting into the meat of it. And I wanted to, Emma, to kind of hear from you because I know you’ve given a talk about— I think it’s called Git for Grownups, but kind of talking about how you learn to use Git. And how you go about that. So what kind of recommendations do you give?

Trevor: Or like, how—

Matty: so I want to get started. Hahaha. It’s impossible to not have terrible puns in this episode.

Trevor: Yes.

Matty: How do we get started, please?

Emma: So when I teach the workshop, there’s usually a range of different kinds of people who come to my workshop. And this has been anywhere from like 3 or 4 people in a room who are like attending a conference, all the way up to the largest version of this workshop that I’ve given is 1,900 people registered for an OSCON webinar. So there is definitely a lot of people out there. There are definitely a lot of people out there in this boat, and there’s typically one of a few different kinds of people. Number 1, someone who is on Subversion right now and wants to convince everyone else to switch over to Git. Number 2, someone who has been told that they need to use Git but have no idea how to run commands at the command line. And number 3, someone who’s at a sort of a higher level, maybe like a management level or a CTO type person, and they know that they want to switch to Git, but they don’t know what strategies they need to put in place because they’re coming from— either they just don’t know distributed version control systems at all, or their current process isn’t working and people are frustrated. So in terms of how do you learn Git, it depends on where you’re starting from. And if you know nothing about Git right now, I find that a lot of the resources that we use to teach people version control are not geared toward the adult learner. So where we get stuck as learners is that we’re told to memorize a bunch of commands, and those commands have no connection to the real world. We don’t really understand why we’re typing them, and then when we get into problems with Git, like we end up in a headless state, it gets really scary really, really quickly. And with Git, because the commands are sort of— the output is spit out at us, there ends up being a sense of urgency that if I don’t respond quickly to being in a headless state, the entire thing is going to blow up and all of my code will be destroyed. And it’s a difficult one to get over if you’re used to thinking of the computer is waiting for my response. But as you start to learn more about how Git works in a team scenario, the more you start to appreciate what those commands are doing, and the more you start to realize that you can reboot your computer. It really doesn’t matter to Git. It’s going to wait patiently until you figure out what you need to do at that particular point in time. If you’re brand new to Git and you’re trying to learn, the first thing I suggest people do is sketch out how you work with your teammates. If you’re working in a peer review system, if you’re working in continuous deployment, whatever it is, write down essentially the assembly line for how your code moves through the different gates. Maybe those are people gates, maybe those are pushing it up to a server, whatever they happen to be, but draw it out, get it in front of you. Once you have that visual piece in front of you, then you can start to write on what are the individual commands that I need to run, and how can things sort of go poorly at any of those particular points. Like, you’re rebasing your work, things can go poorly there. You’re merging your work, things can go poorly there. And as you start to create that map, it’s something that you can use as a discussion point with your coworkers. Like, are we really being the most efficient that we can be by using this particular chain? Maybe something’s sitting for too long in pull request, and it takes forever to bring it up to date. Maybe you need to change the way you’re doing PRs. Maybe you need to change the way, you know, whatever it happens to be. But until you have it written down or drawn out, you can’t even start the conversation. Ta-da!

Matty: [00:20:52] That makes great sense. And I like the idea of understanding your actual value stream, right? You’re saying rather than— because I think what happens often, and I’m guilty of this too, is you’re like, hey, I want to do the thing. Let me go and type the thing I want to do into the Google machine. And then they’ll say, here’s how to do it. And then I go, wow, well, I want to do that thing, so I guess I’ve got to change all the way that I do stuff. This is actually a thing that’s happening—

Emma: Somebody said bisect. I want to do it. What is it?

Matty: Right. It even kind of gets into, like, in the Chef community, because Chef is OpsCode, Chef Software, whatever we call ourselves, has intentionally been non-prescriptive for years about how to use Chef. It’s like, hey, it can do all the things, and make it do the thing that you want it to do. The thing is, what we found— I shouldn’t say we, because I wasn’t there when this happened. They figured this out before I got there— is that people want to be told. So you have to give some stuff, but the trick is to give some options, right? So you can figure out, is this a place to get started or not? And in the absence of these ideas, right, the loudest voices tend to be taken as canon, even if they’re not intended that way, right? If nobody’s come up with a way of doing a thing with foo, and then I say, here’s how I use foo, everybody goes, oh my god, I have to use foo that way. And even if it doesn’t necessarily make sense. And so I like the idea of saying, Your job is to release software. It’s not to implement Git. So, how do we release software? I really love in your talk when you kind of do that thing where you’re like, take all the things out, put the people in it, and say, who does what? Who does what? What’s our value stream? Let’s understand that. I think that’s really hard for a lot of us because it’s easier to— and this goes back to the whole DevOps thing, right? Tools are easy, people are hard. Thinking about how we actually do work. Is a lot harder than figuring out how to create a Git repo.

Emma: [00:22:43] People are a first-class citizen in that workshop. You’re right. The very first thing that I have people do is write down who are the people on your code team. Who actually is responsible for looking at code, testing code? Are your clients involved? Is it just you? Is it just your team? Are you a team of one? Do you have to do a number of different things? Number 1, who are the people? Number 2, what are all of the things that those people do? We build it out from there. It’s not, here are a bunch of commands and therefore here is a way that you might want to construct a scenario which uses all of the commands. This is not a grade 4 spelling test where you have to use all the words in a sentence. This is like, take a look at who the folks are. The note that I wrote down while you were talking was by having constraints in terms of thinking about the team and thinking about what you want to do with the team, you can introduce creativity. But it’s really hard to introduce creativity when you’re just given a bunch of commands and you haven’t thought about the politics of what your situation are. Certainly some people have very, very rigid requirements around proving who checked in code. I talked to some interesting folks when I was at OSCON who are working on hardware and they have FDA regulations. They are working on pieces of hardware that go into someone’s body. They have got really formal and restricted ways of doing things and the idea of Git being sort of loose and everyone can commit code doesn’t work for the FDA. Which, thank goodness it doesn’t work for the FDA. You know, there’s some things where you do want those checks and balances to be in place, but drawing out the team first and talking about what their requirements were in terms of those regulations made it easier to see how to set up Git.

Matty: [00:24:20] I totally— I’m going to be super sensitive to using the word Git now. I was going to say, I totally get that. I totally understand it. It’s going to help my vocabulary in this episode because I’m going to have to think of synonyms for things. So I wanted to think a little bit about using Git in a couple of different use cases. And how we would go about doing so. So one, I guess, starting at the simplest level, was the I’m a single developer. So for me, this is probably the way that I know Git the best, in that that’s where I use it the most, right? I’m totally addicted to source control management, right? To source management now, even for my own projects, just because I like the theory of that it helps me track what I’ve been doing. Now, the reality is how much of that I do, and my workflow is really shit, my individual projects. Trevor can— I introduced him. I’m working on a redesign of the Arrested DevOps website, and so it’s all in Git and it’s up in GitHub. And so I sent Trevor the link to the repo the other day, and I was like, you can’t see anything right now because it’s all in local dev, but if you want to see— and I just look at how terrible my commits are. I do a bunch of stuff that’s really shitty. I roll a whole bunch of stuff up into one commit. I mean, a lot of my commits are the commit messages, Matt realized he had a whole bunch of shit he needed to commit, which is super useless, right? You know, or— so I want to kind of think about starting at that, because I think if you take a month—

Trevor: [00:25:39] It’s a really hard habit to form, like doing commits often enough, remembering that you finished something, and instead of just riding that high of finishing something, using that energy to make a good commit.

Emma: Do you know about interactive add?

Matty: Well, yeah, so let’s talk about that.

Emma: Okay.

Matty: Because I don’t.

Trevor: I don’t either. All right. Please tell us more.

Emma: So interactive add is something that I think it was Chris Ruppel who told me about it most recently, and it is the ability to take all of the things you’ve been working on and to think of them as patches that you’re going to apply to a commit. So when you do your interactive add, and I think the flag is on your add, it’s -p. I, I don’t memorize the commands, I look up based on the functionality that I need, but it allows you to go through your code and say is this hunk something that I should be adding in this commit? There has to be— to separate something into a hunk, you have to have sort of unchanged lines in between. But it does allow you to split things up if you’ve been doing lots of different things before making one commit. And then there’s also the option to do the rebasing to squash. So if you have lots of little, like, oops, oh well, shoulda, coulda, you know, you can squish those down into one. But the splitting apart is on the add, interactive adding.

Trevor: [00:26:53] So, I didn’t know that that actually had a name. I have done that in my GUI client for Git, but I didn’t know that there was actually a command behind the scenes that it was doing something special. I thought it was just doing something smart in its GUI-ness. But now it’s good to know that I can do that manually if I need to. But I’ll probably continue to use the interface.

Emma: Hey, if GUIs work for you, by all means, do what works. The thing that I don’t like about GUIs is if I have something that I need to be able to share with other people. It’s more difficult to explain how I got there. So with bang history, I can say these are exactly the commands that I ran before it barfed, and this is exactly what happened when it barfed. And I can copy and paste all of that, even if it’s just as a gist or a Pastebin or whatever you happen to use. Whereas with a GUI, it’s like I clicked on some things and then I don’t really know.

Trevor: That’s good to know too. So I obviously my command line foo is not what it should be, but I didn’t know I could get the history of the command.

Matty: Oh yeah, that’s based on your shell, Trevor. So to be fair to Trevor, it’s a Bash thing. Trevor is not using Bash. So, but I presume, and I will put this, there’s— you can get history in PowerShell too. Your command history is there. That’s where up arrow comes from. It comes from your history. So you should be able to emulate the same idea of being able to, right, you know, bang his, you know, get the history or to also just even grep through your history, you should— you can do that in PowerShell either way. But the idea is still the same thing, right? Where you can say these exact steps will result in the same thing versus my screen looks like this but I couldn’t tell you how I got here, you know, because I wasn’t paying attention and writing it down because I didn’t know I was going to have a problem.

Emma: [00:28:31] Yeah, and that’s— you don’t anticipate problems until all of a sudden you’re faced with them.

Matty: So for the single— kind of single developer workflow, like the things you need to You know, you don’t even necessarily 100%— like, my thing of why I put stuff, my single developer stuff up on GitHub is kind of almost it’s a backup, right? Like, I’m not really using it to share anything. No one’s pulling that stuff down. I don’t even theoretically need it. Like, I could make the argument to say, well, I have multiple computers so that way I can pull them from each one. But I also actually, I handle that with Dropbox or BitTorrent sync. You know, I don’t even actually use Git to synchronize source across my computers. But again, to that point, I don’t need to have any type of remote to get value out of Git as a single developer.

Emma: Correct. You don’t need to have a remote. Depending on how I’m working on things, I will sometimes, if I’m being super nerdy about my backups, I will push to multiple remotes because then if GitHub goes bankrupt tomorrow, I still have it on GitLab. If GitLab dies tomorrow, I still have it on Bitbucket. But that’s kind of super nerdy. I recognize that it’s not normal.

Matty: That has happened.

Trevor: What was that repository? Yeah, they got hacked and they got all their stuff deleted and yeah.

Matty: [00:29:38] Oh yeah. We talked about this another time, but I talk about that all the time cuz it’s a great infrastructure as code story, Codespaces is. But yeah, you never know, right? As soon as you’re trusting it to somewhere else, something you don’t have control over, you know, you want to kind of distribute that piece.

Trevor: Okay.

Matty: But now, so let’s, I guess I’d like to kind of give some ideas and I’ll encourage you to kind of share them, right? Like, so I want to do this, like how do I do it? And I know that the first step was the. Okay, so I draw my picture. Let’s assume people have done that. What are some of the outputs, some of the possible outcomes of that result, some of those flows that you’ve seen that are effective, and what are the things to watch out for?

Emma: Sure. So I think as a small team that’s just getting started in version control, you probably— and this is like a gross generalization, which is why I’m making a huge pause before I say— if you’re not using version control, you probably don’t have a testing infrastructure set up. Maybe that’s an unfair thing to say, but probably you’re going to want to go with the concept of a collection of work that sort of gets tested all at once and then it gets released later on. So I’d say that there’s a spectrum, and at one end you’ve got continuous deployment. You’re doing multiple deployments per day. And then sort of coming backwards a little bit, you’ve got the concept of continuous integration, and coming backwards a little bit, all the way to GitFlow at the other end. And GitFlow is saying, we have a— maybe it’s a weekly, once every 2 weeks, maybe it’s once a month, but we have a time-based release schedule, or if you’re a big software project, like a Drupal, you have a version-based software release schedule. Along that spectrum is going to be where your team fits. If you are working in an Agile with a sprint-based something or other, then you’re going to want to look for a branching workflow which allows you to collect changes over time and then release a collection of changes. If you’re working on the continuous deployment side, you’re going to want to look for something like— and I’ve got URLs for all of these with pretty detailed tutorials. You’re going to want to look for something that allows you to do deployments based on the branch, where if the deployment doesn’t work, you can roll back to master. So as a post— sorry, I want to make sure I don’t have too many shorthands in here. When you make your commit into a branch, you can deploy the branch. If the branch for some reason fails, then you immediately can roll back to a safe thing on master. If the branch deploys successfully, then you merge it into master, and now you’ve got a fresh or a safe starting point for the next branch that gets deployed. That one is, to me, it feels like tightrope walking because if you don’t have the infrastructure set up around you, there’s a lot of different ways that you can fail. I think that it really depends on the system that you’ve got set up and how much you trust your infrastructure and your deployment scripts and whether you’ve got your Jenkins jobs or your DevOpsiness. If you don’t have any of that stuff, then you’re going to probably fall back to something like a GitFlow.

Matty: [00:32:36] Well, and I think the other thing about that, when you said being able to roll back, is this can get into a larger conversation about kind of the myth of rollback in the first place, which is you always roll forward, you know. So if you’re in that kind of a scenario, so like, because again, I think like when you’re talking continuous delivery, it could be one of the mechanisms could be that, that basically what that second branch is, is the release candidate, right, you know, that you’re always working against, but you still have master, and then you can kind of talk— if you’re talking trunk-based development, you don’t even necessarily have that. It’s everything’s on master because the whole thing, right, is that your code is always deployable. Continuous delivery, right, at any time. Doesn’t mean you’re deploying it, but it’s always deployable. So if it’s not, it’s reverted, you know. It’s kind of a little bit of a different— and that’s, I think, where sometimes things get challenging, especially looking at when you kind of look at the— I don’t want to say prescriptive because again, the CD book is pretty like kind of vague, but then you start talking to Farley or Jez and they will get their opinions start to come out. But if you think about kind of the mechanism and the way that I’ve always think with continuous delivery is very closely aligned to trunk-based development because it either passes or it doesn’t, right? And if it doesn’t, then you’re CI, which means you either revert the change or you fix it and push that change. To that point, like it’s tightrope walking, but it’s Because you’ve made a conscious decision that that’s what continuous delivery is. It’s not tightrope walking, but it’s like we’re moving towards— it’s roll forward. That’s the thing that I think we run into a lot when we talk to folks about CD is, you know, cake, eat it, right? You want to have continuous delivery, which brings a lot of value to it, but it doesn’t mean that you get to have like 30 different versions of your code. The two are kind of fundamentally incompatible because the idea of continuous delivery is Master is always releasable. So how can you have different branches that are before the CD pipeline starts? Now, in my opinion, like, I’ve kind of been like, yeah, again, I philosophically go back and forth. I kind of—

Emma: [00:34:32] well, it depends on your infrastructure, right? Like, it depends on whether or not you’ve got a system in place where you can make those trust-based decisions. Like, can you actually trust master? How do you know that you can trust master? And certainly in the—

Matty: if you’re doing continuous delivery, you’ve made that determination. That you can.

Emma: Sure, but the regressions slip in. But sometimes you can’t test everything. You can test it, except when you can’t.

Matty: Your QA tester is not going to catch every regression either. I mean, bugs will make their way to production. It doesn’t matter how many human gates you put into place, right?

Emma: And it’s also the unit of change. Because if you’re used to working on very large tickets, and then you go through a larger QA process, That’s not a Git thing in terms of how you then choose to make smaller changes or how you hide things behind feature flags or, you know, those are not Git’s— Git doesn’t care how you structure your code. Git is just there to make the capture and store the information.

Matty: I think the key of that, and let me, let me know if I’m kind of summarizing this correctly, so like you said, like how much you trust your infrastructure. I just want to make sure that people understand we’re not saying like how much does it mean that you built like some awesome cloud-based thing. It’s actually even the infrastructure of your process and the infrastructure of your work. Which is that I have the pieces in place that let me trust master. Which is, if I’m taking the philosophy of CD, I can’t just say, I’m embracing continuous delivery, so my code is always releasable. Well, you can’t just say you’re doing that, right? There’s all these things you do that make that be true, and then if you’ve actually done that, then you can say, okay, yeah, I can trust master, because theoretically, not even theoretically, in practice, it’s as releasable as I can possibly test.

Emma: [00:36:11] I’m laughing because I’m old enough to remember when editing on a server was— that was like the original continuous development was just editing on a live server. Certainly in terms of the business case for how big of a problem is it if something gets deployed that isn’t— that is a regression or that’s a problem or those kinds of things. What you put in as a team of one who’s updating your personal website is probably not going to be the same infrastructure that you set up for an e-commerce system or If you are a provider of cloud-based systems, like if you’re AWS, trust me, you don’t have the same infrastructure as a team of one. So that’s kind of what I mean in terms of infrastructure is also how does it relate back to the business of your website or the business of your product?

Matty: Right. So the point being, and maybe we’re just violently agreeing with each other now, is that I wouldn’t do trunk-based development if I wasn’t doing continuous delivery and not continuous deployment, but continue. I mean, if I didn’t have that, the two like feed upon each other, right? You can’t, In a way, I feel like you can’t do one. They both require each other. So, but that’s one thing. So, but if that’s not your model, right? If your model is that I’m releasing, because again, CD is also like small changes, incremental, blah, blah, blah, blah, blah, right? So if I’m not doing that though, so what are some of the other places where I’d say if I roll up to a, you know, a point release or to a certain timed release, or again, the things like that, when I’m going to roll up a whole bunch of changes into one place. What are some of the other flows, right? Some of the other workflows and again, things to watch out for.

Emma: [00:37:39] I feel like this is a bigger question than what I’m going to give it the answer for.

Matty: That’s fine. Your answer is more important than my question.

Emma: I’ll sort of refer back to a piece that I’m writing right now on a book that I’m putting together for O’Reilly. I’m working— sorry, what is the title of my book? It is Learning Git for Teams. One of the things that I do is I take people through different branching strategies. The 3 projects that I give as an example are probably what you’re doing if you’re doing some kind of sprint-based development or timed releases, and probably using a Git flow in that case, which is the concept of a master branch, a development branch, a QA branch, hotfixes, and the release. So a totally different example is how the Drupal product releases its software, and it has a branch for version 4.5, 4.6, 4.7. Those are releases that are based on, and then we had all of the work that needed to go in there, but it’s not a time-based release. Then you’ve got completely different systems, what Git itself uses. If you go and get Git the product and you look at their branches, and I won’t remember what they are off the top of my head, but it’s proposed updates, next, something, and something else. I can’t remember what those 4 are off the top of my head, but there’s totally different ways that you can structure how your project works together as a team and what those individual branches are that you’re going to be using. It is totally dependent on the politics of how you want to structure how you work together. But those would be the 4 that I would say to take a look at as radically different examples. So something that does semantic versioning or point, something, you know, numbered releases versus time-based releases, and then something that uses truly semantic branching names in terms of what Git does.

Matty: [00:39:27] Gotcha. So if we could take this back a little bit from a little more into the typey typey a little bit. And I know, like we say, don’t start by memorizing Git commands, but I kind of want to go back and talk about maybe some ones that some of us might assume people know that are necessary, or just like kind of what are, what are some of the core things? And like, I liked how you talk about the -p flag, which was like a thing we didn’t know about. Like maybe some other kind of helpful things that you feel like people should know as part of their 101 of actually just interacting with the tool.

Emma: Hmm. Good question.

Matty: Or just things that you love. Or tolerate.

Emma: Things that I love. So, things that folks should know about. If you’re using rebasing, which is super useful, but also the history revisionist in me, it makes rebasing as a concept just kind of gives me the hives. Except I understand how important it is to the way that Git works. It’s not that I’m afraid of using it, it’s that it frustrates me that that’s how the software wants to work.

Trevor: I’ve never really had a good succinct explanation of why I should be rebasing. Could you also go over that?

Emma: [00:40:30] So, if you, right now, if you have a piece of paper and a pencil in front of you, I’ll give you 30 seconds to get one.

Trevor: I can get Paint in front of me really quickly.

Emma: Beauty. So, if you draw, like, a series of Christmas lights. So, you’ve got a string and a ball, and a string and a ball, and a string and a ball, and a string and a ball. This is going to be a representation of what happens to a series of commits over time. What rebase is saying is, I want— and this is, in computer science terms, a directed acyclic graph. I can barely pronounce it on the best of days. What rebasing allows you to do is essentially recombine how those balls get strung together or how those lights get strung together. That’s all that rebasing is, and it can get a little bit squirrely sometimes if you aren’t conscious of how or why. So I’m like, I’m drawing little circles, which, for those of you who are watching the recording, I’m drawing my little circles of how things happen in rebasing. But it takes all of those same commits and it just reorders how they’re strung together. Now, if you want to bring your branches up to date using a rebasing strategy, what it does is it takes all of the commits that were made on a different branch and puts them before the work that you’ve been doing, and it redraws that picture. So that’s one way of using rebasing, is to bring your work up to date instead of using merge. The other way to use rebasing, which why it uses the same term, it’s like, I mean, I get it, but it’s frustrating for me, is when you’re working on your own work, you can also use rebase to take a series of items. So again, if you’re watching on the— can I do this? Can I draw in? I don’t think I can. If I wanted to—

Trevor: [00:42:10] there might actually be, I think if you look in the Hangouts—

Matty: well, the problem is, Trevor, every time you or I talk now, we lose Emma’s— Yeah, video, so.

Emma: So if I take all 3 of these and I want to squash them into one, I can also use rebasing to manipulate how those commits appear in my timeline. So I can either redraw how they’re connected, that’s rebasing, using rebasing to bring your branch up to date, or if I’m working locally, and Matt sort of alluded to this earlier, if I want to take my work and make it appear as though those 7 commits happened in one commit, then I can squash them down.

Trevor: So is that really only useful then when you want to avoid, as Matt was saying, kind of the garbage commits, like the ums, the fixes, trying to see if this works, trying to see if this works, trying to see if this works again?

Emma: So in terms of those, the reason why you would want to rebase your own work, so the reason why you’d want to take 7 commits and put it into 1, is so that you can use some of the other tools that ship with Git, like git bisect. What git bisect allows you to do is it takes a series of those Christmas lights and you’ve got, you know, one light is broken and all of a sudden you’re not really sure which one the broken one is on the string. You just know that your whole string of Christmas lights isn’t working. So by using Get Bisect, you can take out each light one at a time and say, is this the broken one? Is this the broken one? Is this the broken one? And if you have a series of 7 or 8 lights on your string that are not in a completed state, they’re just you thinking about what the problem might be, you’re going to have a lot more of a challenge to figure out if you’re in a working state or not if you want to come back and use git bisect. Now, if you don’t want to use git bisect, it really doesn’t matter if you squash those commands or not. So let’s say, for example, when I debug my code, I can look at the current version of the code and I can figure out where the problem is with no problem. Great. But if you need to actually go backwards in time to see how a piece of code evolved and say, like, I can’t, you know, I’m looking at some regressions. I know this used to work. I have no idea why it’s broken. I cannot figure out from the current codebase why it’s no longer working. To be able to step back in time, if you don’t have functional groups of commits, git bisect is not as accessible to you as a tool.

Matty: [00:44:30] I think, and correct me if this isn’t appropriate, we talked about this like before we started recording. So like when I, when you talk about things that I don’t know about, Of which that is a long and exhaustive list. So for example, when we’re doing DevOps Days, so like that whole devopsdays.org website is built completely around like a shared Git repo in GitHub. And so if you’re an organizer for a local event, the way that you get stuff up there is through PRs, right? So you’re like, I edit my own little bits and do that. And so Bridget Kromhout, who is an organizer for Minneapolis and who has been on our show a few times and stuff, she has commit bits on that. So she’d be someone who would do the merges. And I had one where it was like, my PR was like 20 commits at least. Like it was just a bunch of stuff. And to be fair, it wasn’t like ums and whatever. They were things that we were testing locally within our organizer group to be like, okay, I added this thing. Oh, this vendor has now given us a logo. I can put that up there. And we intentionally were kind of saying, we’ll push one PR with all the commits so that we’re not hitting up the central at the same time. But then Bridget, like, yeah, sure. Her DM to me was, do you even get Squash Bro? You know, I’m like, I don’t even know what that means, but I could see the advantage to there, right? Is so she’s merging, she’s accepting the PR, it’s one thing, right? Because that’s what’s intended. Like, I’m not sending that to her because I’m like pick and choose which commits to merge. I’m saying here’s a bunch of changes that are within my own bailiwick, you know what I mean? So that to me seems like kind of a legitimate— not to say rebasing is not But a reason for rebasing to squash commits too is to help clarify the communication of a PR, you know, and that’s like thinking about version control as a communication tool, right? So if I’m submitting a pull request and realize we haven’t even talked about that at all, so hopefully you’re listening, you vaguely know what a PR is. Actually, we might want to take— we’ve got a couple minutes. We are really—

Emma: [00:46:18] I talk too much. I’m sorry.

Matty: No, no, no, no.

Trevor: This has been awesome.

Matty: It’s been great.

Trevor: That was a fantastic explanation of rebasing because I mean, every other time someone’s tried to explain it to me, it’s always been In the context, it sounds like I’m going to lose all the important commit messages that I spent writing. You know, I spent, you know, thinking, oh, I’m going to, you know, I changed this so that this would happen, or whatever. And I’m going to lose all these commit messages where I’ve, you know, described what I’ve done. And that’s like the reason that, you know, everybody writes commit messages, so that you can see what has been done. But no, that makes sense. Yes, thank you.

Emma: Yay! So the other thing that I sort of alluded to perhaps earlier on, but I know I definitely emailed you as I like tipped my laptop over and like people wonder why I’m suddenly going crazy over here, is that the way that we use central code hosting systems, and I’ll specifically pick on Git in this one. If you go and look at their education or guide or something like that, I’ll give you the URL afterwards, but they’ve got a description of how to do a pull request and how to work with teams on GitHub. They have what they refer to as a conversation piece. You submit the pull request and then you have a conversation piece where people make suggestions about how the code should change, and then there’s a new pull request submitted. Maybe it’s not quite finished, and so you have more of a conversation. All of a sudden, you’ve got a series of commits which are partial ideas, but it doesn’t actually say, combine all of those commits into one single commit when you submit your pull request. Probably, the conversation is happening in ticket or in comment form on GitHub. When you’re doing that final merge in, the pull request, I believe, is actually a GitHub term initially. Because I know that Bitbucket used to call it a merge request, and now they call it a pull request. But it’s basically when someone says, I have some code that I would like to include in the main sort of copy of the repository. And you, you have a discussion. In Linux and Git original land, that used to happen over a mailing list. So that conversation happens, and then when the final piece of code is pulled into the repository, if you’re doing it in the way that GitHub says to do it, you’ve got a bunch of single commits which may or may not make sense individually. And yet the way that we used to do things was you recompiled— compiled is kind of a dangerous word— but you put together a patch and it was something that was traded over a mailing list. Drupal still does this. You upload your patch file to drupal.org and the patch was the entire commit. It had all of the ideas in one place. And so what these centralized code hosting systems are discouraging us from doing is thinking in whole ideas and putting in that commit message what the business logic was, what the thinking or the rationale was behind that final merge being accepted in. I think it’s kind of dangerous. There’s my little thought bomb. Away you go.

Matty: [00:49:09] We’ll definitely post a link in the show notes to the online version of your thoughts or rants. You called it a rant.

Emma: They are total rants.

Matty: I think it’s a lot of different things, kind of thinking about breaking up how we think about change to a project, right? Versus is it this small, you know, and that kind of gets a little bit into, yeah, we could get into a much bigger conversation about, you know, atomic, very small changes that are continually rolling. And that works again in a continuous delivery model. But if you don’t have that around it, like again, there’s a lot of danger that can come with cherry-picking parts of a philosophy or part of a methodology. Because it works as a whole, but it doesn’t work without, right? You know, so you can’t say like, I’m gonna just do tiny little bits, but then I’m gonna squash it all together at one thing later, but not refer to it, but refer to that later thing as just, it’s all those tickets that we did over the last 2 weeks. Like, how many releases have we had that, which is, what’s in this release? All the things we did in the last 2 sprints. What is that, right? You know, so I think I get where you’re coming from. I had to get one last one in. So we are coming right up to the end of our time, so we’re gonna move into our I think this has definitely told me that we’re going to need to talk about this some more.

Trevor: [00:50:23] Absolutely.

Matty: We steal so much from the Food Fight show, so I’m going to steal from Nathan and Brian where we say, we’re definitely going to have to have a follow-up episode to this, and then we won’t. We’ll at least want to. It’ll be a desired thing. I would definitely like to hear— well, a Rest of DevOps drinking game today in this episode. Every time I say definitely, take a drink. Apparently. I would love to hear—

Trevor: no, that’s for every time you say git. That’s hard mode.

Matty: That’s— oh my God, that’s just not fair. Uh, we’d love to get feedback on how our first, like, real more technical episode has gone.

Emma: And was it technical enough? Did you want more technical? Did you need more commands?

Matty: Exactly. I, I think there was an amazing amount of great content. I accomplished my goal of learning a lot, but I’d like to know if the listeners learned a lot. That being said, let’s go into our checkouts. Emma, what do you have for our listeners or viewers to check out?

Emma: I’ve got 3 checkouts today and maybe a bonus one. I have to decide when I get to number 3 if I want to share the 4th or not. The first one that I have is a Kaleidoscope app, which is on OS X. It’s an amazing GUI, just using it for a merge tool. The reason why I like it is that it allows you to do diffs on images. If you’re checking an image into the repository and you want to see if the image has significantly changed or how it’s changed, you can drag the image over top of one another and see where the changes are. Maybe like Wraith, W-R-A-I-T-H, in terms of the automated image testing. That’s my number one. It is a paid app. It is fairly expensive and it is only available on a Mac, but I quite like it. They don’t pay me to say that. The next one that I’ve got is a workshop that I’m really excited about. It’s starting in January, although sold out, so look for the February one. Rachel— Rachel, I don’t know how to pronounce your last name, I’m sorry— Nabors, Nabors, and she is doing a workshop on how to draw comics, and I’m hoping to get more diagramming experience out of it for techie people. She did an OSCON keynote presentation this past year. I’m really excited to be taking this workshop with her. Then my third checkout for today was GoGnome, yay! In the Groupon, we’re using your trademark, and we don’t care debate. GNOME actually won and Groupon has backed down. So I’m super excited about that. My fourth one was going to be a whiskey checkout, which kind of— Oh, nice.

Trevor: [00:52:48] Always welcome.

Matty: I just haven’t done them in a long time. That was my very first checkout in episode 1 was a whiskey, yeah.

Trevor: It was.

Matty: Okay, so my— Now you have to share it or I’m going to be—

Emma: My whiskey checkout. I am typically an Islay kind of person. I’m just sort of deviating from my norm here. I’m going with an Oban 14 for my, my whiskey check.

Trevor: I had that recently. It’s good.

Emma: Oh, it is smooth.

Matty: So now I’m upset that I don’t have a— that’s okay. So my first checkout is actually vaguely related to Arrested Development in its name, which I didn’t— was part of the reason I like it, but I didn’t think about that for the checkout. But it’s a tool called Teamasil, which is a generator for tmux sessions.

Trevor: So does that also decrease your sex drive, cause numbness in the extremities, and produce a feeling of camaraderie?

Matty: Well, anytime you use tmux, it could cause a numbness in the extremities of your pinky finger if you haven’t remapped your control key. Awkward. That’s for sure. But I was using tmuxinator before, actually, and by using it, I mean I gem installed it and never actually used it. But then nothing against tmuxinator, I just keep forgetting it exists. Better branding, maybe? I don’t know. Like calling it Temasil, and then I’ll remember. So I’ve already started using it a little bit. I’m a big fan of tmux, and I like the idea of being able to kind of very easily with YAML create tmux sessions, which, yes, I know, tmuxnader, that’s what you do too, but Temasil has a cooler name. I also have— there’s a thing called the NoPhone, which had a Kickstarter, and I want to say it was like $18,000. It is a technology-free alternative to constantly hand-to-phone contact. It is this generation’s Pet Rock. It’s basically a slab that looks like an iPhone, except it doesn’t look like it at all. It’s just a black slab of plastic that is to help you put your phone down, but if you still feel like you have to hold something that’s like a phone. The Kickstarter is really funny. The testimonials are great. My favorite was, not a real phone, as a testimonial. And then the other thing is it’s a link to a blog post that Lindsay Holmwood wrote back in September, but it just came to my attention the other day called It’s Not a Promotion, It’s a Career Change. And it was— Joshua Timmerman is the one who referenced it to me, or at least I read it through his blog. And it was about how in tech, you know, we kind of see that the way of being promoted is through management, and that when you change from being— if you’re, you know, kind of a subject matter expert or individual contributor and you become a manager, it’s not really necessarily a promotion. It’s totally changing your career and you’re doing different things. And likewise, that shouldn’t be the only way that you see to move up because engineers don’t necessarily make good managers and nothing against engineers. Anybody doesn’t necessarily make a good manager. Just because you’re good at one thing doesn’t mean you’re good at managing people. And I have had that exact experience myself as I went from being an admin up through manager and director and then said, you know what? I am just not— this is not my thing. I want to go do other things. So we’ll have a link to that and all these things in the show notes.

Trevor: [00:55:46] Cool. So I saw an interesting article yesterday. SanDisk is releasing a— they’re calling it the UltraDIMM SSD, which is a solid-state drive that fits in your DDR3 slot. The idea being that the memory has the shortest route to the processor, so we’ll have the fastest response time. It’s very interesting. Put a link to it in the notes. Also, Android L is out, which is really pretty and really useful, and I love it. I also got an inbox invite. It seems so far to be pretty useful. I’ve been using the pins to keep track of messages that Matt sends me that I’m supposed to follow up on and not losing them, but still not responding to them. Finally, I would— I was— the final piece I was going to talk about was the fact that we just landed the Rosetta probe on the comet, but Matt, as we know, stole my thunder within the first 5 minutes of the episode. But still cool.

Matty: Maybe if people are joining late now, they’ll know. Although they probably were joining late because they were watching the livestream of it. So anyway, I want to remind everybody, including myself, that we have a newsletter. I should be reminded of it because I never remember to send it, but you can sign up for this newsletter that I never send at arresteddevops.com/bananastand. It is the best way to know about upcoming podcast episodes and cool news with DevOps. We don’t spam you. Literally, we don’t, because I never remember to send it. That being said, we really are going to try to be better about that. And give you information through the banana stand.

Trevor: [00:57:06] I just had a dramatic change in lighting thanks to the sun, and of course Windows is telling me my battery is low and it blocked what I was about to read. Thanks to our sponsors PagerDuty and RedGate and our loyal listeners. If you guys enjoy— or everybody, if you enjoy watching Arrested DevOps, we’d appreciate it if you would visit arresteddevops.com/itunes and leave us a review in the iTunes Store. Thanks to Emma for joining us, and be sure to check us out at arresteddevops.com or @ArrestedDevOps on Twitter.

Matty: We are always happy to get your input, ideas, or feedback at shows@arresteddevops.com.

Trevor: I am Matt, @MattStratton, and I’m Trevor, @TrevorGHess.

Matty: We are Arrested DevOps, and remember, there’s always DevOps in the banana stand.