Smooth Deployment and CI Pipelines for WordPress Teams

Zach: Hello, everybody. I’m Zach Stepek, here with another episode of the Woo DevChat. I have Carl Alexander here with me.

Carl: Hey.

Zach: And we have a magical guest with us today. And we do a little pre-show chat before we start recording. And our guest today, I didn’t know how to pronounce his name. So, now we know that “Maciek” is very close to “magic.” So Maciek Palmowski is with us today. I knew I was still going to butcher something, and we’re going to talk about CI/CD, continuous integration and deployment.

Carl: I love it. I did, I think, one of the OG talks. I did a couple of talks on CI/CD, like how to deploy, how to update plugins automatically, how to set up a workflow.

I was taught it’s always been a bit of a harder sell on WordPress. Although, all this stuff is trending up. I see there’s more interest in testing because testing is an important aspect of CI/CD.

So, do you want to give a small intro? You give the workshops, Maciek. I’m calling you “magic.”

Maciek: Okay. Yeah.

Carl: Your magic P.

Maciek: So, in my case, I even got interested with everything related to automation, because I am lazy. I am lazy. And just at some point, I realized that doing the same thing over and over, it’s just boring. It’s horrible. It’s tedious. I did not want to repeat myself doing all the same things. For example, even the simplest theme that we are deploying. Every time we have to, for example, install some Composer stuff and run some NPM scripts, and remember about this every time. It’s horrible. I have better things to do so.

So I learned that I can automate it in some way. And thanks to the fact that I was so lazy, although some people told me that that I shouldn’t use the term “lazy,” but efficient. I’m not sure. I will still go with laziness.

Carl: If you think of all the progress that we’ve made as developers due to laziness.

Maciek: I think, most of progress in the whole IT, the laziness is somewhere underneath all those great and bright ideas.

And here it was the same. It was boring, doing the same thing. And this is the general thing behind CI/CD, because we are humans. We make mistakes. And when we start doing something over and over, that it will quickly become boring. And if something is boring, there is a much bigger chance that we’ll make these mistakes.

So we should just write a script pipeline, whatever, that will just do those things for us, because machines are amazing when it comes to repeat stuff. They love doing this. They can repeat things over and over. The only problem is that we have to program in the right way, because if we make a mistake, they will repeat it over and over, because it’s not a problem for them. S

Carl: They’re dumb. They’re just dumb. They’re just listening to what you say.

Maciek: Yeah, exactly. Exactly.

Carl: If you say, “Jump off a bridge,” the machine’s going to jump off the bridge. They’re not going to say like, “Wait, should I be doing that?” No, they’re just going to go.

Maciek: Yeah. Or maybe a more CI/CD example, if you write, “remove /rf” and yeah, it’ll just remove the folder and that’s it.

Carl: “rm -rf /”. Just delete your entire machine.

Maciek: Exactly. And this was exactly what you wanted to do. I also did it once or twice, because I was sure that I was in a bit different folder. Yeah, it happens.

Carl: Yeah. Or you forget you’re connected to the server.

Maciek: Or something like this. Yeah. It happens. It really happens.

So, this is the best thing about automation. They will follow whatever you want. And this is the worst thing about automation. The machine will follow exactly what and do what you want. So, yeah, this can be a problem. This can be a problem.

Carl: But you only make the mistake once. Because if you fix it, then the machine’s not going to repeat it again.

I always thought that was the main argument, that I was introduced it to, at least in the WordPress ecosystem, it’s like accident protection. Just even something like automated deployments. Like the number of times you overwrote something or you deleted something because you were manually deploying with FTP and something like that. It was just like, it’s countless. Like I’ve done it countless times.

And how do you prevent, how do you like feel safe? Because a lot of the CI/CD, too, you didn’t get to it yet, but I assume you will. But it’s also about constant development. It’s like this idea that I can deploy… Let’s say I make a change to a site, before I use CI/CD, or an agency, you basically would deploy things by hand. And then you’re scared to do it because if you make a mistake, so you wait and then your releases become larger and larger and larger. And then, and that’s the whole point. I forgot what the term is, like “continuous development,” or like?

Maciek: The CI goes for “continuous integration.” The second one is for either “delivery”-

Carl: Yeah, but this idea that you always deploy, you’re always deploying a master branch.

Maciek: Deployment. Continuous deployment. Yeah, this is something really difficult. It’s easy to start doing it, but it’s really difficult to do it in a right way, because overall, the CI part is the most difficult.

Zach: I would agree.

Maciek: Because it’s all about testing your code. every time you change something, you should run all the tests.

Carl: You have to test first.

Maciek: Test first, exactly. Test first and test again.

Carl: You have to start by writing tests before you can even do CI. So, that’s already like a problem.

Maciek: To be honest, I’m more about this gradual approach to CI/CD. For example, I did those workshops and I told at CI/CD school, you can do many types of tests, either are unit tests and to end tests, integration, because there are lots of tools and so on.

The moment when some person decides, “Okay, so I will now spend the whole week and I will integrate everything into my project.” It’s impossible. It’s impossible. I’m always thinking that it’s much better to go step by step.

So there are many tests that only require configuration files, or just adding a simple action. For example, PHP style, or this whole static analysis. It’s very simple to integrate. You just install one library. In the configuration file, you just point where you have all your libraries. And that’s it.

You will be sure that, if you wrote the documentation, so this might be a problem in your Dropbox, specifying all your variable types and things like this. It will check if the variable types are correct, is the number of arguments in different functions and methods is correct.

Those are simple things, but they can prevent from pushing a fatal error to production. So, it’s amazing. And it just requires one configuration file. So, great. The same things go with all those code sniffers, linters. While they won’t make your code better, in terms of how it works it, for sure it will look better.

So, if you work with the theme, with the whole team of the developers, you won’t spend some time at the beginning, wondering why some other developers use tabs and not spaces, or in a different way, because everyone will be forced to use the same coding standard. And, in the long run, it also helps to work. And again, it only requires one configuration file and installing one library. That’s it. That’s really simple.

Carl, you mentioned using Buddy. For example, in Buddy, we have few actions that don’t even require almost any configuration, apart from adding the URL. For example, we have visual testing, so it’ll compare the screenshot before and after the deployment. A really great thing to check, if you didn’t mess the CSS, for example. And only passing the URL, it’s not a test, but it works, and it can prevent some major bugs. Of course, at some point, you have to get to this moment, okay. We are out of those simple options. We have to start writing some tests.

Either unit, either integration, or maybe end to end, because we live in beautiful times. We have so many tools we can use. And for some reason, so many developers in the work for space decide to not use any.

Zach: And I think if we break this down into its core components, a CI/CD workflow is really simple. It’s such a simple concept that it really is something that we should have had, much earlier in the WordPress space. But WordPress has been slow on adoption of things like Composer and so orchestration has been harder.

Carl: I, still, personally, don’t think it’s happening.

Zach: But I would agree, in most cases. But there are great projects out there, like Roots with Sage, that are Composer first.

Carl: Yeah, I know. Bedrock. I’m like the biggest bedrock fan, basically, because unless you use Composer.

Maciek: I think I’m the biggest one. Sorry.

Carl: Oh, okay.

Maciek: I’m sure I’m the biggest one.

Carl: We could fight, somewhere in person. We can try to get Ben from Roots to just come and officiate the biggest Bedrock fan fight.

Zach: Would you like a trophy, Carl?

Carl: I don’t need trophies. I don’t like stuff. So I’d probably just give it to somebody after.

Zach: You definitely would. That is 100% your personality.

Carl: Yeah. The only trophy I’ve ever kept is… This was really cool. So, nobody can see it, but it basically Work camp LA did this like disc. They gave speakers this frame with a record on it, with your name. So, it was a bit like you were a music star. It was like, “Oh, this is great.”

Zach: Have you ever tried to play your record?

Carl: No, I’ve not tried to open it, either. I’ve not tried to open the thing, either, but that’s the only trophy… I actually, I have the one from Work Camp, US, the original Work Camp US, they have one that was kind of like a light. But in general, I don’t like stuff. People really used to love me, at Work Camps, when I spoke, because they’d come and see me if they liked swag. They would come and see me and just get all the swag that I didn’t want.

Zach: Absolutely. So, what I was saying though, is if we break this down into its fundamental parts, it’s really a simple set of concepts that do a very complex thing.

And deployment is probably the most important part of this workflow, to get clients to buy-in on. That’s the hardest part is, “Hey, we’re going to set everything up in a repository. You’re going to commit everything to that repository. Your developers can no longer touch code directly on the server. You’re going to have everything set up so that it is checked when it’s committed. And then we’re going to have these separate environments and nothing will go to production, unless it’s been tested in staging.” And all of this stuff is going to happen. And it’s this added layer of complexity for an organization that might be used to just cowboy coding everything.

But it is so powerful. And the one thing I want to point out here, that really made sense to me, because I come from an Agile development background, is that Agile and CI/CD pair really, really well, because in Agile, you’re supposed to be doing things in short sprints, and committing code constantly.

Well, why not make it so that when that code is committed, it’s tested against your standards. It runs its unit tests and you make sure that it’s running properly. And it goes to the environment where you can test it in a production-like environment before it goes to production. Why not automate those steps? Why do that part? Yet, so many organizations still do it manually.

Maciek: Oh, yes. They do. I know a few of them and I’m constantly surprised. I know what is the main argument, because it takes times and it costs money, which isn’t a valid argument.

Zach: No, it takes time and costs money to set it up. Just like testing does, when you first implement unit testing. But afterwards, it saves you money.

Maciek: Exactly. In the long run, that moment you will be fixing the bug on production, it will be probably the time when, if you would write all those tests and test everything before pushing to production, you would see the difference.

And, in terms of time of money, because it’s, I mean, I can’t… I mean, I can, because I saw it. How difficult is to manage a project that breaks, from time to time, on production? For example, you are booked for those 40 hours a week to do a new project. And, from time to time, you have to spend an hour, two hours, out of the blue, to fix some other projects. So, all your planning for all those projects, is breaking with every bug introduced on production. And without fixing the root cause, so the lack of tests, you will never get rid of all your problems, when it comes to planning.

Carl: Yeah. That one’s always a challenge. I like to talk when I give talks on testing, but CI/CD falls into that, too. It’s kind of like you’re fighting this alternate universe.
Because if you write a test and it catches something, and there’s another universe where you didn’t write that test and maybe something broke, and then you lost three hours or a day, figuring it out. But now that you wrote the test, the test broke, you fixed. It took maybe… Sometimes it can take half a second, or something like that, and the problem is solved.

But it’s really hard when you’re dealing… I think, now, it’s getting better, but it’s always like a struggle, even for me, when I do consulting work, to invest the time in that, because it’s a time investment and it’s really hard for managers.

I don’t blame them, but it’s hard to figure out what the ROI on doing that is. But I would say, like I had a good discussion, too, with Tonya Mork, who works on Core and things like that. But yeah, I think it’s even more important to do it. Personally, I think tests are way more important, the smaller the team is. And because, if it’s just me, like, for example, like me working on EMIR, if something breaks, it’s me, first of all, that has to go and fix it. It’s an emergency for me. But also it diverts time that I have to spend on marketing, or other things. So I just want to have safety. I want to feel safe that I won’t break stuff. But when you’re bigger, it’s like, “Okay. Well, we’ll just do a ticket. We’ll do a Jira ticket,” and then they’ll get fixed. And that’s that. And it’s an inconvenience for a while.

Obviously, for e-commerce stores, so if you have a WooCommerce store, it’s much more important to have this kind of stuff in place, because if you’re… This is like… This is my favorite argument that I use for Emir, too, is basically like, if your site goes down for a minute, you’re losing a couple thousand dollars in sales a minute because your site’s down. That’s your cost. So, for WooCommerce, I find if you manage a WooCommerce store, it’s really important to have these sanity checks, like smoke tests and things like that.

So if you’re not familiar with what a smoke test is, it’s basically testing your live application. So, you make sure simple things… Common things that you might want to smoke test are, can you add something to a cart and check out? Once the site’s live, because it’s all well and good that your deployment went well, but you also want to make sure that you don’t want to wake up and people are starting to send support tickets, “Yeah, I can’t check out.” That’s a big one, in that scenario. So, CI/CD can help with that. I don’t know specifically with Buddy what you can do, but just in general, just arriving and testing, once your deployment’s done, is really important as well.

And it’s not something that’s talked a lot. I’d like to do a talk on it. I’ve not, but I’ve never heard of anybody doing a smoke test post-dep.loyment testing stuff. Have you done any, Maciek P? Magic P?

Maciek: To be honest, I’m not so much into WooCommerce development, but I remember that during my agency years, we at least tried to do some simple tasks. In most cases we just checked what are the most important parts of the website? When it comes to e-commerce, let’s try running a simple end-to-end test to see if I can add to cart. Can I go through the checkout, filling all the data?

And also, in many cases, it was also important for us to check if the contact forms are working correctly and are there no JavaScript console log bugs, because this is also something, especially when we are using more and more JavaScript on our front end, so sometimes having a small bug in JS can break everything.

For example, I really love those website that are using a preloader and something hangs, and we can see the preloader until the end. And it never ends.

Carl: But also testing, the other end-to-end test, too, I had, actually, an Emir customer, I was working true. It wasn’t even serverless related, but he had a WooCommerce shop. And if you were not logged in, the images, didn’t appear. Like the product images.

I still don’t know what the issue is. I managed to narrow it down that there was like an opacity zero that was being added somewhere, basically, and making the image disappear. But only if you’re not logged in If you’re logged in, the images looked fine. But that’s like a common thing, too, you need to test logged in, not logged in. All those things are really important.

Maciek: And also, this is so important to automate it because for example, going to the website, checking a form and filling it out, first as a logged in user, then as a logged out user, it’s horrible. It’s boring. I can do it once or twice, but every time more, it will just bore me to death. So, that’s why I try to automate it. And especially that, for example, using Cypress IO, it’s so simple. Really, it’s so simple to run some small end-to-end as that. I really don’t understand why people don’t do it.

Carl: Usually, the challenge is starting.

Maciek: Oh, that’s true.

Carl: I want to do a talk on it, but I wrote an article on, it’s called GrumPHP. It’s basically like, it runs… It’s kind of like CI/CD, but it just runs locally.

So, I always use it as the gateway, like the introduction to CI/CD, because you don’t have to worry about pipeline set up, because that because the problem with CI/CD also for a lot of people, the same thing with testing, the initial investment is a bit steep. You’re like, “Okay, well I don’t have any tests. I don’t have anything to copy paste,” because you’re going to copy paste tests and then modify them.

But writing that first test is always more time consuming. And then, if you don’t have anything, no test suite set up, then you have to set that up, and then you have to set up your GitHub pipeline. So, there’s a lot of upfront investment that can make it a bit intimidating. That’s why it’s always tricky to tell people you should do it, but it’s how to start. And oftentimes, too, it’s a temporary pain. Like you do a deploy. You messed up. You fix it. Client’s not happy. You’re like, “It won’t happen again.” Obviously, it’s going to happen again in six months, but you’re like, “Okay, for six months.” It’s not one of those pains that’s so acute that you’re like, I have to invest the time.

So it’s always tricky, when you’re teaching about it, to get people on board about it, that’s why the e-commerce, the WooCommerce I find is such a better sell, because if you like tell them like, “Oh, that shop owner is going to lose $10,000, if you screw this up.”

Maciek: It’s a perfect argument. That’s true.

Carl: Yeah, you’re going to be a bit more nervous about that.

So I think if you manage WooCommerce stores and things like that, I think there’s more of an incentive to invest that time. But I think it’s good for everyone. And once you’ve done it once, you can carry it on to other projects.

I’m going to shill a bit for Buddy, but also when I give my talk for CI/CD, like I’m a big GitHub Actions fan, but the one thing with Buddy that makes it accessible and easier for people to use, is they have a really good graphical interface. So you can go in and you can plug all your steps yourself. It’s not this intimidating large YAML file. They support that. But, in general, what people that love Buddy for, is they love it for that. So, if you’re looking to start, it’s good. It’s a good tool for that.

Maciek: Yeah. It was me, many years ago because I remember my first adventure with the GitLab CI. After spending a few hours that I wasted on something that didn’t work.

Carl: Yeah. GitLab’s even more intimidating, because if you do it self-hosted, you have to manage all the runners and all that stuff. I didn’t use it. I’ve never used it.

Maciek: It was a very horrible experience back then. Maybe it changed, but still, I remember it. I remember it and for some, I’m not too keen trying GitLab CI again. And then, I found Buddy, and it turns out, yeah, you can, with a few clicks, you can create a pipeline, you can start automating things.

And the cool part is, it’s not limited. It’s not limited, because it gives you all the options you have with using all those long and dangerously looking YAML files, because the YAML file is somewhere underneath. It’s just nicely divided into small chunks that you can manage.

And this is the basic thing about about programming. Every problem that looks as big and scary and almost impossible, the moment when you start dividing it into smaller chunks, step after step, you see that, okay. It’s not so horrible. It’s not so difficult. Oh, wow. I almost finished it. And just going step by step.

And I think this is the really cool thing about Buddy, that it really enables you to do it step by step, because when you have one big YAML file, you still have one big YAML file, and here you feel like everything is separated. So, this is something really cool.

Thanks to our Pod Friends NitroPack and FooSales

Zach: Yeah. I haven’t used Buddy before, but I have used Branch, very similar tool.

Maciek: Almost the same experience. Almost the same experience. Exactly.

Carl: Yeah, it was the same idea with Branch. It was to make it… add a UI, make it more user, like…

Maciek: User-friendly.

Carl: More user-friendly.

Maciek: Or developer. Let’s say, developer-friendly.

Carl: That’s like the number one complaint with Emir, is like, you need a better… You need to do it with more with the admin. I was like, “Well, it’s a developer tool. It’s command line.” But yeah, I think that’s always what the main comment that I get from Buddy, is always that.

When I gave talks, I’ve known about, I’ve written about Buddy before you worked there, like four or five years ago. And one of the reasons that it was brought up to me, and why people liked it so much, was because of that. Because if you’re somebody like me, a YAML file’s not very intimidating.

But I always preferred CircleCI over Buddy, personally, but before GitHub Actions and now GitHub Actions I think is better than CircleCI, but I think Buddy comes up in discussions constantly because of that. They’re the only ones that really are basically, let’s make it less intimidating for people that are just actually starting with CI. It’s not that it’s not a power user tool. It’s just that they make it a lot more approachable for the uninitiated.

Maciek: Yeah. But I also think, one more thing, because the similar thing is quite often brought up, when we talk about Git. Most developers love using Git from the command line, but there are so many nice GUI tools. I really like them.

Carl: I don’t. I refuse. I never use it from the command line. Mostly because I refuse to use it, because I love staging lines. I’m a micro committer. So, if you don’t know what a micro committer is, basically, instead of… If you make a couple of changes… Like I will make like different commits for all these small changes and some people will just lump everything together, put an emoji commit message and then leave it at that.

So, because of that, I like staging specific lines in Git. And I find that so hard to do with the command line tool, but with a GUI tool, I just select the file and I just select the lines I want to commit. It’s so simple. I always lose a lot of senior dev creds, not as much as the fact that I’m a two-finger typer. So, if you didn’t know that, like I’m a two-finger typer. I don’t actually know how to type. So, that always like shocks people.

See, like Maciek’s like basically laughing his ass off, because I’ve lost like a lot of developer cred. Some people are like, “You need to give away your card now.” Like, “You’re not one of us. You’re not one of us.” But yeah, no, I don’t type. I don’t know how to type.

Maciek: So, the only thing is that the YAML files don’t frighten you, right?

Carl: No, they don’t frighten me. And also, I think a lot of the actions, like the reusable actions, there’s just been a lot of energy. That’s the that’s the way I talk about GitHub Actions, is just like a lot of the stuff that Buddy does with their admin, or a little with their graphical user interface, comes from community open source actions with GitHub Actions, but it still requires you to piece it together and stuff.

Again, it’s not as nice. With Buddy, you just get it all, but GitHub Actions is also super powerful and if you’re coming from CircleCI, I was just like, “Oh, cool. This is better.” And there’s so much more energy and people discussing it and sharing how to do things. So it was just simpler for that.

Maciek: Yeah. The fact that GitHub Actions are open source, and all those actions for GitHub Actions are open source.

Carl: Well, we had a technical difference. I have to go back to Buddy to try to get it to work. But I remember, I couldn’t compile Docker images. I couldn’t compile Docker images from-

Maciek: Inside of Docker?

Carl: Yeah, from Docker, inside Buddy. Buddy has steps to build, but it was… I don’t know. I had a complex workflow and it didn’t work, and you released something and I haven’t tried it. But there’s a few technical differences. It’s not that black and white. It’s not just… But in general, at least for CI, the most important thing is to just try to find tools that make you comfortable, to start doing it.

Same thing with testing. It’s very overwhelming. You’ll read so many things, like you should test everything and stuff like that. I always say like-

Maciek: Oh, yes. When you start reading about test-driven development, at first you think, “Okay, I’m not a developer.” I’m not the developer. They just wrote about it, that I’m not the developer. There are so many articles.

This is also a bit complicated, because there are so many articles about testing. I think that there are a lot of those articles that shows you how to install. For example, PHPUnit, how to run PHPUnit at WordPress, or how to use Pest PHP.

We have few of those articles that are about some edge cases. But we are missing so much in the middle, how to start writing meaningful tests, because we already learned how to check is true, and the article ends with, “Okay, so now go on and start testing everything.” Great. Thanks. But I don’t know how. And the next chapter that you will find are some edge cases, how a person tested some edge thing that happens only on his server twice a year. It’s interesting to read something like this, but because you only know how to write this simple test, you really don’t know how to push further, how to start writing those meaningful tests. And one of the things that we can read quite often is take a look how others are doing it. Well, yes, that is true, but still, it might be very difficult to make this next step.

Especially when we add WordPress to the equation, where the definition of unit tests in WordPress is kind of weird, especially those official unit tests, which are integration tests. And the first thing we have to start learning when we start unit testing our things are how to mock some functions or how to install the work person background. And on the other hand, you see all those Laravel articles about how to use Pest, and it just runs out of the box.

And so, yeah, starting to write tests in workforce environment, it’s difficult. It’s really difficult. So, I remember Carl, that you have a nice article about it, about how to start writing with you.

Carl: Yeah. I’ve written a couple testing, even with Laravel, is always a challenge. They make some things easier, but-

Maciek: Oh, that’s true.

Carl: You were talking about the people that write about test-driven development and things like that, and how you, if you don’t do it, you’re not really a developer. You should feel bad. I never had a lot of, I shouldn’t say respect, but I don’t think that’s the right approach.

Maciek: That’s horrible. That’s the worst approach.

Carl: Yeah, but it’s kind of funny, because I talk about it a bit, too. I’ve taught object-oriented programming to WordPress developers.

And one of the key aspects that I’ve done, that nobody else does, is I just don’t arrive to you and say like, “You’re not doing it this way. You should feel bad.” I’m just like, “No, I understand why you’re doing it this way.” And I’m not here to tell you that what I’m doing is better. I’m just teaching you how it works. And then it’s up to you to decide whether there are advantages to doing it this way.

So I feel like it’s the same thing with testing. I just haven’t done it as much, but if you’re listening to this and you’re like, “Wow, this, this looks really intimidating,” it is. And it’s our job. Especially Maciek. Maciek. I’m butchering his name. That’s why I should just say Magic P. But that’s why he does workshops and things like that, because it’s intimidating to do.

But it’s really, I think, it’s important in the long run. I talk a lot about your future self. You have to learn to be kind to your future self. So, there’s a couple of things that you could do, to help being kind to your future self. One, it’s writing tests, because it’s really easy to say, “I’m going to remember this,” while you’re coding something right now.

Maciek: You won’t.

Carl: Because you’re in it. You’re thinking about it. Like it’s fresh. But how many times have you come back later and you read your code, and you’re like, “What the hell was I thinking?”

Maciek: Every time. Every time.

Carl: So, that’s why documentation’s important. That’s why testing’s important, because sure, you might be like, “Oh, this is so obvious. I don’t need to write a test for this,” but really, you have to think about who’s going to come later and look at this code. And those are all practices that are good for that.

So, they’re good for you as a developer, just because they make you think about the future. They make you kinder to your future self, so that you’re not completely lost.

Examples. How many times have you written a to-do in your code? And then you come back six months later and it was three words. And you’re like, “I don’t understand what those three words mean now.” It’s so common. I do that… I just still have comments like that. I try to write longer ones now, because I’m like, “Okay, I need to actually remember, be able to piece it together.” But yeah, so for CI, a lot of the content that I’ve written, like GrumPHP, Buddy, just try to find people where they’re at and try to onboard them that way. So, you’re intimidated about CI/CD. Okay. Well, how often do you deploy and something messes up? Like there’s an error, or something like that.

Okay, cool. Well, maybe that’s when you should look into Buddy or Branch, especially those two, because they’re more user-friendly, but they’ll help you deploy your code safely. And that can be just a nice first step. You can be like, “Oh, I can push a change now. And I don’t have to stress out that I’m going to overwrite the uploads directory,” or something like that. And then you… No, but we’ve all been there.

Zach: Oh, of course. Yeah, absolutely.

Maciek: Personally, I mostly removed code. I mean, removed folders rather than overwrite them. So I’m not sure which one is better.

Carl: The result’s the same. The result’s the same. The client’s yelling at you.

And I feel like that’s always a good first step, because I feel like that’s always where people have the most pain. They’re just like, “I want to deploy safely. Like I don’t want to be scared.” I talk about fear. You’re scared of making changes to your client’s site. You’re always like something you dread. And something like Buddy is great for that. You can just feel like, “Okay, I will push it to Git, and it will make it safely. We’ve done this hundreds of times, now. There’s never been a problem. We’ll be good.”

Then you can like start adding tests to that. So you can get into CI. And you can be, “Okay, this broke five times.” Like this small piece of code, broke five times. I forget what the technical term is. But there’s always areas in your code where you’re going to spend more time in. There’s stuff you write and then you never touch it for sometimes ever.

And then there’s some piece of code that you’re always like in it. There’s something always breaking there. So, if there’s stuff that’s breaking all the time there, that’s usually where I start. I’m just like, “I want to be sure I’m doing this.” And then you go from there. I don’t know. It’s a tricky conversation to have. I’m appreciative of all the work you do, teaching people about it.

Maciek: I had a really great conversation with Luke Dowling, he’s one of the co-creators of Pest PHP. This is also a way to unit test your code. It’s more similar to using Jest.

And I remember that he got a question about how to start adding tasks into legacy projects. And I really like this approach, because it’s really good. Because, as you mentioned, the most important thing is to get our deployment safe on production.

So, let’s start, not with those unit tests, because unit tests concentrate on small pieces of code. Let’s start with either integration or end-to-end tests, just to see if, after doing some changes, the most important parts of our website are still working. If they are working, then that’s more or less okay. And after having those tests that will prevent from pushing a non working website, you can start thinking about refactoring or adding unit tests to every function, every method, but start in this case with the big ones, just to be sure that your website will be alive after deployment, because that’s what it’s all about. We just want to deliver a working product onto production.

Carl: Yeah, it’s about feeling safe. That’s really how I pitch it. It’s about like feeling safe, working on your stuff. When you don’t have tests, when you don’t have automated deployments, everything feels kind of like very fragile. You feel like if you touch anything, it’ll just break apart and then you don’t want to touch anything. You don’t want to take risks. Refactoring is a huge risk. You’re like-

Maciek: Oh, exactly. And it’s almost impossible without doing, without having tests.

Carl: No, that’s one of my main personal reasons why I like testing, is because I’m OCD about coding stuff. And sometimes I want to rewrite part of it and you feel safe. I’m thankful. Or like I have to sleep at night.

Zach: Absolutely.

Carl: Because of that. I work on a product and I can sleep at night, because I know that I’ve not broken anything.

I can make a deploy and things will work. And that’s really hard to do if you don’t have tests. So, it’s a source of stress. And it’s one of those things, too… I think you must relate to that. Well, both of you must relate to that, but after you have started testing it a bit, it’s like if you stop eating junk food. At first, you’re like, “Oh, this sucks.” And then, you feel so much better. You feel better. You can notice it.

So I feel like testing’s a bit like that, because at first it feels painful and hard to do, but it’s hard for me to go back to the stress, the worry of everything. Like everything being fragile, everything potentially breaking. Whenever I make any changes, that feeling of safety is hard to explain until you’ve lived it a bit. You’re like, “Oh, how bad can it be?” And it’s like, well, I don’t want to go back. It’s bad enough that I don’t want to go back to that.

Maciek: Of course, on the other hand, we also have to remember, and that even if you have a test suit and everything, you will still probably ship a bug, from time to time. And that’s normal.

But there is a big difference. When you have all those tests, you also have this feeling that, “Okay. I really did everything on my end to prevent from shipping this error, this back to production.”

Okay, it happens because we are humans. Sometimes we just miss something.

Carl: Yeah, you can’t get every potential scenario.

Maciek: Exactly.

Carl: We could do an entire article on testing. This idea of a hundred percent test coverage.

Zach: It doesn’t exist.

Carl: I don’t believe in it. I think it’s kind of a mitt, like it’s a mitt.

Maciek: Yeah. And still, even if you will have the coverage, it won’t cover every case, because your code can be covered, but you didn’t think what will happen if someone names the file with some strange UTF-16 letter, or something. Yeah, no. There’s a lot of scenarios, but I also think it’s just, it sets the wrong framing for what you’re trying to do.

Carl: You get obsessed with this number, but really, it’s hard to maintain that number. And that number doesn’t really mean anything. It doesn’t… You could have coverage, and like Magic P said, you basically still miss cases that are important. And then, you don’t feel safe anyways, but you have this number. So, it’s really just about being honest. Try to write as many tests for things that you can think of. And then you’ll miss some that’s what bugs are for. Just write a test for those bugs. That’s always how I say it to start, like you have a bug. How do I write my first test? Do you have a bug right now? Write a test for it. Fix it. Test is green. You just did your first test. You did it. And it’s that simple.

Maciek: It is. This was the way, how I was introduced to unit testing, thanks to Alan when it comes to WP-CLI. I remember when I met him for the first time at WordCamp London, and I found a bug with when it comes to importing multiple files using WP-CLI. And I had some idea how to fix it. And Alan was, “Okay, great. But first write a test.”

And it was for me, “But why? But I know how to solve it.” “No, first write the test.” So I wrote the test. It was still weird, but I did it. And I wrote my glamorous fix. I was so happy that I just saved other WP-CLI users from my bug.

And it turns out that I created another one, which was possible to see, only thanks to all those other’s tests, because someone had a bit different case. And yeah, so anyway, it turned out, it wasn’t a problem with WP-CLI, it was the problem with importer itself.

Carl: Yeah. But that’s all part of a process.

Maciek: Without all those tasks, and really WP-CLI has thousands of them, for every case, at some point someone found the bug for, we were able to find it and I would never, ever, because I would, like I said, I would never even think about the problem with… Because I remember it was probably something related to importing navigation minis and things like this.

And I didn’t even think that it can, in some way, that can introduce a bug in this section of code. And it did, it did. And it was quite logical, quite visible, but I don’t know the whole code.

And this is also a very important thing about testing, that when you are a new developer, you don’t know the whole code base. That’s not a problem. If you have a good test coverage, you can just come in, try to write your fix, or this new feature, or whatever you want. And you will quite easily see if it broke something else, or not. And you don’t have to even know the rest of the code base, because the test will solve it for you.

Zach: Absolutely. Yeah. That’s a big thing.

And I think just to bring everything together here and start to wrap up, I think that, once you deploy unit testing and end-to-end testing across an application, starting with the core workflow paths, start with the things that people do the most. Move to the things that people do less frequently. And you’ll get to full coverage, or as close to full coverage as you can, a lot faster that way, in my opinion.

As you start to look at this concept of continuous deployment, and using any of the tools that are out there, whether it be Buddy or Branch, or even just your host’s ability to deploy from Git. That’s a great place to start, if you want to implement a code repository, and you want a branch called Staging to deploy to your staging server, and you don’t know how to do that, but your host has Git integration? That’s a good place to start. It’s a good place to get your feet wet.

And then, just build on that practice over time, just like no development team becomes Agile overnight, no development team will add continuous integration and testing overnight. Test-driven development, it’s a goal, it’s a destination, but there’s a journey to get there. CI/CD is a destination. There’s a journey to get there. Just like using a code repo in the first place. For some teams, there’s still a journey to get there.

So, just starting off, on that journey, and moving toward it, learning things about what these tools can do and the efficiencies that they can add to your team, are huge. And if you’re working on a team where multiple people are committing code, multiple people are introducing potential bugs. Potential issues.

In those cases, the benefit, the impact of taking the time to implement a true end-to-end development workflow with a source repository through to an integration testing and deployment process, will have dividends in return. And so, just keep that in mind, as you start to explore these tools. I will open up the floor to both Maciek and to Carl for last thoughts on this CI/CD topic.

And if you liked this topic, let us know. We can always dive deeper into any of the topics that we cover. So, if you liked this topic, or if you have additional questions, definitely reach out to us and let us know.

Maciek: I think the thing that you mentioned about, that it’s impossible to do overnight, this is one of the most important things you have to remember. Really start slowly, go step by step. With every new test you introduced into your pipeline, you are a bit closer to your goal. And don’t worry if it will take you a month, a half a year. It doesn’t matter. Every time when you add something new, a new way to test before you deploy your code to production, you are becoming a better and better developer or a better team, because it’s also important when you work as a team.

Like I said, and like Zach mentioned, it’s impossible to do overnight. But just push forward, push forward, step by step. Don’t worry. You will get to the place when you realize that pushing your code without any testing, it’s like impossible, because you will be scared of doing something like this. And this is really not a nice feeling, when you are afraid to push something that you did, and something that adds value to the code.

On one hand, you feel that it’s great. And on the other hand, you are afraid to show it to the world, because it may break something else. And having all those tests will make you much calmer. You will feel safer and you will be… It will be much easier for you to share whatever you created with the rest of the world.

Zach: Absolutely. To bring it back to your love of cycling, for a bit of a metaphor here, one does not simply go out, buy a mountain bike, and the next day do the Tour de France. It just doesn’t happen, right?

Maciek: Of course.

Zach: There’s steps along the way. And just like anything, we need to take those steps, one by one, and arrive at that destination. Carl, any thoughts?

Carl: No, I think you guys articulated a lot of it. I always, I can for hours.

Zach: Carl always has thoughts. Yes.

Carl: Magic P’s like, “Wait.” It was like, no, I like literally, I could not shut up about all this stuff, but I think the essence of what we were trying to get across has been said.

CI/CD is aspirational. It’s something that is there to help, in some cases, not lose money. So, like I said, if your site makes you money and things like that, obviously there’s a financial incentive to go into that.

I think if you’re a developer and you’re wondering about it, know that it’s aspirational. Know that, thanks to products like Buddy and Branch, it’s easier to approach. But we all had to learn. We all had to learn. We all had these moments of frustration where you’re like, “I wish I’d started.”

But the benefits, once you’ve had it for a little while, it becomes something, you’re like, it feels weird to not have it, because it does make you feel safer. And it’s kind of a balance thing. It makes you feel safer. And because of that, you feel more confident. So you feel more confident to make changes. You feel more confident to release your code and you feel like it brings you confidence.

So you’re less scared. And because of that, you’re more confident to do things that could be risky, like refactoring, rewriting some things, because you’re like, “Well, will I break things for my previous customers?” Well, now I have hundreds of tests that can tell me that I didn’t. Obviously, there’s still some risk every time, but it makes you feel a bit safer. And because of that, you’re willing to take more risks.

That’s the whole point. And hopefully, you enjoyed our little conversation on it.

Zach: Well, Maciek, we really appreciate you joining us today. Where can people find you on the interweb?

Maciek: Mostly on Twitter. Search for @palmiak_fp. And yeah, this is the place where you will find me the most, because I really don’t understand how to use LinkedIn or Facebook. It’s too complicated for me.

Carl: Same. You can’t really troll, you can’t troll on LinkedIn. No, I guess some people maybe troll on LinkedIn, but I’m a Twitter troller. So, what social… You can kind of troll on Facebook, but it’s not the same. Twitter is just like a fun space to troll on.

Maciek: Yeah. So, this is the place and you can also find me when it comes to the place when I work on Buddy, Buddy that works, because I’m someone called a worker’s ambassador there. So, if you have any problem with workers and CI/CD, you can just talk with me. And maybe I will help you to get started with CI/CD adventure, together with WordPress.

Zach: Hey, we all need a guide when we go on these journeys sometimes. So, that is a great offer.

Well, this has been another episode of the WooDev Chat here on Do the Woo. On behalf of Carl and myself and Bob and Till, who wasn’t with us today, thank you for continuing to listen to our journey into all of these dev topics. If there are things you want to hear about, please, obviously, let us know. If you want to provide feedback, there are definitely ways to do that.

You can find me on Twitter, @zstepek. You can find Carl. And Carl, you’re out there as @twigpress, right?

Carl: @twigpress.

Zach: Yeah, just reach out, let us know what you think, and what you want to hear about, and we’ll try to get it scheduled for the near future. Thank you both, again, for being here. And I hope that you have a great time until our next episode.