Read the show notes and download the full episode here.
Michaela Light 0:02
Welcome back to the show. I'm here with Luke Kilpatrick. And we're going to be talking about cool things you can do with Git to speed up your whole merge process using a new tool called Git stream. And we'll get into that in a moment. But first, if you don't know, look, he's been doing cold fusion for years, nearly
Luke Kilpatrick 0:22
two decades, right? Yeah. Yeah. A long time.
Michaela Light 0:25
Yeah. And you started off doing web development even before that in the years when the web hardly even existed in 1996. And right now, you do you lead the developer experience team at Linear B. And you've done that developer relations kind of role at quite a few companies now. So
Luke Kilpatrick 0:46
yeah, I've been doing developer relations, but last 1012 years, but yeah, cold fusion has always been sort of one of my my first loves. And that's what got me into doing web development. And I had the opportunity to work with some of the some of the greats. Going back to broad choice back in the early back in the late aughts, but 2007 2008 worked with the break Hampton and Shawn Corfield and Brian Renault are, Brian, Brian Kotek. And, Joe, just Jeff, I've had the chance that and actually fairly recently, at Nutanix, I actually had Jared Rucker, Howard working for me. That name sounds familiar.
Michaela Light 1:33
So the CF objective, Yep, yeah,
Luke Kilpatrick 1:36
he worked for me for about for about a year there. And, yeah, still keep in close touch with that community. And it's been good. But yeah, building out into doing, you know, moving from doing code all day to telling people about code. And actually, what got me transitioned into the dev rel world was actually being co manager of backfocus, the Bay Area ColdFusion user group. And I discovered that being part of the user group program back in the day, that I enjoyed talking and connecting people, and teaching people more than I liked writing code. And so I transitioned in my career into into doing that. So I still write code occasionally. But most of it these days, is helping people improve their workflows and improve what type of stuff they're
Michaela Light 2:24
doing. Excellent. So maybe we should start off, not everyone uses get I know, it's a shocking thing to hear. But, you know, in our state of the cold fusion union survey, annual survey, there are still people who don't use any kind of source control, or what I would call source control. So maybe I say what Git is, and why they should be using it.
Luke Kilpatrick 2:51
Yeah, well, like I know, there's still a lot of, you know, sort of single person teams, ColdFusion developers out there, a lot of times, you're like maintaining legacy systems, or you're building new systems. And if you're only if you're the only developer, you know, source control is more of trying to keep your own checks and balances, rather than, you know, working with a team. But as soon as you add a second developer, source control becomes incredibly important, because you don't want to step on each other's toes, you know, if you're not the only person in writing the files, source controls, critical. You know, I remember back in the old days of when I first started using subversion, and how much the changes and merging and all that fun was, but it was really important, and just not, you know, once you add a team of four or five developers, you can all be working on different files and locking stuff doesn't really work. And it because it stops you from being able to do stuff. So you know, the idea with Git where you, you know, gets gets a really different way of thinking about source control, compared to the older systems like Microsoft Visual Studio, code and teams, and, you know, materials fairly close to get. But there's, there's a bunch of the different source controls out there. But the industry is kind of standardized on Git. And if you're looking to get work these days, if you don't understand Git, or know how to use Git, it's really hard to be a developer.
Michaela Light 4:15
I would agree with that. So just to be clear, Git and other source control tools let you they save in a repository, a copy of your code together with the differences that each programmer is made when they make a change. And with Git, you can have separate branches. So one feature requests may go in one branch and other in another. So it keeps it organized. And then you can roll back anytime you know if you made a screw up. I know no one listening ever screws up their coding, but just in case you did, you can roll back to a pre prior version. And then the other thing we're going to talk about later in the episode is merging of changes so that mine is better and I would like to say that even for one programmer and his or her dog is useless still be using Git because you really have more than one program in your project you have you from six months ago, and you have you now, and often the two don't talk to each other.
Luke Kilpatrick 5:09
Yeah, there's always been that problem. And and the other thing was with Git, especially when you start doing things with GitHub, and some of the other hosting platforms, is code reviews, and reviewing, having other people review your code is a really nice feature of Git, and GitHub, as well as Bitbucket and with if you use Git lab, most of the three main big repository companies can get lab calls, merge requests, but they're okay, you know, code reviews, a very important thing, because a lot of times people will find issues just looking over another person's code. And if so, they become a critical part, especially in any type of security thing, if you're doing anything with socks, socks, too. Usually, code reviews are required.
Michaela Light 6:03
Let me just share the screen with the results from the survey so we can see what the top ones are. You'd actually Nate, you work your present. Luke, you, you picked out the GitHub, Bitbucket and GitLab are the top three probably account for well, 60% I can't quite do the math. Or maybe 70%. Probably
Luke Kilpatrick 6:21
closer to 70%. Here. Yeah,
Michaela Light 6:23
yeah. And then some people have GitHub enterprise which itself, which is still yet. Yeah. And then stopped version still exists. Yeah, folks use that. But
Luke Kilpatrick 6:34
there are a few others. Azure DevOps is also similar to Git as well. Yeah.
Michaela Light 6:39
Yeah. Some, and then some of these other things like zipping up folders and compare, you know, beyond compare, and they're not source control. Guys, listen, no,
Luke Kilpatrick 6:51
no, no, there's Yeah, definitely. The majority, though, is, is is using using Git, and then a few others here.
Michaela Light 7:01
Yeah. So there's still a chunk of people, you know, 6%, who don't do they don't I mean, these people who say they don't use any source control in the zip up folders, folks and Google Drive, yeah, Google Drive copy directories, I think there's a chunk of people who haven't quite got the message. So
Luke Kilpatrick 7:19
well, it just, you know, GitHub takes a little get takes a little bit to wrap your head around. But it's still, you know, it's, it's, you know, the top three are all based off of Git, and just a little history of Git. Git was actually created by Linus Torvalds, or Linus reliance, or how have you, who's the if people remember, he's the founder of Linux. And he won. He didn't like any sort of source control systems out there for managing Linux. Yeah. So he created Git, so that it would manage Linux the way he wanted to work. And then it's spread through the industry like wildfire over both the last, I guess, the last 15 years, it's been really, really big. You know, that it's, it's hard thinking that 15 years is like 2007. Now,
Michaela Light 8:05
wow, yes. It was hard.
Luke Kilpatrick 8:10
You know, I'm, I'm back and remembering the little old cfunited Back in that day.
Michaela Light 8:14
Yeah, there you go. In fact, if you think of 2007 50, we're 15 years away from 2007. But you go 15 years before that. It was before the internet really existed in 1992, or commercial Internet, for sure. Um, Gerald was academic internet. So it was quite, it's quite a long time ago. I just want to say to listeners, you know, just in case, you've got the false impression, you can only use Git for open source. Not true. You can use it on private projects, commercial projects, maybe you need a paid version, like Bitbucket or GitLab. So,
Luke Kilpatrick 8:49
as well, so git lab is open source as well itself. So you can run your own git lab server for free. You can run your own git server for free. The thing advantage that GitHub and Bitbucket and all these other things, they take care of all that managing of the server for you. So by running, and the way that get stream works right now, which is which the product we're going to talk about in a little bit. It requires you right now, we're only supporting, you know, it's new, we just came out on September 27, or 22nd. So, like, you guys are hearing it first, you know, and, and it's, it's exciting, but it only operates on GitHub at the moment, but we're looking to support the other product, other other flavors of get hosting shortly. But that's so you know, and it looks like the majority of your from your survey. People are using GitHub, it's kind of it could become one of the industry standards owned by Microsoft. Good company, very supportive developers. You know, it's been really interesting to see how Microsoft has changed over the last 15 years of our opinions of it as developers.
Michaela Light 9:54
It used to be used to be evil, right, but yeah, they now they're moderately good at
Luke Kilpatrick 10:00
Yeah, well, they've they've they've embraced open source like stuff like Visual Studio Code, which is a phenomenal open source project that they've released to the world. And, you know, as becoming a bigger and bigger IDE, you know, they've done a lot of stuff. You know, everybody thought when they bought GitHub and LinkedIn, Microsoft would ruin them. And in fact, it's both have accelerated, and they've left them alone enough to still keep their own culture. So you know, it's, it's who would have thought that Microsoft, Microsoft, in the 90s was like the worst thing ever, and the Microsoft or the 2010s. And present as a developer, they're actually a pretty great company to, to work with. And that's, that's been a big change. So it's, and it's, it's exciting to see that because they're giving, you know, they're giving away tools to developers for free, that are really useful.
Michaela Light 10:54
No, that is definitely what they've done with both GitHub and Visual Studio code is great, because they have the money to invest to pay for developers to be doing it. So they're still mostly open source projects, I don't know if it helped be official source.
Luke Kilpatrick 11:13
Visual Studio Code,
Michaela Light 11:14
sorry, getting my things messed up. That's like 99%, open source. And then there's, like 1%, there's their telemetry stuff that they keep private. But the point I'm trying to make is, on a normal open source project, people volunteer their time here, Microsoft is paying developers to work on these open source projects, promote them, to, you know, listen to do roles, probably they probably have a paid role, like you, Luke, where they listen to what developers want, and what issues they have with it. And then they improve it. So definitely, it's great. Now, I will say, you know, I'm not a big Microsoft fan, to be honest, even though they're doing these great things. Because they do get benefit out of seeing all the code that goes through GitHub, I'm sure they have some AI being written in the background that scans all that code to be a virtual assistant coder over your shoulder that will give you suggestions just like co pilot. Yeah, exactly. And I think they do a similar thing with VS code, they kind of see what kind of coding issues people have, and what have you. So,
Luke Kilpatrick 12:19
you know, Microsoft's, Microsoft's doing it for their benefit, too, right. But it's changed, it's changed. They've changed their tactics a lot from working with developers and encouraging developers rather than trying to, to basically suck out money from developers, which is, which is the previous thing, you know? And that's, that's always the rub. Right? If you're not paying for it, chances are you're you are the product.
Michaela Light 12:45
Right? So let's, we talked a little bit about, you know, what a merge is, but I think we want to explain to people, you know, what, what is requests and mergers, because they are the meat of using GitHub. This is where get stream helps speed things up. So yeah, tell us what a branch is?
Luke Kilpatrick 13:06
Well, so usually, when you're starting to work on a new feature for your app, usually your best ways to do is you, you clone the repo, and you create a branch, and the branch is basically your area where you're working on. So this is where your branch is diverting from the trunk. So think back to a tree, the trunk is your main line, and then you branch off to make your changes. And then once you've made your changes, you need to merge those branches back to the trunk. And that's where stuff comes into conflict. Because, well, what if someone's working on a different branch at the same time on the same piece of code? How you resolve those conflicts? Now, you know, resolving conflicts is something that we have an almost every
Michaela Light 13:47
interest to clarify a conflict is where two people edit the same lines of code in different ways, in effect during the same piece of code. Maybe they changed some variables or whatever.
Luke Kilpatrick 13:57
Yeah, yeah. So So you've, you've got that conflict, and that conflicts got to be resolved. And, you know, and that's, that's the merge process where you're resolving it now, if things are going really well, and people are working on different parts, and people are doing different things, you know, get will merge stuff really quickly, without conflicts. But there's also you know, if you screw up if you don't do it, well, if you if your code is not perfect, 100% Because, you know, doesn't happen to me, but I know it can happen to other people is, you know, if your code is not perfect, you've got a, you've got a problem because now you've either merged in with no review, and you've now broken the trunk, you've broken the build, and you owe someone a case of beer. That used to be our that used to be. I used to work on a team that if you broke the build yet by beer for the team on the Friday, so don't break the build. And that's what we have CI for is to check to see if that merge is not is doing that CI is Continuous integration. But the problem is so you can merge, and there'll be no review. So GitHub in 2008 can have this idea of what's called a pull request. And so when you pull your, your code down, and you make your changes, and then you push it back up, to commit it to the branch, you want someone to verify that your code in the branch is good and correct before it gets merged into the trunk. And that's what's a pull request is call her that's that code review. And what's been really interesting in that has how the industry has changed is that we have been doing a lot of digital transformation to doing what's called CI and CD. Now, Ci is continuous integration. And what that is, is tests and unit tests. And basically, when something is merged to trunk, there's a whole bunch of changes, tested based on tests that have been written. And then the second thing, once everything passes, the test is deployed. Now back in the old days, we deploy and make a release every nine to 18 months. And, you know, we all remember the old versions of Photoshop, that would take 18 months to come out. You know, you could have a kid twice for that time. That's not how the world works anymore, especially in cloud, a lot of companies are deploying 510 15 times a day. And the only way to do that is through a great CI process, and through a great deployment process. And we and a lot of companies are getting there. But what we did in our research is we found what's actually slowing code down the most is actually the human element of the code review. So that code review, you say, hey, I need a code review before I can merge. And now you have to get somebody else's attention. You have to get their time. And now they have to end they're coming in cold. You know, they don't know when the code review is going to be what's in it. You know, it might be, hey, I changed the CSS and it looks good to me, LG, you know, LG TM, or it might be a 500 line thing, to go and dig through multiple files. So there's lots of variability in that. And because of that variability, it's a little bit of a Pandora's box, as you open up that PR, and you don't know whether you're going to take your five minutes, or it's going to take you 20 minutes, or it's gonna take you two days. And so that's what we're trying to solve, because we found that, that's the slowest part of the cycle now. And that's what we're doing with Git stream is to try to accelerate that code review. And code reviews are really important, because they catch a lot of the bugs. And it's that human interaction. But there's also a lot of stuff that doesn't really need the deep code review. But you know, there's, it's different for every different team.
Michaela Light 17:46
I was reading through the the Git stream website, you have this statistic there that says, you know, the average time to throw a pull request to make it through production is how long?
Luke Kilpatrick 17:59
I've got seven days. So it takes you days. Wow. So that's that's the average. I've worked on open source projects, where it took six months for a pull request to be picked up. I've I've seen stuff. Some teams are really good. And they'll pick them up all that day. It all depends on your team discipline. And I've heard people say like, Hey, can't this be fixed and culture? And yeah, it can. But culture is hard to change. And culture is hard to impact and hard to pick rules around. Whereas if you can programmatically say, here are the rules, and here's the rules to follow to do that. And it's automatically doing based off what you've written, it becomes a much more effective thing. So so let me so I'm going to back up a little bit and just say like, what gets stream actually is. So the way that we figured how to solve this is, you know, you submit your pull request. And get stream then jumps into action and takes a look at it. It sees how many lines you've written, it seems what files you've touched it, and it seems who you are. And what it does is based on we've got this file called a.cm file or continuous merge file. And it's a Yamo file with a set of rules. And those rules can be adjusted for everything from line writing to estimate the time to merge, there's a whole bunch of different properties that you can put in this. And what it does is it reads through and says and it adds labels or it can add reviewers or it can add comments to give the reviewer a lot more information about that pull request. It also can be certain things like say you're editing the UX files, you want to make sure that one developer is your, you know, Master UX person, they want to see everything that comes through and they have to approve it. Great. If you touch these files, it automatically assigns that reviewer. So there's a lot of power here. And it's all power that you can use, which is great. It's all control, but we make a few suggestions. But really, it's it's taking and sitting down with your team and figuring out okay, what are the set of rules and guidelines we want to do? And what do we want to encourage? One of the things that I think a lot of teams try to encourage is small PRs and Because PRs can be expensive, because they use a lot of time, going to a smaller process that are faster to review, and and more readily available, improves your throughput, but also is going to improve your code quality. Because the faster those that code that branch lives, the longer that branch lives, the more on my warrant divergent that comes from the trunk. And so you want nice, short live branches, small PRs, and small amounts of change over time that builds up to do it. And that's how you get a faster and more reliable product as you release it often. And so that's that's how things in the elite teams are changing. To do that, and we assist that with Git stream by basically, you know, you touch this part, it, it follows the rules, it gets decorated with the right labels and comments. And so when it's assigned to you get a notification, it says, hey, you've got this PR, go do it. And that hopefully speeds it up so that instead of taking seven days to PR, it may only take hours now to get that merged. And then once the PR is cleared, you're free to merge, and you'll adjust for your conflicts and you're ready to work on your next project. And that's work on your next ticket. And that's, that's the idea is to really speed up the time needed. And if some stuffs touched, like, say you did docks or tests or something like that, and you don't need to review, you can do the pull request, it will decorate it, it will auto approve it not emergent for you if you want as well, for the little stuff. And so that way you're not bothering people. So you're freeing up time to there's lots of functionality and ways to make it work and adapt for however your team works.
Michaela Light 21:38
So it's sort of like an assistant to all the developers, I mean, this could be done by a human right. Oh, yeah. And I'm sure in some organizations, they have an assistant to, like looks at things and said yes, small change, standard change, critical change. And maybe an analogy here is when you go into the ER and a hospital emergency room. They do triage, typically, particularly if they're busy on a Saturday night, for some reason, a lot of people have accidents on Saturday night, I can't think why. But they'll have a nurse who triage is and they say, Okay, this patient, you know, they just cut their finger, they need a band aid, you know, this patient is a standard, whatever it is, I can't think what a standard medical procedure is, but it's not, you know, they broke their arm. So they need it setting, it's not going to kill them. And then they have heart attacks or other things that are like, you know, this needs a critical care team to come in and review what's going on. And same thing with these, you split them up three ways, right, you have the auto approve simple changes, you've got the standard ones that one person can review. And then you've got the critical changes to maybe the core code or some critical piece of functionality. Or maybe there was a refactoring done that that affected a lot of things. And then you want more than one pair of eyes, or maybe senior pairs of eyes to look at the change.
Luke Kilpatrick 22:57
That's exactly it. I have a friend of mine who works for SAP he has he's the vice president. He's got 2000 developers that work under him. He has three developers working full time to get these pull requests assigned to the right people for review. So you know, one of the things does if he adopts gets streamed, you know, those three people can now be working as developers and contributing code rather than having to spend all their time figuring out who does this pull review, pull request review. So there's, there's some ways of, of this to, you know, automate and help these larger teams. And this is free, that's the best part get streams free. And we're hoping that both open source and commercial stuff picks it up. It's a tool to help you use it. One of the big things we're doing right now is Are you familiar with Oktoberfest?
Michaela Light 23:52
I am Yes, it's happening right now it is.
Luke Kilpatrick 23:55
And we've actually got a blog post about this on how we can use this because one of the cool things about Oktoberfest is you get all these great PRs and all this open source and everybody's helping out. And some of them though, there's some people that just want the t shirt, and they may not the highest quality PR, like add your name to a list. Hey, PRs accepted, great, but that's not the right way to do it. And if you're a maintainer, you've now got a big bunch of spam requests that you really don't want to do. And so what we've actually done and created a special CSV file for Oktoberfest for maintainers, to actually work as a spam filter. So when someone submits a PR, and if it's of low quality, it gets labeled as a spam question mark. So we're not actually kicking it out, but we're throwing a label on it for the maintainer so they can go and look and see all the ones that are labeled and and check and see whether or not it is You know, it's it's, it's all that type of stuff. So yeah, that way.
Michaela Light 25:07
Yeah, so hack Tober fest for folks who don't know is is a month long, like, Let's improve our open source projects we use and do some contributions. But and that's the positive side. And I encourage people to do that for all ColdFusion open source projects are out out there, even if it's just a little thing change, like fixing errors in the documentation, as most developers are capable of doing, I would say, but, you know, all the way up to adding features or fixing things. So but like you said, it produces a lot of changes that may or may not be wonderful.
Luke Kilpatrick 25:42
Yep. Well, and so one of the things that I've encouraged a lot of the Oktoberfest is we've got this really cool feature called estimated time to review, this is actually a little bit of our secret sauce on Git stream. And it allows us to take a look at your code, see, we make a guess, at how long it's gonna take that review, if it's a small change, it's gonna get like five minutes, if it's a big change, you're gonna see that it's going to take an hour or two, to review all those changes. So we make a guess at that and put it in as the comment. So that, you know, when you're trying to schedule your day, or trying to thing as you know, okay, you know, what I'm gonna go bang out 10 of these five minute reviews, but I know I'm going to need to schedule some time this afternoon to go put this other as just having that alone has been huge. And we're actually using get stream to get stream team is actually using Git stream to develop git stream, we like eating our own dog food here. Since July, when they started using it, our pull request, time has been cut in half, the time from that commit to when it gets reviewed, and merge has been cut in half. So if it's taking you seven days, it's now taking three, it's and it's potentially even faster, because you're getting when you open a pull request, you get a whole lot more information, rather than just hey, it's pull request, it's now okay, you know, it's touching this area of the code. You know, one of the cool things you put into it as we we fully support regular expressions, you know, hats off to Ben for to say, you know, regex is good. We actually support regular expressions that actually allows us to, you know, you can search some of your code to find, so one of the ways we're doing that is checking for dependencies. So if we deprecate something, we can actually have that in the commit file, we actually can put that in as a comment. So even after you've submitted a pull request, you can actually see oh, you know what, maybe I should do go change that to do this. And then I can clear it and resubmit. So there's, there's some stuff that we can put in there that allows us to help, you know, fix those deprecations. Fix dependencies, there's a lot of different ways that this is being used, because set, we've not even been out for even a month yet. And we're starting to see some surprising use cases from our from our users out there.
Michaela Light 27:59
So I do also give visibility on all the pull requests and who's you know, holding things up and who's the fastest, whatever you want to kind of know you call them pull requests.
Luke Kilpatrick 28:11
So so we've been actually, so this is actually where Linear B makes its money. So Linear B, we provide a phenomenal set of tools that hooks in between your source control system and Git, and we support git BitBucket. GitHub, Bitbucket, Azure, DevOps and GitLab. And we hook into JIRA, or there's others are mostly Jira, but we're, we support a few others as well. And we take the that and measure that together. And so that's, that's where we, and we saw that, but it's free for up to eight to eight developers. So if you're a small shop, check out linear b.io. And you can hook that in and and see what you think. But that's really the idea here is that with get streaming as people start using get stream, like it, and then they'll want to see the insights and then want to see that metrics and the data. And you know, we have a product for that. And that's how, you know, I pay my bills. But that's, you know, we're giving this tool to developers for free. But it's usually the management or the product to the engineering leadership that wants to actually see how stuff's actually going. And thankfully, those guys have budget, whereas developers, we don't get that much. So so that's kind of how this has been. That's that's sort of the business model here.
Michaela Light 29:31
I was wondering how you can give it away for free. So it's a free, it's sort of a bit like I don't know if which version of Git does this maybe it's bit bucket is free for up to five developers for remember. Right? Yep. So it's a similar model to that. One team. Yeah.
Luke Kilpatrick 29:50
Get UPS free for open public repos. But if you want private repos, you have to pay so like that's like all these companies, they they give something A way to get your user to get out. And then there's something else that allows them to have a business. Right? Right.
Michaela Light 30:08
So, okay, well, that makes more more sense. So folks can try this out today for free just on a small development team or
Luke Kilpatrick 30:19
smooth for linear. For linear, linear BSP is free. The metrics and the dashboards are free for update people. Yeah, and there's some features that are in the enterprise product that aren't available in the free product. But get stream, this tool that we use for helping manage pull requests and do all that that's completely free. And if it's up to me, I will always keep it free, because it's a tool to help developers and it's a tool to help you get stuff off your lap, the primary thing that it does is getting stuff off your laptop into the team, Team branch, right? Like, and that's where we've got a lot of tools that help us code, we've got a lot of tools that help us test. But this is sort of the first thing we saw this gap of getting code from your, you know, it works for me on my laptop into the trunk that we found is the slowest process, and this is a way to try to accelerate it.
Michaela Light 31:13
Oh, that sounds great. Do you have a roadmap for what you're going to be adding into this?
Luke Kilpatrick 31:18
Ah, yeah, the biggest thing we're trying to do next is support Bitbucket as your DevOps and Git lab same as Linear B does. That's our, that's our new atrium. And then the other cool thing that we've got working on is that we're actually going to provide this as a plugin for Visual Studio code. So you'll actually be able to see the rules and automations in Visual Studio code and will actually look at your code and say, Okay, you currently hit this automation, you hear really do that. And that lets you get get your pieces together.
Michaela Light 32:00
This is very cool. So now, you it how many folks are at Linnea be doing this stuff.
Luke Kilpatrick 32:09
Ah, we're small company, we've, we're half the US half in this Israel, our product and our product and engineering teams are in Tel Aviv, marketing sales, a lot of our leadership's over here in the US, we're scattered around the US, Israel is a little smaller, so everybody kind of centers into Tel Aviv.
Michaela Light 32:30
But that's the Silicon Valley of Israel, as I understand,
Luke Kilpatrick 32:33
it really is I got to go there in July. And it was amazing. And we got a fantastic team there. And it's linear bees, about 80 people were growing, it's I joined I only joined in June. So this is we literally I joined. And actually I've been deep in the product. Even though I'm I report into the marketing team team. I'm, I'm still hands on in the code. Still, I'm doing developer marketing, Developer Relations, this whole whole area. And you know, so I've had really my fingerprints in the product, which has been really awesome to make sure that this product is something that's useful to developers. And that's something that's been really cool. I've been really happy working with the team to make something that I think helps people like me, you know, you're always much more passionate about a product that you want to use.
Michaela Light 33:28
Luke Kilpatrick 33:53
it's code agnostic. If it can get to GitHub, it can be used, all we're doing is we're just checking our lines. And we can do a regex on it. We're not reading your code, per se. We're not storing it. It's just it's just, everything's all controlled by this.cm file. And it's a Yamo file that you write. And, yeah, the biggest thing is we're going to be we're adding more and more power to the labels. So like one of the cool things we just added yesterday, how active development is our labels now monitor state, we have stateful labels. So if you go and make changes to your code and resubmit the pull request, the label will change based on that. You know, so there's, there's some cool stuff there. You know, we colored labels, so if you decide, you know, you want to color code, there's a lot of different things we're trying to do to decorate you know, a lot of ways we're taking your pull request and we're decorating it with information and that information helps. How helps a lot
Michaela Light 34:51
very cool. Well, here at Terra Tech, we mostly use Bitbucket so we'll be excited when you come out with it. With that, I think we might have one or two projects that are on GitHub. So maybe we can play with it.
Luke Kilpatrick 35:07
Yeah, can you try it's a, it's a cool piece of text I've been, I've been really excited about it. And it's, it's pretty easy to get up and running. You just install it from the GitHub marketplace. And then you just copy in your GitHub actions file and a.cm file. And you save it, you commit it, and you're ready to rock and roll. It's it's a pretty quick onboarding.
Michaela Light 35:31
You can use this on private repos, or public ones, correct, right? Yep.
Luke Kilpatrick 35:37
Yep. Yeah, it's just it's right now we're set up for GitHub. Cloud that supports GitHub actions.
Michaela Light 35:42
Okay. So another thing on your roadmap, I guess, is people who have on premises GitHub.
Luke Kilpatrick 35:51
Yeah, I, the on prem, GitHub, we mostly it should work. I just haven't, we haven't had someone really test it. You know, as I said, we've only been live for for about a month. And it's been great seeing the usage go up and up and up. As people start to do it. Like, we're, I think this is a problem that almost every developer working in a team has. So I view it as you know, we just need to get people aware of this. And when they get aware of it, then they're going to start to see the power that this can do to make, you know, code change committing just that much faster. And that that's really what it is. It's a it's a tool to help folks get their code into trunk faster, because I don't have a job. I like code that ships and gets out to people. So I can go work on something else. Anything that helps me get my code into production faster. I'm all about?
Michaela Light 36:37
Well, I think that makes sense. Because it's not just wanting to get in into production, it's hard to remember what the heck you did on some code, you know, from seven days ago, let alone if it goes out beyond that. No, yeah. So, you know, I think this is a great aid for having effective code reviews, because otherwise someone reviews the code, you're like, I can't even remember what I wrote there, you know,
Luke Kilpatrick 37:03
exactly, you know, doing your own prs. You know, doing your own reviews. And it's just also, you know, categorizing, I think I just think categorizing the PRS is such a powerful thing. Because, you know, if it comes in as this is, you know, got to reviewers, and it's going to be a high risk area, people are going to pay a lot more attention. There's always a joke, and I say this joke all the time, when I'm speaking, it's like, if I get a 10, line, PR, I'm gonna go through with a fine tooth comb, you're gonna have tabs, not spaces, I'm gonna make sure that it's, you know, everything's right, your camel cased, you're, you're all set, if you give me a 500 line PR looks good to me. Right, Ed, Ed, a lot of people do that, because you're not gonna go spend time to dig through that 500 line PR, but if the small PRs are taken care of, and you now see, when those comes through, that this is a bigger deal, that PR, you're going to spend a little bit more time in the review to make sure that it's done right. And it's doing what the developers said it's going to do, because that's annual, and that keeps your error rate low. It sure changes, you know, it accelerates your amount of change. But it also lowers your rollback, because those code reviewers, those code reviews are of higher quality.
Michaela Light 38:20
I'm looking at the pricing page. And I'm a little confused, because you've got several products that Linear B, you've got a security, product metrics, and all kinds of things. But they're all rolled into this three pro or enterprise version.
Luke Kilpatrick 38:36
Correct? Yeah, yeah, that's basically, that's basically how it works is you've got the free, we've got the free, the free tier, the, which you know, has, has a lot of features a lot of functionality. But of course of all free tiers, it's, you know, you'll want, we want you to upgrade, right? So
Michaela Light 38:56
that's so otherwise you can stay in business and make this cool stuff. Exactly.
Luke Kilpatrick 39:01
So that's, that's, that's what we're trying to do. You know, we're, we're growing. We've got, we've got a large number of users that are really enjoying Linear B, Linear B has been around for four years, five years. And it's had some really great success. So we just closed a $50 million round in early May, just before the VC, the VC winter started. So you know, we're, we've got some nice runway, and we're excited. And there's some there's some really good stuff happening. And git streams, you know, my part of it, and I'm excited to see how it gets used. And I'm always interested in feature requests. What does it do that it would be what should it do for you that it doesn't do now? And you can check out the docs dot Git stream.cm is the main URL to go through the docs to check it out. You know, linear b.io/devs the dev website I I put it into dark mode because, you know, developer pages look different than than leadership and engineering pages in my view. You know, I want I want our site to be for developers by developers.
Michaela Light 40:11
Very cool. Well, thanks so much for explaining this new get to get stream. If folks want to find you online. Luke, what are the best ways to do that? Oh,
Luke Kilpatrick 40:22
probably easiest way. I'm on Twitter at El Kilpatrick. You can email me, Luke at linear b.io. That's probably the fastest and easiest. And I'm happy to hear from from folks. LinkedIn is also good. Luck. Kirkpatrick on LinkedIn. You know, I've been if you're in the CF community, chances are we have one or two people in common because they've been been around that for a while. And it's actually a great opportunity. You know, we found this I'm speaking on Wednesday at SAC interactive, which is Nolan Eric's user group in Sacramento. And, you know, I think it was his posts on LinkedIn that brought me here. So I'm excited. Excited to do that. And it's, it's good to get back into hanging out with this community and bringing something that I think every ColdFusion team, if you're using Git should be using.
Michaela Light 41:20
Cool. All right. Well, thanks so much for coming on the show and great luck with Git stream in the coming year.