Software Delivery in Small Batches

[00:00:00] Hello and welcome. I'm your host Adam Hawkins. In each episode, I present a small batch, with theory and practices behind building a high velocity software organization. Topics include dev ops, lean, software architecture, continuous delivery, and conversations with industry leaders. Now let's begin today's episode.

[00:00:25] Hello again, Adam here for the next episode of Small Batches. Just two quick things. Before I introduce today's guest, first Small Batches has a listener request line call into plus +1 933-833-1912. And leave your request in a voicemail. We're getting down to the end of the interview backlog. So it's time for me to start planning future solo episodes.

[00:00:51] I've received one request for an episode on value streams. So dear listener out there who made that request, Roger, I've lined up some amazing guests to discuss the topic and we'll put together a solo episode just for you. Preference for future episodes goes to listen to requests. So call in, tell me what you want and you'll probably get it.

[00:01:12] Second is the Small Batches listener survey. This is a short five minute survey designed to tell me a bit about you and help drive the narrative thread on the podcast. Find the link in the show notes.

[00:01:25] Now onto today's guest, today I'm speaking with Keith Pitt. He is the founder of buildkite.com. Buildkite is a platform for running fast, secure, and scalable deployment pipelines on your own infrastructure.

[00:01:40] It is by far and hands down, my favorite tool for the job. It's rare in my experience to find software that just works well and stays out of your way like Buildkite does. Now, this episode is not the pitch for buildkite, but believe me, I am not shy about proclaiming my love for it. In our conversation. I invited Keith on the show to discuss continuous delivery inside a software company, building continuous delivery tools.

[00:02:05] I thought it would be a nice look behind the curtain in a way to see how they approach a building these tools. Now, I got to say that I was smiling ear to ear during the conversation. First because frankly, I admire Keith. He built, builtkite from the ground up into a successful business. That's now his full-time focus.

[00:02:23] That's no small effort and it should be commended. And a little sidebar there, he actually pitched bill kite to me, probably six or so years ago at a rails conference speakers dinner. I think I said something along the lines of, I don't think that's gonna work well, the jokes on me because it worked and it's fantastic.

[00:02:44] The other reason is because I just assumed that the engineering team was following continuous delivery. Oh no, it's even better. They're following continuous deployment. So dear listener, if you need a north star to guide you in your software delivery journey than just listen to Keith. Their engineering practices at buildkite are top-notch.

[00:03:06] So if they can do it, then you can too. Now I have one final request for you, before we get into the episode. This was Keith's first ever podcast appearance. So if you enjoy our conversation and want to hear more from Keith, then tweet him and let him know now here's my conversation with Keith Pitt.

[00:03:30] Adam Hawkins: Keith welcome to the show.

[00:03:32] Keith Pitt: Thanks. Thanks for having me.

[00:03:33] Adam Hawkins: I'm sure my pleasure. I'm so happy to talk to you today. So I already gave a bit of introduction to you and what you do, but why don't you give listeners a little bit background on bill kite and how the company started and what you do with the company.

[00:03:50] Keith Pitt: Hi everybody. I'm Keith, I'm the CTO and co-founder of Buildkite. If you haven't heard of Buildkite is a CICB platform, but it's, it's a little bit different than some of the CICT platforms you probably used to. We have something called we have a hybrid approach to CICD. So instead of handing over all your source code to some third party to happen test it, Buildkite kind of keeps it in-house for you. So you're on these things called agents on servers that you control and Buildkite is the orchestration piece in CICD. So we take your code and we run it on servers that you control and report back the results, which is probably a little bit different than some of the CICD tools that you may have played with in the past.

[00:04:29] Keith Pitt: So that's the product the business itself has been going around for seven years now, seven plus. years we have around 30, 30 staff and we've just raised, we've just finished our first raise. we did a an angel investment in the very, very, very beginning, but we just did our first series a where we raised $28 million dollars. the company is valued at $200 million. And so that's been a bit of a wild ride that we've finished up now. And now we can kind of get back to get back to business.

[00:04:58] Adam Hawkins: Hmm. Well, great. So, you know, part of the reason why I wanted to have you on the show was to get the perspective of somebody inside a business, building tools for CEI and CD. Now that's pretty much about all this stuff. I talk about on the podcast. So, you know, you mentioned buildkite is about the size of like 30 people. So let's start to kind of working through what the internal workflows are for deploys. So like, let's say that hypothetically, I'm an, I'm a new person at buildkite. I made my first commit and I want to take this commit or deployed as commit to production. Can you walk me through that process?

[00:05:37] Keith Pitt: Yeah, we'll do so. So buildkite has been practicing continuous deployment since I think commit three or four. I had been So I still remember basically running. Seven years ago, running rails, new Nash dash database Postgres. Nash dash skip the test unit and whatever the command line arguments were, you know, and then get, add, get commit, initial commit, bum that done that.

[00:06:02] Keith Pitt: And then the next step was. Setting up continuous deployment. that was my next step because I, it didn't really feel real until it was on production. And so if that's the first thing I did was build continuous deployment into it. And so that was kind of step one for buildkite, which is interesting because it was a Roach and an egg problem that I had was I was trying to write a CGI tool, a SED tool that needed to deploy itself.

[00:06:25] Keith Pitt: And so. I actually can't remember how I solved that, to be honest, but I did something and I remember I had the buildkite, but back then it was called build, build box, but it was, and I had to, we had to change the name. It was a whole story there, but, yeah, so we had continuous deployment from day one, which meant that when I'd make a change, it could go to production straight away.

[00:06:49] Keith Pitt: There was no tests though. There was no tests at that point, tests would come much lighter and buildkite history because I was. The time I was sort of optimizing my workflow was optimizing just for the building of it. And and because it was just me, I could kind of hold the context of all of the, kind of my head at once.

[00:07:06] Keith Pitt: And it was only two or three models as well. So that kind of really. helped. And so We've been doing continuous deployment for, for seven years now. And honestly, it hasn't really evolved all that much. Believe it or not.

[00:07:16] Adam Hawkins: That's, awesome. that's amazing though, like that, just like I hate to interrupt, but it's sort of comes to the, one of the themes that's actually been coming up a little bit on the podcast is the idea of starting to work, sort of, if you start working that way really early on.

[00:07:33] Adam Hawkins: It's hard to stop, right? If you get those practices in place early, you can never go back because of how important and how powerful they are. Like you said, You started working that way to optimize for your development, like how quickly you can, how quickly you can iterate your flow of change, you know, as you're bloating a product that is actually the most important thing that matters.

[00:07:52] Adam Hawkins: That's definitely. That's the only thing that matters. Right? And Now seven years later, it's still there. It's still working and I bet you, you can't imagine working any other way.

[00:08:02] Keith Pitt: No, absolutely not And, and so the wet flight, So if we skip ahead seven years, I'll give you an idea of how it works today. So a developer at Buildkite is making a change.

[00:08:12] Keith Pitt: They push it up as a poor quest to get help when they create that pull request that will trigger a build. in buildkite. Now what happens next is buildkite take that commit and we will run the tests. It's like, okay, here's this aspect we have around, I think, 10,000 tests, automated tests at buildkite, mostly made up of. Model and integration tests.

[00:08:39] Keith Pitt: And then, all those things run and it takes around five minutes for that process to happen. So we take the aspect test and distribute them across 50 or so agents, we can get the speed that we want at the end of that process.

[00:08:51] Keith Pitt: If it's all good, it'll send back a big green tick to get hub and say, Hey, this poor quest is ready to go. That pull request is then reviewed by peers at buildkite. Then then the merge button becomes in essence the deploy button, because merging a pull request that buildkite will trigger a master build. I build up the master branch, which then would it be deployed when that goes green? And so the process kicks off again, runs all the tests again on the master branch runs all the linting and then before that screen and would trigger. a Deploy. out of the deployed parts is, is still very, very basic. I think people would be surprised to learn how basic outer play process it's still a staging into machines. Get fetching, get checking out and restarting humans.

[00:09:39] Adam Hawkins: That's amazing. I love that so much actually, because, I had another conversation with somebody and we were talking about. like, He was a rails developer and was talking about like, Hey, should I do Docker?

[00:09:50] Adam Hawkins: And do all this stuff. The point of this thing is that you don't need all this like fancy stuff, like Docker and Kubernetes, you can build a really successful business, build a product, just SSH into machine and restart the web server. Like, so you don't need all of the other stuff on top of that, right? Like there's of course motivating factors, but you know, like if it's working, you don't why change?

[00:10:15] Keith Pitt: Yeah. And so that's kind of been our approach for, for a long time now. note that there is a bunch of stuff. that Other tools can give you, which would make it much nice. I'm not trying to put down Docker and Kubenetes or anything like that, but for us, it just, it means that deploys can be super quick. So we use, so we don't use Capistrano, but Capistrano uses a tool called SSH.

[00:10:37] Keith Pitt: kit. and that's what we use. We use SSH kit directly. And and if we have just a small Ruby code change, we needed to put a production, deploy takes only a few minutes or less, and that's still deploying to a couple of hundred servers in production and it's worked out really, really well for us. What else do want to say about it? Lost my train of thought then. Hmm.

[00:10:54] Keith Pitt: Let's say you were talking about the like the capacity to roll that changes quickly. Like if it's working, you know, maybe nothing, nothing to say. Yeah, so that's what I was gonna say. We don't have a extremely sophisticated rollback system either. What we do is we usually roll forward. But, for the most part. When you start for the longest time, I've,always thought as automated testing as being part of the deploy process.

[00:11:09] Adam Hawkins: Hmm. what do you mean?

[00:11:11] Keith Pitt: So, so people think of those two different phases to shipping software. There's the testing and the deploying. I only think of. it as deploying. Yeah. Testing is part of deploy.

[00:11:22] Adam Hawkins: Exactly. I mean, that's in line with the continuous delivery pipeline model.

[00:11:26] Keith Pitt: That's right. Yeah. Yeah. So when you start thinking about it like that, then it changes how you think about A lot of things, for example, you don't want a six hour deploy. You want a 10 minute deploy. You want a five minute deploy, so your tests have to be fast.

[00:11:39] Keith Pitt: So you have to kind of solve the fast testing problem. So that's really important to solve the other part of it that I think the continuous deployment. makes for really awesome coding is that when you're an engineer, buildkite Every line of code you write could be in production in five minutes.

[00:11:55] Adam Hawkins: Congratulations. That's great. I mean, that's kind of the holy grail that we're trying to get to by all of this stuff that we're talking about here.

[00:12:02] Keith Pitt: Yeah. But that doesn't come like that can be quite scary. Like that's a scary thing. The fact that my, this, I could write, use a dot delete all in, in some code and have that run on production very, very quickly.

[00:12:14] Adam Hawkins: So there's a lot of, you have to try and mitigate that mitigate risk, for each deploy, and there's lots of different ways. to do that. Yeah, there's actually great segue probably into the next bit of the process so we've covered a, you're doing continuous delivery. That's amazing to have, especially start a spark from that and continue that practice for so long.

[00:12:32] Adam Hawkins: You have a really short lead time from opening PR to get into production. Probably. under, Was it under like 10 minutes or 15 minutes? I mean I think all indicators point to great. So no, so far. So then you said that continuous delivery is scary or this like, given that you could get into production so fast That's scary. My fear is that it's the other way around where if it's taking too long, I'm scared of that. Right? So like that five minute thing that you're talking about, like, Hey, that's the, that's the normal thing. So, but you can only get there and feel safe if you have sufficient, to. Hey, automated testing and then be sort of like risk mitigation practices, like, blue-green deploys or canaries, or like these types of things, as you said, risk mitigation. So what risk mitigation strategies does Buildkite use for deploys?

[00:13:26] Keith Pitt: So, so what about, a testing number one, number two, everything that we build is behind a feature flag, Hmm, everything that we build. So we, we rely heavy, heavy use of feature flags. our feature flag system is incredibly basic. We don't have a fancy feature flag system We build feature flags in one of three ways. if we're building a new page, We just went linked to the page. It'll be a URL. If you know the magic URL to get somewhere, then you, you, you can find a secret pot of buildkite. If you've ever contacted Buildkite support before chances are that you've been given a secret URL because there's a lot of functionality in buildkite that many people don't know about because we're building it.

[00:14:06] Keith Pitt: And we like to give people access to it sooner. So we give them, here's a secret URL for you to try and play with and just to solve your problem. I like that we spent linked to it from anywhere. And then the last thing we do is just put a link on the page. and then. There you go. We've shipped a thing. That's feature flag number one, feature flag.

[00:14:21] Keith Pitt: Number two is sometimes for more complex things. We might column in the database to turn the functionality on and off. And and if we need to turn it on for customer, we might just go to the production console and flip it. Or we might, Or we use a red, a space system. There's a gym called a rollout that we've been using for five years and within the gem has changed that much, but it doesn't really need to change It's it's very basic. So so everything we do, everything we build is behind a feature. flag. Even, even, you know, even internal, Even when we're making changes to the internal state machine handler for a build, we will often put that behind a feature flag and test it for ourselves first. See what happens, everything. Okay. We might turn it on for another customer, another customer, then we will manually gradually roll out the change the way this mitigates the risk is that the code that we're adding generally is not being used by customers straight away.

[00:15:09] Keith Pitt: They're these sort of no object deploys where We deploy some credit production and nothing should change. There should be no visual changes. There should be no functional changes for customers until we decide to turn it on. We also, we don't have a staging environment, which is something that, has, which is good and bad but I think that the reason I don't have a staging environment is because. we It's practically impossible to have your staging environment equal production. It's basically impossible and that's because of a different shaped data in the database. Builkite has done a base is in the tens of terabytes.

[00:15:49] Keith Pitt: So there's really no way that we can have. a copy of that data somewhere, especially if you want to have it. All the secret. Especially with that data to be anonymized. we couldn't really have that. and also the, the traffic profile of staging of state department is very different to production environment Builtkite runs around a million requests, per minute. So it'd be quite difficult to replicate that in a staging environment. So we don't have that. We've but the only time that. we've, I mean, we don't have a Canary deploy system, But that has bitten us multiple times. So I think actually this week we are going to start looking into implementing a Canary deploy system and the Canary deploy system will be, we deploy to a server, make sure that's healthy and then roll that change out to the rest.

[00:16:36] Keith Pitt: And that'll that'll look, that'll solve. That'll look for problems where, There is a bug in configuration or, you know, there's a, there's a syntax error or something that just happened not be cold by an automated. test. Oh yeah, I've been there. I did a whole episode on it called preflight checks is you'd be surprised.

[00:16:53] Adam Hawkins: So for the listener that gives a bit of insight information here is that, Keith is talking about, I believe like sort of the backend or the web application part of buildkite, which I guessing is a Ruby app or a Ruby on rails. app, Right.

[00:17:09] Keith Pitt: Yeah, I probably should explain how, what builkite is. I completely completely forgot to mention that. Thank you. Buildkite is a rebound Rouse monolith. And so we've been a monolith for a while now. we have, depending on your categories, categorization of microservice, I would say we have. two microservices in production. One is a proxy that all web books go through. Basically, if you've ever built a here's a little pro tip for listeners.

[00:17:37] Keith Pitt: If you have a system that sends out web hooks, you want to make sure that those workbooks can't be sent to 1 to 7.00 to 1. Or whatever the easy magic URL is, which is 1, 69... You want to make sure that your machine's constant to that, and you also want to make sure that people would just constant of DNS entries that point to those things.

[00:17:57] Keith Pitt: So we send all web pokes out through this proxy that will sort of resolve the DNS entry and make sure that it's not, in, it's an allowed list of IP addresses. but that's one service that we have in production. And The one is the, we run Qamar from GitHub, which then turns HTP euros into HTTPS heroes. So those are the only two services that we have in production.

[00:18:25] Keith Pitt: And we have the Rouse. monolith But we treat the monolith differently in production, depending on the domain. So agent.buildkite.com is still the monolith api.builkite.com is still the monolith, but we have different duplicate users, easy too. and we have different auto scaling groups depending on. domain.

[00:18:40] Adam Hawkins: Yeah, different different processes. Like if you take the 12 factor out model, you have one code base, but different processes, you can run them in different scales, different vertical skills, horizontal skills, So you got one big monolith doing, all this stuff. And so then to bring it back to the canaries and like the risk mitigation, I mentioned, you mentioned, doing the Canary to catch like a syntax error, some configure.

[00:19:04] Adam Hawkins: So for the listener, you know, I did this episode on preflight checks specifically about. this, This exact problem, because I also, as a Ruby developer hit the exact same problem of, oh, you had some code that wasn't actually evaluated until you got to production because, Hey, it's a dynamic language. There might be some if statement or some conditional thing play to some environments, some new CoPath is executed for the very first time ever.

[00:19:26] Adam Hawkins: And then it explodes naturally. don't want it to explode. And then it like impact the user, So then you do stuff like canaries or preflight checks is a way to like mitigate that.

[00:19:35] Adam Hawkins: So starting with canaries... Yeah. So we're going to be probably adding one of those very soon. And it's the catch that the biggest problem we've had in building history is, is Webpack related build issues.

[00:19:45] Keith Pitt: You know, you will, you will deploy to production. And then somehow we're packing decides to include date dot JS six or seven times. And you don't know until production hits and, and then all of a sudden pages don't load and so it'll hopefully catch those classes of problems.

[00:20:02] Adam Hawkins: Yes. That's the, hope, right? But that's the, what actually, I'm really enjoying hearing this sort of origin story of the pipeline here, because it speaks to the, kind of the intent of not adding things until you actually have a problem. This is something that I tried to convey to other people I talked to and for the listeners also is that The most like the most important tests to add are the most important like adjustments to make are things that actually mitigate, known regressions that have actually, you know, that have happened to you.If you have a regression, you can write a test or change your workflow in such a way that that regression is never introduced. Again, but you have to actually do it. with, you know, with intent and you don't, you can do that with any technology. You know, you don't need to have some, you know, fancy microservices and blah, blah, blah.

[00:20:49] Adam Hawkins: You can do that with like simple VMs and you know, like basic stuff, but you have to start you have to start with that frame of mind. And like that's the vibe. That I'm getting from sort of the software architecture and the delivery process at bill Kay. Let's just really, really good to see. And And also for the listener, like when Keith has been talking, I've been smiling and grinning and nodding along to stay here, how it's all working, because as you know, this is sort of the, kind of the peak that we're we're trying to get to. When we talk about software delivery performance, you know, Keith mentioned the lead time, how fast they go from commit to production, there, the ability to innovate, iterate quickly doing continuous deployment. Like these are all really, really important and impactful things that definitely changed the way engineers work and ultimately create business success too.

[00:21:40] Adam Hawkins: I mean, and you're talking about feature flags. that's part of. like, I think one mistake or like sort of fallacy that people fall into is they hear stuff like continuous delivery or continuous deployment and they think, well, yeah, I'll just start deploying to production every day, but sure. If you have A, B and C, you need this and you need this and, you don't work in such a way.

[00:22:02] Adam Hawkins: Right. And you were. talking about Okay. We don't have staging, you know, there's a lot of people who are probably thinking like, oh my God, how could I, how could you ever do that? But if you have feature flags, we have canaries, you have automated tests, then you can go straight to production and not have any fear.

[00:22:19] Adam Hawkins: Like if you have fear, then you need to change your process. You need to improve your process because you can't work in a fearful. environment.

[00:22:25] Keith Pitt: Yeah, totally. And that's why, you know, I think at some point you have to kind of trust your tools. You have to trust your tests. If you don't trust your tests then why you're writing them in the first place we trust our tasks. You know, if, if the tests say, yes, this is a good change. This can go out. Then we listen and we say, okay, we're going to trust the tests. Don't let us down. if you're lying to us, we'll delete you. And so that's kind of how we approached it and and we've been pretty pragmatic about it. You know, we make changes when we need to.

[00:22:57] Keith Pitt: We, we try to learn from our mistakes by doing, you know, internal incident reports. and then we, if you've seen our status page we've, with kind of very transparent, No incident reports. We try to, we were as open as possible into the sort of the whole stack of issues we've had. And, And we learned as well, you know, and, and we, keep it very simple and that comes a lot of price, but there's also a lot of cons with that.

[00:23:21] Keith Pitt: but we try to fix the cons where we can. what kind of cons do you think? Obviously it's it's what are the cons. I'd be good at this bit doubt.

[00:23:23] Adam Hawkins: Oh yeah, for sure. Just to maybe prime the pump a little bit like cons, like, Cause when you said cons, like, what I started thinking about was this might be a hard thing for new people to grok. Like if new, new insurance, joined the team was like, Hey, you're doing this as sort of like, kind of out there in a way, because like, from my perspective, I honestly, I don't see any cons.

[00:23:42] Adam Hawkins: I can't think of any other than like, it might be off putting to some people, at least that was, that's kind of my takeaway.

[00:23:50] Keith Pitt: Yeah, I would say the biggest con is just, you have to be a bit, a little bit brave. You have to be confident in your tests you know? and you have to, you know, I find that it changes how I program quite significantly.

[00:24:03] Keith Pitt: I am, I tend to be a much more defensive programme. I, I tend to rescue a lot more than I used to in, if I'm running some code, I'm thinking, Hmm, what happens here? If this breaks what's going to happen to production. So when you're using a combination of feature flags, you have to kind of rescue a lot more code, and then, you know, you can wrap that up in different tools like scientists to make sure that The changes that you're making to production, aren't going to break on you. And if they do break on you, at least, you know about it.

[00:24:33] Keith Pitt: Yeah. one of the best feelings in the world, well, I wouldn't say best feelings, but you know, the system is working when you push to production and then your exception track it goes crazy. But no customers know the difference. No, no one knows. that something has happened. It's because you pushed a change and you think, okay, well, the system is working. I know that change. Wasn't good. Let's we went, we don't we generally don't roll back on buildkite, we generally just roll forward? So if we've got a bit of time, we might just we'll either do a revert commit and get home and revert back to the pull request. Or we will just maybe just fix it really, really quickly push to change that to production.

[00:25:10] Keith Pitt: Yeah. Okay. So I want to ask you one question. Now we ae running out of time, but to get some insight into the future sort of internal structure, and like you said, you mentioned, you mentioned your razors series, got some money. This is going well, likely going to try to grow the business, maybe hire some more people. So what are your initial thoughts on in adding more engineers and how does that relate to like team structure and the way that, you work? Right. now?

[00:25:42] Keith Pitt: Yeah. So people would be surprised to learn that this is the first time that we've we've taken on money. And this is seven years into the journey. We took a very small seed round in the beginning. And that was mostly just to cover our wages, Tim, my business partner, at Tim's and our wages for the first two years.

[00:26:01] Keith Pitt: A little story that I have is that we, once a year, we try to go to San Francisco cause, I'm Australian and I'm based out of Perth, Australia. And once a year we try to fly to San Francisco because that's where a lot of our customers are. And, And we met with a customer there and we sat down at the table, you know, there was like, A lot of very, very smart people in this room. And they all said, buildkite is the best tool that we've, we've, we've found, but we've not heard of you. And that's a bit of a problem. Who are you? What's going on? This, this is all a bit too scary. This is just some sort of scam or something. No, no, no, no, we're real. We're real. And we kept hearing this quite a lot, you know? so. Which has kind of rubbish at marketing, honestly.

[00:26:46] Keith Pitt: I think that may be a little bit of, I think Australians tend to be very humble and I think that maybe our humbleness has become part of the product a little bit, but the, the raise that we've just done mostly go to sales, marketing, and really supporting those functions of the business.

[00:27:05] Keith Pitt: Really helping tell the story of buildkite of a little bit more, in terms of engineering head count, we don't know who will have any. But everyone agree that at the moment we think we can kind of do more with less. We don't have big dreams of being a significantly large company. Cause buildkite been profitable since almost day one as well. Amazing. Yeah. I remember when we came out of beta. I had a credit card form. And that was how I could get traction early on is by telling people, Hey, if you like, Buildkite, please pay for it?

[00:27:37] Keith Pitt: And we've been, we've been growing off profits for seven years and it's only now we're thinking, okay, well, This of people not knowing us, how do we solve it? And this particular problem with the right solution was a capital raise. Hmm. And so we, the aim is to take the money and just continue to build a sustainable business and and grow at the rate that we want to grow. Because we know that when you grow too quick, a bunch of problems can happen, especially when you hire a bunch people, Because one thing I've learned is that when you hire one new person, it's a whole new team it seems very obvious when you say it out loud, but as soon as something that I really internalized before odd people, and so we don't have any grand intentions of, of, going, going great, but we, we are going to use the money into kind of building what's next for buildkite. and we're kind of excited for what's next. If you think about what CIC is today as being maybe only 10% of what it could be and what could it be? What is the other 90% of CICD? I don't think any tool has really explored that idea yet, but I think we've got a real good idea what that is.

[00:28:44] Keith Pitt: So Which this space. We're very excited to see what's next.

[00:28:47] Adam Hawkins: What a great way to end the conversation. I think we'll have to check in in a year and see how you're doing. If the company's grown And, you know, if you're still doing continuous deployment.

[00:28:58] Adam Hawkins: I have no doubt we'll be doing it.

[00:29:03] Keith Pitt: You know, how your canaries work and just how, you know, how's it going as you're growing.

[00:29:07] Adam Hawkins: I think these are the really, really interesting stories to hear from people on the inside of these organizations. Like how, how does software get built in the real world? And was it like.

[00:29:19] Adam Hawkins: Well, Keith, thank you so much for coming on the show. It's been so much fun to talk to you. I wish I had more time to just kind of shoot, just talk all this stuff through with you. It's been so much fun and, you know, for the listener I've been grinning and having just such a good time, hearing all the things that he's talking about, No, I love buildkite. It's a great product and I'm even happier to hear that they are Working so well internally and probably having fun doing it. that's just, what more could you ask for really?

[00:29:50] Keith Pitt: Yeah, thanks. Thanks for having me on the show.

[00:29:52] Adam Hawkins: So is there anything you'd like to leave listeners with before we call it a day?

[00:29:56] Keith Pitt: Yeah, so I would encourage people to go check out buildkite. I think that probably settle for the tool that you've got. There are better tools out there for the job.

[00:30:04] Keith Pitt: And I think that buildkite is that tool, you should check it out. So if you want it to like to know more, just go to buildkite.com.

[00:30:09] Adam Hawkins: Yeah. And I can say with confidence that I know buildkite is the right tool for the job. Like if you're unhappy with the tool that you're using, or you're curious, like just try buildkite, it's great. It gets out of your way and allows you to solve your problems. Like if you know what you're doing, buildkite is fantastic. You'll not find a better tool than buildkite. Like I use it. I love it. You've already heard me say that. Just try it. You'll like it. It's amazing.

[00:30:33] Adam Hawkins: So Keith, thank you so much for coming on the show and talk to you next time.

[00:30:37] Keith Pitt: Hopefully. Thanks Adam. See you later.

[00:30:40] Adam Hawkins: That wraps up, this batch, visit smallbatches.fm for the show notes. Also find Small Batches FM on Twitter and leave your comments in the thread for this episode. More importantly, subscribe to this podcast for more episodes, just like this one. If you enjoy this episode, then tweet it or post it to your team slack or rate this show on iTunes.

[00:31:01] Adam Hawkins: It all supports the show and helps me. It's more Small Batches. Well, I hope to have you back again for the next episode. So until then, happy shipping.

[00:31:10] Adam Hawkins: Are you feeling stuck, trying to level up your skills deploying software? Then apply for my software delivery dojo. My dojo is a four week program designed to level up your skills, building, deploying and operating production system. Each week participants will go through a theoretical and practical exercises led by me designed to hone the skills needed for continuous delivery.

[00:31:36] Adam Hawkins: I'm offering this dojo at an amazingly affordable price to small batches. Listeners spots are limited. So apply now at softwaredeliverydojo.com.

[00:31:49] Adam Hawkins: Like the sound of Small Batches? This episode was produced by pods worth media. That's podsworth.com.