 Hi everyone. Apologies for the delay. This is my first word count and my time zones are all wrong. So I didn't realize the time was actually starting. So nice to be here all. Appreciate you giving me the opportunity to come and present to you all. Hopefully this session will be of interest to everyone here or at least most people here. So I'll just do a very brief introduction. Thank you for that wonderful one. So my background is in web development and I've been working for 20-something years. The last seven years or so I've started to work increasingly with WordPress. I've been through a bunch of different roles through my career. So senior dev, team lead, CTO and co-founder amongst others. At this point in time I work for an amazing organization in the UK called Coding Black Females. So we work to try and introduce and support more black women in the tech industry as we're a very underrepresented group. And so I work as an instructor and consultant as well as mentoring some of the students. As mentioned, I do spend a lot of my time working towards supporting black equity in tech. So a lot of the work that I do outside of my main role supports that as well. In terms of just where I'm from, so as you might be able to tell from the accent, I'm not from here. I'm born in the UK but my heritage is from a tiny island in the Caribbean called Trinidad and Tobago. Oh, you're each. All right. And so I love to spend as much time out there as I can. That's a little bit about me. But I would like to just get to know a little bit about you all. I did have a kind of questionnaire set up. But I think it might be easier just to actually just ask a question in the room. I don't realize how many people are going to be here. I've never done this before. So we'll do it the old fashioned way rather than trying to do it through the questionnaire. So let me just ask how many people here have been working with WordPress for more than a year? OK, how many have been working for more than? Keep your hands up. Give your hands up. Everyone keep your hands up. If you've been working for more than five years, keep your hands up. More than seven years. More than 10 years. More than 15 years. OK, there's a couple old school. OK, all right. All right. OK, this is great. How long have you guys been with it? 20 years plus? What are we talking? OK, all right. So yeah, we've got some. All right, cool. We've got some veterans in the crowd. Great. All right. Second question would be. OK, all right. Old school. Second question would be how many of you in here would consider yourselves developers? You write some kind of code. JavaScript, PHP. Excellent. OK, all right. Thank you very much. OK, and then final question. This one's just for fun, really. It's not really to do with anything. If your relationship with WordPress is still as sweet as when you first started, you're not feeling trapped or in battle. Put your hand up. How many people are still in love with WordPress today? OK, there's a lot of people that did not put their hands up here. There's a lot of trauma in this one right now, but it's OK. We're going to try and work through that. All right. So I'm going to skip over that one. All right. So for today, the purpose of today is to explore some of the modern tools and processes that we can use to deliver our products more efficiently, more productively, and efficiently. If we're happy as developers, our customers are happy as well. So we all want to be as happy as we can. So some of the principles that we want to aim for in our development process is reliability. We want to make sure that our projects and our products are going to be as reliable as possible to make sure that we don't put any extra burdens on ourselves. We don't put any extra stress on our clients and customers. We want to aim for productivity. We want to be able to do the work as much work as we can and ideally for as little effort as we can. So we look for ways to improve our efficiency and our overall productivity as a result. Of course, security has to be a priority for any developer. We want to think open terms of our own tools, infrastructure, and also the end result for our customers to make sure that their end product is as secure as possible. We live in the age of constant breaches and security failings. So we want to try and make sure that we avoid ourselves being caught up in that where we can. Agility is simply our ability to adapt to change, both in the needs and requirements of our users and customers, as well as the environment and the markets that we operate in. And finally, sustainability is about us being able to create tools and solutions that allow us to build work, to maintain network, and to sustain our overall businesses. So just a quick preface before we get into it. When I refer to development in the context of this presentation, I'm just talking about building WordPress projects that are involving the deployment and use of code. So JavaScript, PHP, whatever your poison is. But this is not really around the configuration design of WordPress, so to speak. This is a developer-focused workshop, but it is not only for developers. We will not be doing any coding. So for those of you who are interested in following along, if maybe you're interested in developing or you work with developers, hopefully you'll be able to follow through this as well. We have around an hour and a half, which sounds like a long time, but it's actually not a very long time for what we're trying to cover. So I'm going to be pushing through this as quickly as I reliably can. And we can't really do an exhaustive list of the entire development process. So I'm going to be focusing on four key areas and trying to just walk through those. Participation is definitely encouraged. So look, you have your laptop set with you. So if you choose to follow along, then hopefully by the end of the session, you will have an example of a working environment that you can take home and experiment with and build on in your own time. So for today's agenda, we'll be looking at source code management, development environment, WordPress boilerplate, and CI CD. And then we'll just be recapping everything that we've put together. So starting off with source code management. So source code management tools allow us to track changes to our software projects over time, meaning that we can experiment with new features or bug fixes without worrying about effecting, interfering with or breaking other parts of our code base. They also allow us to work effectively as teams by allowing multiple developers to work collaboratively on different parts of the project. So I'm going to skip the survey again. Actually, I will just ask a question. Who in here uses Git already? Okay, a lot of people. All right, great. So a lot of you are already familiar with the benefits of those. Those of you in the room that maybe haven't experienced or use it today. Some of the motivations we have for using it is that we have better protection for our code. We can collaborate more easily with teammates and remote collaborators. It allows us to troubleshoot more quickly because it helps us to track when and where problems may have been introduced in our code base. It helps us to deliver higher code quality and it allows us to deliver much more consistent releases. So for those of you that have already kind of worked with Git, you know that there is a learning curve to it, but once you kind of get comfortable with it, it's one of those tools where you're like, how did I actually ever manage without it? So there are lots of different SDM tools. Git is the most popular one today and GitHub is a platform that a lot of people tend to use. It's not the only one. We do have alternatives like Bitbucket, GitLab and others, but for many of you in the room, I'm sure GitHub is a platform that you've all been familiar with. So those are the two that we'll be looking at today. So Git itself and GitHub as the web platform that goes alongside it. For those that don't know, Git is a command line based tool, but it can be integrated in many graphical tools that you use on your desktop. While GitHub is a web-based platform that supports collaborative development and it's built on top of Git. So many of us here will use this with our teammates and maybe our project collaborators. And it adds a bunch of extra features on top of the basic Git functionality, code reviews, pull requests, issue tracking and a lot more as well. So some of the pros and cons that we have around Git and GitHub or GitHub in particular. So because Git is so ubiquitous nowadays, it has amazing tool integration. Almost anything that you can imagine will work with it is integrated with it. So it's very easy to find tools that support your workflows. It's really useful for project management. Many of us might use additional external third-party tools, but you can actually do pretty comprehensive product management within GitHub alone. It provides you with quite effective access control. So you can manage roles and responsibilities across your team about who can see, access, push through repositories, et cetera. And it also provides a suite of collaboration tools. So we have discussions, issues, project boards and a lot more as well. Some of the potential downsides, there is a learning curve. If you haven't ever used it before, it can take a while to get your head around some of the mechanics of it. But it's worth persevering because once you do become familiar with it, it really is something that's quite transformative in how you do your work. There are potential risks to privacy. So if we don't manage our source code effectively, there are risks of leaking passwords and other secrets that we don't want out in the public domain. GitHub has gotten a lot better at warning us about such things. So if you commit an API key or anything like that, we'll actually warn you. And in some cases can take steps to rectify that. But we do still have to be very conscious about how we approach security management of any sensitive data, passwords, pass raises, API keys, et cetera. Okay, so we're gonna do, I'll do a little walkthrough, but before I do, I have any questions from those so far. We'll do a little Q&A after each of these sections before I get into it. So, do you have any questions for anyone at all? All good? Okay, great. All right, so let me stop the screens. Okay, all right, so what we're going to do is, I'm sorry? Oh yeah, sure, apologies. All right, so when we want to use Git, so I'm gonna be doing this for those in the room that aren't familiar with us. I know a lot of you have been through this, so you can just kind of take a break, browse on Google, whatever you want to do. So for those in the room that haven't, so Git is effectively a way for us to provide a managed space for our code bases. It's like we can create a home folder for it, but it's a folder with special powers. So we can effectively track all of the changes that have been made over time, and we can create these parallel universes if you think like the Marvel multiverse, you've got all these parallel worlds, and we call them branches in Git. So it means that when we want to work on a particular feature or bug fix, we can create a new space for that work, we can do the work, and then once we're ready, we can bring it back in and share it with our teammates or whoever else we're working with. So in order to go through, I'm gonna do a quick walkthrough of what we can do. So some of you may not have a GitHub account. Can I actually just check, is there anyone here that wants to walkthrough that doesn't have a GitHub account right now? Cause if not, I can actually just skip this whole bit. So everyone's already got a GitHub account, so we don't need to do this. All right. So we can just skip this whole piece all together. Everybody has Git, everybody has GitHub. So we can actually just move on to the next part. Excellent. So we will come on to one of the fun parts. Now, I realize this piece, if anyone wants to walk along, is going to involve a fairly heavy download. I didn't think about how many people were gonna be here. So I thought, oh, it'd be fine. But this many people downloading a, and I see a lot of Macs in the room, and it's going to be a fairly heavy download. So it might take a while. So don't all jump on at once, because I don't know how strong the wifi is in here, but I think all of us trying to download at one time could be a bit of a challenge. So what I'll actually do, if I, let me share, before I go into the walkthrough, it will give a bit of time for some people to download while I'm kind of presenting. So we're going to be using a tool called Lando. So if you go to Lando.dev, and you can just click on the nice, right, get Lando button on their home screen, and then you can just download Lando. I would suggest don't do it all now. Maybe stagger it out over the next few minutes, because for Mac users, the downloads are around 700 megs. So it could take a little while, but I'll be talking through it, and then hopefully by the time I get to the point of walkthrough, some of us will have it installed on our local machines. So Lando.dev, for anyone that wants, and then just click on the download button. Okay, so full screen that. So the definition of a development environment is like a private playground where we can basically create, test, and fine tune our WordPress projects and components before we release them for public consumption. So this environment is ideally self-contained, and it should closely reflect the production systems that we'll be deploying to. But the isolation means that we can ensure that any changes or experiments that we make shouldn't affect any of our real world users. So we want to keep our changes away from our users until we know that they're valid. So I had a survey, but again, we'll skip that. Does anyone here use a Docker-based development environment at the moment, container-based? Okay, container-based developer environment? There's a few. Okay, great. Yeah, Docker, yeah. Okay, there's a few over here. All right, great, so there's a few of us. So we have lots of options for development environments. We could potentially be using a remote server, maybe we've got a test or staging server where we're doing our work. We might have a native development environment where we're using the built-in tools on our system. So a lot of us are using Macs, and so we have a lot of tools built in. There are disadvantages to taking some of those approaches. Some of us may be using virtual machine-based environments where we set up a virtual machine where we can do our work kind of exclusively in an isolated fashion. And then some of us have already raised our hands to show that we're using containers. So a virtual machine is like running a completely separate machine inside your actual machine. So if you have a Mac, you could be running a Linux machine or Windows machine inside of your own physical computer. A container is like a lighter-weight version of that. So it allows us to create an isolated environment, but it doesn't take necessarily the same resources as a full virtual machine. We have quite a few different options available to us as developers. We can use raw Docker containers. And if you're a kind of Docker enthusiast or aficionado, that's probably a good way to go. But for a lot of us trying to get set up and configure Docker in the way that is gonna make us most productive, it can take quite a lot of effort. And so I've, over the years, tried numerous different development environments, MAMP, ZAMP, local DevKinster. You name it, I've probably tried it. For a long time, I was using local. That was one that I settled on. It was like a nice graphical interface. It gave me a fair bit of flexibility, but it's very easy to set up new sites. And the challenge for me was when I was starting to work with other teams, it meant that I then had to help them to configure their own environment. And there's a lot of effort that goes into that, especially for someone that maybe doesn't do WordPress development regularly, trying to configure and install all the components. So I wanted a way that meant that our development environment could be reproducible across a team and not necessarily assuming that everybody has prior experience in developing for WordPress. So Docker allows you to do this because you can create a container that has all of the components and tools that you need for your local development and that environment becomes reproducible. You can share it across your team, you can effectively include it in your source control and people can just rebuild and spin up that environment on their own machine. So some of the advantages of using a container-based solution, we can improve the stability of production because we are testing in environments or developing environments that are very close, if not identical to the environments of our production servers. They allow us to have support for our source code tools so we can integrate with Git and use that to source code control any of the configuration that we need for those local environments. It allows us to reduce the security risk because we are creating self-contained units that can be shared effectively and tested before they get distributed and overall it allows for better developer experience because it means when we're starting a project we don't have to worry about how we're gonna configure all of these multiple components on our system, we just download the image, fire it up and we're ready to go. So as I've kind of pointed out already, for this one we'll be looking at a tool called Lando which is a free and open-source local development environment and DevOps tool that's built on Docker and developed by a company called Tandem. So it's not specific to WordPress, unlike some of the tools that I've used previously, this one can work with multiple languages and frameworks but it does support WordPress very well. It does provide an easier way for developers of all skill levels to simplify the requirements for their projects and to get quickly to work on them. So while it's built on Docker, it effectively provides an abstraction layer on top of it so it's much easier for those that aren't super familiar with Docker to actually get started. Some of the pros and cons of Lando, it has really flexible configuration so there's not really much you can't do or configure with it. It allows you to come close to environment parity which is something to make sure that we avoid discovering issues due to the components that change between development, staging, production, et cetera. It helps to align our teams with a consistent way of working, a consistent set of tools. I think if anyone was in David here, David was there. So if anyone was in David's session yesterday and he talked about trying to manage the differences between himself and his colleagues and the different environments they have by having a single environment we can avoid those kind of challenges and make sure that we're using the same environment across the team and all the way up our environment chain. And then it's built on Docker which is a very mature and well established technology. There is lots of tooling for it. It's very well integrated with lots of tools and services that we use. Some of the downsides, there can be a fair amount of upfront effort depending on the complexity of your project. So someone on the team, maybe a team leader, someone has to go through the initial effort of getting everything configured. Once everything is set up, then it's very easy going for everyone else but there is that work to do at the start. And while running container-based environments aren't necessarily as demanding as a virtual machine-based environment, they can still have performance impact especially if you're running multiple, complex containers on your system. As a local environment, you want to make sure that your system can handle the environments that you'll be running. So something just to keep in mind as you spec your system. Okay, so we're doing a walkthrough of this. Again, if there's anyone that has any questions at this point, feel free to raise your hand. Everyone's good. Okay, so that's all I want. All right, so I'm gonna come back to my OBS code. Okay, so with Lando, they provide what they refer to as recipes. So recipes like an abstract, an abstracted collection of tools that we can use in a predefined environment. And by using a recipe, we can effectively get our workflow up and running really quickly. So they have recipes for WordPress, Laravel, a bunch of different other stacks. And so if you're working on another stack, you can also use Lando to support your dev environment. So we kind of skip the get walkthrough. So I do need to go back to it. And what I'm gonna do is just create a new repository for this project. So again, if you're wanting to walk through this, then you can follow along with this as well. So I'm gonna create a new repository. And I'm going to call this WCUS. I'm gonna leave it as public. I'm not going to add a read me or get ignore or license. So it'll just be a bare repository. Okay, and so once you've created your repository, then we're going to clone it locally. And so I'm gonna grab that. And I'm assuming if you've got all these tools ready, then you already have BS code, which is what we're using for development today. So I'm gonna clone that into my dev folder and then open it. Okay, so at the moment, I have got my empty repository cloned locally. As of now we're actually going to set it up for our local development. So the first thing we're gonna do is just run the initialization. So has anyone managed to get Lando downloaded? Yeah, we've got at least one. Anyone else? Okay, so he's our representative for the crowd audience. Everyone look over his shoulder if you're not sure what's happening. But hopefully if anyone else is downloading them when you can, you can just follow along. So once we have Lando installed, in order to get our environment set up, we're going to do Lando init and then we're gonna specify the recipe and we're gonna select WordPress type. And so that's literally the first compound we're gonna run, Lando init recipe flag and we're gonna select WordPress. When we do that, we're gonna have a couple of questions that Lando will offer us. So it's gonna ask us, where do we want to get the code base from? So I'm gonna be specifying the current working directory. Then it will ask us, where is our web root relative to our destination? So I'm going to be specifying a folder called web, which doesn't exist yet, but we'll be coming to that when we actually look at our boilerplate. So the web root is gonna be web and then it's gonna ask us what we want to call this app. So I'm just gonna call it WCUS. So then we get a little text graphic just letting us know that it's been set up and initialized and it will give some instructions to go to the directory where it was initialized and we can run Lando start to get rolling. Which we're not gonna do straight away. It gives us a few more details. So the name of our app, the location where it's being held, the recipe we used and we can look up the documents for it as well. So in our file explorer, we'll see that one file has been created for us called dot Lando dot IML. And so this is a configuration file that Lando will create and we can use to configure the overall environment. So it's just a regular IML file that a lot of you will be familiar with already. So we're gonna make one addition for our particular needs. And so we're going to add another entry called services. So one of the things that Lando allows us to do is to define the different services that form the part of our environment. So we might have a web server, proxy, database, any of the components that we need. And so we're going to define simply for our app server which is going to be the component or the container that's actually going to be hosting our PHP application. We simply want to specify the version of PHP that we're going to run. And so for that it's gonna be PHP and we're gonna use PHP 8.2 for this particular project. You can use any version of PHP with Lando, I think from 8.2 all the way back to 5.6 if you want. So you can configure it as you need for your own project. You all right there, buddy? Okay. All right. So we've set up, we basically defined the one change that we need for this project. So this can be as complex as you need right now. We're just saying we want to run PHP 8.2 in our app server. And so now that we've done that, we can go ahead and run Lando start as it suggested. So I'm gonna put that in. And so what will happen is, yes, yeah. So we'd run without, it's just to set the version. I think the default is, it might still be 7.4 or something, but because we're using Bedrock we need 8.0 minimum. So yeah, you don't have to do that if just whatever version you need. Okay. So what it's doing in the meantime, it will basically configure, it will move everything into place, configure all the pieces that we need. I'll just show you some of the output just to, so it's letting you know that, okay, I've got a bunch of SSH keys. So that's just a little warning from it. And then it lets me know that I'm using an unsupported version of Docker desktop. So the reason that Lando is quite a large download, especially if you're on a Mac, is because it includes its own version of Docker desktop with it. So if you already have Docker installed, it will kind of moan when you're installing it, but you can ignore the complaints. It's just saying that you're using a version that I don't know about, but it will work fine. So it's just letting me know that I've got a new version than the one that it provides. Then it provides some details about my running application. So it lets me know the name again. So WCUS where it's been installed. These services are included in this project. So I have my app server and my database. And then it lets me know the URLs that it's available at. One thing actually that I skipped is when you install Lando for the first time is that if you want to use an SSL URL, you will have to go for a very easy step to trust the certificate authority. So it's documented on the Lando site. It's literally just like one line of code, super easy. One time you don't have to do it again. I've already got Lando installed, I don't have to do it now, but just one thing to keep in mind if you plan on testing with local SSL. Okay, so now we have got a development environment that is effectively ready to go. One thing that I would recommend is that if you don't already, you can go into your extensions. And if you look for Dev Containers. So Microsoft have an extension called Dev Containers, which allow you to connect to Docker-based environments such as this or any other container. And so this means that you can log in to your container using VS Code. So all the steps I'm gonna do, we can actually do externally. We don't have to log in. I'll show you actually what happens when you do log in just so you can get a feel for how that process works. If I want to access or run a command within my container, so say for example, I wanted to do a Composer install, then the way to do that from the outside would be to prefix it with Lando. So I'll do Lando Composer install. And if I ran that, it would run the Composer command inside my virtual environment. So the thing to keep in mind here is that if you created a container like this and you shared it amongst your team, they don't need to have Composer or NPM or any of the other components installed in their machine. It's all gonna be included in the environment for them, which is what makes it so useful. Say something to go through all that trouble. So I'm not gonna do that right now. So what I will do is I will simply connect to my running container. And I'm going to select my app server. So WCUS, I'm gonna select the app server. And what that does then, it creates a new connection into my dev container. And you can see now that from this little label down here, it's connected to my container. So what that would mean is that if now I chose to log into my terminal, I'm actually not connected to my host machine anymore, but I'm actually running inside of the app server container. And so from here, it's now, if I just do like another, so I'm gonna do PWG. So it tells me where I am, I'm gonna list the root. And so you can see all of the file system for the container as opposed to my host machine. Okay, so if we go on to this point, then we now have our repository set up in GitHub. We have our dev container set up. I'm actually gonna switch out this one for a second and drop back into this one. So what I'm gonna do at this point, just because it's good practice, is I've now added my config file. So I'll just do my first commit. So I'm just gonna say, installed Vando. And I'll commit that, so a bit of staging and commit. So we'll be pushing that later on. Okay, so now we have the beginnings of our development environment. We have a container that's ready for us to actually work in. It's been set up WordPress, but we don't actually have WordPress installed right now. And so now we're going to move on to the next stage. And before I do again, any questions or comments at the moment? Okay, everyone's good. All right, so now we can talk about WordPress boilerplate. So boilerplate is a set of reusable code that we can use as foundation for building our sites, themes, plugins, or any other component. These templates will often incorporate developmentless practices. So it helps our end product to be more reliable and sustainable. By skipping a lot of the donkey work that we typically have to do when we're starting a new project, it means that as developers, we can become more productive and agile and we can start delivering value much more quickly and consistently. So I had a question again. So for this one, I would just want to know, does anyone currently use a WordPress template or boilerplate in their projects at all? We've got a few, okay, great, thank you. All right, so there's a few of us here, nice. So I'll be looking at one called Bedrock and some of the reasons that we might want to consider using Bedrock are because it helps us to lower our overall set-up time and effort. It allows us to deliver higher consistency across our projects. It helps us to reduce security risks as it has a number of features that improve the default security profile of WordPress and it also has improved dependency management for ongoing management of our projects. So Bedrock is framed as a modern boilerplate that aims to improve the structure, management and security of WordPress projects. So it's not a theme or a plugin, it's actually a framework upon which we can build our WordPress sites and it brings various best practices from the wider web development industry into the WordPress ecosystem. Some of the advantages of using Bedrock are it has amazing Git integration so it can be, if you're already using Git-based workflows, it fits very well into those. It introduces state management so we can effectively manage the states of our projects at any one point in time. It has various security enhancements including better password hashing algorithms, it removes config and vendor files from the web route so it separates our web content from our configuration and it allows us to use environmental configuration. So if you've got multiple environments in your workflow from local development through staging and production, we can now configure those much more easily. Some of the cons to think about, again there is a learning curve involved in switching to it from default WordPress development. Not all extensions will support it and there can be times when there are incompatibilities with certain tools that might be hard coded to expect the standard WordPress structure and because Bedrock has a different structure they can sometimes be incompatibilities with that and while it gives us more control over the kind of maintenance process, there is a level of effort that we have to think about. So it doesn't allow us to use the default kind of plug-in update mechanisms. We can control it now, we can version control all of that. The updates and the changes that we have to make but we have to think about the workflow that we're going to use to support that. Okay, so now for us to get set up with Bedrock, so if we've managed to get our first starter environment ready, then I'm just gonna go up to my instructions for this. Okay, so I'm gonna switch back to VS Code. So now we've got this empty space and so what we're going to do to get our Bedrock-based project is, we're going to run the following command. So it's going to be composer, create project and then all we're going to do is specify roots with Bedrock and so this command is going to effectively initialize the WordPress folder for us. So composer, create project, roots with Bedrock in my local development environment folder and so when I run this, it's going to effectively download the default sets of components which should only take a minute or so and we're done. So the one thing that will happen here is because just a quirk of how composer works, we can't install a new project or create a new composer project in a non-empty folder and because we have our Lando file in this folder, it means that we have to let it create in the sub folder and then we're just going to move all the files out. So you can do it in the command line or you can just do it in VS Code. So I'm just going to select everything in that folder and I'm just going to let you move it into the root and then I can get rid of the Bedrock folder. We don't need that anymore. So I'll just delete that. Okay. So now we've got all of our files ready and available in our dev environment and so the thing that we can now see is if we check our source control, we'll see that we've only got 17 files that are actually available to be committed. So even though we have a bunch more files available, those are all being kind of ignored by the .gignore file that it creates. We also have a default license, default readme and of course you can remove or configure any of those as you need. So now that we've put all of the files in place, the next step is to actually initialize the project. And so while we could technically go into our, in fact, let's see if we can do that. I'm gonna try a new thing today. So I should be able to do, what do I call it? WCUS and that'll be at .lando.site. And that's not running yet. So let me just make sure, let me show you that one. So I'm gonna just install and when we install, we can use the WordPress command line. So Bedrock comes with Composer and the WordPress command line provided as default. So we have access to the CLI out of the gate. And so I'm going to do setup URL is WCUS.lando.site. And I need to also, I'm gonna set the title. So title equals, I'll call that WordCampUSSA2023. And then I'll set my admin username and my admin password. So obviously for your own, you would set your own accounts and password. I'm just gonna do a basic, which we would not normally ever do, but for the purposes of demonstration. And so should now be able to normally run that. Oh, I need to, oh, sorry, because I'm outside. I'm outside of my Dev environment at the moment. So let me do that command again. And this time I need to prefix it with .lando. And now I have database, okay. Oh, okay, yep, sorry, I missed the key step. All right, so with Bedrock, what we need to do, one of the first things that we have to do is we no longer are doing our configuration in the WP config file. So we now have a file called .n, which allows us to define the variables that are specific to this environment, which I have not updated. So I'm going to create a file. So I can, oh, if I'm in my file view, that would help. So I'm just gonna create a copy of that file and I'll rename this as .emb, okay. And so now I'm going to configure this to use the defaults from Lando. So when we created our Lando Dev environment because we used the WordPress recipe, it provided some defaults. And so I know that for the DB name, it's WordPress, also WordPress for the user, and the password as well. And then we're going to uncomment this one because the DB host is now on a separate container, which is called database. So we're gonna set our DB host so that it points to the database container. We've set the connection details for our database, name, user, and password. And we can leave the all key stuff. We don't need that for this example. And then we just need to set the correct URL. So I called it WCUS. So the URL will be WCUS.Lando.site. And so I'm gonna save that file and then I should be able to now re-run my installation. And oh, I'm sorry, I missed my email. So I have an email and I'll just do my own email address. Okay, so now it should actually go ahead and run successfully. And so if I come back to my site, I should, why is that not picking up? The joys of live demonstration. So I have, and it is running. Let me just check and make sure everything is running. And yes, it is. So why is it not picking up? Oh, I think I know why. All right, I might have to just do a quick modification of my host file, I think. So, all right, so I'm gonna go to, sorry, this is not normally necessary, but I had to fox around with my host file because of my Wi-Fi connection. And I think I might have broken it. So I'm gonna just add it manually here. So WCUS.Lando.site. And this should not be necessary for anyone that's following along. It's just because I had to make some changes to my setup. Try that again and still know. All right, it's not the ideal. Not sure why it's not picking up. Now, I just try one thing, if I don't, I will move on and come back to it. Okay, so I was just like, thank you. Okay, we, all right. So now we have our bare bones WordPress site. So, following the hiccups, we do have a standard site. We've been able to create our own account. So I've got my admin account, I can log in, but we don't need to go into all of that right now. So I go back to, okay, so I'll come back here. And all right, so we've now got our repo setup. We have got our dev environment setup. And we have got our initial working WordPress project. So I will just go back and I'm gonna do one more commit. I'll just say we installed Bedrock and commit that as well. So at this point now, we'd be ready to pretty much go and do whatever we need in terms of our development. So I go back to our WordPress. Okay, so then the final step is now, if we want to take the work that we're doing, so we don't need to go into the actual development, but the next step would now be, okay, we want to actually be able to deploy this work to another environment somewhere. And so for the purposes of this demonstration, we're just gonna set up a temporary account on a new, I'm gonna create a new hosting environment. So I'm gonna use.com and let me log out here. So PortRabbit is a hosting platform. I'll be just using a trial account for purposes of this. They have some nice features for development. So I do use them in certain projects, but they allow us to have like a free account that we can use for a couple of days. So that will serve for now. So what I'm gonna do is create a new account. I'm just gonna use a POS address. So I'll do WCOS and I will just let me just use, just make a new one, just did, and I'll save that for now. Okay, so I'm just gonna make a new account for the purposes of testing and I'm going to create, and then just check my email. Okay, and so again, PortRabbit supports more than just WordPress. They can, you can use it for various PHP applications. So I will be setting up for WordPress. And so it brings us into the dashboard. And so PortRabbit is quite nice because it has a number of DevFriendly features. So it gives us SSH, WPCLI out of the box. It also allows us to support Git-based deployments, which is something that I'm quite fond of. And so for the purposes of this, we should be able to just use it to demonstrate how we can push our work from our local machine all the way up to our hosting environment. So we have to make a few changes here. So one of the things that we'll observe is that we have access to environment variables directly in the interface. So we have a static .m file in our local environment, but PortRabbit allows us to define it through their GUI. And so what we can do is we need to make a couple of changes. So because we're using Bedrock, and one of the changes that Bedrock introduces is the structure of WordPress. So as mentioned, the web root is now in the web folder. We also have the config folder where we can define a number of the constants that we want to use across our application. So where most of this work we've previously happened in WP config, it now happens in the application config slash application.php file. And we can see that we're defining a bunch of the standard constants that we would expect to see, w home, site URL, et cetera. But now it will check first for the environment variable in our .m file. So it's loading the value that we've defined here. So in this case, WC-RES. And for the site URL, because Bedrock rearranges, we add WP at the end of it. So in our web folder, instead of seeing the expected list of WordPress standard files, they have now been shifted to the WordPress folder. And just to show you in there, now you're gonna see what looks more familiar. WP admin includes and the various root files that we normally expect to see. So Bedrock separates those core WordPress files from our own files or folders that we kind of modify. And all of those live in the app folder. And so here we have our folder for MU plugins. For MU plugins, plugins, themes and uploads. Uploads is our media library folder and of course, themes, plugins and MU plugins are as expected. So when we're doing all of our work, we do this in the app folder and we don't really touch WP folder. You'll see that it's grayed out because it is getting ignored. So none of the core files are actually included in source control. They're managed entirely by Composer. So it saves us having to commit all those files and deal with all the changes when we do updates. So going back, we're just going to make a couple of changes. So we're going to change this to slash WP. To point to the correct place. Then we need to set up our database. So this particular provider, they provide us with a number of built-in variables. But because they are named differently to what our code expects, we then just have to provide our own ones. So we're going to do dbname equals, I'll just copy that. So that will be my SQL database. And then we've got host user and what's the name, host password. Okay, and then we just need to set the WPNV. So this is a environment variable that's introduced by Bedrock. So it allows us to distinguish between our different environments. By default, it provides us with development, staging and production. So we're going to treat this as our production environment. And just make sure there's nothing else I'm missing out. Set URL and nothing else that's good. Okay, cool. So now we've updated our environment variables and that's gone through. So then the only other thing that we need to modify is our root path. So again, we always have to remember that because we're using Bedrock, it modifies the path. So our web files are now held in the web folder instead of the roots of our applications. So I'm just going to change to make sure that PHP knows that it loads from the web folder and not the root instead. So we can save that. And then after that, the last thing that we have to do is to effectively make sure that we can connect to our Git repository in this environment. In order to do that, we need to go into SSH and get our SSH details. Now I need to, I might have to disconnect because I need to, I need to put in my private SSH key and I'm not about to do that in front of everyone. So we just, is it possible just to blank the screen for a second or do I just disconnect? I can just, okay. All right. So I'm going to just pop in my private SSH key. So let me do that real quick. I don't know, right? Okay, so, S-A. No, no. No, actually, do you know how I've just done PB copy? Actually, that would have been easier. Okay, so let me just paste that in real quick. So add SSH key, and that goes in there. Okay, it's done. So if you'll come back, please. Right, so, yeah, we drop in our SSH key and then now I can go back. So what we could do at this point, if I go into my application, so I'm going to copy this URL. And so to test it first, we can do it locally without having to involve ourselves in any kind of external. So I'm just going to get remote, add production, and provide the URL that they've given me. And so now I've got that set up as my remote. So I should have origin and production. My origin is pointing to GitHub, production is now pointing to my hosting environment. So first I'm just going to do push origin. Let's get it off on GitHub first. Let's do minus use, make sure, okay, and then we're going to try the same with, I might need to wait a minute, we'll see if it works. So when we set up the SSH key in the hosting environment, it normally needs a couple of minutes to push through. So I'll give it a try, hopefully it's had enough time. Can it read? Yeah, I don't think it's connected yet. Okay, so I might need to give it a minute. So I'll come back to that. Okay, so once the repository is available and my SSH key has been picked up, then I should be able to just push to that repository from here. So then the next step would be, I'm now ready to go ahead and create an action file. So if I go back to our presentation. So we've done quite a lot of set up, but now we're at the point where we can start talking about CITD. So that stands for continuous integration and continuous delivery. It represents a set of practices and tools that allows to automatically test, build and deploy our code changes at any time in a reliable manner. It ensures that every change we make to our code is can be thoroughly tested, can be integrated smoothly with any visiting code, and then we can release it safely to our users, improving sustainability of our solutions and improving our team's agility. So question was gained to be, is anyone already using CITD in their processes? If you're over here, okay, there's a few around, great. Nice, all right. So for this walkthrough, while there are lots of different tools are out there, Jenkins, GitLab, et cetera, I'll be using one of the simplest options, which is GitHub Actions. If we're using GitHub already to manage our code and to maybe even juggle our team responsibilities, then we can use it for our CICD process as well. Some of the motivations why we want to introduce CICD into our process, it helps us to improve our production stability, it enabled us to have easier releases, we can have shorter feedback cycles, and finally it allows us to increase our overall user satisfaction because there are less errors for our users to deal with. So we're looking at GitHub Actions, which is a CICD platform built into GitHub that allows developers to automate our build tests and deploy pipelines directly within our code repositories. So we can run, create, and share reusable actions to perform almost any desired task in a completely customized workflow that can be triggered by a wide range of events within any repository that we host on GitHub. So it's very flexible, quite easy to get going with, and it's just super easy so it's already built into GitHub. So some of the pros and cons of using actions or GitHub Actions, so pros, most of us are probably using GitHub already, and so it's really integrated into that. It has a real easy setup. We just create a workflow file that I'll be showing in a moment. It allows us to utilize shared actions that have been built by the community, so there's a vast library of action available that we can use and integrate into our own workflows, and it has support for multiple operating systems. So on GitHub's infrastructure, they support Windows, macOS, and I think Ubuntu, and if you want to have additional operating systems, you can configure your own runners in-house. Some of the potential downsides is that if we are relying very heavily on GitHub for everything, then we do have a degree of fender lock-in that we have to think about, and some people might want to consider that some aspects or parts of that platform are closed-source and they may prefer to use a fully open-source solution. Okay, all right, so let's try and walk through this. I'm gonna try and see if I can push yet. Okay. All right, so now it got picked up, and so I'll just quickly show what's happened here. So, PortRabbit has Git deployment built-in by default, which is great, and so what it means is that by simply pushing to the repository in the PortRabbit environment, it will actually trigger off a deployment for us. So in some other environments that we use, we have to kind of either set up the hooks and everything that we need, but PortRabbit has it wired up already, which is amazing. So all we've done is just we just pushed from our local repository to the repository in PortRabbit, which you can see here, and then it has triggered off a build of its own. So in this case, it looks for some files that I haven't set up, and then it does a Composer install on its own. It doesn't require us to make any further changes. It has Composer already set up and ready to go, and so it's taken the composer.json file that we have, and that defines all the dependencies that we're using, and it's downloaded that, installed it, and deployed it. So now it's showing us the release cycle. So basically, it builds it on one machine and then pushes out to the final one. So if it has worked as we hope, moment of truth, and we have a site that's now ready to set up. So, okay, good question. Oh, sorry. So we can again, we could go through the web interface, but we can just as easily go through the command line. So I'll just go back to when I set up my local one and we just stop. So we're going to get rid of that. We don't need that anymore, I know we do. Landow, and then all we're gonna do is we're going to first modify our WPCLI config file. So this is the file that defines how WPCLI operates. And so what I'm gonna do is actually add a couple of aliases. So I'll do one for my development environment. And for that, it's gonna be the same as the default. So it'll be path, and that's gonna be web slash WP. And then we're gonna have one more for our production environment. And for that, we're going to set the SSH value. And then we're gonna grab that from here. And I'm just gonna get rid of that. Okay, so we've now got a couple of aliases that we can use for WPCLI. So when we have multiple environments, this is like a really easy way to allow us to connect to those environments using WPCLI. So I'm gonna save that. And so I'm gonna use that alias. So I'm gonna say, now I'm going to use command line in space to connect, hopefully, to our production instance. And we're gonna run the exact same setup as before. So I just need to fix the URL to reflect the actual one. And so I can grab that from here. And then drop that in. So now we've got our URL, title is fine. We'll leave everything else as it is for the time being. And I think that's really good. And it doesn't let me connect because I already connect. So I use an air. Let me just try manual connection. Okay, that worked. So that should be on the end of this one. I think that's how I've normally done it. Let's try that though. Oh, okay, all right. It's because it's using the wrong key. Okay, so I need to, yeah. Sorry, it's using the wrong SSH key. It should be using, can you remember, is it minus I to use, can you remember how you specify? That's right, yeah, that's right, thanks. So I think, can I do that in our Lord, right? Let's see if I can make that work. This was not happening in my practice run last night, promise. Okay, so can I pass in, oh, I think I have to do it at the end, minus I. And then it's gonna be in, I do the same, see what that looks. Let me see what I just do. And I haven't put up that one. Okay, I'm gonna do it the old way because I messed up something in my certificate setup. But normally again, I'd just be able to do it directly through the CLI. So I'm gonna call that, we're doing WC, yes, and then we'll just add that there. All right, so we'll print the password and we'll do the same. And yeah, we don't need such answers for now and then we'll do that. So we'll just wait for it to finish and then we should have our site ready here. Okay, so we've got our live one and so this, the files that we're now using have been pushed up from our local repo using Git. So then the last step in our process is simply now, how do we make it so that rather than pushing directly from our local repo, we can have it go up from GitHub instead. And so in order to do that, all we have to do is to create a workflow. Wait, don't let me see. Oh, yeah, I'm gonna, yeah. We have to do is to create our workflow file. And so I'm gonna make a new folder called dot GitHub. And then another new folder called workflows. And in this one, we'll create a file called it deploy dot, why not? Okay, so from this file is how we will now define exactly what we want to deploy to, or from GitHub actions. And hopefully if Apple is on my side, I can just paste and no, it's not my site. All right, let me see if I can just do it. Could you grab it from my gist? I'm gonna grab it from here. So this file is what GitHub actions uses to define the workflow that we're going to run based on the events that we specify. So just to look at what it has, you can look on GitHub documentation. They've got a lot of really comprehensive docs. So we set the name for our workflow, which is deploy. We are gonna specify which branch we want to be triggering from. And we're also specifying the event that we want to trigger. So we can do push, pull requests. There's a bunch of different events that we can fire on, but for this case, we're just gonna have this run when we trigger a push event to our main branch. And then when we run a workflow, that's built up of one or more jobs. So in this case, we only have one job. It's a very simple workflow. And we're gonna have a single job called build. When a job is defined, it's going to be executed on a runner, which is effectively just a virtual machine that GitHub hosts for us. And so we go through the process here and what we can define then is the steps that are involved in that particular job. So we have the first thing that we're doing is using the checkout action that will check out a copy of our repository so that the runner can do its work on it. And then we're going to have a second action and all that's going to do is to sync our repository from GitHub with our port rabbit repository in this case. So we're going to need to specify where our repository is coming from, the branch that we want to sync, the URL for our destination repository and the branch that we want to sync on that side. And then we also need to provide the SSH private key for GitHub. So I'm going to go to my repo and that is genius slash WCWS. So I just need US. And then we'll leave it as the main branch and then we just need to grab our port rabbit git URL. And so we're going to be using that. And so we just drop that in as the URL. Okay, and so then we leave main and then we're going to have to, I'm going to have to copy the private key one more time but I'll do that using that, so I'm going to do. And then once I'm in here, I'm going to go to settings and then we can define our secrets. So again, because obviously our keys, our secret values, we're going to use the secrets here and I'm going to have to disconnect it real quick and then I'll disconnect as short as possible. Secret key, sorry. So I've created a secret in my repository called SSH secret key. Could be that, yeah. So that now contains a secret key and if you've used GitHub before, you'll know that once you enter it as a secret, it's no longer displayed. You can't access it, you can only change it. So that's now available for the workflow and so that will be retrieved. So here we're defining that we want to take the value for that private key and I think I need to change up to destination, private key, so that will be pulled from that value that I just created. Let me just make sure I have both of them in case. Can't link, I need both but I'll do both just in case. Okay, so we've got our destination private key and the base private key. So we have, I think, got everything that we need. Let's update that to three back there and that too doesn't need, that's fine. Okay, so we've got checkout, get sync, source. All right, I think we have everything and so now let's just push these changes up. So I'm gonna do that one. And then configure that workflow. Do that and we'll push and let's see how badly this breaks because it will reload it's right. Okay, so we'll go to our actions and it is running. And we'll see what happens. Oh yeah, it did break, so I'm expecting inputs. So destination private key. Let me just check the repo for the action. I've probably put in something wrong. So it's expecting destination, SSH destination. Okay, and now we come into the trial and error process where we figure out how to get our action working. But let's see what happens this time. Yeah, of course, right. They say never demo live and this is why. But let's see what happens this time. Just push it up. See, this is why it's good to have an audience. Okay, I think you are correct. So let's check. And yes, you've been a prize. All right, so appreciate it. Thanks, bro. Let's try again. SSH secret key. Oh Lord, yeah, oh my days. Too much pressure. Any other takers working it black? Say now, speak now, speak now. All right, so please Lord, can we just... All right, takers, what are the odds that we're gonna get a green check this time? Let's see what happens. All right, failed, failed. Okay, what's happened? I did not read. That's the way I've never seen this error before in my life. What is this? The hell? Oh my, honestly, I have no idea what this is. To be a ownership. First of all, I find that very personal. Oh yeah, sure. Question tonight. What? Are you sure? Yeah, so it normally, GitHub Workspace is the default location that it will check out into. So get a workspace. I've just never seen this before. Let me just quickly check another project that I know is working. Sorry, I need to find. Yeah, this had to happen live, right? Isn't that one? That is a different task. Okay, this is super weird. I don't know if I'm gonna go for a full debugging session live. So what we might have to do is imagine that this is a green tick. And so normally without this error, it would now just be doing the same job of pushing from GitHub Action up to our final destination. And so that would give us the ability now. So whenever we merge, so obviously you can set up your branch protection rules, like protect whatever branches you need. And that gives you control over who can push to what. So if you've got a developed branch, a main branch you can control, you can set up multiple environments. So for example, we typically have a staging environment. Depending on what workflow you use, you might have a production branch or whatever. And you can extend your workflow file to support different environments and different contexts that you need. And then it allows you to have full control over that development process. So I'm not gonna try and figure out why that's come up because that looks like a very esoteric error that I've not seen before. So I'll just carry on to the conclusion. So the idea was to have at this point a fully working CI CD workflow, which I'm sure I'll figure out afterwards. But in a normal scenario, this would be how we begin that process of allowing our work to be pushed up to our production environment. Okay, so we're just about to wrap up. So let me just finish up. So we've just looked at some of the different tools or processes that we can use and how they can benefit some of those principles that we try to incorporate into our development workflow. So this is just like a really big summary of how they can all contribute towards that. The next steps in terms of what we can think about, we have so many different ways that we can explore and extend these processes. So we can look at integrating unit testing. We can integrate versioning and semantic versioning to our projects if we're releasing products, for example, we can automate documentation and release notes. We can implement commit linting so make sure that everybody is committing in a consistent way. We can develop our own custom WPCLI commands as we do and we can look at monitoring and logging our applications as well. So this is really just the very beginning of how we can actually start to build out a really robust development workflow. So that's it from me. Thank you all, we've made it to the end. I appreciate it was a very long session so thank you for sticking around. I hope you all had something of value from this even if it's not the final outcome I was aiming for. But I really appreciate you all being here to the very end. So thank you and enjoy the rest of your time. I appreciate it. Time for a couple of questions. Any questions for anyone? Right, yeah, it's one of those random ones, right? Yeah, it's pretty good, I'll be working with you. Okay, so. So one of the things we've been discussing is a lot of the new stuff in the full-site editor, it winds up in the database settings. Do you have any recommendations or have you found patterns that work for getting that into Git and sort of keeping those things in sync? Yeah, definitely. So we have a custom WPC-LI command, for example, that allows us to sync, yeah. So basically it allows us to sync the data and the media from one environment to another. So let's say you want to maybe update your staging environment from production. You know, maybe you've got some data you need to update it. I was talking more about like the things like you can set the, you can set the, you know, like the theme palette and that type of stuff through the admin dashboard or you can use the themes.json file. And likewise with patterns and templates. So you can also have them. They can be a file or they can be in the database. Yeah. Have you found a good way of. Yeah, typically for us we try and keep it the file base just because it's easier to manage. There's a tool called Dictator, which is like I think an open source one you can find on GitHub. And that allows you to capture different aspects of the state from your database. So you can reproduce that in different environments. So say for example, when you're talking about the theme, you could capture like maybe like the widget configuration or the theme configuration. And that goes into a file that you can then source control and you can distribute that. Yeah. Yeah. Okay. Thank you. We have time for one more question. Hey, you speak more about the thing you were about to speak about before he changed his mind. So talking about syncing environments and what kind of tooling you use for that. Yeah, sure. So I guess a lot of people would typically use things like DV Migrate Pro and whatever else. We found that actually because we use WPCLi so heavily, we have a command for example that will sync between any of our environments. So if I need to pull staging down to my local environment, I can just run a WPCLi. It syncs the media library and it will sync the database or using the built-in WPCLi tools. It's not something that I have in a public repo right now, but I could, yeah. If you get my details, I can probably let you know I can make it available. So we use that quite heavily to synchronize. So for example, when you're starting a project and you might do everything locally and now you've got the whole site configured and you wanna push it up, you might have to do typically like a database lift and shift, you know, you copy the whole thing and do that. And now we can just do it directly in the command line. So it's literally like WPCLi Bedrock Sync Development Production and it pushes the database and the whole media library from development to production and we can do it from any environment that we define in our WPCLi aliases. So if I wanna push from development to staging or staging to production or vice versa, we can do that. So it's like a super easy way. Once you've got through the headache of actually setting everything up, then after that it's just, you know, you run one command, you can integrate it into your workflow if you want, we can do it manually if you need to as well. Yeah, I will, yeah, if you grab my details and I'll see if I can actually put that in there. So it's actually, oddly enough, I used that, that was what I started with. So they provided a shell script and I modified it so heavily, it was just getting to the point where I was like, okay, do you know what, it'll be easier if I just do this as a command. And so I used, effectively, I replicated the logic but I'm doing it as a WPCLi command. So I added things for support, like I can support multi-site, which their script doesn't. Some of our projects use S3 for media library. They don't support that so I built in support for that as well. So now we just have a command that does it but it was based on the one that they started off with and we just kind of extended the crap out of it. Yeah, all right. Okay, thank you all so much, I appreciate that. Thank you.