 Hi everyone. Apologies for the delay. This is my first word count and my time zones are all wrong, so I didn't really know if the time was mentally starting. So, nice to be here all. I 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 organisation 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 realise 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? Okay, how many have been working for more than a year? Give your hands up, everyone give your hands up. If you've been working for more than five years, give your hands up. More than seven years? More than ten years? More than fifteen years? Okay, there's a couple. Oh, school! Okay, all right. All right, okay, this is great. How long have you guys been with it? Twenty years plus? What are we talking? Okay, all right. So yeah, we've got some veterans in the crowd. Great. All right, second question would be... Okay, 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. Oh, excellent. Okay, all right, thank you very much. Okay, 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? Okay, 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 okay. 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 that 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 and design of WordPress, so to speak. This is a developer-focused workshop, but it's not only for developers. We will not be doing any coding. So for those of you that 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 like 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 CICD. 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 project over time, meaning that we can experiment with new features or bug fixes without worrying about affecting 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. So 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, 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, etc. 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 and the sensitive data, passwords, passwords, API keys, etc. So I'll do a little walkthrough, but before I do, I have any questions from those so far, and we'll do a little Q&A after each of these sections before I get into it. Do you have any questions for anyone at all? All good? Okay, great. So let me swap screens. Okay, 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 going to be doing this for those in the room that aren't familiar, so 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 wherever else we're working with. So in order to go through... I'm going to do a quick walkthrough of what we can do, so some of you may not have a GitHub account. Can I actually just check if anyone here that wants to walk through that doesn't have a GitHub account right now? Because 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. Okay, so we can just skip this whole piece altogether. 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, and I didn't think about how many people were going to 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 Wi-Fi 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 download's 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... So I'll 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 a 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 serve 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 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 it set up and configure Docker in the way that it's going to 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 was 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 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 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. We can use 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 going to 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 is 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 etc. 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 here 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 by 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's 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 has to go through that 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 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 alright so I'm going to come back to my VS 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 so if you're working on another stack you can also use Lando to support your dev environment so we kind of skipped the get walkthrough so I do need to go back to it and what I'm going to do is just create a new repository for this project so again if you're wanting to walkthrough this then you can follow along with this as well so I'm going to create a new repository and I'm going to call this WCUS I'm going to leave it as public I'm not going to add a readme or getignore or a license so it will 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 going to grab that and I'm assuming if you've got all these tools ready then you already have VS Code which is what we're using for development today so I'm going to clone that into my dev folder and then open it okay so at the moment I have got my empty repository cloned locally so now we're actually going to set it up for our local development so the first thing we're going to 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 in it specify the recipe and we're going to select WordPress type and so that's literally the first component we're going to run Lando in it recipe flag and we're going to select WordPress when we do that we're going to have a couple of questions that Lando will offer us so it's going to ask us where do we want to get the code base from so I'm going to 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 going to be web and then it's going to ask us what we want to call this app so I'm just going to call it WC US 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 going to 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 YAML file that a lot of you will be familiar with already so we're going to 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 other 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 going to be PHP and we're going to 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 alright there buddy alright so we've set up we've 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 going to put that in and so what will happen is yes, yes so it would 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 to have to do that 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 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 then 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 so 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 going to do we can actually do externally we don't have to log in to see what happens when you do log in 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 would do Lando composer install and if I ran that it would run the composer command inside my virtual environment so what I'm going 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 MPM or any of the other components installed in their machine it's all going to 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 going to 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 going to 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 login to 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 an s and do pwd so it tells me where I am I'm going to 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 and get up we have our dev container set up I'm actually going to switch out this one for a second and drop back into this one so what I'm going to 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 going to say installed vando and I'll commit that so add that 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 alright so now we can talk about WordPress boilerplate so boilerplate is a set of reusable code that we can use as a 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 great, thank you. Alright 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 setup time and effort it allows us to deliver higher consistency across our projects it helps us to reduce security risks 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 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 root that creates 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 sometimes 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 maintenance process there is a level of effort that we have to think about so it doesn't allow us to use the default plugin 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 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 going to go up to my instructions for this which are ok so I'm going to 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 root with Bedrock and so this command is going to effectively initialize the WordPress folder for us so composer create project root space 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 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 so now we 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 commited 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 let's see if we can do that we're going to try new things today so I should be able to do what do I call it? WCUS and that will be at .lendo.site and that's not running yet so let me just make sure I'll just check if that's running so I'm going to 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 CLI out of the gate and so I'm going to do setup URL is WCUS .lendo.site and I need to also I'm going to set the title so title equals I'll call that WordCamp US USA 2023 and then I'll set my admin username and my admin password so obviously for your own you would set your own account and password I'm just going to do the basic which we would not normally do but for the purposes of demonstration and so I should now be able to normally run that 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 and now I have database oh okay yep sorry I missed the key step 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 that file so if I'm in my file view that would help so I'm just going to 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 default 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 going to 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 off 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 so I'm going to save that file and then I should be able to now rerun my installation and oh I'm sorry I missed my email so send me an email and I'll just do my own email address 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 not picking up I think I know why I might have to just do a quick modification of my host file I think so 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 going to just run it manually here so wcs.low.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 no alright it's not the ideal I'm not sure why it's not picking up now if I don't I will move on to it thank you okay alright so so now we have our bare bones WordPress site so 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 alright 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 going to 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 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 I'm just going to set up a temporary account on a new I'm going to create a new hosting environment so I'm going to 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 going to do is create a new account I'm just going to use a post address so I'll do ws and I will just let me just use just make a new one and I'll save that for now okay so I'm just going to make a new account for the purposes of testing and I'm going to create and then check my email 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 deaf friendly 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 WPConfig it now happens in the application config .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 etc 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 wcrs 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 there now you're going to 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 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 by composites 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 one so we're going to do dbname equals and we'll just copy that so that will be my sqr database and then we've got host user and host and then we just need to set the wpn so this is a environment 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 let's make sure there's nothing else I'm missing out set URL and it looks 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 application 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 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 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 no no actually do you know how I've just done PB copy that would have been easier okay so let me just place that in real quick so add SSH key there goes it more okay it's done 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 a region and production my region is pointing to get our 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 to make sure okay and then we're going to try the same with 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 I hope it's had enough time can it read yeah I don't think it's connected yet 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 setup but now we're at the point where we can start talking about CICD 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 anytime in a reliable manner it ensures that every change we make to our code is can be doubly tested, can be integrated smoothly with any visiting code and then we can release it safely to our users improving the sustainability of our solutions and improving our team's agility so question was going to be is anyone already using CICD in their processes? if you're over here, okay there's a few around great, nice, alright so for this walkthrough while there are lots of different tools that are out there Jenkins, GitLab, etc 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 deploy 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 test and deployments pipelines directly within our code repositories so we can run, create and share reusable actions to perform almost any desired task in a completely customised 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 because 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 already integrated into that it has a real easy setup we just create a workflow file that will be showing in a moment it allows us to utilise shared actions that have been built by the community so there's a vast library of actions 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 the fact that some aspects or parts of that platform are closed-source and they may prefer to use a fully open-source solution okay, alright, so let's try and walk through this I'm going to try and see if I can push yet okay alright, so now it got picked up and so I'll just quickly show what's happened here so Forgrabbit has a deployment built-in by default, which is great and so what it means is that by simply pushing to the repository in the Forgrabbit environment it will actually trigger 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 Forgrabbit has it wired up already which is amazing so all we've done is just we've just pushed from our local repository to the repository in Forgrabbit 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 all in 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 of 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 so no question so and again we could go through the web in space 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 so we're going to get rid of that we don't need that anymore, I know we do Lando and then all we're going to do is we're going to first modify WPCLI config file so this is the file that defines how WPCLI operates and so what I'm going to do is actually add a couple of aliases so I'll do one for my development environment and for that it's going to be the same as the default so it'll be path and that's going to be web slash WP and then we're going to have one more for our production environment and for that we're going to set the SSH value and then we're going to grab that from here and I'm just going to 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 going to save that and so I'm going to use that alias so I'm going to say now I'm going to use command line in space to connect hopefully to our production instance and we're going to run the exact same set up 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'm going to connect let's try using here 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 so 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 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 I think I have to do it at the end minus I and then it's going to be 90 same see that works let's do and I haven't put up that one okay I'm going to 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 going to call that we're doing WCES and then we'll just add that all right so we'll click the password and we'll do the same and yeah we don't need such changes for now and then we'll do that so we'll just wait a bit 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 we have to do is to create our workflow file and so we're going to 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 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 on my side alright let me see if I can just do it grab it from my gist 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 the GitHub documentation they've got a lot of really comprehensive docs so we set the name for our workflow which is deploy we are going to 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 run but for this case we're just going to have this run when we trigger a push event from to our main branch and 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 going to have a single job called build and the job is defined it's going to be executed on a run 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 and then we 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 copy the private key one more time but I'll do that using 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 are secret values we're going to use the secrets here and I'm going to have to disconnect real quick so we just put it in and then I'll disconnect as short as possible secret sorry so I've created a secret in my repository called ssh secret key should be back 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 I can't really need both but I'll do both just in case okay so we 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 3.9 and that too doesn't need that's fine okay so we've got checkout, gitsync source, alright I think we have everything and so now let's just push these changes up so I'll 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 we know this right okay so we'll go to our actions and it is running and we'll see what happens yep it did break so I'm expecting input destination private key let me just check the repo for that action I've probably put in something wrong so it's expecting destination, SSH or 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 yep 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 sir you've been a prize alright appreciated that thanks bro let's try again SSH secret key oh lord yeah too much pressure any other takers black say now speak now alright so please lord can we just alright takers what are the odds we're going to get a green check this time let's see what happens alright failed failed what's happened did not read that's the way I've never seen this error before in my life what is this the hell oh my I honestly I have no idea what this is dubious ownership first of all I find that very personal oh yeah sure question tonight what yeah so it normally workspaces the default location that it will check out into so work the workspace I've just never seen this before let me just quickly check another project I know it's working sorry I need to find you know this had to happen live right that's a different task um okay this is weird I'm okay don't know if I'm going to 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 job action up to our kind of 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 going to 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 CICD 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, I hope you 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 your time I appreciate it time for a couple questions any questions for anyone right yeah it's one of those random ones right okay 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 any patterns that work for getting that into Git and sort of keeping those things in sync yeah definitely so we have a custom WPCLI 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 maybe you've got some data you need to update it I was talking more about the things you can set 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 you can also have them they can be a file or they can be in the database have you found a good way of we try and keep it to file-based just because it's easier to manage there's a tool called Dictator which is 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 a safe example when you're talking about the theme you could capture maybe like the widget configuration or the theme configuration and that goes into a file that you can then source control and then distribute okay thank you we have time for one more question can 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 DB Migrate Pro and whatever else we found that actually because we use WPCLIs 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 all 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 want to 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 want to 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 run one command you can integrate it into your workflow if you want we can do it manually if you need to as well release the code I will yeah if you grab my details and I'll see if I can actually put that in a so it's actually oddly enough I used that that was what I started with so that it's a 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 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 alright, okay thank you all so much, I appreciate that