Using Pantheon’s Multidev and Buddy – a perfect WordPress development combo

Yeah, and the cool part about the multi dev environment is that the only thing similar that I saw was Netlify or Vercel, where every time when we deploy something to a branch, we get this pre preview URL or whatever it's called because it's it's named a bit different based on which platform we are using and I Oh, this was always something I missed. And in the WordPress environment, I really remember that if I'm not wrong, Aaron Edwards from WPM, you dev mentioned that they have something like this behind the scenes.

So this is something they use with multiple, so there is a slight limitation, at first, there's about 10, that you can actually create, but you can reach out to support and ask them to increase it, which I think is 25 or 30. I can never remember off the top of my head, but I want to say it's around that area. But that's one way of doing it.

Yeah, let's let's let's be honest, having 10 staging environments at the time should be enough. Because if you are not handling, handling, dealing with your features, 10 of the time, you have a bigger problem, rather than just not having quality them before. So sort of that's true. Okay, so I think that enough of theory, let's start showing up what, how many they have looks like. So let me share my screen. So a custom question you can respond in the comments. Is the font big enough? Or should I increase it? I don't see and come and see it, but we will see it, the moment that someone will, will say that the font is too small. Okay, so as you mentioned that Pantheon always uses git get somewhere. And yep. So that's why I created here, a repository that is based on on the Pantheon WordPress specification, and that there is only one difference, this dot Buddy folder, and in this doc Buddy folder, we will have a script that will let us create a multi dev environment. Each time we will push something to production, it there is quite a bit of code. But the most important thing is that it uses this tool called Terminus. And Jose, could you explain what is Terminus?

So terminus at its basic is essentially the API for the dashboard, but on the command line, which is amazing to do, because oftentimes, we as developers don't like to touch, you know, a graphical user interface. And we're just like, oh, all these shiny buttons. What does it do when it breaks? We're more familiar with like, you know, sudo, do this, or Command do that? Right? That's essentially what Terminus is. It's a basic way of running commands. For the dashboard.

Yeah. Yeah, exactly. That's the problem with Terminus is that while it has a lot of possibilities, you really need, in most cases, some kinds of bash wrappers to make everything working, because, like I said, it's powerful. But you also need to learn how to how to use it. For example, here, this is the simple example, we had to create a function, the tax is the multi def already exists. And so we have to list all the environments and check if the if the one we are we are using right now is already created or not. If not, we will be creating a new environment. So as you mentioned, this is kind of an API for the dashboard. So let's take a look at the dashboard because this is also something so as you mentioned, we have those three environments, we have the dev test and life. And if we would like to push something between the environments, we would have to deploy it using using either dashboard either specific terminal command. And here is the most important part of the day, the multi Dev. Okay. Single all the all the environments that are that are already created, you can delete them, you can merge them, you can see which of them are ahead which are behind. And what's most important, you can, at any point, just see how they look like, at this point. This is our site. That's it, it's working. And we can update the database of each of each environment separately. So we can test many, many things. The way we want.

So this is this is something that really it's like the beauty of the whole containerization system. That's why it's like It's all contained within one little thing.

chart. The cool part today is on that one, there's actually two different locations you can get it from there's that connection. And if you actually look on the development development mode as well, there's a little pop up that shows in there. So if you cause connection, and then clone with Git, that will also give you that same Oh,

yeah, that's true. And I can even see detailed instruction. Exactly. Great. Great point here. This is also the thing, you should remember that you will be working with two Git repositories at once. Because we will have this git repository that I have on GitHub, and this will be our, the place when we will store our code. And on the other hand, we will have this git repository inside of Pantheon, which will be I would say it will be our file system. But

it's more like a remote rather than that. Like the source of truth.

Yeah, exactly. Also also a great, a great comparison. Another thing that we have here when it comes to variable is this this machine token. Could you explain what is the machine token?

Yeah, so what's really funny is I had to think about this one to the other day, I was like what exactly and how can we compare it? The machine token is very similar to like the, the GitHub token that you use. It's a way of authenticating. That's like the quickest way it's like a little pass and like, Oh, hey, we have this. This is our password. We're going to use that and we are this person or we are using this token with that. Huh, yes, you guys as many as you want to. So it doesn't have to be just the one, you can recreate another one being like, Oh, hey, I totally forgot what I use for this one, let's just create a new one. Because I've done that a couple times,

yes, and the place you can do it, it's in the account in the machine tokens, you have to copy this token and better hide it because it's kind of kind of an important information that you shouldn't share with the rest of the world. Next thing we have the Pantheon site, the Pantheon site as this is this ID, that we have in our URL, when we log in to dashboard, we will use it quite a few times using Terminus. And we also have the site name. And in some cases, we will use one, one of those there are not interchangeable, some commands would prefer one value over another. And we have the site URL, this is a helper variable that will that we created that will store something from our deployed script, it will store that our branch, I mean, the environment URL, so we can pass it later, for example, in Lighthouse are in something different. Okay, so these are all the variables, like I said, here, we just launched this, this is kind of important thing with this dot before, because this means this shell script will run in the same shell as the rest, so we can save some variables and keep them for for later this is an important part. And when we will generate it, we will use that git push action. And we'll use the get URL we have already will use the ID key that will be able to copy into our our Pantheon environment because we can use the SSH keys here and we can copy it and we will be able to authenticate. And the only heart part that is left is the Git ignore file. Why it's difficult? Because normally, we don't store some things in Git. Like we don't store the vendor folder. We don't store what else I would say node module.

But it's gonna say it's essentially thinking of like what we don't want to version control. That's a good way of putting it too. It's like what do we not want to keep in our repository? Let's ignore that.

Yes, bugs. Because our Pantheon git repository is a bit more of a file system. We want to keep it there. So the best practice is to copy the Git ignore that we use for our WordPress. And fix it a bit. Remove the lines that we won't need. In our case, I just added that we don't need to copy that dot Buddy account dot Buddy folder, but dependent on your configuration. Sometimes you will like to push the vendor folder sometimes maybe you'd like to use the node modules folder for some reason. It all depends on the project. But for sure, thanks to using such approach because there is a command in terminals called multi def. And now it's sorry, it's built command built push, right something like this.

For deployments,

yes, for pushing. Yeah, there's the there's one command. And it's sometimes has a problem when working with multiple gate accounts set up at once. And in many cases, when we are using CI/CD There is the second gate environment somewhere underneath. So there can be problems. And that's why I decided that it will be easier. Just use use the git push action and configured in a in a perfect way. So so we got it. So the only thing that is left is to create a new branch right? So let's do it. Yeah. So let's find my favourite file to get it is a readme HTML file. Oh, and one more thing, remember that the main branch has to be Master, right? Yes, yes, because for a moment, I was using the main branch. And I was kind of surprised that I had some trouble with multi Dev. Okay, so let's find, let's find the first thing first, I already did some changes here. But let's add some more Smiley's at the end. And let's create a new branch. And let's call it web one. And here is also another thing, there is a limitation when it comes to the length of the, of the multi dev environment. What is it?

It's 11 characters. And why? Part of that is because of the DNS record, when when you create a branch it's essentially creating a new site with that branch name attached to your site. So if you have like super long name branch with your site called this is really ridiculously long. And then you have super long with ridiculously long dot Pantheon site.io. That creates a slight issue with record.

Yes, and right now you can see URL. And right then we can see that the novelty that was found is created. It takes a bit of time, so we have a moment to talk about something else. So how do we have a Star Wars day today? This is May the fourth What is your favourite character from Star Wars world? And everyone posts your favourite character from Star Wars.

We want to know and even your least favourite character we you never know. What's really funny too is like you can see I'm still wearing my actual like Star Wars t shirt. That star. I have another one that's a ying yang with the two Thai fighters and the X Wing. But no, my my favourite character actually was and always has been Yoda. And part of that reason is just because growing up I used to watch the Muppets. I used to love making the noises making the voices and over the years I learned how to kind of do that. So Yoda was always one of my favourites and go to to actually imitate so I was my favourite What was yours?

To be honest, it was also Yoda because he was always the smart one and I fully understand why he did escape to swampy island far away from everyone else. I mean, I sometimes feel the same although I try to I try to have a bit better contact with people so So I live outskirts of my city rather than an empty planet. Oh, I see. didn't finish we have now we have something from LM. My town they are. Yeah. So yes. I I learned one thing during one dry run about you about this containing voices.

Everyone's like I said, Yoda, it was just because of that. I remember one day I just added no or was like, strong with the Force you are. And I was just like, oh, okay, why not? Let's do that. And like I said, it was Kermit the Frog that originally started because it was Kermit the Frog here. going to teach you about multi dev environments.

But you're much wiser. And to be honest, this was really the the I think it was the most important moment of our dry run. When I learned about this. It was like, it was like amazing. Yeah, because we are still waiting a moment here. And those creating of new environments sometimes can take longer, sometimes shorter, it all depends on on our main on our main environment, because if we have a bigger database or a lot more files, they have to be copied from one environment to another. So yeah, suddenly, it all takes time. And now we reach this and

I was gonna say actually, the cool part about that is on terminus, when you actually create that little part, you can actually define from where you're actually cloning from to That's the cool part about it. So it's like, oh, do I have to do it from live all the time? Not necessarily. Right? Let's say you're doing between two different environments. You want them to look about identical as possible. So you can test something like doing a B testing. Right? You don't have necessarily cloned from dev test or live you can do it between a different multidomain environment as well.

Yeah, yeah, that's okay. So everything got deployed. So let's see. First of all, is the site working, because this is, this is the first thing is, let's go into the readme HTML. As we got those Smiley's everything is perfectly fine. And the cool part is here, as you see, we exported this variable, the site URL. So after the deployment, we can play around and start automating some tests, because there are many ways we can we can test so first of all, let's check if the website is alive after each each deployment because this is one of the most, most important things now It certainly takes a while because we have so many actions. And while I'm streaming and everything at once, it's so it's the web action. New Relic Web. Okay, so we can just use our, our variable here. Yes. And I remember that we have something in the footer, just let me go back here. For example, we have this proudly. So let's check if the site contains probably this is one thing, let's add this action. And another thing, maybe let's test the lighthouse score. Because it's also something very, very important these days. So let's lighthouse. And again, we are just using the same, same variable. So every time we deploy a new, a new brand new environment, or we use the same one, because now let's just go here, and maybe change something again. So you can see that. Yeah, I'm going to, I'm going to do something with a readme. HTML file, again, because it's one of the easiest ones. It's much easier. Oh, I did not refresh the file. Let me do it right now, because I already see that it was the previous version of the readme. Oh, no, it's Sorry. It's the wrong branch. Yeah. Yeah. So we'll, we'll change it in a second.

But I like what Alan said on there, too. One of the things that he likes to do is visual comparison testing. Oh, it's a phenomenal way of doing it, too. Yeah. But it makes it easy to that's that's the beauty of it.

Yes, we could also do it, but we would have to learn to twice and I think, yeah, but using the visual testing could be also a great thing. Now. The Edge browser, behave nicely behaved nicely, because you are trying now to Okay, so let's go back into the readme HTML file. Let's delete it again. Checkmarks do it. Yeah, we can. Yeah, really? I think I will have to invest in a bit. Oh, the pigeon is responding. Let's wait a second. Yeah, I should really invest in a bit better. Computer for streaming. I never thought that I will be doing this in my life. Yeah, this is something that you that you constantly learn.

Really, we're always learning too, though. So that's good.

Yes, we are constantly learning things like this. And for some reason, now. This is really getting out of hand. So let's refresh this once again. And I hope this is the last time Okay, now it's perfect. There this we did it. So now let's add some sad faces. Because it was a bit troublesome to me. Let's commit directory to web one branch. And let's see what happens in a second. It should. Yes, it's running already. And let's take a look at at what is happening. During this action. We see the multi def web one already exists. So skipping creating it And now I just realised that there may be one thing missing in the script. But we'll see, I may be wrong. Now that we are pushing this change into into Pantheon and right. Yeah, it was a quick test, because everything was and we said that the validation is successful. So that so it was it was responding. And now we are waiting for. For the lighthouse results. And we see it was 99 100. So we passed everything, everything is working. And all of this that we were able to pass to pass our variable, I mean, our URL as a variable. So so this makes it really, really cool. Okay, so we already played a bit with all those environments. But what if we would like to push them further, so we would like to merge them and move them to first the development environment, the test one live one. So here is a little, a little problem that we discussed earlier on where we Tulsa. So because we are using two separate Git repositories, you have to remember that only one should be the source of truth. And it should be the one that you have in GitHub, not on pantheon. So the best practice would be not to use many as many features as possible inside of the dashboard. So if we would like to merge this branch, the best way would be, I think we did we create a pull requests about the web knows, now we didn't, I skipped this, but let's create quickly a pull request. Because so let's do it, we have let's create the pull request. Let's create it and let's merge it automatically. Merge pull request, confirm merge. So at this moment, of course, everything will run here, because it will try to push everything into sorry, it was this. Yes, I was I was playing, I was playing around with something. So here, it will just push everything into that development into the development environment. Also, because I set it up to run automatically, I should do it due to run manually about it. It's that big of a deal, I created an action that will move everything from development to test. Again, we were using terminus for this. So there is just one action for this. And again, the environment it looks like like in the previous one that we are doing. First of all, we are authenticating and we are using this command, Terminus environment deploy, we're using our name and dot test, it means that we will move our our development code into the test environment. We can also use dot live, it will move our it will move our test site into live site, right? Yep. Yes. And there are some parameters if I remember, could you? Could you tell us Yeah.

So on test in particular, you could actually do when you deploy, you can say yes, I want to clone from live environment. And you can also add the I think it's the clear cache. So once that's done, obviously deploying, it'll clear the caches shortly after. Which is cool. And it's amazing at times, because it's caching likes to be cached sometimes.

Yes. And if I remember, we can also move something without the database without the content and the this is this is the thing that happened here because it was deployed code test, and deployed code to test that's it. So at this moment, if we would go to the test environment, we can click the visit test site And if we would go to the readme HTML we should have for some reason,

we need to deploy it.

Yes environment or en V colon deploy. And you can deploy, test and then deploy to live.

Yeah, so we could also automate it as a part of our, our pipeline. Or not, it's up to us how we want to how we want to work with it. Because yeah, we have the saying, it depends. It depends. Uh, we are waiting. A moment for for this. This is this one. It's on up here. So yeah. Yeah. Yeah. About the Star Wars again. Which trilogy? Do you like the most? The oldest one? The new one or the new one?

There's only one the original three.

Yeah, it could clear caches.

So what's really cool, like I was saying, multi dev environments are freaking amazing, because you really can test a lot of stuff. We actually when I when I was on the support side, a couple years back, we had one company who actually redid their entire site, like they rebuilt the entire theme, the entire look on a multi dev environment and then pushed everything live, and it just worked for them. And it was ridiculous to see like, I think it was maybe a couple months worth of work trying to get everything sorted out. And because they were able to clone from the live environment to that multi dev environment. They were always like, okay, so it's gonna work this way, it's gonna work that way. Then push into dev then push into that test environment, they were actually able to test even further being like, Oh, we can load test most of this stuff. And it's it worked for them, that they switched everything off. They're like, oh, it just worked. Which was awesome. It's great to see. And one of the things that I like doing is recommending, especially if you're like starting with some something new is testing plugins, right? You can test updates that way. That's kind of how we used to do it over at web dev studios. You'd get the git branch, you'd branch off, create a new update version, test that way, the cool part is you can visually test now because of that, as Alan was saying, that comparison, it makes it so much easier for you. You can test core updates this way which before you'd have to do everything on live or even on a staging environment, which not always going to happen because you have people constantly doing something. Mm.

So yeah, and and in most cases, we have one staging environment that we would like to test many cases. I mean, it would, it would really work great having together using bedrock, because bedrock is using composer, comm composer to manage plugins and our core, so it would be so much easier because we just change the plugin name, we just change the plug in version, we just push it to another environment. And we can see what happens.

So that too. So on on the platform, we actually have a way of using integrated composer. So all you have to do is actually push the composer lock in composer json file, and the platform will pile everything for you. That's actually a really cool way of testing that feature to in a multi dev environment being like, Oh, hey, well, this worked for us. If it doesn't, you can at least say hey, we tried it out. It doesn't fit our needs. If it does, awesome, you can push it to the main branch.

And also, there is one amazing thing about such testing approach because every plugin, like to leave something behind in the database, for example, or file somewhere in the uploads. Most of the plugins don't clear, don't don't clean up after themselves too well. So in this way, when we put everything into one of the multi different environments, and we just decide that now it wasn't that it just left all this garbage inside of the multi dev environment that we will just remove if we were not satisfied, or we were satisfied, but we decided, okay, so we'll implement it time to create a task like time to create what we want to do with it. And the whole, the whole story about it, we just did the testing. So the basic if, if it's working, if it's not working, if it's working as it should, or maybe the server exploded, the minute that we activated it. So yeah, this and this is something really, really great. And tell me it's possible to switch the version of PHP on different multi dev environments.

Yep. Yep. That was actually one of the things too. I can't remember one of our universities that we host, they're like, Oh, how when, when PHP 8.0 came out, I code you guys have it on the platform? Or like, yes, at the moment. It's slightly, of course, in beta version of it all. And like, Oh, can we test? Yeah, you just change this little flag on the Pantheon dot Yamo file, and it will rebuild that container using that PHP version. And so you could literally have each individual environment testing like, Oh, 5672748, and I want to say eight one is coming out, but I don't fully remember when Oh, which I was like, Ah, I'm looking forward to that, of course, because, you know, eight one.

Yeah. But this is this is a really amazing way to just to test test your test your stack tests, your plugins, it depends whatever you are doing, because you will behave a bit differently when you are a plugin developer when you are a theme developer when you're an agency again, I mean, I should have this big banner just saying the bands.

Yeah. Another actually came to mind was like the forms plugins, you know how many WordPress form plugins are, they're really out there available, you could literally test almost every single one of them on each individual multidev environment being like, Oh, here's one for Gravity Forms. Here's one for WP forms, here's woo forms. Here's this other one, you can test our form

seven, the contact form seven is seen as the one a normal. For me, contact Seven is the one and only because I can put it old is shortcodes inside of HTML, so I can do whatever the designer fobbed off. Okay, so honestly, if any one of you in the audience didn't yet, try the multi dev environment, really do it really do it because you can even use it in the sandbox mode. So just for the internal use, for free. This is the way how I did it and how I ran this webinar so you can really work with you. The only problem is that you can probably use your domain you have to stay on the Pantheon site. I'll probably right. Yeah. So So for testing, it's not that big of a deal. And if you Get used to it, you will probably be interested in buying it because it's a really, really helpful tool. Okay, so yeah, we have some questions. And if you have any more questions, you still have time to ask them in the in the commands on YouTube, on Facebook, on LinkedIn, wherever you are watching else. So let me see, we have this question from, of course from Elon. I've encountered a fair amount of issue when deploying code Pantheon over the years, what suggestion Can you provide when using a private GitHub repo and pushing changes to pantheon?

So one of the first ones that comes to mind is obviously, if you haven't already look into using a custom upstream. That's one way the other could potentially be, depending on what kind of issues you're having, obviously reach out to support. I know, at one point, when, when I was at the web dev studios side, we did have some issues from time to time when it wouldn't push completely. Like it missed one or two folders. And we couldn't figure out why even I'm still stumped on, like, why it wouldn't push certain things. So I was like, That's a new one. So we just redeploy again, and it would show up. So it was really interesting to see.

I mean, I think that the way that we cover it during the webinars, so not using the terminus to do it, but just create a separate action to push something to navigate. This should solve many problems, although if you still encounter them, yes, contact the support of our because it's Alan, you know each other. So yeah. You're probably have a private chat after after this webinar. Okay, and from what I see, this is, this is the last one. Okay, so I think it's time to slowly wrap up everything. So first of all, thank you very much for, of course, for helping me with, with the multi dev environment, I really learned a lot it was, I really had to play a bit with bash and learn it because I'll be honest, in most cases, my bash skills are just those one liners. And this time, I had to write the script behind the one liner. And I think the cool

thing is, if you learn from it, that's actually what I ended up doing too. Because we have an internal site there. We have like eight internal sites that we use for like training. And that's kind of how I learned like Bash scripting as well using Terminus with that. We update all these sites all at once, and it's just automated now. All I have to do is click a single button and it does everything for me.

Yes, I mean, the terminals is very powerful tool. You just have to get used to it. That's it and then connect all those all those skills. I mean, like I mentioned, bash is quite different than writing in PHP. So but as you said, I learned something new and, and probably few more webinars, and then maybe I will be doing a webinar on Basics of bash, or how to start with only should or I don't think so.

Volunteering, it looks like he's, he's automating everything with bash. So,