Welcome to Press This, the WordPress community podcast from WMR. Here host David Vogelpohl sits down with guests from around the community to talk about the biggest issues facing WordPress developers. The following is a transcription of the original recording.
David Vogelpohl: Hello everyone and welcome to Press This the WordPress community podcasts on WMR. This is your host, David Vogelpohl, I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you hear every week on press this as a reminder, you can find me on Twitter @wpdavidv, or you can subscribe to press this on iTunes, iHeartRadio, Spotify, or download the latest episodes at wmr.fm. In this episode I’m really excited we’re going to be talking about working effectively with your dev team using continuous deployment and joining us for that conversation is Rob Humar, Rob. Welcome to Press This.
Rob Humar: Hi David. Thanks for inviting me.
DV: I’m really glad to have you here. For those listening this is definitely a developer focused episode. But in this episode where Rob is going to talk about is basically how his team at Dexerto mastered continuous deployment workflows within the team, but also the impact that had on their business as a whole so it’s kind of like this whole business story that Rob is going to walk us through here today. If you’ve been thinking about using continuous deployment or if you’ve perhaps had trouble implementing it, maybe some of Rob’s lessons will be helpful for you, Rob. The first question I ask every guest I’ll also ask you briefly tell me your WordPress origin story.
RH: So I’ve been working with WordPress for probably 15 years now. So I can just navigate the WordPress docs, like the back of my hand. I suppose I got into it I was just a friend that asked me one day he was like, Yeah, I need to work somewhere on online to do a blog and upload some news and look around the internet, I suppose, WordPress popped up and, and that was the best platform at the time and that’s where everything started.
DV: Very interesting. So how do you build sites to up until that point it was WordPress your first way of building sites.
RH: Yeah so I was, I was probably both. I learned how to do web development in the days of like hard coding PHP free CMS world. So everything was just done manually.
DV: Sure, sure no WordPress is a good tool for that so 15 years ago, this would have been approximately 2006 So right before widgets and shortcodes it sounds like which would have been an exciting time to get started. Awesome. Well thanks for that and then you know I mentioned earlier in the introduction that you’re with a company called de Certeau, could you help everyone understand what the survey that’s
RH: yes so on, leave lead web developer DeSoto. DeSoto is an online publisher for gaming news were one of the largest in the US and, and the largest in the UK, we focus on eSports. Just variety of gaming platforms, and we have a number of WordPress websites.
DV: since this is an audio show Could you spell the search for everyone.
RH: Yes, so it’s spelt funny, actually d, e, x, e, r, t, o but if you’re, if you’re a Call of Duty fan you’ll understand why I said so.
DV: I am a call duty fan but I do know that reference but I did get lost a little bit as I was retired researching this episode and the articles so it’s really fine. You know we have a lot of agencies and freelancers and product makers on the press this and it’s really good to also get the perspective of brands. So, I’m kind of curious. Can you briefly describe what continuous development is for the sake of our audience if you’re not familiar.
RH: Yep, sure, continuous deployments, it’s just basically a process of automating every single step of a deployment process for every single change that you use the code base. So instead of waiting for a release date, and building up a backlog of changes to a codebase and then do anything one big you continuously deploy new changes again and again again.
DV: It’s automating that deployment process. Would you consider unit test to be part of continuous deployment or not.
RH: Yeah so the, the process from the start as far as, I mean, let me get a word, right. So, instead of doing human testing, continuous deployment automates a lot of the testing processes. So that could include like PHP unit tests. That could include linting so you could do JavaScript linting in the tests you can do stylesheet linting in the tests, and just getting rid of all the, all the testing that could take a long time by a human, and doing it really quickly with a computer.
DV: That’s an awesome description thank you for that and I think as I think about where teams get blocked on adopting continuous deployment is in the complexity and setting it up and I think, you know, not doing some of those things and their their manual deployment processes, you know, in order to save time, but it’s really interesting to think that, you know hey a little investment in setting this up, can have big returns on time later, and especially the time for fixing problems.
RH: Yeah 100% The setup process of continuous deployment is, is the hardest part of it. Once is setup. If you fail to use it easily. Developers should be able to come and just press a button and upload the code changes to whatever platform you’re managing your code base on and everything should get triggered. So one question.
DV: Like I feel the draws there right like making a mistake with your deployment and causing an outage costs money introduce risk into a business from from the development perspective of course people want to like do their best work and make sure it works well and not have to deal with headaches later so like there’s a big draw. But then, you know, there also can be blockers to people entering using continuous deployment. So when you implemented continuous deployment at de Certeau. What was the deciding factor like what was it something that broke before, like what was the, Why did you decide to deploy to pursue that strategy.
RH: The biggest deciding factor for us was because we’re a fully remote company. We don’t have an office. All our developers all over the world. So we needed a way to make sure that all these developers could work well together in a team, and other code was following good standards and practices that we’ve put in place. And like I said, the biggest draw to it is safety. You need to run these tests before you do a deploy because the uptime of our websites that biggest, biggest factor that we care about basically.
DV: Did you have a distributed team from the start or was this related to the global lockdown.
RH: No we’re fully remote team from the start, and the future.
DV: So did you operate without continuous deployment for a while.
RH: Yeah, it was only a small development team at the start, so I guess it wasn’t as important but the more developers that you add to the team, the more important it gets because you don’t want people overwriting each other’s code by doing manual uploads to via FTP or something like that.
DV: So you have the issue of overwriting and causing issues with, you know, multiple people trying to deploy. What about like the quality of work I feel like if you have like individuals doing their own linting and unit tests, assuming they’re even doing them integration tests and things like that, I feel like if each one’s unique a snowflake that that might cause other problems at scale.
RH: Yeah, exactly. We need to make sure everyone’s following the same standard. From experience a code readability point of view as well. You need the developers to be able to pick up, pick up the codebase and be able to understand what’s happening quite quickly so we need to. So for example, one of the rules that we have in for developing PHP plugins is, everything has to follow the WordPress VIP standards. And one of the WordPress VIP standards is every PHP function needs to have a PHP doc description name with it. And if it doesn’t have that the WordPress VIP standard or for open ever saying, Look, you need to include these, and it goes like that just make the codebase, a lot better than everybody.
DV: Do you use any other standards for WordPress specific linting tools in your continuous deployment process. You mentioned VIPs.
RH: Yeah, nothing’s plugged in WordPress specific. We do have custom styling. But that’s just, that’s just what we came up with as a team and how we like to work.
DV: I’m not familiar with the VIP center specifically but I’m guessing it includes the WordPress code quality standards, that would be, guys, do you know that to be true, yeah that’s that’s exactly what I mean. All right, good, good, good. Well, that’s excellent to hear, I think, you know it’s good for folks to get an understanding of like what’s involved and what the processes are and I think a lot of folks do you in general, but I really want to get into some more specifics around, you know how this process was like for you and you know some of the things you found that, you know help drive success when when you explored it, but we’re gonna take a quick break and we’ll be right back.
DV: Welcome back to Press This the WordPress community podcast on WMR. This is your host David Vogelpohl, I’m talking to Rob Humar about continuous deployment within your developer workflows Rob right before the break we were talking a little bit about kind of the factors that led dissertatio to kind of adopt continuous deployment you talked about there being a smaller team with perhaps less of a need, they’ve been really with a fully remote and larger team. It really kind of wasn’t a choice you felt for consistency, not overwriting each other’s work. And you know, creating a standard by which your business can operate and from the development percent perspective. Just curious, how did agile play a role in how you change workflows or did it.
RH: Yeah, so quite early on we, because we have quite early on we found out we needed a good way to manage tracking new features and bug reports. We have quite a large team of editors who are writing the content that using the WordPress platform, all the time, and they’re very good at spotting. Focus on the front end, and the amount of new, like I said, the amount of newbie symptoms we needed a way to track them coming in and then tracking the process for other development costs. For instance, we can track when they’re being worked on. When they’re going into QA, and when they’re ready to be deployed, etc. and because we are fully remote team. We need an easier way for these remote developers to be able to pick up jobs, and start working on new jobs.
DV: Okay, so the approach with Agile helps you in terms of specific specifically processing kind of requests coming in from the business specifically editors and allow them to kind of pick it up on the fly, as well as I’m guessing communicate back to the stakeholders around the progress you’re making towards that.
RH: We have to tell product team as well that need to know where abouts these books are in the process of being fixed. And they can report active, the internal stakeholders.
DV: Do you invite the stakeholders to like your sprint planning meetings and things like that or do you do that in a separate context.
RH: We’ll get them out to the sprint meetings but we do have a digital product manager in there that will pass all that information on to the stakeholders of the company.
DV: All right, good to know. So, let’s get back to the continuous deployment side so what does your CD tech stack look like and why, like earlier I asked you about your standards but I’m just curious if you’re using composer get, I understand how you configured your stack.
RH: So we, So, a lot. It’s all based around because GitHub is one of the biggest code repositories in the world, and most developers have experience using it, and they can easily create pull requests and push code changes and into branches, etc. So that’s what we use to manage and track all the code changes again sticking with GitHub we use GitHub actions to run the actual continuous deployment, and that will trigger on various actions that you’re doing GitHub, like pushing changes to a new branch, merging the staging branch into the production branch, and that will run various deployment scripts depending on what was, what has been triggered. And what you can do on GitHub actions. So, basically GitHub actions is like having a little computer in the cloud that you can do anything on basically. So we can run our Pete PHP unit tests on there, we can run our theme code changes through Webpack, so it builds, and it’s checking for lint errors. We can install all the dependencies that we need for the, for the WordPress Project, Project. And we also manage all our WordPress plugins by composer, because we need to create a consistent development environment. So we need everything to be consistent, including the plugins. So we don’t leave plugin installations to the actual WordPress admin area, because we don’t want other developers installing plugins the other but other developers haven’t. So we need everybody to be consistent. And then, on a WP Engine side we we luckily we can SSH into the wiki engine so we can do a lot of things on the WP Engine server via command line, which you can trigger through the little computers that you’ve got on your actions. So for instance we can sync all the files using our sync. And then we run a little program from via the GUI PPCLI called dictator, and actually controls the configuration state. So again it’s going back to that consistency between different environments. And finally, we use the grip of releases to manage rollbacks. So on every big change, we create a new version. If that version of code has an error and we need to quickly rollback we can just quickly go back to the previous version.
DV: Awesome. If you’d like to learn more about what Rob is up to you can visit de Certeau calm and that’s spelled DXER To calm gaming news eSports. Thanks everyone for listening to press this the WordPress community podcasts on W Mr. And this is your host David Goble. I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you here every week on crest.Arrived Thank you that was awesome. I loved how extensive you went into that I’m sure there’s much, much more. I gotta say hearing your approach here I feel very confident in how, in my ability to get eSports and gaming news from dissertatio You sound like you’d have a very, you know, well put together workflow here. I know it’s you kind of mentioned even the very beginning that we chose a lot of these tools particularly GitHub and GitHub actions because you know 70 developers have experienced with them. And, you know, I found that also to be true, but what do you do, have you had to deal with a developer that hasn’t had experience, or at least some experience using your tech stack for your workflow.
RH: Luckily for my natural development, interview, it’s pretty easy, like I said previously, it’s setting up as a continuous deployment that’s hard. And once that set up the developer doesn’t actually need to know what’s happening behind the scenes, they can push your change to GitHub, and then get up as a really nice user, user interface, it says, say as the tests are running. So we have a test on a theme and it says after running and then we have a test on the, the PHP code that we’ve written, and that will flag or green or red, if there’s an error. Everything’s fine. So that’s pretty much all the developer needs to know. They need to know that the tests are running, and they need to know the results of the tests but from a behind the scenes point of view of an internet is never easy, really great point.
DV: As you think about it, especially in the terms of like impact to the business and impact to the individuals and this notion of efficiency, like, not only is it faster to run the automated actions, versus doing it manually, but you also don’t have to learn and configure, you know, the way you would check this things in a manual way and kind of a snowflake environment where every developer has their own way. So I’m guessing that means you can have individuals who focus on those parts make them better as part of the CD process, and then everyone else can free their mind space and time for other things. Is that how it works out for you.
RH: Yeah, so we have a QA engineer that deals with setting up the testing and the deployment scripts, and he’s an expert in all of that. And that means that, like you said, the developers don’t need to focus on that at all, and they can focus their minds on writing the code.
DV: I like to call this concept, you know, scaling your opinion and processes like this I think of this also in terms of like the block editor in WordPress where developers are pre creating themes that content creators then deploy, but it’s a way of scaling that that insight and that intelligence in that quote opinion, so you can reuse it over and over and over and over and over again, and amplify the value of what you do. Do you find that to be true.
RH: Yes, definitely. Because we were scaling up quite quickly. We also needed a way to get these developers set up remotely, and set up on their local environments, easily, so we were able to take a lot of this continuous deployment and create kind of like startup scripts for these new developers that were joining the team. And now we’re in a place where we can just get the development type in one line of code and a local environment will get set up on their machine that matches, everybody else in the team that speed and consistency is so important.
DV: I have a few more questions but we’re going to take a quick break and we’ll be right back.
DV: Everyone welcome back to Press This WordPress community podcast on WMR is your host David Vogelpohl and in the middle of talking to Rob Humar about continuous deployment. Rob before the break, you were sharing some really interesting information. You know around your tech stack and how it impacted your team, particularly around as I described the kind of scaling your insights and your innovation, and by having folks both focus on specific parts of that process versus everyone having to become an expert at all the different things. So, as you went through this at Dexerto How did this approach solve the problems you were having before adopting continuous deployment you mentioned things like training and onboarding but like what was the overall impact and after you deployed it in the business.
RH: Things were a lot faster. And things were a lot safer. Basically, we then had that we then had free environments that we could run the code through pretty quickly. We have a master development server, where the developers can just quickly load up code changes in testings out quickly, then we can move those changes over quickly to a staging server. And on the staging server that can get run through visual user testing, and then once everything’s been tested, we can quickly move everything over to the production server. And because we’re using continuous deployment, each one of these environments is exactly the same, it goes back to that point we’ve been mentioned about consistency, and make sure that makes everything work better.
DV: So someone out there right now Rob is listening to this podcast, and they’re thinking about deploying continuous deployment in their business, or maybe they’re about to pitch it to their boss to get resources to get time to introduce this into the workplace, you mentioned two things in the after that stood out to me, faster, and safer. So I asked you a couple of quick questions on each one of our one question on each of those yet faster mean that you deployed more things quickly and thus introduced more opportunities for dissertatio to make more money like they did have a material impact and like the features you were releasing and best opportunity to earn revenue.
RH: Yes definitely, because we are such a high traffic website, we get over 50 million page views every month. We can quickly really quickly upload changes to the code base that could have an impact, and you can see these changes in real time. If we upload, because we’re an ad revenue based company, if we uploaded something that changed. Maybe the position of an advert on the web page, we can instantly see whether that’s creating more revenue or not creating more revenue.
DV: So if you don’t do these experiments, faster, then you lose the opportunity to make more revenue within this.
RH: Yeah, exactly. And again, if, if it does the. It makes things worse, and we can quickly change back as well.
DV: Yeah, you can iterate I think the iterating is key to digital success. And then you mentioned safer, and I think I’m okay if you want to scare people a little bit about how important testing is because I think it’s vastly important. But, help, help folks understand like what’s that selling point and safer.
RH: Yeah, I’m sure a lot of developers have had a nightmare in the Bucks been some something’s been released on production and it’s all gone. Gone pear shaped. Because of this continuous deployment, we can make sure everything’s going through a variety of tests. And because they’re passing these tests that we should take off. Few things that can go wrong already before you release it into production, and that can make sure your codes at least 80% safer than it would be if you weren’t running these tests
DV: that can have big impacts on the experiences you’re managing Well, Rob, this is huge. I really want to thank you for walking me through your workflows here and the success you found in your team and the impacts it had to the business, but just thank you so much for joining us today.
RH: Thank you very much for having me on.
DV: Awesome. If you’d like to learn more about what Rob is up to you can visit Dexerto calm and that’s spelled DXER To calm gaming news eSports. Thanks everyone for listening to press this the WordPress community podcasts on W Mr. And this is your host David Vogelpohl. I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you here every week on crest.
