(upbeat music) - Hello and welcome to Tag1 team talks, the podcast and blog with Tag1 Consultant. Today I'm talking with Randy Say, the maintainer of DDEV, who's also gonna be doing a demo of some of the features and functionality in a little bit. DDEV is a very popular Docker-based PHP development environment and it enables you to get up and running in minutes, even if you don't have any Docker skills. If you're developing code in PHP and you haven't heard of DDEV, or don't know a lot about it, you're gonna wanna stick around and learn more and see how it works because it's gonna save you a ton of time. And for all of you DDEV users, we're gonna be talking about some of the history and talk about the future of the project as well. Michael Myers, the managing director of Tag1, Tag1 and her teams are very active in contributing to open source projects and communities. In fact, almost all of our client work comes to us because of our contributions and reputations with projects like Drupal. So it's really important to us to support the ecosystems and the tools that we use and rely on. We're super proud to be a sponsor of the DDEV project. And I would encourage you to become a sponsor too, if you're not already, if you like DDEV and use it as a tool day to day, every little bit helps and counts. Tag1 builds large scale applications with Drupal as well as many other technologies for global 500s and leading organizations in every sector, including Google, New York Times, the White House, the LCIO to name a few. If you need help with your large scale application, please email us at
[email protected]. I'm really excited to have Randy on the show today. Randy, welcome to Tag1, I'm Teem Talks and thank you so much for joining us. - Oh, it's so great to be with you, Tag1, such a fun bunch of people and always enjoy talking about DDEV too and enjoy talking about Tag1 and enjoy talking about your Tag1 t-shirt, which the people listening. - That's it. So before we get started, I just wanted to share a story with you, 'cause it really touched me in the last few months alone. We've had three different DDEV users reach out to us via our contact form and thank us, not just like profusely thank us for our support and sponsors just for DDEV. I had enough of sure, like telling these people that do some, but over the last 17 years, we've sponsored a lot of open-source projects. I can't recall outreach like this before. And so, I hope, I'm sure you know this, but I just wanted to say it, people are super passionate about DDEV. They love the work that you're doing and it really blew my mind to see that kind of outreach. - Well, we do all appreciate your sponsorship of DDEV and it's a great community. We're working it all together. So I'm glad that people are telling you about that and we did it really appreciate it. Thank you. We were gonna keep doing it anyway, but if that was a tactic to get us to keep doing it, it would work. I think it would be really helpful to step back a little bit and provide a little bit of history and context for people. Can you give some insight into, you know, like when and why did DDEV come about and you know, in your involvement? How did you get involved? - Yeah, and it was kind of an interesting thing. I went to work, I took a regular job with a company named Dread in like 2016 or something like that and their goal was to make a Kubernetes-based posting environment. And so like I just, you know, tried to understand all the things and I love hosting and I love all of the things about it but I really didn't, that wasn't my thing. What they were doing wasn't my thing. I wasn't really into it, but they had as a piece of it, DDEV. They had an infant DDEV as a piece of it. And for five years, they let me work on DDEV. I mean, that kind of generosity is amazing. Like I say, I wasn't really all that thrilled about the other things they were doing but they let me do DDEV. And it was a lovely thing. And of course, then they lost their funding. Some of your listeners will remember that. They lost their funding like many startups do and they went away. And because it's a great thing to do, I just kept on going with DDEV and maintaining it. I'm old and money isn't the thing and having something really valuable to do is the thing. And so I just carried on. And then one day, I don't know, a year and a half later or something like that, platform.sh comes in and says, well, we'd really like to sponsor DDEV. And can we give you a salary? And that worked out. And they've been doing that now for two years. As a matter of fact, I saw the anniversary. So for two years, they've been sponsoring DDEV at a very high and very appreciated level by paying me a salary, which is amazing. And more than that, it gives us a lot of money significant credibility to the project when I was just flying along saying, well, I'll do it. And we didn't have the financial resources. It wasn't as credible to people that DDEV would survive. I knew it would survive. I knew I was on it, but we wanted a long term sustainable approach and platform.sh stepping up was a real piece of that. So that's another pretty cool part. But we have been just, it almost seems like everything we do is just moving along step by step. Everything incremental. DDEV has been incrementally going for, is it seven years now? Maybe it's coming up on eight. But yeah, that's the history. We just move along and find our way. - That's amazing. I'm really glad that platform stepped in. They are a really great company to be associated with. And as you said, really drives some of the adoption. So can you give us a sense of who uses DDEV? And like what is the most common use case? Like what are people doing on a day to day basis with DDEV as a tool? - So DDEV is built and focused on local development. So people who are web developers already know this, but people who aren't might not know, you can't have two artists working on the same canvas at the same time. You know, things just get really messy and things don't work out. Developers used to do that. They used to work like on integration servers and you'd have two people out there changing code at the same time and it wouldn't be under source control and things like that. And we have at least moved on past that and most developers of websites do their development on their own machine. And that used to be really hard to set up. It was like I could do it because that's my background. I love Linux and I love, you know, and I could always sling and Gen X can big and PHP can big and make it work. But most people that's not their focus. They know more about JavaScript or PHP or whatever it is that they don't want to know how to configure Engine X and PHP and run it locally on their machine and fix it for different projects. So the whole idea is to be able to have your project, your website project, checked out on your machine and use it there and not have to think about that. And preferably for your team who might be using WSL2 or Linux or Mac or even traditional windows to be able to do it the same as you do. So everybody using the same thing, the same configuration, even though it's on different operating systems, different environments. The data is currently quite focused on PHP developers. So we have, we will take a look later, but we have special integrations for lots of different CMSs and frameworks. We've branched out to helping Python developers and Django, but we don't have a lot of takers there right now. But that's what DDA is. Is it's for local development of websites on any platform? One of the individuals that reached out, I looked them up and they're a Python developer. So they're definitely passionate about the folks that you have doing it. I mean, it really is amazing, right? I don't do much development anymore, unfortunately. And it's a lifesaver to be able to spin something up and get going very quickly. I don't have the skill to sling engineers anymore or the time to dig into it. So it's a time saver and then that consistency. So you're not introducing problems that you need to solve later. That's a big part of the whole tool chain is to find things early and often and have consistency across our environments. So there's a big gap for the longest time in local developing. And people work on it. It works on my machine. What's wrong with yours? The developer catchphrase. So-- [INAUDIBLE] Yeah.
One of the things that Edav does, Edav is built on top of Docker. So, what is going on is there's little Linux machines in there and those Linux machines look the same on any platform and any developer's machine. So, your friend down the hall has the, if you've checked in your configuration, which is the normal thing, then your friend down the hall or down the world or across the world has the exact same little Linux machines running, whether it's on Mac or Windows or ARM64 or AMD64 until or whatever those machines are the same and that's why it can work. And so, the Docker is an amazing technology but it's usually pretty intimidating to people that Edav doesn't expose that much of what's going on with Docker. We say it's Docker-based but we don't expect people to have to know anything about Docker. They just have to have a Docker provider installed. Now, if you happen to be savvy in Docker, is there, you know, can you do more or is it really just about abstracting the complexity to enable you to develop a man and deployment? Now, people that do want to add services, for example, can do that. We also have add-on so you don't even have to know that but there's somebody in the DDEV Discord trying to create a brand new service the other day. Somebody in the Tag 1 Slack wanting to figure out how to use a RAM disk or mounting the database on so that it's just sitting, you know, so that it doesn't have to be written to disk. So those are little complexities that people can do all of those things but the average person doesn't run up against that at least at first so with the add-on ecosystem and everything we don't have that need to really know about Docker. So why would you say people adopt DDEV over other solutions? Like what makes it stand out? I think the biggest thing is the great community means that it's really well maintained so the community is very, very active and lets us know when things go wrong and we're able to get to those things and figure it out. As you know, all the piece parts are changing all the time so we've got new upstream components all the time. A new version of PHP comes out, a new requirement for a different database version changes, a new release of, you know, magento 2 comes out that changes how it works and you have to change this and change that. And because the community is so great and so engaged in all of that, we're able to keep it. And of course the community sponsoring two of us maintainers to be working on it all the time is a fantastic thing. But aside from it being predictable and maintained, a lot of people really, really like the performance especially on Mac OS which is always a black mark on Docker with Docker desktop and stuff like that. DDAV implemented a technology, an open source technology called mutagen which is used on Mac OS two or three years ago with great, great help from the maintainer of mutagen and that has made a huge difference so that performance locally is really exceptional. People love the, love the performance of DDAV. It's the best, the, how fast the, the DDAV instance comes up but also how responsive the web browser is because it used to be that when you were running something locally on Docker, it was just like go to a page and wait, wait, wait for it to load and with mutagen doing all the work under the, under the cover there, it happened, it's really, really fast. It can be faster than a real hosting environment. It can be as fast as a Linux local development environment. That's awesome because speed really negates, aiming at local right? You might as well connect to our most human development like we did back in the day. It's critical and you know, we attack ones certainly appreciates being in general. I'm curious, the open source, you know, the community, you said they're reaching out, they're sharing ideas, problems they were running into. Are they going beyond that? Is there a contribution from the community? Oh yeah. Yeah, we have contributions and we're totally dependent on them. So the, you know, like the type of three and droopal communities have always been there, but Craft CMS adopted, adopted DDAV a couple of years ago and there's a number of, another number of other communities that make sure that things are kept up. So we had a great contribution. There was a major change in Magento 2 recently that needed some effort applied to it. I think community brought that in. We have a couple of, a couple of hard hitters on Magento 2 that make sure that that's kept up today. So the people come into the, into our, a DDAV discord or into the GitHub issue queue or stack overflow and they say, well, this is, this is what's happening, this is what needs to happen, this is what's broken, this is what, you know, so we've, we've got all, all for, for quite a long time, we had, yeah, you know, we have, we have deep roots in the droopal community, but for quite a long time, we had a, a major contributor to typo 3 is a major contributor in DDAV and he, he kept things chip shape and typo 3 community still does, but anyway, we love that and I think that's, to me, that's the fundamental thing that makes DDAV fly is the community engagement and making it so that it's, you know, so that it's real so that it works for them. Yeah, I think, you know, between what I mentioned earlier with the, the users reaching out and saying, thanks for the sponsorship, the companies like platform making big sponsorship, the people using it like, you know, from every angle, the community seems to have, you know, fall in love with it and want to support the platform. Then I think that, you know, to my experience and open source, the community is the heart of the project, right? It's, it's, you know, what, what talks about the help of the project. And so it's really great to see. What about add-ons? Like is that like another way that, that people can contribute or is, you know, yeah, so DDAV has whole add-on ecosystem, which has been maturing over the last couple of years. You used to have to, it's like, if you used, if you, DDAV provides a web server and a database server, it'll do MariaDB or MySQL or Postgresql out of the box. No problem. All that stuff is built in and, you know, a bunch of things are built in there. But as far as like other things like Redis or Solar or Barnish or those things that people tend to want to add, those aren't built into DDAV. But there's a community technique for those to be placed in a GitHub repository in an add-on format. And it's really, really easy to create the add-on. And that add-on contains the Docker tidbits or whatever that you need. And then you can just add it with DDAV Get. So you can just do a DDAV, get DDAV/DDAV-Redis. And boom, it's installed and it's going. And so that's, that's great. And we have official ones that have been promoted into the DDAV repository. But anybody can create their own on their own account. So they can basically take the template that's out there, the add-on template. And you just click a button and you build your own. And then when you put the DDAV Get label on that, then it shows up in DDAV Get-DashList-DashAll. So there's quite an ecosystem of those. And we probably, it's probably outgrown some of the technology that we have. Right now, you find out about things on the command line with DDAV Get-DashList. And one of the things that we talked about yesterday, we had our annual full-blown review, our advisory group. We have a DDAV advisory group from the community. And we had our annual review of the past here and plans for the next year meeting. Two-hour meeting yesterday. Had 16 or 20 people. It was great feedback. But one of the things to come out of that was that we probably need to grow up a little bit more and create an add-on registry. Probably something on ddav.com that would show in a little more detail and with a little better access what those add-on.
are because there's a lot of them and some of them are experiments, you know, that might have might not have succeeded. Some of them have been promoted to fully official. A number of them are really well used and we need to do better with that. Anyway, there's a whole add-on ecosystem. It's not hard. Creating one usually requires a little bit of Docker knowledge, Docker composed knowledge or maybe a lot, you know, for something that's really complicated. But they're straightforward. It's amazing how nice it is to build one and then they just use GitHub queries to find them, which is pretty nice. For teams that are working together where everybody has their local DDEV, you know, an infrastructure change is made, you know, and rolled out, is there a way to propagate that back to everybody's local development line so that everything stays in sync and we don't end up back with what worked on my machine? Yeah, the strategy, the standard strategy is that you check in your.dd.v directory. So the.d.v directory is in the top level of the project. And so normally on a team like the project leader, somebody would check in the client-approved configuration or you'd make a, or somebody would make a PR on their project with a change to DDEV. So let's say that you're upgrading from PHP 8.2 to 8.3. Somebody would make that change and the dd.vconfig.jam will file. They would check it in, they'd make a PR on the project, and then that PR would get pulled and everybody would have that same configuration. Awesome. Well, I'd love to shift into a demo and and show off some of the tool, maybe, you know, common use cases. You bet. Yeah, I'd be happy to do that. What I'm going to do is I'm going to go over to, I'm going to share my screen first and I'm going to go over to the dd.v docs. Let's see if I can share properly. Always share. I can only share the whole desktop because otherwise I get confused anyway. So here I am, I am going to go to dd.v.read the docs.io. And this is where the dd.v docs are. And I'm just going to go to the CMS Quick Starts because that's where the usage information is and it's quite easy. Can you see my screen? Okay. Yeah, let's create. Okay. So I'm just going to go to the CMS Quick Starts and you see we have their Quick Starts for backdrop, Craft CMS, Django, Drupal, Expression Engine, Ibexa and Larabelle, Magento, Moodle, Python, Blask, Shopware, Silver Stripes, Detamic. If that's the right way you say it, Type O3 and WordPress. So we have Quick Starts for all of those. I'm just going to take and take a look at Drupal. These are all very similar and the and most of them are using very sorry, most of them are using Composer strategies. And so the the basic ideas of almost all of them are the same. But what we'll do is we'll do a Drupal one. And so I am going to just do these steps right here. So what I'm going to do is create a new directory and then I'm going to use the DDEV config command to tell it what the DDEV configuration is. And then I'm going to start the project and then I'm going to use a Composer create, a DDEV Composer create, which is the same as what you may have used Composer create-project. DDEV Composer create is just a slight variant on that because you can't use Composer create project in a non-empty directory. So DDEV Composer lets you do that. So we're going to do a Composer create a Drupal recommended project then a Composer require Dresh Dresh. And then we're going to install it and then we'll just use it. And that's we'll just do that right quick. So I am going to switch over. I love that you support Drupal 6 and 7. Yeah and they, you know, it works fine. I mean there was, well, there's still over half a million Drupal 7 sites and it's not end of life yet. Hundreds of thousands of six. But that's really great to see, you know, that you're providing this compatibility. Well, remember that people, web developers don't work in a perfect world and lots of them in care it sites that have been neglected for a long time and need to be resurrected or need to be upgraded and you have to figure out how to run those somehow. So DDEV supports clear back to PHP 5.6 and with some specialized techniques you can go even farther back than that. But yeah, I mean Drupal 6, a lot of times people say, well, why don't we remove Drupal 6 and 7 because they're obsolete or at least Drupal 6, right? And I said, no, because everybody has to be able to recreate these things. So let's see what I can do here. I just want to make sure I don't already have one of these. I'm going to CD into a, I'm making a directory called my Drupal 10 site. And now I'm going to do a DDEV config. So what I'm going to do is I'm going to do a DDEV config. And I'm just taking this straight out of the of this, the Drupal CMS Quickstart. If you can't see, if you can't see my screen or you're listening to this on audio, I'm going to do a DDEV config - project type equals Drupal 10 - docroot equals web - create docroot. And there I am. And I have now done a DDEV configuration. If I do a LS-LA, we'll see that we have a DDEV directory now. So the DDEV directory contains the configuration. Now I'm going to do a DDEV start, which builds the containers and projects that I need and brings them up. So it's going to bring up engine X by default. And it's got PHP, FPM coming up behind that. And it's got - we're not doing anything special. But then we've got a router that takes the the host name my Drupal 10 site and sends it to the right project. So - Oh wow. I just think you said right in your browser. I mean, this is like - I mean, literally you just cut and paste and you're up and running. This is crazy. That's exactly right. So now I'm going to do a DDEV composer create Drupal recommended project. And it's going to put Drupal 10.2.4 in there right away. There we have got the - the composer install is almost done. We're just waiting for it to copy the last bit in. And then we'll put a Drush in because what is Drupal without Drush anyway? And we're stopping and starting to make sure that all the things point to the right things inside everything. So and now I'm going to do a DDEV composer require in a half a second here. DDEV composer required Drush. And now Drush is installed inside there and I'll just do the DDEV Drush SI -Y demo umami - - pass equals admin so that I can know how to log in. And Drush will install that for us. And then we'll have a working Drupal system as soon as that's done. So this is basically all that it takes in the in the Quickstar it would say that I should do a Drush DDEV Drush ULI now. I don't usually do that but we'll do it here. And that shows us the link. You see that it's got the proper link and everything and I'll just click that link and open it up and here is our project and we're logged in as admin and we can go and look at our umami site and it's got everything that we would have wanted in there. So that's that's how a Quickstar works and that's how it works for the other ones. And this is a fully functional well I mean it's a fully functional demo site but that's all that we had to do and it used standard composer techniques and there it is running and it's all configured properly. We can go to the reports and hopefully we'll get a status report that says everything is okay. It's got warnings but these warnings are about oh you're running this in a development type mode so that's that's the scoop. Anything else you'd like to see there? Yeah. It should be named at the super quick start guide. I mean what it's been like 90 seconds and you're up and running with a full install. That's that's pretty awesome. Someone on our management team is very technical um but you know the ease of DDEV this past weekend we were talking about workspace and which Andre Mattiscue on our
developed and you wanted to check it out because it sounded so cool. And able to spin up DDEV in a few minutes, install the module, get it up and running. It makes it so easy to just try things, right? Oh, I heard this module is cool. I want to experiment with this. It really empowers-- I'm not like the core use case, Perdidaev. But it enables me to do things that I just wouldn't do otherwise. Because of that ease of use and that functionality. So I wonder how many-- I'm sure the people who use this developers have a similar need of time studio. But I always wonder how many people are using it in the way that I am just quickly spinning up and trying something. You bet. Yeah. That's a great use. And you've never done anything to lose. And DDEV has a lovely feature called Snapshot, where it can make a binary representation at a snapshot of the database. So you can actually do DDEV snapshot before you go do something weird. And then go right back to it with a DDEV snapshot restore. And there you are. And that's a great thing for migrations. It's a great thing for experimentation. Super easy to use. Some people don't even-- there's so many features in something that's grown up all these years that nobody knows about all the features. And so sometimes people don't know about them. I should put the snapshot feature into the tip of the day. We have a tip of the day when you're running DDEV start the first time in 24 hours. And I should make sure that Snapshot's in there. I love it. It's brilliant. It makes it-- on one hand, it makes it super easy up and running. But on the other hand, there's no end to the complexity that you can do with it in the custom configuration. And so really, wherever you are on the spectrum or your paths from one end to the other, it's a really fantastic tool. Given all that it does, what does your roadmap look like? Like what other things is it you're focusing on over the next year? Yeah. That was yesterday's meeting. And you can go out to the DDEV discussions and you'll see the whole recording of yesterday's meeting for the annual planning meeting and all that kind of thing. But the-- much of DDEV is focused on-- well, let me just-- yeah, I don't want to go into too much detail. But the biggest things in our roadmap have to do with community, sustainability, and then some technical things. So as far as community, we want to continue training contributors and maintainers and make sure that everybody can contribute and that they're successful contributing and that we provide all the materials for them. We try to document everything. But we have-- last year we did, I don't know, 10 or 12 or 15 weekly sessions, which were live and recorded, training about contribution and maintenance things. And we're going to start that up again this year and make sure that those are recorded and make sure that we document the things that go in there. So making sure that our community stays sustainable and our community is the first priority, then the second thing is the sustainability. We've been working on making sure that the project is financially sustainable. But we spent a lot of work on it last year, reaching out to potential sponsors, reaching out to individuals. And our support level is definitely up. And we have a second paid maintainer, which is a great thing. Those are great. But we need to keep on that. And our goals are much higher than our current. So sustainability and just making sure that all those things are properly set as the second thing. And then the third thing on the technical, we have a proposal to consider breaking up some of our images into multiple images. So right now we have a, this is kind of often the weeds, but we have a web image which contains both NGNX and PHP and a lot of other things. And those could be separate images and containers. And so considering how to break that up and make it more modular is a, it's on the table for this year, it's on the table. We will experiment with it. So those are, but those are kind of the three main for us. Most of DDEF's history feels very incremental. Just keeping up, just helping people out, just solving bugs, just making sure that people can do what they do. And so I expect that this year will feel mostly incremental. But we want to, we want to remember those key things that we need to grow in. - I love the priorities. You know, and to learn with everything you've talked about. Community, sustainability, drives technology. That seems like a really good foundation to have in place. So without those two, there is no technology. So that's really great. Man, this was awesome. I really enjoyed chatting about this. You know, it's no wonder why DDEF has gained, you know, an awesome reputation and it's so popular. My hope folks listening and watching, you know, that aren't using it, aren't gonna check it out. Thank you again for joining us. We'll post links in the show notes. You can check out the various things that Randy talked about. If you like the talk, please remember to up post, subscribe, share it out. You can check out our past Tag1 team talks at tag1.com/TTT. That's three T's for Tag1 team talks. And as always, we'd love your feedbacks, suggestions and topics for future episodes. Maybe there's something you want to see Randy dive into in more detail, show off the add-ons. You can email us at
[email protected]. That's THG number one dot com. Again, thank you, Randy and everybody who tuned in, we really appreciate it. See you soon. Great to see you. Thanks.
PodcastTranscript AI