How to deploy PHP with Buddy

Hello and welcome everyone. Today, we are going to discuss a bit about how to deploy PHP applications with body. I will be your host today, my name is Maciek Palmowski. Normally, I work here as a WordPress ambassador. But apart from being a WordPress ambassador, I spent many, many years working with PHP. I think WordPress, of course, so I know a thing or two about deploying PHP applications. So before we start, let's set some ground rules today. So the whole webinar will be will consist of two parts. First, I will show you some things about the basics of deploying PHP using Buddy. So we will go through deployment, managing dependencies, building them. Later, we will also talk a bit about how to optimise the whole deployment process to make it faster. And, of course, I won't forget about adding notifications, because this is something very, very useful. Apart from this, later, I will show you a bit how to connect Buddy together with GitHub pull requests, because this is a really cool feature. And I think it will, it can save a lot of time when you use it. So I really encourage you to do so. And in the end, I think I will show you how to create a simple uptime robot application using body. So and so this will be the first part and the second part I will try to answer as many questions as possible. But if there will be too many questions that the will be able to handle, don't worry, I will create a separate post with the questions and answers and we'll publish it it quite soon. Okay, so with this out of the Oh, and remember, if you have any questions, just post them in the YouTube comment section. And I will try to answer them in the end like I mentioned.

Okay, so let me share my screen. And let's start with our application. This is a very simple application that I that I created just for this webinar. First of all, let's take a look at all the dependencies. Let me just make a small zoom, it will be better for you. First of all, we will be using composer and in composer, we will require this library called masters. This is something glad this is very simple PHP templating engine. It's much more simple than twig or blade, but it will be enough for for this demonstration. Also, there are some development dependencies. We will use at some point, PHP stampede unit or code sniffer. Those are code quality tools, which I think is always a good idea to use in our project. Also, this product uses PSR four autoloading. So we don't have to use all the includes to include all the classes, everything will be included automatically that based on the name namespacing the folder it is and as you see here, I already prepared some scripts, so it will be quite easy to run them using a composer just by running composer run and pap unipi Stan or something like like this. Okay, so that's all about composer. We also have package json because most of our project will will consist of some CSS. So I will cover the basic here too. This is a very simple situation we will be installing node Sass and we will run this script called compiled styles that will run Node Sass and compile style css into style css. That's all. Apart from this, let's take a quick look into our index php file. It's very simple. We're just requiring the autoload php file. This is the our main class. Here you see we are using the the master engine. We will load the template called index and we will pass some data from the main class. This CMS list is just that array with few few CMS names in it. That's all. And let's take also a quick view and our index moustache. should file. So as you see, this is a very, very simple HTML, the only dynamic part is here, when we will go for all the position on the CMS list. And we will list them as as another position of the unsorted list. That's all. So, let me check with did I didn't miss anything. So let's start with connecting this repository to Buddy. So let's create a new project.

I already connected my GitHub repository, I will be using GitHub in my situation. But of course, you don't have to use GitHub you can to use GitLab, you can use Bitbucket, you can use any private repository, or you can use our built in Buddy git repository. So it's really up to you. So we will connect this repository called webinar. And after a few seconds, the project is already important.

So the thing we are going to do first is create a pipeline pipeline is nothing else than a set of actions that we will run in the order we we selected. So let's call this action, edit pipeline deploy to production. And there are three trigger modes we can do is going to be triggered manually. So every time when we will press the button, the action will run on push. So every time when we will push an action into this branch. So into the main branch, the pipeline will automatically run or we can use, we can trigger with recurrently. So it will run for example, every five minutes every hour every day, whatever we select, but we for this simple example, we'll just do it on push and it will be created with that main branch. So the pipeline is added. And in a few seconds, we will be able to to add actions. Okay, so what we have to do, I mentioned that our application is using composer and NPM. So we have to build them first before we can deploy anything.

So let's start with the with the PHP actually, the only thing that we have to do is of course run composer instal. And now we have to run. Sorry, we have Earth composite installed, but know that this means that we won't instal those development dependencies because we don't have to instal PHP sniffer on production. Just take a quick look here, we'll be using PHP seven dot for an environment. This is a really cool feature because sometimes we will need to learn something either in older or newer version of PHP, and this is very easy to change. I will dive into this a bit more in a few minutes. But I just wanted to show you that we can really easily change the PHP version. Okay, so composer instal node Dev, let's have this action. So this is our pipeline right now. But that's not all, we have to also add.

This does no node action, because we want to run this node sass. So let's add a node js action. And here we're gonna run NPM instal. And then we're going to NPM run compile styles. No typo, that's perfect. Okay. And this is the same thing here, you can see we will run it in the node 12 environment. And yes, we can change it very easily. So we are adding in a command right now.

And the final thing we want to do is to deploy it on our server. With Buddy, we have really many methods in which we can deploy the project we use SFTP, we can you use the normal FTP, we could use SSH. And there are many, many more actions right? Right here. For example, we can use amazing to deploy something we use Google Cloud, Digital Ocean, it's really up to us. But in our case, we'll use that plain old SFTP. Okay, and here are some things that might interest you. So let's start from from what to upload. We have to select the source. And here we can choose between GitHub repository, this would mean that we will upload exactly What we are having in our GitHub repository. In our case, this is not the way because we first want to build some artefacts and we want to deploy also some folders that will be created in our pipeline. That's why we will be using the pipeline, pipeline file system. Source Path, yes, we want to upload everything, the think. So let me just enter credentials. It's right like this. And here, you will see a very interesting thing, that remote path because we have to put it somewhere on the server, not directly into the route. And because I entered the correct credentials, I can browse through for the whole server and choose where exactly I want to put it, I want to put it in that webinar folder. It's empty. So that's great. Let's use this. And one more thing that we have to remember, remember, it's the economic path, because we sometimes we don't want to push everything that we have in our file system. In our case, we don't want to push the node modules files while because we all know that it's huge. And it consists out of many small files, so we don't want to push it on the server. Also, we just want needed. So we have everything kind of modules, great. The credentials are perfect. We want to run from pipeline finances, and great, let's add this action. So this f we have everything prepared, we have, we know that it will run on push. So let's first let's look how our site looks like right now. It's forbidden because it's empty. So it's correct. So let's run a simple change into our index file, we're gonna we are going to change we are doing not only a cool webinar, we are doing a super cool webinar, right. So we will commit it directly into the main branch because we want to trigger the whole action. So we did it and take a look what is happening here, it's already running automatically, I didn't push any button. And it's running, it's compiling. So we already have, we can take a look. Everything was the moustache was installed. And downloaded. Here, we can see that node SAS was installed and downloaded. And now everything is pushed through SFTP. The first time when we upload our project will in most cases take the most time, because because we will push everything for the first time. Next time we will push Buddy will only push the things that change. So you will see the difference. But still, it took only it took only 49 seconds. So it's really great. So let's take a look at our website. Yes, it is working. It's really truly amazing, right? I'm a developer, I'm not a designer, so So I hope that you didn't fault that it will look any prettier. So okay, it's great. We deployed our application. And it took us with all my rambling about 13 minutes. So this is pretty decent.

But now, let's let's dive into few things a bit more. Because before going further. So let's start with the really great thing about filesystem I mentioned it for a moment, when I was going through the FTP SFTP action here, all those blue icons have, those are the files that were in the Git repository. And all those violet or pinkish icons are the files that we that we created during drink hour. So this is this is something you should know and at any point if you'd like to check what is happening in which file, you can just click on it and you can see how the whole file system is looking this is something really useful especially when you will be debugging some stuff. So how like Adrian monk from from from from this TV series always said you will thank me later and okay so so we Got this. Now, let's try to optimise what we did a bit more because it didn't take too much time, but we can make it run faster.

First of all, we don't. Currently we run action after an action after an action. But we can run some actions in parallel because we don't need to wait for composure to end to run NPM we can connect both both actions and run them in parallel. So let's see what will happen. That's right, let's run the pipeline manually. And, yes, let's run it now. You see, both actions are executed at the same time. This, this can really speed up the process, especially where if you're, if some of the process will are taking a bit more time. Next thing, but why are we running some actions every time because we didn't do any change in our CSS on in our composure file.

So we don't need to run those actions every time, it would be great if we could run them only when we need to. So here we have this tab called condition. And in the condition tab, we can select when to run this action. And we have this great thing like run only if there were changes to specific path in the repository since last execution. So in our case, we want to run it only in two cases. First of all, when we will when there will be a change in the composite JSON file. And if there will be a change in some class that we have in the SRC file. So let's save this. The same thing goes with NPM. We don't have to run it every time, we can run it only when either we change. So let's again select this when either change something in the package json file, so we have some new libraries, or there was a change in our scss file. So that's all let's save this action. And let's see what will happen right now let's run the pipeline. Let's click Run now. And you can see that both actions were skipped because we didn't do any change in DOS. So we didn't have to run them at this time. But okay, maybe I'm cheating a bit. So let me show you that this is really working, let's do a small change in our scss file. Let's go into the public. And to style a CSS. And here we have this. So let's click that. And we will change the background. Now it's pink, so we'll change it into maybe white it will. Sorry I did here into white right should be okay. So headlights committed directly into the main branch. So we are committing it. And we can see that the server can see that it's running. And let's see what is happening. We see that composer skipped because we didn't do any change in the PHP and composer json file or in any class. And on the other hand, we did the changes in the style css. So the NPM run compiled size large this time. So yes, this is this is how we can optimise our pipeline. So not only our deploy, our application is deploying to our server. It's deploying quite fast. But we have to look at that Buddy admin panel to see that that everything is working fine. And it will be really great to know that to send a notification to ourselves if something if if the deployment went correctly or when it failed. So let's do so.

Let's add a new action. I am a big fan of discord. So we will do use discord at this time but of course you can connect Buddy with many with other communicators. You can use telegram you can use Slack it's really Up to you. So let's click this cord. Let me copy one thing. Here, I have to provide the channel webhook webhook URL. So let's add this. So every time while all the task will, will run will send a notification to discuss. So let's also add, because as you see, you can also add actions when something failed. When actions will get back to normal, when there will be a warning, or when there will be wait for approve, we can separate all the different scenarios. But during this webinar, we won't dive in, we won't dive into this. So let's add one more discord action here. So if it fails, let's be great to have a notification to. OK, so this should be this should be ready in in a second. Let's go back let's so let's run it. I will show you my discord in in a second. It was a very quick one. And here we have deployed to production by me status successful execution. So yes, it is working from now every time when we will successfully deploy our application, we'll get a notification on Discord. Also, every time when something when something fail, we will get a bit different notification that will say that the deployment failed. Okay, but we still aren't sure about one thing. We moved all the files, get the notification. But are we sure that our website is working? We don't know this. So currently, we should after, after we see the notification on Discord, we should open our browser and see if our website is still running. But we can automate it too. There is a very cool and useful action cold web. And let me run it in a moment.

So we will have here this action is quite simple to use, we just have to enter our URL. And it and it will ping our website to see if it's working. So let's run it and let's see what happens. Our website is working. So everything should be should be fine. Write it again, when when very quickly because of all the actions skipped here. But we can see what happened. Here we can see that the web, download the whole HTML, everything is working. If there will be an error, we will get a failed message. And this is this is something really important to have in our pipelines. Because thanks to this, we don't have to worry about manually checking everything every time. Okay, so our applications on the server, we are getting notified, it's getting basically tested things in a way.

So now it's time to add some continuous integration. Continuous Integration is that philosophy to test everything every time. So we will add some tests that will run on each pull request we will create. So first, let's go back for a moment to our project. Just to remind one thing that in composer were installed, we have few of those tools. We have PHP code, Sniffer, PHP, Stan and PHP unit. And we have scripts that will that will run those tasks. So we will now create two new pipelines. They will be called CI while one will be called PHP Stan. Stan is a static analytics tool that helps you to find some bugs early and it just cares about your code quality. It's a really useful tool that I also recommend to use every time but this time we won't be using single branch we will use branches by wildcards. So every time we will run will create a branch we will run on something on some new branch it will run so this is one thing and we will also create we will also create a unit test action. Okay, so Let's Oh, I just kept him up the code, I would forget about this. We have to this time we have to composer instal, we have to instal everything. And then we have to we have to use composer run PHP, Stan, that's all, let's add this action. This is the one action we have. And let's add a second action because it will be easier to see what went wrong in our product. So let's use PHP unit. And again, I'm Bush branches by wildcard. But this time, we will we'll have to compose around PHP unit, because we have one unit test out there. So it's taking a while. And, again, PHP. And this time, I'm copied my Okay, so everything is prepared, let's. So we have those actions that are here. So let's create a new pull request, let's change something in our code. And I think again, let's, let's use our index file, because this is quite nice file to edit, and it will trigger a change. So we realised that maybe we overreacted with this super cool, let's just let's get back to cool PHP webinar, this time, we'll create the new branch and start a new pull request. So let's call it webinar, patch, one that propose the change. And here on this, on the screen, we have, of course should leave a comment or something. But let's just create a pull request and see what will happen because this is a really interesting thing. Those tests were really quick. But as you can see, all checks have passed. And we take a look, the PHP stat and PHP unit round in the background. So we know that there are no errors, at least in those tests. So we are quite positive about this pull request, and we can merge it into production. So let's do it. Let's confirm, confirm the merge. But again, maybe I am cheating a bit, and maybe it will always run correctly. So let me show you now let's we're going to do another pull request, but this time, it will fail. First of all, let's take a short look at the unit test that we have. It's it's very simple. This CMS list because consists of three positions in it. And we'll test if it has three values inside of this error. Alright, if there are more or less, it will throw an error. So knowing this, let's do a change into our main main class in PHP. Let's we're going to add a new one. Let's add you have group also Joomla is missing, right? Let's add the Joomla in the end. And let's create. So CMS propose a change. And this time let's create a pull request again. Let's see what will happen this time. As you can see some tags were not successful that PHP unit build failure. And we can click the Details to see what went wrong. So we will open Buddy in the new tab. And here we can see what happened failed. asserting that actual the actual size four matches expected size three. So everything went as we planned because we knew that this will throw an error. So because of this bug, we can either just remove this marriage because we know there is a bug or we can fix it or maybe there is a bug in our test. Now it's really up to us to fix it or not. But in our case, let's Let's just remove one CMS from the list. So, so everything will run out We're going to run file. So let's remove the Shopify because let's just have open source. CMS is on the list, let's commit the change. And right now was going to this part, they're still running. But this time everything went Okay, so let's, let's merge the pull request, let's confirm it at this point, because we also have everything set to it to production, run on push, we know that the deploy to production also run in the background. So if we run it here, we will show that Joomla is on the list. So this is how this how we can add this continuous integration, together with body and GitHub, and GitHub. So this is, like I said, this is something really useful that I also always recommend you to use because it will enable you to spot all your bugs early on. And really, this is something that will save you a lot of time. So the last thing I wanted to show you is how to create a very simple uptime robot application.

So let's call this uptime row uptime robot. And this time, it will run recurrently. So every five minutes, this, this set of actions will run solids at this. And we are going to, again, add is action called Web because this is this is very useful for for us are in this one. My mistake, Clinton copied the URL from here. The URL is correct. So let's add this action. And apart from this, we are going to post the notifications every time when Sorry, my mistake, we're going to post a notification every time when the website is working, of course, on production, I would do it only send notification where something is wrong. But this is a simple example that I will just want to show you that how it works. So we're going to send this notification here. And we are going to add one more notification in the failure section. Oh, okay, so this is ready, let's, let's run it manually, because I think we have better things to do rather than wait five minutes to see what will happen. And we see that the uptime robot by me successful execution. And if something will fail, I would get a bit different message. So let's, let me show you that this works. So let me try to bring in URL doesn't exist. This will return 404. So if if it will return a 404, we will get failed execution. So let's wait a moment. It's trying to find it. But 404 takes a bit more time. And here we have failed execution. So this is a very, very simple way to create. Let me just turn this off, because I will start getting messages every five minutes. And I don't want to get get them right now. So this was a fairly easy way to have your own uptime robot application. OK, so this were most of the basics I wanted to cover. I want to show you few more interesting actions because it's hard to show all of them. First of all, not all will be useful together with our PHP applications. Apart from this, we have more than 150 action. So I think we will have to spend about three hours just going with action after action after an action.

But still, I want to show you a few very interesting actions that you really might find useful. I will just add them at the beginning of doesn't matter right now. And I'm just going to tell a few words about them. We have a separate website about all the actions, so it's worth to check it out. So first of all, we have an SSH action, add and click on it so so we can connect our server and run commands on it. This is very useful if you would like to, for example, create a database migration or the whole backup, or maybe we'll just want to run a script on our server, not in body, but on. But on our server, this might be something very useful in this case. So So yes, this, I would really recommend it to you to learn about it. We also have a local shell. This is this does quite a similar thing that SSH but we are doing this in on body. So we are trying to execute some action inside of body. So we can put the result into our file system and push the result. Next thing I wanted to, to mention, would be, like I mentioned a bit before we we have some other methods, I'm just showing you that there exists, but you might use it. If you're using Cloud for clearing cloud, cloud for cash at the end of of each execution is also something very, very useful. But I'm trying to find those actions a bit below because we have a really interesting set of Yes, performance and up monitoring tool. So first of all, we have lighthouse. This is a very easy way to make sure that our application after some change in our code didn't drop in terms of performance, accessibility, best practices, our SEO, we know how it's important to Google. So it's a really good practice to enter our URL here and tested after edge push to see if nothing broke, because it's easier than to pinpoint which change the damage. So I would really, really encourage you also to do this action. Very useful tool, like the link value the link checker, because we are humans, we make typos. And this is one of the best way to spot them. Again, we are just entering our URL, we specify how the how deep should the audit go. And we will get the result of all the websites that that returned either 404 or 500. Error. So again, very useful tool to spot some spot, some some box, and one of my one of my favourites, visual tests, because we, again, we are humans, we make mistakes. And sometimes we just even don't realise that doing a fix at one point of our website will affect something else. And here we can enter few URLs we want to check. And we will compare the screens of before and after deployment. So thanks to this, we will be able to see if the changes that are made are the changes we want to deploy. And if not, we can stop the deployment before happening. Okay, so I think that I covered everything. I think we went through fruit fruit for all the all the things I want, I wanted to show you. As you can see, it was really easy to deploy and test application, we were even able to create a very simple, continuous integration process in GitHub.

And so now it's time for some questions, because I see we have we have few of the of those. So let's start with a question from Carlos. Is it possible to differentiate between draft pull requests and normal pull requests in terms of the push that triggers the pipeline to run? So? No, because we the only thing that we can do is connect the trigger with with a branch and the branch the branch is every time is created. The pull request isn't a trigger. It's the branch itself, so it will run every time. It doesn't matter if it's a draft pull request or a normal normal pull request. screen it will run every time. So it depends if you want to test your application every time that something good if you like not to test during the draft stage, then sorry, it's it's not possible, like out of the box. Yes. At another question that we have is from Jacob. Assuming a you're using a trunk base branching strategy, in good, how could I use Buddy to create a continuous deployment pipeline. So let's start that trunk based is, is the method when we are using the main or master or whatever is that is the name of our default branch. And we are mostly working on it, we are just creating, let's call it short, sharp pull requests for the branches that we immediately after fixing are pushing back into the into the main one, we don't create, like release branches. So it's fairly, it's a fairly simple setup. And it's really great for for small teams. And with with the theory out of the box, other window? Yes, we can use and to be honest, I showed this during the webinar, because this is exactly what you do. So every time you will create a pull request, and you will set the triggers and on push and you will set the wildcards. It will run that's all so yes, but it is perfect for for such for such scenario. Here, I got a question that not fully about the today's webinar. But yeah, I think it's really worth to answer it. Because working test sandbox for each git branch would be a dream setup, how to do it. So the bad news is at the current point, you can't but the good news is that you will be able really soon we are working on it, and you should be able to do it quite soon. I talked with our CTO yesterday. And he promised that this is the feature that is already in the test. So so keep an eye on those tests. And I see I think this is the last question I have. Yes, it's from Damien. He asks about the optimal workflow CI/CD for WordPress applications. So I would say, first of all, we did a webinar once with awesome studio about this. So you can check it out, because it was quite a similar topic. Awesome studio shared their experience on how do they do it. But I would say that some things that I that I showed here. So using the continuous integration of pull requests, this is something this is something really, really important. Personally, I was always a big fan of, of using bedrock to make the whole setup quite easier. But like always, you when you want to create create the optimal workflow for CI/CD. It's mostly about running the tests. So you will have to create some tests to make sure that your deployments will go through and you won't have to worry to check it out. After the deployment finish, but but this is really a topic for for a whole for a whole webinar. Like I mentioned, you can watch our previous webinar we did with awesome studio and Kinsta. I think it should it should that the Bartok showed some some interesting, interesting practices that they use and you could you could benefit from it from from this too. Okay, so let me see. So yes, this was the last comment. If you have any more questions, this is like the last chance so probably I won't answer it right now. But there, there will be a chance to answer it. In the q&a article, I really hope that I they help you and show the basics of using Buddy with deploying PHP applications. If you have any questions, don't hesitate to to find me on Twitter or you can find me because this is one of the best ways to to find me is search for honours here and yes, you can find me here and you can ask me any question I will gladly help help you. Apart from this you can always Ask our support. Those are very, very lovely, lovely people and there, they would really love to help every every one of you. So, like I said, Thank you, everyone. Thank you for listening. I hope that I help you to start your your adventure with Buddy. Or maybe you learned some new some new tricks. And soon we will be back when with some more onboarding webinars to show you the basics from from different from different topics. So thank you very much. And see you next time. Bye