.jpg)
DevXPod
DevXPod
Fixing the CI/CD experience with Vlad A. Ionescu
We're your hosts (Christian Weichel and Pauline Narvas) 👋
In today's episode, we're joined by Vlad A. Ionescu, CEO of Earthly where we talk about improving CI/CD experience.
The hosts â–»
- Christian Weichel, Chief Technology Officer at Gitpod
- Pauline Narvas, Senior Community Engineer at Gitpod
Our guest â–»
Things mentioned â–»
Let's chat some more! â–»
You can improve the developer experience a lot by using containers and being closer to production that way. The CIC D system hasn't really taken advantage of those things as much. So if you look at some of the CI that have embraced containers, they've used them as more like the platform in which the builds run or where integration tests execute, but they haven't used it to replicate that environment on your computer. I think that's something that the industry has missed out so far.
Chris:Welcome You're listening to the DevX podcast. The show where product and engineering leaders share their thoughts and insights on developer experience I'm Christian Weichel joined by my cohost Pauline Narvas.
Pauline:Hi, Vlad. Thank you so much for joining us for today's DevX podcast episode. We're really excited to have you. So for those who don't know about you and about Earthly, could you give us a bit of a quick introduction on yourself and the problem Earthly solves?
Vlad:Yeah, absolutely. Thanks for having me Pauline and Chris! Just a few words about myself. I'm the founder and CEO of Earthly technologies. Before Earthly, I was also the founder of shift left and a head of engineering over there. And I'm also at the ex-Google, ex-VMWare Engineer. I've also worked on Rabbit MQ in its early days, before it was acquired by VMware. Lots of fun times over there, but yeah throughout my career I looked at builds through the lens of a software engineer and I always found them really complicated and difficult. And I've always measured that to whether the engineering productivity is great or not. Whether the tooling was great, the engineering product productivity sort of matched that. You know, starting out in the early days of my career, at some point at Google, I realized Google has like a really amazing internal infrastructure. And a lot of the developer tooling over there was just fantastic. I just saw how productive the engineering team can be in that environment. And that sort of inspired some of the ideas that went into Earthly as well. Of course Google open-sourced some of that technology is basil outside of Google, but it just didn't fit the requirements of the world that we live in outside of Google, which is far more fragmented. And you know, far more varied in the types of tools that people use. And so basil didn't really fit that model really well because you have to adapt every single technology to match it. So through Earthly, I wanted to bring some of that magic that I've experienced at Google to everyone else without the drawbacks of basil. So, you know, basil is incredibly difficult to adopt, whereas firstly is incredibly easy to adopt. And what Earthy is in a nutshell is basically a framework for building CI/CD pipelines that executes anywhere. So you can run it on top of GitLab, top of a CircleCI, on top of GitHub actions or what have you, Jenkins and so on. But crucially, it also runs on your laptop. And this is something that surprisingly like nobody really supports that well. Like being able to run your pipelines locally, to iterate on them and test them. And so on is just such a tremendous productivity boost. This is the number one reason people come to Earthly today.
Chris:I can totally relate. I remember debugging trying to debug say a Jenkins pipeline. I've had better days. Like it's not something I would go and choose to do on a Saturday.
Vlad:I've heard people asking an audience at a conference like "who here uses Jenkins?" And the whole room would be like, you know, hands up and who here loves Jenkins and like nobody else, you know, like it's such a such you know, such a love and hate relationship, I guess, with Jenkins, your very first to use it in many occasions, the world needs better tools.
Chris:We already spoke about the debug ability that's not great with yesterday's build pipelines. What are the problems do they have that we should be solving?
Vlad:Well, I think debugibility and maintenance is maybe the core one. I think the biggest blocker right now for us as an industry. Like you can imagine the traditional CR we've gotten used to this, but it's crazy that we have because you work on a CI/CD pipeline that maybe takes, I don't know, 27 minutes to complete, and then it fails a minute 18, and then you go and change something. You do commit, get commit, try again. And then, you submit another change and wait again for a minute 18 to yet again, fail in, in a different. And then do that over and over again. And it's just crazy that CI has to start from zero every single time, you know, and that's one of them. And just the fact that you cannot execute the locally is yet another sort of user experience problem that I feel should be more geared towards developers the way we consume CIs. So CIs, as many people know they're consumed through a UI interface in the browser. Typically yet most engineers just work in their terminal or their IDE. And those two worlds are very disconnected today. You have one environment locally, which uses build systems and scripts and make files and things like that to run the application and test it and so on and a completely different script in CI, typically yaml based. Or if you come from Jenkins, it's groovy based and nobody knows groovy. And this experience of having these two worlds very disconnected from each other, I feel like it's a very significant pain point. That somehow we've gotten used to as an industry. And I feel like we can unlock so much more productivity if we make that better for people.
Chris:Could not agree more like we saw some of the problems we already also came from Jenkins. And other than performance problems and our build at the time was a set of bash scripts, linking yarn builds together. Then we throw it in some, go in the mix and I'm pretty sure you heard that story many times. Well, we ended up doing at the time. Earthly unfortunately was not yet around. so we ended up rolling a sort of meta build system that basically produces a bunch of shells commands and executes them. But heavily does caching. So there, we basically solve that hey, you know, it fails a build one 18, uh, a minute, one 18. If it fails, it's going to pick up essentially where it left off and then the interaction with. The CI system where you would end up on a UI and you're very disconnected. You're taken out of your flow. It's not a terminal that you can do. We solve with a CLI two, two CI system, which brings me to, to the point that the one thing that, that CI systems do pretty well. Especially for sort of larger pipelines is they offer you a structured output of what's happening. It's not just one long blob of texts, but you get more, more structured that makes it easier to browse.
Vlad:Yeah. And I feel like even that structured output is not structured enough because the typical CI/CD flow is basically a series of commands that you put in a yaml file and the system just runs them one at a time. And it's very linear in structure. And if you ever want to do more parallelism, you have to big that. Then you have to design the script to follow. And as we know, because it just, these scripts are difficult to debug and you know, work with people, avoid that as much as possible. They leave that for us as late as possible, because it's such a painful experience. And I've heard this request from many engineering teams told in the words of, you know, when my build goes slow, I wish I didn't have to throw engineers at the problem. And I wish I could just throw more machines at the problem and. I feel that would be like such a fantastic capability if we could do that. And in terms of structured output, I think for what we're thinking is a lot of the times these CI/CD pipelines are geared towards outputs that are useful somewhere else, like in staging or production. There are these intermediate outputs that end up eventually in production. On the local side when you work as a developer in your local dev test cycle, there are a few more intermediate outputs that you care about more. So things like I don't know, a dump of your little database that you have on your computer, or maybe the outputs of your update script that updated your dependencies or I dunno linting output and so on. Like things you do more typically in smaller chunks those are sort of mixed up in a typical CI/CD script. And I think there's an opportunity there for a tool to come in and understand your script in a deeper fashion that exposes that, then it gives you even more structure. And in fact, this is one of the things that we're going to do at some point ourselves just enable that more advanced structure, more fine-grained understanding of your build and exposing that into the output and to some extent we do that today in the terminal, but we want to take that into a future experience that we're going to have in the cloud as well.
Chris:Awesome. That sounds really great! Can't wait to see that actually. So pulling this one step back to the build systems, and today I learned Earthly is a CI/CD pipeline system, not just an air quotes of built system. Talking about build systems though, like you mentioned basil and at Google, I believe it's called blaze. There is a many clones of it. What do you think they got right? And what didn't they?
Vlad:I think what they got, right especially in an environment of a big company, was to create a standard within the company as to how builds should be. So, if you're on an engineer in one department, you could just easily look at the code and build of another team in a completely different department and really immediately understand what's going on in there. So that, that level of, you know, standardization was really important and really crucial. And for many of these very high tech sort of tech giants that have invested a lot in their internal infrastructure. The developer experience of these tools was geared just so much for that internal workflow that they have. And they were able to retreat in tight loops to make it just perfect and I think that was key for it to be a successful internal project. And I feel like it's probably one of the most advanced systems on planet earth, you know, in, in the way that the things that you've achieved, like it did something, it, you know, blaze internally at Google does amazing things like using the power of the clouds to compile some of your code or using the cash of your colleagues or things like that, which are a bit alien for us outside of Google. And the fact that it was so interconnected with a developer experience of the typical workflow that engineers have meant that they would consume that through a terminal most of the times, and it just felt like the local experience on their laptop. It didn't actually feel like it was actually happening somewhere else in the cloud. And many engineers didn't even realize that like I've known some more junior engineers that just didn't know that behind the scenes, he was doing all this magic, doing the hard stuff in the cloud for you. And you would give you a result really fast. They just thought it was all on their computer. And those are just magical experiences that really enable cross collaboration, the idea of standardization of the build tooling across the company and bringing down collaboration barriers. And I think those are just amazing things to have. Besides all the productivity that you gained from fast builds and so on. Coming outside of these companies like Google and Facebook and so on, the authors of basil and in Brazil that AWS and a bunch of other tools, like some of these tools that were open source like basil just didn't quite fit the model outside of Google. It's not that they got it wrong because their original requirement was to make it work really well at Google. And I felt like, you know, from that perspective, they absolutely knocked it out of the park. But outside of Google, it's a big ask to have to require someone to replace their tool chain, their compiler tool chain, and a bunch of tools that they've used for a decade. And. You can, of course make a case in a big company to do those things because you want more governance and control of where those tools and it's better for it to be standardized. You can make those trade-offs to the big company within your organization, but outside of that big company, the world is just far more diverse. You just cannot keep up. I feel like that's the biggest problem with a tool like basil for everyone else. It feels very alien. Because it forces you to replace all your scripts and all your compiler tools and so on. That's a big ask. It's hard to go in another organization and tell them, Hey, by the way, you have to replace everything now to take advantage of this and you can really do it in steps. You kind of have to go all in on this and we promise you it's going to be great, but like you have to bite the bullet and do this really complicated thinking advance and it's a big ask.
Chris:It is. We really try to adapt basil at one point because we wanted the caching standardization and a team of 15 is not a topic, but we really carefully. And just messing with our Go mod and turning that into Starlog was not in the cards. Like it does feel strange if you're not used to the system.
Vlad:Exactly and go is a Google language. Right. And in many ways they've borrowed a few concepts from basil you know, here and there, but yeah, it's still, even for that, it's still alien.
Pauline:So just like taking a step back I'd love to hear like your thoughts on how you think containers help us improve developer experience, especially when it comes to building software.
Vlad:Yeah. So containers is this magical thing that allows you to pack stuff in. And it'll work in production in many ways, very similarly to how it works on your computer. It's not perfect. You can never replicate production on your computer, but it allows that dev to prod parity to some extent, and that lot unlocked, just a huge potential for our industry. Things like works on my machine. You can improve the developer experience a lot by using containers and being closer to production that way. And so for many companies, this has meant that the platforms team that manages production and dev ops and so on, they can just take a container and throw it in production without necessarily looking what's inside of it. And that is key improvement for our industry, the developer on the younger side, the application developer, they have the capability of putting anything in the container, having full freedom within that little sandbox and being pretty confident that when they put it in production within the constraints it'll work the same way. And that's great for dev and prod parody. But the CIC D system hasn't really taken advantage of those things as much. So if you look at some of the CI that have embraced containers, they've used them as more like the platform in which the build's run or where integration tests execute, but they haven't used it to replicate that environment on your computer. And I feel like that's such an amazing feature to have, and they've sort of missed out on that opportunity that it's again like a tremendous productivity boost, the same way, you know, development and production got closer to containers. I think there's a case to be made for development, and CI to be closer together and have a tighter feedback loop on everything that you build and execute in that manner. I think that's something that the industry has missed out so far.
Chris:I have to apologize to our audience because this is one of the podcasts where we just agree on things. Totally agree with that too. We have a similar take on this within Gitpod to where the user land that you use as you develop. You'll also want to use that in other times, so you maintain that once and you reuse that. And so reproducing build issues. But also making sure that what you build is actually what you think you build becomes a lot easier that way.
Vlad:Exactly. And I think also in the combination of not just developer, and CI, but also developer to another developer. These environments can be so drastically different in many cases. And I feel like this is one of the things that both Gitpod and Earthly really shine in the sense that you know, Works on my machine is lesser of an issue in that case. Because it doesn't matter whether you have an M1 laptop or your windows or you're on a Mac or Linux, all of these things behave the same regardless. And a lot of the traditional build scripts that people have used actually, aren't that good? Like for this particular use case, for example The Mac has a terminal and it has a bunch of Unix tooling in it, like , like sets and find in a bunch of others that you think are the same as on a Linux box. But actually they're very different. And you end up finding that out through another colleague being stuck somewhere. And in this world of remote working and cross time zone collaborative. It's that much harder to ask for help. Hey, what's going on this no longer works on my Mac. So that's yet another thing that the CI will never catch, but your colleagues will be blocked by it. And it's just really painful.
Chris:I remember the first time I stumbled over the difference between new and BSD and figured out that, Hey, does flagship work and it doesn't that's made for rude awakening. If someone wanted to have all this goodness that earthly brings and you know, you're already knee deep into your projects if you want to migrate to a Earthly, how would you recommend I go about this? And I'm sure you've seen plenty of people do that. So what are the things I should look out for?
Vlad:Yeah. Most people end up looking at the Earthly documentation, trying out the tutorial and then trying Earthy in a personal project or an isolated project at work. That's the number one way in which people get started. And once they've gained confidence that it is working the way they expect it to it then suppressed to multiple projects at work and by the nature of teams collaborating with each other and sharing builds and sharing artifacts with each other Earthly gets exposed organically within the company and we've seen it grow automatically from that point onwards. But really this idea of making the build incrementally adoptable within the company. It's something we've designed into the system. Our capability of being super easy to understand is a design feature and the competitive advantage, I think because every engineer has a million tools that they use every day and they're focused on delivering that feature that they're working on and so on. But when it comes to builds, it's just this thing that gets in the way and you sort of have to do it, but it doesn't really deliver the feature that you're working. And so what happens in many companies is that there's a single person called what we call internally, the build guru, which is this engineere that didn't really get hired for this reason. But they happened to know build scripting and they taken up that's responsibility upon themselves to, to maintain the build strips. And. It's only that person that typically understands, you know, what's going on in those make files or bash scripts or release scripts, or what have you. And the rest of the engineering team does not get to be productive in that environment. They like, if you look at the typical batch file or make file, like you'll get very intimidated by it. It's just the opposite of user-friendliness and bringing a tool that anyone can do. The scripts have and can easily understand and maybe even be productive with tweaks without ever reading the documentation. I think that is critical. Like we've all seen how somebody really needs to change that Jenkins file and they don't know groovy. Yet they still try a few commands here and there. Somehow they make it, they managed to make it work, but it's is just horrible. Sometimes the technical depth that you accumulate on those in those ways, but what did that experience was much more smooth without ever reading the documentation, you could just read the code, understand it, and be able to be productive with a build script. And that idea of democratization I think is really important. It's one of the reasons earthly is really easy to adapt. Like you can just read it, you can understand it quickly. There's a very low bar for you to get started with it. And I think that's really important as a product capable of.
Chris:At the beginning of the season, we have the DevX pod, we had a definition of what is developer experience and the definition that Anton gave was good developer experience is making it easy to do the right thing. And in this case, earthly seems to be doing just that the right thing is to go and fix that build and not wait for the Build Guru to have to do that for you will most likely be a bottleneck or out of office just in that moment or in a 10 hour away timezone...
Vlad:And I feel like a lot of the traditional scripts, like bash scripts. I think there, you know, one of those things that make it too easy for you to shoot yourself in both feet with a single bullet, like, it's the right thing is really hard to come by in that context. The easier a tool is the more, you'll feel very natural for you to do the things that you're meant to do. That's how you make a tool very intuitive.
Chris:Yeah, I feel the need to throw in a personal anecdote. My first job in Germany apprenticeships are a thing. So I did that when I was 16. And my first job after that was being that built guru, except it was not bash. It was on files. Back in the day. And if we built stuff that was using J and I, and mess with an Oracle database and put JVM byte code into that database and executed from it, a lot of nasty stuff. I can totally relate if you're the person who asked to, has to fix that build, especially if it has idiosyncrasies like that, you're not in for a good time. You'll want to democratize that. You'll want to make the rest of the team, understand how they can fix those problems. And you'll never want to put J and I using bytecode in an Oracle database.
Vlad:Oh, yeah, exactly. Exactly. And I could tell a Pauline was shocked when you said and files.
Pauline:Yeah. I didn't know what that meant. Up until this point, I was like, yeah, totally agree, no to Jenkins, I had to write groovy scripts in one of my previous roles. And I remember I didn't know what I was doing and I don't think anyone did as well. And I think we were all sort of just making it up as we go along and it just wasn't a good developer experience at all. But yeah, I didn't, I hadn't heard of that one, but Chris mentioned.
Vlad:And files, imagine something, you know, like Maven is more primitive than grateful and basically imagine something even more primitive than Maven. So,
Pauline:I can't even imagine.
Chris:all ex all XML, you know, back in the day is all XML.. you were in for fun. If you wanted to extend it we've come a long way. We still come a long way. Like looking at earthly, comparing it to what we have back then. Oh my God. If we come a long way, speaking of coming a long way, there are some steps around software builds and specifically around us supply chain that the industry is moving towards. And so here I'm referring to essentially the recent push for supply chain security. It's always been a topic, but it seems like lately it's becoming more and more of a topic. There are initiatives like cell side coming out of Google and others. How do we navigate the trade-off between making it easy to do the right thing? That is securing our supply chains, but still keeping that comprehensible for developers having that in the tools and not turning this into a black box so that developers don't even understand why am I doing this? And how's this working and what is it doing?
Vlad:Right, right. No, that's a really good point. I am pretty familiar with this issue because before Earthly I founded a company called shift left, which is a security code analysis company. And I feel like supply chain is probably the biggest threat right now for application security in general and containers in many ways, I feel like unintentionally, they made it a little bit worse because once you allow the application team to just have full freedom within the container, like you've sort of lost control of the organization level and you need other ways in which you can influence and control what kinds of dependencies go in production. And again, when you sit on the production side, you don't have that full visibility inside of the container as much. So what some companies are doing, are they standardized based images that people have to use for various language within their organization or they have some other means to take control over their dependency chain. I feel like so far, there's nothing perfect right now. And as an industry where it's sort of still very much exposed I dunno what the right answer is and what exactly this will get better over time. In what way? I feel some of the work that Docker is doing with supporting the supply chain, putting the build of materials in the metadata of containers. That's a significant step forward. I think we will need something to put all of this together somehow, and to allow people to just enforce at some point, you know, if the next log for J comes up, you want to be able as an organization leader to just say, I want to see all the projects that have this and end up in production. And I want to be able to see that build of materials, of every single container that I've put in production. And a lot of the times the build of materials comes from base images and the chain of images that you might use along the way, but maybe it doesn't contain actually the dependencies that you download in your Docker files. Those will not get in the metadata of the containers. This could be an area where CI/CD providers could provide more insight and put two and two together. If you're downloading from maven we'll put that metadata, they play in your container, in your image. And when it gets to production, you now have a full sort of pane of glass of control over exactly what gets in, where it came from. I think there is quite a way to go until we get there as an industry, but it's definitely one of those problems that we really need to solve and address.
Chris:The last point you made where these different initiatives towards bringing a software build of material to the code that we ship and tying that together is going to be a really interesting challenge. Also, the work that's happening in the Go ecosystem with shipping and as bomb as part of the binary, having that in containers, all the work that the chain guard is doing, this is going to be a really interesting space to work.
Vlad:Yeah, for sure. For sure I think we will make a significant advancements here. And also I've seen this shift from this responsibility going from more like a security team to more like an engineering team. And I feel like that's a really important advancement because. you look at traditional security, they've been in the way of I'm going to ship this to production, but now the security team says no. So like that has worked in a traditional model where maybe you had don't a once a month type of releases, but it doesn't really work when you have. I don't know once per day or multiple times per day, there's just no way for someone to go in and say, okay, stop the build. We're going to stop innovation right now. We're going to stop, you know, all these critical features that are going into production or critical bug fixes, and we're gonna just prevent because of security reasons. And for that reason, because security has been traditionally more disconnected from engineering, I think there has to be a more a shift. having that role inherently and, you know, having the security experts in the engineering team or having the tools that we use more security focused. And that is not an easy thing to do because a traditional engineering team will just be focused on delivering features. They're never measured on their security and there's really good reasons for that, but it does create this problem for when things get into production, there's less control over it. And there has to be some mechanism by which the control is available to the people that really care about it and embed all the necessary information in the images or have that sort of security check that is maybe much more automated. You put the engineering hat on the DevOps hat on, and you make that much more fixing in many cases or you just have a better view of that. I think that's something that's going to evolve over time.
Chris:This comes back to perpetual topic where we end up centralizing more and more topics on the engineers. Like, you know, many years ago, we'd have people doing infrastructure and we'd have people doing the application engineering work, quote unquote, and Kubernetes, all blurred those lines.
Vlad:And we're doing the same thing. Hey, again, where we're pushing something that was before a discreet function. And we're pushing that we're shifting that lift and pushing that into the engineering teams, which also means that as we do that, we need to, as you said, we need to invest in the tools that make that easy to do. Coming back to that definition of good developer experience. If we want to not burn out our engineering teams by burdening them with ever more complicated tasks. We got to make it easy for them to do the right thing. And so the job for security teams now becomes not to say no, but to enable those development teams, those engineering teams to do that job, which has just become yet another bit larger. Right, right. Exactly. Exactly. Yeah. I think you, you hit some good points over there.
Pauline:This actually brings us quite nicely to our next question. I think we've already mentioned that the shift to the left. I feel like that's a common theme we've been talking a lot about recently, actually in this, in the podcast. What else do you think developers need to pay attention to next?
Vlad:I think it's much less what exactly is going to hurt them in some way. Ideally as an industry that you should be nothing. It should be just out of your way and not have to worry about it as much. Right? But we are seeing some shifts in the industry and I, and those shifts are technological advancements on one hand and also more like productivity driven advancements. So on the technological advancements side, there's been new and one laptops or M two laptops nowadays that have. More platform mixture into the mix that together with the AWS graviton instances, where you can run arming production and a lot of the existing production like applications run on, on AMD 64 these days. So not arm, that's going to mean a lot of mixed compute in the future. And over the next decade, I think we're going to see just a lot of that in our environments, both in production and on people's own computers locally if they don't use Gitpod, I guess. That's one area. And then another area is a lot of the companies that are scaling up and they want to introduce some kind of structure in their engineering process. For one reason or another, they end up with mono repos and as an industry the tools that we have, the more traditional CIS, they're not really prepared for monorepos it, you know, if you look at circle CIA and a bunch of others, it's just really hard to trigger the build only on the pieces that you've actually changed in the. And that is tremendously painful right now. There is some ways with GitHub actions to, you know, trigger only on changes of a certain sub directory and things like that, which you can use, but fundamentally, if you introduce more dependencies across different. You want to have a really good understanding about what exactly is new, what has changed and what kind of computation you won't have to repeat as a result of a change and, you know, overcoming that is probably, you know, the next big sort of productivity challenge that we have to think about and address.
Pauline:Awesome. Yeah. Thank you so much for sharing that, Vlad. So we're actually at the end of the podcast already. So many great take takeaways from this episode. So how we usually end each episode is we offer our guests and everyone on the call to just share one thing that they want to shout out about that could be a product, a book, or just something that you want to share. And this is your space to share it with us. So I think because you are our guests Vlad, do you want to go first?
Vlad:Uh, yeah, absolutely. So I've read this book sometime ago called a black box thinking by Matthew seeds. And it's this really interesting description about how a culture of experimentation is actually much more important than expertise. And I feel like this has relations to, you know, develop your experience as well, because it's much more of a trial and error kind of thing that you have to iterate on over time. And to get that. And, you know, this book basically goes into the, like the airline industry or the healthcare industry and the like the biotech industry and compare the different cultures across these different types of ways of dealing with experimentation and actually with failure. Really? How do you accept failure and learn from. And you see some stark differences, like in healthcare, for example, it's not accepted. Whereas in the airline industry is really embraced with the black box that you put in airplanes, and that has resulted in healthcare being less prepared for we're worst case scenario situations. And just this idea of experimentation being really powerful for organizations is just really interesting and comes across and. So I'm definitely recommend black box thinking.
Pauline:I've just added it to my good reads wishlists. Because it sounds amazing, I'll add that to my next thing to read. How about you, Chris?
Chris:It does sound great. Indeed. I'll pitch how we a Gitpod I've taken steps to secure supply chain block posts. And it is very much in theme with this episode. In this blog post we for one, dive a bit into our build system and how we made it salsa level one compliant, what salsa is and that it has nothing to do with tacos. And what were like the steps we're taking to the next.
Pauline:Yes. And that blog posts, hopefully by the time this episode is out, it should be out at a similar time. So we will also put the link down in the show notes if you're interested in reading. For me this week, I wanted to share a book I'm currently reading. It's called the great CEO within the tactical guide to company building.
Chris:And it's been recommended to me by a lot of people, at Gitpod. It's very interesting to relate the the learnings and the teachings in that book to our stage at Gitpod.
Pauline:So yeah, I highly recommend everyone. Check it out. It's a fantastic book. So yes, we will put all of the things that we shared today in the show notes if you want to check that out and Vlad, if people want to connect with you and chat some more about earthly, where can they find you?
Vlad:So come to Earthly.dev and we have a slack community come say, hi, we're very open to new people and really welcoming. And yeah, we'd love to talk to you.
Pauline:Amazing. Well, thank you so much again for being part of this episode of DevX P od. And we'll see you again soon.
Vlad:Alright, thanks for having me on the show.
Pauline:Thank you for listening to this episode of DevXPod Want to continue the conversation about developer experience head over to our community discord server at gitpod.io/chat We have a dedicated channel there for us to talk all about DevX to make sure you don't miss the next episode follow us on your favorite podcast platform or subscribe to our newsletter DevX Digest
Chris:you can also find out more about Gitpod on gitpod.io Start any workspace and tell us about your developer experience See you in the next episode
