Customer stories: Why WP agencies should use CI/CD

Hello, everyone, welcome to today's webinar. Today we are going to talk why WordPress agencies should use CI/CD. I have two great guests with me. It's Justin Foell and Greg Ricakby. They're both from Web Dev Studios. Guys, tell us a few words about yourself.

Sure, I'll go first. My name is Justin, I'm the engineering manager at web dev studios. My job is really to support our dev team in all aspects. So I occasionally play lead engineer when I need to also tend to do some of the DevOps work. So I tend to work in Buddy occasionally when I need to get things working, and really working closely with Greg to make sure that everybody is heading in the right direction.

Thanks, Justin. I'm Greg Rickaby. I am the director of engineering at web studios. And I've been there almost nine years. And like Justin said, he works with me, as we direct the department in a certain direction. That direction is set either by me collaboratively with Justin or by our executive management team. And my job is really to support Justin and the team as a whole. I also wear several hats hiring manager, also sales engineer. So I'm on a lot of potential sales calls and always talking about ways to solve problems with people that we aren't even working with yet. So love my job. I'm excited to be here and talk about CI/CD and how much has helped our company grow.

Version control: That's great to hear. And I am Maciek Palmowski. I work at Buddy as a WordPress ambassador, and I am your regular webinar host. So before we start talking about CI/CD, about automation, if you have any questions, you can ask them using either YouTube or Facebook. Comments, it depends. Where are you watching us. And if you like our webinars, don't forget to subscribe to our YouTube channel. There are really a lot of cool materials, not only webinars, there are also some tutorials showing you how to start your adventure with Buddy and different technologies. Okay, guys, so let's talk about automation. But before we start talking about CI/CD, we first have to talk a bit about the foundation on which CI/CD stands. So version control. So what do you think should we use it? Or is pushing everything through files is a great way.

I mean, it's, it's interesting, I thought about this, because it's been a while since I've talked to people that aren't using version control. But when you think about WordPress, as a whole, it has over 40% market share of websites out there. So there's going to be a super wide spectrum of development processes from you know, people are doing like no code or low code solutions, where they're just, you know, adding plugins, configuring stuff in the themes all the way up to, you know, enterprise businesses that are have like highly configured, rigorous releases, and everything in between. And I kind of have to like take a step back and remember all the people that still are working with WordPress and not using version control. So I know they're out there. And I just want to advocate that. You know, even if it's not on their radar now, it should be on their radar going forward.

Yeah, that's, that's totally true, because I heard that some people don't use version control because they think it makes everything much more complicated.

Right? And you're you brought up the like, should we still be doing that? Just uploading files via FileZilla. And I've occasionally run into like the telltale breadcrumbs of somebody that is still doing that because you'll go into their site and they'll have a copy of this file. And it'll be this file dot dot bak backup or dot two or and I don't I just don't think that's a sustainable way to work. It also is like, becomes a security concern at some point where you've got these stale files sitting around that could contain security vulnerabilities that might still be accessible. through your site. So I think even if you're like a solopreneur, or a single developer, you know, switching to version control, it's not, I don't think it's gonna slow you down as much as you think it's gonna. Like, even if you're just the one guy that's going to commit to, I'm going to make all my changes and commit them to the main branch, I still think that's better than nothing.

I mean, I can understand because using version control, without automation, it may. In this case, it may be a bit annoying, because both of them start to make make make all the wonders when when it comes to automation. But if you try to convince someone about version control, why, why and how, who, how should this person start? Because you can be sure you will hear this argument about Yeah, but this is CLI. It's awful. I don't want to learn it.

Well, sure. Well, I mean, to start, I would suggest you, you don't have to do everything through the CLI. There, there's a lot of people here at web dev that aren't like, like super knowledgeable, the CLI, I think everybody is at least comfortable. But you don't have to be there's several tools out there. I know, tower is a popular one. If your projects on GitHub, you can use their desktop app, which is fine. And most of our development team is using Microsoft's Visual Studio code. And that's got good support built in. So you really don't have to, like go out of your way to add this thing to your workflow.

Personally, I'm a big fan of good crack, and we even had a webinar with them. Because using a Git with graphical user interface is kind of similar of using Buddy because it's CI/CD with a graphical interface. So So yes, this is this is kind of, Okay. What are the biggest benefits for to do use Version Control?

Yeah, I don't, Greg, jump in, if you want to handle any of these, but just keep rolling with this. I mean, for me, it's like, you have the ability to now go back easily, right? That's the number one thing. It's it compounds, though, as your team grows, like, you know, maybe you want to determine when bugs were introduced. Maybe you have like a big feature that you are working on. And all of a sudden you find out oh, there's the security fix, I need to get out? How can you quickly move all that work that's in progress aside so that you can work on the security issue and send that out right away? Like, that's gonna be a nightmare? If you have no version control, or in then maybe it's like, Okay, I gotta created another copy of this thing. It just becomes untenable really quickly.

Yeah, I want to echo that, like, let's just take a quick step back at like, what is version control. At its simplest form, distilling this down to just like plain English, Version Control is taking a snapshot of your code at a certain point in time. That's it. That's all it's doing. So when Justin said, we need to roll something back, because of a security thing, or whatever, or we need to set it aside, if you were working in a feature branch, or even if you weren't, you can always go back to another branch, you can always check out a branch or go back to the start, let's say, I'm working on like the main branch, and I create a feature branch to work on this feature. And I find out that there's a security thing in it, I can just go back to the main branch and start over, without having to like keep track of all of those files, and where I was, all of that is going to be retained in your Git commit history. So that to me, I just wanted to set the stage like that's what at its core, Git is first control is just taking a snapshot of your codebase at a certain place in time.

Yes, and in my case, when it comes to version control, the things that like let's say bought me into into using is where branches or branches because very often, it was the situation when I had to work on few things at the same time. And it was much better to do everything at the separate place and then merge it or sometimes not because it's a quite often thing when when our client and something's decided, I don't need it anymore. Okay.

Right, and then you don't have to worry about taking it out at that point. It just never went in

And when it comes to my personal project version control always gave me also, it was a great help to. Because when I work on my personal project, I don't do it every day, but from time to time, and it's much easier to see what was my trail of thoughts? Why did I did something? Because we all know how it comes with the documentation, especially in our personal projects. I don't know, how are you? How about you? But I'm, yeah, okay. So

I don't have any. Right. Some somebody famously said once there are lies, damned lies and documentation.

Yeah, exactly. I mean, to be honest, I know one developer, who like documented everything even documented, like small gists, just in what I was doing pull requests, and he just wanted to show me what could be done better. And he even documented each line. It was like, it was incredible. Like, wow, I really can't believe that there are people out there like this. But like I said, Really? Wow. It was, it was tremendous. Okay, so we talked a bit about the foundation, because yes, without version control, we can automate anything, because automation works on those snapshots, on those triggers, because automation has to have a trigger, when to run, for example, when we push a new file, or sometimes when we press the button, or every few times. So when it comes to automation and CI/CD. So let's start with the simplest question, what does this CI/CD means? Because I know that this abbreviation is always is always giving a lot of trouble to many people.

Right? I think at its core, it's it's like you mentioned, we're just connecting those commits that we're making. So like the snapshot in our code to an action. And whether that's like, it could be as simple as like, I'm just gonna send this file out to this server. Or you could have, you know, 10 steps that come before that to make sure that this code meets whatever standard you want to set before it goes out. Yeah, and I think that's why we love it is because you can automate it, and then it's one less thing you got to do, I don't have to open up FileZilla and choose the right server. You know, send my files out, I can connect it all so that when I make this commit, I know that if it's on this particular branch, it's gonna go to this particular place.

Yes, yes. That's, that's also, I don't know, how about you. But for me, CI/CD is also a great touristic tool, because whenever I am calling in some coffee place, or something where the internet is poor, I don't have to push them directly from my laptop, right? I just have to send a push to the sea ice to the CI/CD server, and it will do all the all the heavy lifting. But okay, what are the what are the benefits that every every business should consider? Why they should adopt CI/CD? Because we know that many managers have a list of arguments about now we shouldn't know, let's let's let's give it because it will, it will be more complicated. Yes, it will be probably more expensive, we won't be able to release on time, and so on and so on.

You kind of touched on one, just now where you're like, Hey, I'm at the coffee shop. You know, that's actually like a big security concern when you think about that, like I'm connecting possibly through an unsecured FTP site at a coffee shop on a public Wi Fi network. Like there's so many like points, like attack vectors, essentially, where people could intercept your credentials, and now they have access to your production site.

On the web, right? Right.

The thing I like about that is CI/CD solves that in that you are going to send your code to the CI/CD server and it has the credentials that it needs to connect to your FTP site or via SSH to deploy those files. And then it has an added benefit of like, I no longer have to share those creds. With all of my team. I could have five people working on this thing. And they don't need to even know that information. They just need to know that when they make these commits. These files are going to go out

Yes, I will also say that CI/CD, kind of standardise our way and we don't have to worry about some things because we just send a push into this black box, something is happening there. And in in the middle, we decided to change our hosting our credentials. The developer doesn't have to care about it, it will just happen just inside inside of CI/CD. But what about the rest of the arguments? You know, that will be become more complicated? I heard it not, like many times from from many managers that

I just, I want to jump in on the complicated part. Like it can't there is a learning curve. Like you can't get around that there is a bit of a learning curve. If you're not familiar with version control, we'll just talk about Git and not asking in today.

Sorry, about SVN lacks just posted a great comment. If anyone's still not convinced with Greg and Justin points, tell them that Git is better than SVN.

It is on point Lax. But once you get over the learning curve for Git, and you have a pipeline setup in a in a CI/CD environment like Buddy, I would argue that your work is actually simplified. Because Justin mentioned earlier that VS code has support for version control, and it supports get out of the box. So if I'm working locally, and I make a change, and I save the file, and then I just look at the left side of my screen, because that's where it happens to be configured for my VS code, I can click on the verse control button, and I can type in the name of my commit or the whatever I'm working on. And I can hit the checkbox and publish. And then my code appears over there. If anything, my work, workflow just got simplified. Now I'm not having to switch apps, I'm not having to go to Filezilla not having to connect to a server. Now I know that with FileZilla, you connect to a server once and then it's just there. And then you can drag and drop. I've even I know that like on Mac OS you can use what's it called transmit, transmit. And it can set up like a virtual directory where if you just save it, it auto FTPS it up. I mean, it doesn't get any simpler than that. But then you bring up all the points that Justin made earlier is like I'm at a coffee shop, do I really want to connect to the server, or even a VPN or use a VPN? So what I'm getting at is like, I'm able to work in my code editor, I'm able to work on my files, I can save the files, I can check or commit those files and publish those files. And then that blackbox happens where it's sending them to the right place. And I don't have to think about it, I don't have to worry about it. I can wait 30 seconds or five seconds or three minutes, depending on how your pipeline is arranged. And my code changes will just be up there. If they pass assertions, which we'll get into. But you get the point, if anything, you've just simplified and engineers workflow. And if you're on a team, you've just made your entire team's workflow identical. So now you're working on on the project together, and you all have the same workflow. You're all checking code in and out in the same way. And if you set up and structure your code, and standards in the same manner across your entire team, now you are ensuring that your code is going to be formatted correctly and linked it correctly before it even hits a server. So I don't see any drawbacks. Once you get past that initial learning curve of setting up Git and setting up the CID CD CI/CD pipeline. So

yes. And also you forgot about some steps right now, because we also have to test our count, we have to instal composer dependencies and pm depends disease. Like there are a lot of things to remember about before pushing our website. I mean, I remember the times when I just open open my notepad wrote some HTML, and that's it. But right now, it became a bit more complicated. So having that one universal flow that is happening somewhere else, we don't have to worry about it. That's much better. And just for your information, my longest pipeline, that usually usually took 40 minutes, we had one on on amazing Beanstack and every quick fix to 40 minutes.

I want to touch on something that Greg mentioned. And that is like a key word in my mind. And that's team like going back to the solopreneur single developer that is still asking themselves Why should I you even use version control? That is really the it's the fastest path to growing your team to thinking ahead of like, I'm going to add some somebody else to this workflow? Because just imagine yourself working on a project, you're not using version control, how is your new team member that you've added to this project going to know? Like, are they going to have to download everything from the production site? And work on those files? What if you're both working in the same file, and you're going to be uploading those back? You know, it's, and I don't think anybody really imagines themselves going at it alone forever, you know what I mean? So I think this is, that's the way forward is adding a little bit of structure to your process. And then CI/CD is just another thing where it's like, Hey, cool, I don't have to give my new developer who I don't really know, the FTP creds for the site, they can just make commits into our repository, and know that, that stuff will go out to those servers.

Yes, and this is this. This is, I think, a part where we are a bit discussing why CI/CD is a valid way to go not for developers not for but for managers, because managers often just don't fully understand why we as developers needed direct clicking all the time. So it doesn't matter where they are clicking but but this security approach, the easy way to to grow our team way to add some actions that prohibit going up further in our pipeline, either when there is an error on or when we are having a junior developer, and we wouldn't like him to or her to push right now to production, we would prefer to block it until until review or whatever. But yes, this is this is something that every manager should also understand that CI/CD is also for you, you won't be doing anything in the CI/CD. It's, it's not your part, but you will benefit from it like a lot.

And there's a great comment from Victor and chat. I don't feel sure now. Because I totally agree with his sentiment.

When I were let me just show it on the screen. When I work alone. I need a robot to check my work. Yes, that is true. That is true. And hi, Victor. It's nice that you're with us. So So okay, we will discuss the basic of CI/CD. And tell me, so which CI/CD application are you using?

We're using Buddy, no surprise.

I'll go over the why you don't mind that. That's, you know, that was part of my role here several years ago was to figure this stuff out. And at one point at web dev studios, now just a quick setup, web dev studios, we build websites, obviously. And we're a team of 40, some individuals that that get together, and we just build some awesome, awesome stuff on the web. But working as a team, we've already covered this, but working as a team and everybody kind of doing their own thing. It's not sustainable. So what we needed to do was to was to make it easy for our teams to do their work without having to worry about FTP creds and sharing that information and making sure that, you know, they had what they needed to get their code up to our development environments. So we had originally we were on, I think it was called Beanstalk. I don't know if that's still a It's a wild bits, product. We were using that. And then we made the switch to GitHub. And once we moved to GitHub, like that unlocked, pull requests. And when you start introducing pull requests, you can introduce code reviews. And it was, you know, when you have a team as large as ours, and you have, let's say 25 projects going on, you would have to have somebody reviewing the code. And this will go back to Victor's comment just a second. You know, as human beings, we only have so much time in the day to review this stuff. And if you're opening a pull request that has dozens and dozens of changes or files in it can take a long time for a person to review that code. So why not have a robot do that? Right. So we started looking into other ways to automate our pipeline and we we started with deploy bot. And that didn't, we weren't on that long. And we made the decision to go to Jenkins. That didn't last long at all. We quickly realised that, you know, I'm not hating on Jenkins. The reality was, it's extremely complex. Yes. And it required a full time person, essentially to manage it. Jenkins, which we didn't have the capacity to do, nor did we want to. And then we found Buddy, actually, one of our engineers have was trying out Buddy, and she suggested it. So I signed up for it. And we have been on it ever since I actually think we're grandfathered into this ancient plan that we pay a ridiculously low amount of money for, for the amount of stuff we use. So thank you for not making us upgrade. But we've been on Buddy now for four years, maybe even five.

I know which plan you're talking about. I also had it for some time. And yes.

So that's how we got to Buddy is that's the, we needed to scale, our code review processes, our team expanded as our projects got more complex, as clients, our clientele got bigger. We went from, you know, small, SMB, to now we're working with the NBA, Microsoft Viacom, they expect a certain level of automation and QA, along with, you know, their projects. And we needed to, to scale to meet those demands. And Buddy gives us all of those things. And just real quick, why did we move off of Jenkins, which makes I think everybody, most people on this call or on this webinar probably are familiar with Jenkins, they know it's probably the standard, or Travis CI or, or seven, circle CI, the other ones. But the reason we went with Buddy is the use user interface is awesome. It's simple. If you want to add a pipeline, you click this button, and then you can make these connections. And you just, it's very, it's beautiful. The user experience the UX on Buddy is why we're still there. It's also reliable, it's never been down like it's been great. So that's why we're on Buddy is we love the user experience. We love that we're grandfathered in, and they're not nagging us about upgrading. We love that. Everything just works. And we can make really complex pipelines very, very quickly, to ensure that our teams are able to scale and move code across the Kanban. board over to production on Thursdays. So because we don't ship on Friday. Don't ask because we will.

Yeah, I mean, about the shipping on Fridays, this is one of the best tools you can you can always have.

Some will argue, though, that if you have a robust pipeline, that shipping on Friday shouldn't be a problem. But I'm not even going to touch that with a 10 foot pole. Yeah, don't ship on Friday.

That's true. That's totally true. And what are you testing in your pipeline? What exactly?

I'll let Justin go. Because that yeah,

sure, sure. So I guess our first line of defence is we do have, like coding standards on all of our so we have coding standards for PHP, JavaScript, CSS. And when you submit a pull request, we have an assertion pipeline inside of Buddy, that will check the files that have changed against those coding standards, and you won't even be able to submit your pull request until it meets those. So that's like the very first line of defence. And, yeah, past that, you know, we can integrate unit tests, but mostly right now it's, we have been able to automate like the build steps. So these are like the additional pieces that we have, where we're using, like modern JavaScript stuff to, like, kind of compile and minify stuff. You know, we people don't have to worry about doing that on their system. It's especially helped when we're working on you know, we'll have like, let's say a legacy project that uses an older version of PHP or an older version of NPM. That has to stay on that version in order to build correctly. You know, you don't have to worry about like, Okay, I gotta switch my NPM to this version, and then I got to compile my stuff, and then I got to commit it, and then I gotta send it up. All of that stuff is handled in Buddy. So our development team doesn't have to worry about it. They can just get to work.

Yeah, well, you mentioned those legacy projects. Like yesterday, I was pushing something that contained gulp in and at first, I just got a lot of errors and later it was just an easy fix. I just had to downgrade then the Node js into version 14 dot O and it started working. And yes, this is something incredible that we can do it with just like one click and not like recompile everything we have on our local machine because this should be done very, very bad, bad experience and tell me what were your biggest mistakes when it comes to CI/CD? I mean, I once or even more delete the whole project because I had to do some server work. And there was this one thing that I had removed this temporary folder. And this and it wasn't the temporary folder at all happens.

Yeah, I mean, they're, they're always pitfalls. And to be honest, like, for us, it's been a very like, iterative process. You know, like, when we started using Buddy, it was very simple. It was like, Alright, we're gonna commit to this branch, and it's going to FTP these files up to the server. And then we added assertion steps. And then we realised on really large sites where it's sending all the FTP stuff, we could simplify that by changing it to our sync, where, you know, there's some communication going on and saying, okay, only these files have changed, let's only send those files that helps speed things up. So we we've kind of been iterating. And just adding stuff to our pipeline, kind of the way we work is we have a template pipeline that has all the steps that we normally like to do. And as we add stuff, we go back to that template pipeline and go, Okay, now I'm going to add Lighthouse scores to our deployment so that we know, like, here's how this is going to affect the performance of this site.

I would say as a manager, that the biggest mistake we ever made was not having, not having it at all. How can you ship something confidently, if you don't know if it's even been tested? You know, I don't.

I mean, there were also some like growing pains, I remember when we first introduced our sink. The, one of my, my coworker Aubrey said, like, double check your work at least 10 times when you're using our sink, because we turn on the Delete option, so that if files get removed, we want them to be removed on the server. But if you set it up current incorrectly, you could like nuke your entire, like, media library if you're not paying attention.

And did you nuked your media library

I did, I did a labs on like a lab server. So it wasn't, you know, we were very measured with our approach, like, Hey, we're gonna we're gonna try it here in a development environment on a test server first, before we roll this out to like staging and production. And, you know, that's also kind of like the robustness of our process to is like, you know, we don't just have local and production, we've got a couple of steps on the way where we can do like client review, and internal review to make sure that we're not going to blow anything up on a client side where that's their source of income.

That's the beauty of Git, by the way, is like, if you have your main branch, which may go to production, you can have a develop branch, and you can have a staging branch. And then you can configure configure Buddy, to if you commit and push up the develop branch to go to your dev environment, or to the staging branch to your staging environment. And that's, that's awesome. Like, I don't know what we would do without that. Could you imagine, Justin, if we did, like, I can't even imagine how you would code the lab and then to staging and then eventually production without version control. It's just I can't even imagine.

I mean, I can't imagine in a way, but it wouldn't end in a nice way. Because you probably have opened few tabs of FileZilla. And at some point, you'd mistaken the production with staging. And that's how, you know, the production version. Right? Yeah. And you mentioned a bit about your, about staging about your development environment. What is your general workflow?

So in general, we have, typically, I would say, four environments. So you have your local, we have a server that we call WDS Lab, which is our like, it's just a Linode server where we set up a bunch of WordPress sites so that our dev team can kind of work together in a sandbox. And then typically we'll have two environments, on our clients hosts. So if you're on WP Engine, let's say you'll have a staging and a production. And we've actually got in our template like because we work with several hosts we've got like example templates for WP Engine page in the WordPress VIP, our lab site so that when we start a new project, it's super easy, we just copy the pipeline So out of those changes in credentials, and then they're ready to go with all the latest stuff that we've configured in our using on a lot, all of our other projects.

Yeah. When it comes to your tooling, apart from we know you're using Visual Studio you're using or using Buddy and what else?

Yeah, so we'll use. I mean, for the back end, we'll use composer to manage all of our plugin versions. And I'll actually turn it over to Greg, because we have a whole tonne of tooling that we do on themes with JavaScript, too.

Yeah, we use. First of all, we use WordPress coding standards for everything, that's our baseline. So we will pull in the WordPress coding standards and every project, we have them configured in such a way we, in addition to having like a project template template for Buddy, we have a project template on our GitHub, it's a private repo that contains all the information for code standards. So we are running like es lint against our JavaScript. And that's just using WP scripts. If you're not familiar with WP scripts, the team that does all the work on Gutenberg and they have a really great NPM package called at WordPress scripts. And it contains a bunch of pipelines that you can use on your local or on Buddy to test your code to run builds to do that kind of stuff. So ES lint for all of our JavaScript, we use stylelint for all of our CSS, or sass. And then we can do things with like markdown lint, we've, like I think WordPress scripts, even supports like package dot JSON, linting, and stuff like that. I don't know that we necessarily need that. But the workflow is when you're, when you're working locally, you branch off of main, the main branch, and you create a feature branch for, you know, feature, my feature, ticket number, that's kind of our standard is we put a ticket number in our feature branch, and then the engineer types NPM, run dev or NPM, Dev. And that will spin up WP scripts, which will watch for changes. And when they make changes VS code, usually, if they have VS code configured correctly, will catch like a linting error, right? If they made a if they type the function name Caballo case instead of camel case, like es lint will flag that immediately in their code editor. And then they can fix that error there. In addition to that, we have a check locally, we use a Git hook. The pre commit git hook, we leverage an NPM package called left hook, which will run assertions locally before you can even commit that your code and get it up to GitHub. So if all is working, right, your code editor is telling you, Hey, you made a mistake here, fix it. And then when you try to commit the file, left hook will run. And it will run es lint and say, Oh, hey, I can't commit this file because it has a warning or an error in it. So the engineer has the opportunity to fix it there. And then it'll get sent to GitHub where we run that same set of things again, to double check our work. And if that all passes, then they can open their pull request. And then that's the robot part that I keep talking about where the lead engineer can get there. And they can worry about analysing the solution that the engineer created, and less so about, did this engineer meet coding standards? Did this engineer put up period? Did they use the semicolon correctly, like, don't make people worry about that, make a computer do that. And that's where Buddy comes into place. So once all of those assertions pass, and the pull request gets merged in, that triggers Buddy to send a file or send that file to whatever, depending on the branch, and staging or develop, it sends the file to the server. And now we are confident as a manager, I'm confident that my team is shipping clean code that is bug free. And that has been properly tested. And that gives me peace. So if you're still if you're a manager, and you're listening, and you're not sure, I think that's that's it like that's gives you the peace of mind to know that your engineers not only are growing because they're seeing these mistakes in real time, thanks to the tooling. But you can also sleep better knowing that this code your shipping has been well tested, not only by humans, but by robots and what a great that's a great place to be. You can focus on other things.

Yes, that is true. This was always the thing that I did I like about automation, because let's be honest, I am a lazy person just like this. I prefer to spend. I mean, I think this is one of the things that the common thing about developers, we are lazy and thanks to our laziness. Of course, someone can say they can use different words, but I still think it's laziness. We tried to develop solutions that help us be lazy and concentrate only on the things that matter. The things that you said about when you get the pull request and First you just start analysing, okay, but the coding standards mess and things like this. And when someone, okay, when someone starts fixing it during this pull request, the whole pull request becomes some noisy, it's hard to concentrate. But that's probably at some point, when you have all these coding standards, math and thing. You're just okay. It's probably it's fine. I the only the only difference in this in this change, and it's really hard to see, see the logic and concentrate on it. So. So as you said, Yes, we need a robot, we need a robot body, right? As you said, Yeah. And but do you think that even solo developers could benefit from it? Or is it just for teams?

I keep going back to that, like, are you going to be a solo developer for all time. And even if even if you are, like, why not sign up for Buddy, because I think you get like five projects for free. And then you can eliminate that part of your workflow where you have to open up FileZilla and send the stuff up. Like, it seems like a win win to me. And I want to go back to the thing that Greg said about the reason we chose Buddy, is because it looks great. And the user experience is great. Like, I can't stress that enough. Like, if we were going to do Jenkins, we would have a full time person dedicated to managing Jenkins. I can literally say, hey, go configure this in Buddy. And just about everybody in the team knows how to use it. And even if they don't know how to use it, it's so intuitive. That in clear how it works, that you can learn it super easily.

I mean, this was also one of the reasons why I started using Buddy because I've been using Buddy for so many years, I'm even even don't forget, I even forget how how long it is already. But probably a bit longer than the new. And so yes, I was first I was first a client of Buddy and, and a very happy one. Every time when I switched jobs, I tried to encourage the company where I work, hey, maybe let's switch to Buddy, you will see the benefits quite quickly. And this was the same thing. Everyone just everyone was able to learn the basics quite quickly. I mean, it's great to have an engineer that focuses on it. So we can see those small things, how we can make our pipeline better or faster or more secure. Because yes, there are many aspects that we should take care of. But still setting up a very simple pipeline can be very easy. I mean, it's just like, when it comes to typical, deploy it just like clicking one play in one place. Just select when, when you want to deploy something, and that's it. That's, that's really it. Okay, so um, I think that we really explained why WordPress agencies should use, even if not, Buddy, but we I mean, we encourage you everyone to try, but at least to use some kind of automation, because it will really, really help you help you grow. And we have, we have some we have some questions. So it will be a great moment to answer them. So first of all, like I said, I think you you know, this, this person, right? likes that test against Lighthouse should be done before every release to the production or on every Pull Request feature, or can we skip this test on some pull requests?

No, may take this lesson. Yeah. Okay. You should run it all the time. And you should, on the pull request level. If Lighthouse gives you like a decrease in score, that should be your opportunity to find out why. And that's your opportunity at the pull request level and then your branch to make changes or fix whatever. And then it should also run prior to releases and after releases. I'll echo what Alan said in chat as well like Buddy is also great at make verifying after a release. So you could definitely rerun Lighthouse after a release is done to verify the changes are there. So I might set at the PR level. It might be like a warning. If Something doesn't pass, but at the Edit release level, that that should be an error and block your release, so that you can have an opportunity to fix whatever the error is before it goes out to production. So running all the time, but different, different requirements, maybe Friday release,

I want to point out that lighthouse, you know, while it's primarily a, like performance measure, there's also like other things like accessibility that are tucked in there, and maybe your PR isn't meeting those accessibility requirements in that it could potentially flag that. So it's not just performance that it's looking at.

And if I can ask, Which score do you consider as the one you said to as a minimum one?

There's four. Right. There's performance, there's SEO, there's accessibility and

and those General General General? Yeah,

I think we're just using the DT whatever the default configuration that Buddy gave us when we set up the pipeline.

50, if I remember, yeah, yeah, it was for each one.

It may be. I don't think I'm doing that for accessibility, though. I want to say ours is higher than that. But we are definitely trying to be accessible first. It's hard. It's that's why it's such a challenge out there. Accessibility is a big topic a big deal. But it is important that our pull requests are accessible. Or, you know, the code being shipped into a pull request is accessible at all times. It is it is a priority at web dev studios. So

Oh, Ellen mentioned the best practices. It was yeah, gotcha.

Yeah. And some of those may not be applicable, we are on a dev environment. So Lighthouse may not be picking up the correct. You know, whatever server configuration for it could be any number of things. But accessibility, that's not a server thing. That's a PR thing, or that's a code thing. And that's not going to change between environments. So yep.

Yeah. That's, that's true. And we have also a question from, from the bloody mirror. What about cash and security?

Which, which cache are we talking about?

It's a general question. So let me cover Buddy has gone. Yes.

It can speed up your pipelines. And then I will touch on security quick. We put our we put, we use keys, SSH keys and Buddy. And nobody else hasn't. It's just Buddy Buddy can talk to the server. We also have two factor authentication turned on on our Buddy account. So nobody can even log in without having two factor authentication. So those are the two things that came to mind when I saw this question was Buddy has caching to speed up your development pipelines. And it's secure in that it has two factor authentication and your credentials for your hosting environment can be secured with an SSH key and put in one place instead of sharing it amongst the team.

And then forgetting who has them because showing, showing his one thing, but getting it back, this is this is the real problem. Yeah. And yeah, when it also comes to cash. You can also use Buddy to

get cash after.

For example, in many of my pipelines, one of the last actions is purge Cloudflare cache, because I'm a big fan of clock star. And that is, that's true. Oh, and I see, we have one more question from from Subash. What is the benefit of using CI/CD for a new developer or someone who is still learning how to count properly?

Having that robot tell you, the mistakes you're making. And the more that robot knows that the more opportunities you will have to grow and get better.

And and also, the fact that you're asking these questions means that you are, this is a very good question. You should, you should, because this is, I mean, this is the standard way to go when it comes to let's call it enterprise, WordPress, you know, this higher level, or even development and in any language, but the moment when you are start starting to take it seriously. Things like tests like CI/CD, like automation, this will be your everyday bread. That's it.

Yeah, I want to just echo that. Real quick. If you were to apply at web dev studios, we're going to review your application and we're going to get on an interview. One of the first things we're going to ask you is how comfortable you are with Git. We're not going to ask you how comfortable you are with CI/CD. We're going to ask you if you have experience with it. We're not going to dock you points for not knowing about CI/CD. But the basic expectation at this at at an agency and I would say this is probably true any agency Is that you have experience with version control. It's a requirement. So

and on the other hand, if someone doesn't ask for this, it's a bit of a red flag. Because this means that maybe you will end with putting Powell files through FTP and naming them. version two, version six, version nine, and so on and so on. And I also see one comment from from Ellen, she's very active here. Automation that provides feedback based on best practices helps you level up your skills, identify errors early and keep your code in alignment with those standards. And yes, that is that is exactly true. Okay, so I think we answered all the questions. And you told us a lot how, how development looks like the enterprise level studio, like web dev studios, it was very nice to because I also learned a lot a lot about you, because I'm, to be honest, I'm a big fan of, of all your works. So So thank you, thank you very much. And let's see what we are have installed for for you in two weeks, because in two weeks, we are doing another webinar. This time, we will be doing a webinar about e commerce automation for DevOps pros. So get your calendars and Mark 24th February. And the next thing is, if you want to be informed about our webinars, you can also sign up to our meetup group. It's called Buddy CI/CD group. So I encourage you to do it, you will get info about each each upcoming webinar. And like I mentioned before, if you like this webinar, remember to subscribe to our YouTube channel, you will get access to all the webinars and all other interesting tutorials quickstarts and other stuff that we will think think of and create on YouTube. So thank you, thank you guys, for for for spending time and chatting with me. And I hope to see you soon at some point and we will and we'll dive in maybe in some more. Maybe we'll do some live coding cares because this is something that can can break life so nicely. I think we should do it next time. What do you think?

As long as there's a robot checking your code? Okay.

So we will we will set the test in the background and we will see what is happening. Okay, so thank you everyone for joining us. It was very it was very nice and have a nice day or night depends when do you live by