 Hi, my name is Tim Nolte and you'll have to bear with me. This is my first time actually doing a talk in general. My wife gives me a hard time telling this gentleman, Tony, earlier that my wife gives me a hard time that whenever I get around people I love to talk. So I figure, well, I love to talk and if you catch me in the hallway or something I'll probably talk your ear off. So maybe that means I can speak, I don't know, we'll see. So a little bit about myself, I actually don't use WordPress in my day job. I actually work for Sprint. I'm a computer programmer for Sprint. But I've been involved with WordPress for about the last, well, what, 10 plus years. At least, yeah. I started using WordPress like in 2006, set up my first personal blog then. And yeah, but before that I actually got into web development in 1996. That was when I was in high school. And our school had internet and I got connected with a local company and I did their first website. It was all HTML. We didn't have things like CSS or JavaScript back then to work with. So things like image rollovers. I mean, I actually dabbled in a little bit of C code to do image maps and this is way technical geeky stuff and I was just trying to learn it and get things going at the time. But yeah, so with WordPress in 2006 I decided I'm going to do a blog. I wanted to have some place to start sharing my thoughts. And so I did that. I also did, 2006 was about the time when podcasting was really pretty popular. And I had gotten connected with some people on some things and wanted to share my thoughts for that. So I started a podcast and was doing that for a while. Throughout those years I was actually doing a lot of PHP and development for ministries and whatnot. I did a lot of different sites. When I moved here, actually I'm originally from Minnesota, when I moved here to Michigan about 11 years ago, oh yeah, actually so it would have been more than 10, but anyways, 11 years ago I got a job with a Sprint affiliate company and that's where I was doing PHP. Again, no WordPress, but that's where I got into the telecom industry, did some work in manufacturing with a lot of PHP. And anyways, that's kind of my background. Right now on my freelance site, I got a lot of stuff about WordPress. I like to do WordPress stuff on the side. I've done some subcontracting, I've done some side jobs for a new site. I just helped a friend stand up a new WooCommerce site. And I have a lot of plugins or at least two plugins that are in the works and I'm trying to get them done, but there's a lot of life happens and whatever. But on my personal site, I'll post about that stuff. My personal site is kind of like everything, my whole life. So you'll see probably every day, well not every day, many days, like four plus times a week, you'll see how post I run. I'm a runner. You maybe saw that when the speaker info came out and so I post that, but I like to post the whole gamut of things in my family. But in digitals.com, that's where you'll find most of the WordPress stuff and links to my GitHub and whatnot, which is there too. I've contributed to a lot of WordPress things, even some of the plugins you may have heard of like WordPress SEO, the host one, I've been contributing to that, seriously simple podcasting, I've contributed to that. Then I'm always looking for if I'm using a plugin, if there's some issue bug or feature, sometimes I'll just fork it and submit to it. While I've been doing a lot of that, the hot topic these days is the word DevOps. This talk is kind of about what is DevOps, what does it mean, and then how to start applying that. I'll kind of go through a little bit of some stuff that I've done over the years in that realm and then too with WordPress specifically. Really DevOps, it's a software engineering culture and practice that aims at unifying software development and software operations. It's the programmers and it's those that are doing servers and infrastructure and trying to get all that working together so that both sides can make the best use of their time. There's a site, an article called Revisiting What is DevOps by Mike Leucides. In there he says it's always easy to think of DevOps or any software industry paradigm in terms of the tools you use, in particular it's very easy to think of if you use Chef or Puppet for automation configuration, Jenkins for continuous integration, Cloud Providers that you're doing DevOps. Really DevOps is not about the tools, it's about the culture and the mindset and what you're trying to accomplish between both developers and those in the operations side. Really DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases and close alignment with business objectives. Really the point of implementing DevOps practice is about saving time, money, resources and being smart about that. What ends up happening is it becomes this intimate understanding between the development side of things and operation side of things. It's very easy for us as developers to get focused on the tools we're using and those things and sometimes get to have a disconnect between the business users, other teams that are supporting us. Even at Sprint, I'm a developer there and primarily we focus on just our code. We have servers that it runs on but we're not the administrators of our servers, we're not the administrators of our databases. We have to interact with them and even there we have challenges of there being this disconnect. If we're doing this thing, well, okay, well, we don't support that. Working together to have this cohesive environment where all the teams and pieces are working together. Time is valuable, so automate all the things. We hear a lot about automation with continuous integration and DevOps and that's the focus. If you've done it more than once, you need to figure out some way of automating it so that you don't have to manually do it ever again. We've got all kinds of solutions out there to do that sort of thing. However, time is valuable, so really the important thing is to automate the right things. I love XKCD talks about, okay, here's the theory, okay, I've got some work to do and I need to write this bunch of codes, so I'm going to do some automation to make things, give me more free time, right? But the reality of it is we start working on code and you want to do this automation, well then the automation takes over and then the real thing that really gets done. There's sometimes a disconnect between what we need to do for what tools we use. What's the hot new tool? What time are you going to invest in learning that tool before you start actually reaping the benefits of that and doing automation and everything that's involved with that? So what does DevOps have to offer the WordPress world? Again we're talking about increased productivity, increased quality, reduced time to delivery of releases. When I talk about releases, this is like if you're a business and you're actually selling plug-ins, selling themes or even if you're just doing stuff on WordPress.org or even just for clients. If you're doing custom plug-in or theme development for clients, how do you get things fixed? How do you get things deployed in a timely manner with quality? In terms of increased productivity, we're talking about developers, designers, testers, who can work on solving new problems and not repeating the work needed to solve previous problems. So we don't want to keep solving the same problem over and over again. So once we've figured it out, how do we keep moving forward? And some of those things that we have to deal with are environment setups. And I love these types of things like, okay, sometimes I know even my experience at Sprint is you've got these very complex environments and nobody knows how the whole thing works together. And that's where DevOps can come in and start bridging that gap between what the different groups are doing. Everybody can start having an understanding of what the big picture looks like. With repetitive tasks, like we were saying before, we want to try to automate everything. We don't want to have to repeat ourselves and do the same work if we can find other ways to do things. Earlier on, the guys talking about the local dev and setting up those things to quickly spin up new containers for local environments, those are things that are going to help move things along, keep things going faster. And of course, what's the definition of insanely repetition, repetition, repetition? So the next piece too is the business workflows. And again, that whole overall, what's the big picture and how does all the pieces fit into what the business needs? I mean, when I talk what the business needs, I mean, this is even if you're an independent and you're just doing something with WordPress.org, well what are the things, you know, as you're releasing plugins or releasing themes, what are all the pieces that you're doing to make that happen? Because some of that too, you've got support. You've got not just the development, but then you've got support after the fact or if somebody finds an issue, are you going to be open to collaborating? Are you going to document how people can contribute? So all those things are workflows and processes. This is kind of how are we, from a developer standpoint, how are we branching and whatever, again, it's workflows and processes. So the other thing too is increased quality. And a team can rely on testable, reproducible, quantitative results that give a clear picture of the current state of the product. And that can be accomplished through unit tests and standards and business requirements. And with unit tests, it's like requiring code that is tested that fulfills the requirements. With your standards, can code automatically be checked against well-defined business industry standards? Like one thing I do with a lot of the plugin development that I'm working on is I started automating and building in the WordPress coding standards, right? So it's like I have a plugin I'm working on, I want to submit it to WordPress.org. It's like I want to make sure my code right out of the gate as I'm developing it is following the WordPress coding standards so that when it comes time to submit, it's not going to get rejected because well, you're doing all this whatever over here. And one thing too, right now, there's kind of the shift with object-oriented PHP versus kind of the old procedural, classic WordPress development. And some of the WordPress coding standards are still kind of in that procedural world. And so if you try to do things where more object-oriented, some of those things might fail the WordPress coding standards. So it's nice to have those automated testing and evaluation to check those standards. And then business requirements by having tests and the standards. And you can have those actually built into your automation to produce reports that show, hey, this plugin, it's actually fulfilling all these requirements. So this theme does these things. So with reduced time to delivery and releases, when standards and best practices are followed, there are less mistakes and less changes required to prepare for release. You've got automated tests. You've got an environment set up where you can have user testing on demand. With the plethora of options like Docker containers and now there's a lot of stuff going on with just a whole gamut of solutions for spinning up things to test small pieces, you can do that all on demand. There's a lot of services, Travis CI and some of those are ones I'll kind of mention later too, but those have the ability to just kick those off on demand by any user and then you can test and evaluate that. Which in the end, because you have those things in place, you can have more releases, right? So you're not stuck with, okay, I've got to go through, because it takes so long to come out with a fix for my plug-in or theme or push something to a client's site, we're gonna do it once a month. Nope, you can have things in place to basically identify it, fix it within a day, boom, you can push out a release. I look at some of the changes, and Google got a lot of flack about this. Initially what was when they started going to their build numbers, they weren't like version 3.0, 3.1.1, they started going to, it's like basically every time, I mean, constantly coming out with updates. And it's like now we're up to like, I don't know, version 69. It's like historically that's unheard of to have a version number of your software at version 69, right? It's always, well no, you got these major milestones. So your first release in the first phase is always one and then later down the road it's version two. Really, all those version numbers and that way of thinking, it's kind of an older way of doing things that doesn't really matter when it comes to getting those things released and having a lot more releases. So, where do you begin, right? So when you're talking about DevOps and WordPress and all this stuff, how do you get started? I mean, the first thing is that it's important to take small steps, right? The world of automated testing, getting teams working together, it's all gonna be, it's a culture change, it's a way to think differently. And the other thing too is there's a lot of examples out there and guidance on how to make that stuff happen. But you need to start small and find out what's gonna make the most impact initially. And here's some resources, both Carl Alexander and Tom McFarlane. I follow those guys a ton. They got great resources just all around. I mean, Tom McFarlane and Carl, they both have a lot of information. If you want to get your WordPress development moved to more object oriented. But then again, just with automation and testing and standards, they're kind of on that leading edge. And so I love to follow those guys. Things like just, okay, how do I manage Git with WordPress? Unfortunately, WordPress.org is still using SVN. So if you wanna publish a plugin or a theme, it's gotta ultimately hit SVN. I'm waiting for the day where it can all just be Git. But again, whether it's Git, SVN, or you're using Mercurial, or CVS, or whatever, it doesn't really matter. At the end of the day, you gotta use what's best for your organization, for your productivity, and then figure out how to make those leaves. I mean, ultimately, you gotta get it committed to SVN to get it in WordPress.org. And there's ways to do that. I mean, a lot of people, I mean, you'll see most companies that are doing newer plug-in, theme development, a lot of them are on GitHub. It's a very common place where they're using Git. And it's like, well, but if they need to get something to WordPress.org, they gotta make that transition to SVN. And so there's tools, there's scripts to do some of that stuff. So what you need to start off with is you need to identify your pain points, right? So you need to clearly identify those things which will reap you the most benefit based on the time you will spend. What are you repeating? What is taking you the most time? What's requiring the most support? And those are the things you need to ask yourself and identify from a high level to start determining, okay, what am I gonna start doing in this DevOps world? Where am I gonna start making changes? Where am I gonna start getting the conversation going to start making strides to a better holistic environment? Again, next KCD, spending the right time on the right things. This is a very interesting picture on how much time you can actually spend on something to automate it based on how many times you're doing it and basically there's a cutoff point. It's like, if you're spending X amount of time and you're only saving a minute, you can't spend more time to save that minute because overall, if it's not being done that many times, in the end you lose the value of it. So again, making sure that you can evaluate, okay, how long is it gonna take us to use this new tool? Because it's supposed to save us time. If it's gonna take you more time to learn that tool, to apply that tool, then you're gonna reap back, it's return on investment, that whole thing with business, then you got to value, okay, maybe there's an alternative tool. Maybe the way we're doing things is what's best for us now. But then other things like culture and the conversation and getting teams together, some of that is even more valuable than the tools. I mean, it's for sure more valuable than the tools because you're getting people to have those conversations to communicate and get on the same page. And then you can start having the next level of conversation and what tools to use, because you're all on the same page. So the other thing, and I kind of mentioned this already, is there's so much, I mean, in the day and age of the internet, there's pretty much not anything out there that's available to us. And so I appreciated when Michelle was talking in her last, in her talk about this battle between what do you use and what are you gonna write my own stuff because it's always better. When you're getting started in this area of automation, go find what other people are doing and using, and that's where I started. Even using things like Travis CI, I noticed, hey, this plugin, they're using Travis CI. So what are they using? Okay, I can see they're using Gulp or they're using Composer, NPM, whatever along with their plugin development flow. And so I slowly, it's like, okay, yeah, I see that time savings. I was able to add that to my workflow, my process for development and it didn't take me much time. And again, I'm evaluating, okay, if it's gonna take me two weeks to get going on this to make it work to give me some benefit, then maybe I'll hold off on that. But if it's a matter of just one command, I'm already using Composer, right? So if it's another Composer requirement, boom, I add it and now all of a sudden I can start using it. Case in point, I just added PHP MD, which is the mess detector for code evaluation. So I just added that to my Composer, it's there. Next step for me is I'm gonna actually have that fail or pass on my tests. So there's a lot of free and paid services for your source control, for continuous integration, reporting. There's a lot of plugins, so I'll also give you an example. There's a plugin that does some direct GitHub integration. Automation scripts, there's like some shell scripts or different things that can be used to automate those pieces. So, example time, and we'll see how this goes. So there's a couple, there's a plugin, like I mentioned. And there's also a theme that I used to maintain that I also did some of this with, and I will bring that up here. Let me know if this font is too small. Is that pretty small? How's that? So actually, I'm just gonna go. All right, so one of the things, well, let me just take a step back here from the Travis. So you can see, this is a plugin that I'm working on right now. And I'm using Composer. I'm using NPM. I've got files, configuration files for unit testing. PHPCS is the code sniffer which implements my WordPress coding standards. And then I've got, in my Travis CI configuration, I've got it running those things. And one of the nice things about Travis, well, not just Travis CI, but Travis CI as an example is I can set up in there to actually run and test my plugin for one thing, I can specify the different branches I want tested. So right now I've got this 1.0 dev branch, which is where I'm doing most of my work. And I can have it build that automatically for me. But then I can have it test WordPress version, which PHP version, and multi-site. So me, this is my plugin, nobody else has to deal with it. And I'm like, I'm going to go through and I want to test it all and make sure I can evaluate and say, hey, this is what it's going to work with. And I'll know, and even my unit test, that's part of it. Interesting thing of it is that with Composer, I decided to add the PHP MES detector, like I mentioned. And the current version of the MES detector that I'm running actually requires PHP 7. So of course, the act of running that failed all of my pre-PHP 7 builds, and I saw that right away, cuz I had this set up. I added it to Composer, updated my Git repository. My tests automatically ran all of a sudden I get a slack and I get an email saying, all your build failed. I'm like, what did I do? I didn't even change any code yet, because I added that in. That's one of those things where, okay, is it important that the build gets failed because of a particular development dependency? Yes or no? And that's where you can go and you can set up in your Travis CI what actually runs when. And so you can have specific builds that say, okay, I'm going to test this WordPress version and this PHP version. But I'm not going to do the MES detector tests. You can see here, here's where it's running my PHP unit tests. Here's where it's running my code sniffer for my WordPress coding standards. And it's got a check in there. So this is a script that Travis CI runs and it's detecting, okay, here's the version, pass that through. Here, okay, is my CSI build saying use the coding standards. There's one job that does the coding standards, the other ones don't. So it's all configurable. And then you can see I've got after success that I'm actually running, there's a service called CodeCode that does reporting on the results of all your tests and so you can get reports on that. And that's that whole business workflow, right? Like being able to at the end of the day look at everything that you've created and have somebody that's not the developer, not the technical person, say have something to look at and say, okay, well, I can see that the quality of the code's going down, what's going on? And you can start having the conversation, well, the timeline, we just had to get it in to get it shipped. Okay, well, what was the hindrance? You can start having those kind of conversations. The other piece that I wanted to show is, so there's a gamut of services that I've used, like I said, Travis. Another one that I've used is a code ship. And it's very much like Travis CI or Deploy HQ. And in this scenario here, this actually was a theme that I built for, I was managing my church's website, and it was a custom theme I did. And like originally, I actually had this when the build would pass and be complete, I actually did use R-Sync to upload it to the website. But then we actually switched hosting from a VPS hosting to pressable, managed WordPress, and of course, they didn't support R-Sync. So I was like, okay, now what am I going to use? So then that's where I switched that to basically FTPing. And that's where it's like, okay, being able to figure out, okay, where do I need to go with it and how do I get there? And so again, it was like, I'd been doing a lot of stuff with R-Sync before with Jenkins and CI, and so it was available, so that's what I used to use. Then later on, it was, nope, can't do that. We switched hosts, now what I do? Well, okay, what's the thing next, the best thing to get it done to keep my automation in place so I can quickly deploy. Another thing too is in the Git repo, there was an integration branch which I had set up specifically to go to a test dev site. So that way, commit code changes and would automatically push to a live environment. And things like Travis CI, when it runs all those tests, it actually runs those in small containers with the PHP version you want. And this is more for, okay, I'm pushing it out there for like user testing or I want to see, interact with it and whatnot. And especially for your production builds, and this would be like for a client or for your own internal purposes. Now the other thing you can do too is with this sort of setup, you can use a script to automate pushing your builds to things like WordPress.org. When you want to do a plugin or a theme release. So back to the configuration that I'm using. PHP code sniffer for WordPress coding standards, PHP unit for unit testing. I've actually got some gulp tasks on using gulp to check and build the internet internationalization for the plugin. And then even, it's kind of handy that there's a little gulp task that does WordPress read me to mark down. So basically my WordPress read me file is the same read me that shows up in GitHub. So GitHub is all marked down. But there's the WordPress plugin and theme read me. It's got a form of mark down, but they're different. So this lets you basically maintain one file and automatically generate the other one. So in practice, with having your automation set up, the unit testing, and what I'm able to do, when I showed you the console I'm using, I'm able to run all kinds of that stuff locally. I can run the code sniffer, I can run PHP unit, I can run all that locally before I ever even commit. Then when I commit, then the test automation comes into play. I mean, my local environment is, I think it's PHP 7.2 with Nginx, right? Well, if I need to test under other conditions, yeah, I could try and have all those setups installed on my local machine. Or I can just push it out there and specify what I want. And it'll test all in all those different environments. And that's the one thing too, like when you're talking about plugin development, theme development that's going to be used by the masses. It's important to be able to test, how does that thing going to work, depending on which PHP version, which WordPress version. Are they running under Apache or Nginx, all those different environments. And when you've got automation and services like Travis CI, I'm using Travis CI or a code ship because I don't want to have a whole server that I've configured with Jenkins. And I've done that before too. Again, some of it's all stepping stones. So if you're already using Jenkins in your organization, use what Jenkins has. And you can use a lot of the same scripts with Jenkins. But then that's the thing is you can automate those tests against your final release if it passes, you just let it automatically deploy. You can, but you don't have to. That's the nice thing too, is making sure that you're doing what you're comfortable with and what the business needs are, what the organization's needs are. So, and yeah, with deployments, and that's what I was showing you a little bit. So you've got basically publishing directly to the servers. So that was like the R sank and the FTP deploying Plugin TeamUp via a plugin. So there's a plugin I started using, well, I've got it in the resources. But there's a plugin that's a GitHub plugin. And you can install it in your WordPress install. And you can directly install plugins or themes from GitHub. And it manages that and looks at, and you can switch branches. You can update the plugin directly from GitHub onto your site. And that's one way, like right now, I got a client site that, the WooCommerce site, I think I was talking about earlier. I actually installed that plugin on their site because a free WordPress plugin that we were using, I actually made code changes too. And it's a .org plugin, but I submitted a pull request. And I'm waiting for those code changes to actually be accepted by that free plugin. But I needed those features in the client site. And so I'm gonna support them. So I'm pointing that plugin to GitHub, to my GitHub version. And that's what's driving it. Once it gets submitted, then I can just have it install from the WordPress.org repository. So that's another way of being able to deploy your plugins and themes. And then the other thing too is deploying your plugin and theme updates to WordPress.org. And again, that's all pretty much done through SVN. So once you've gone through, I'm not gonna go through the process of how you get submitted to the WordPress.org repository. They've got documentation out there for that. But once you actually get your plugin or theme accepted, then regular updates are all gonna come through SVN. And there's a lot of good resources out there. If you, on my slide deck here, I've got them all listed out. You can get them online too for the services, plugins. There's scripts that will automatically deploy and take your git however you want that. If you want specific tags that used or specific branches, you can configure it to do that. And then it'll automatically commit it to SVN for your rollout. So with that, that kind of concludes my talking. I wanted to make sure I left some time for Q&A and I wasn't sure how long this was gonna take me to talk anyways, so. Any questions? Yeah? Have you ever heard of GitLab? GitLab? Yes, yes, I did just see even some recent articles about that as well. I haven't used GitLab, but yeah, it sounds like a pretty nice setup. Well, and actually what I saw recently too was they are now supporting total local installs of GitLab. So you don't have to, there's a lot of, me being a developer at Sprint, there's been for many years a lot of concern about information outside the company. Surprisingly enough, we're actually moving to Office 365. Which I was like, really Sprint Office 365? But yep, we're moving there. And so, yeah, GitLab, for any companies that have concerns about all my code is out in the cloud, you can have that all local. I mean, that's things like using Jenkins local. You can set up your own local Git central repositories. I mean, that's nice about Git too in general is it's decentralized version control versus SVN, I tell you. I don't know how many times I've had felt the pains of SVN at work when I use Git at home. It's like, my coworkers give me a hard time because I always talk about Git. It's like, hey, you should try it sometime, it's way better. But again, it's way better to me. Like for me, it's way better. I appreciate it a lot more, but yeah, any other questions? Yeah? How often does your company know that, I guess, they do know you? Sprint, you mean? Yeah. Well, I mean, I don't do anything in, I don't do any side work in the telecom area. And yeah, I don't, I mean, I think they're probably pretty indifferent. What I do on my own time, I don't know if they necessarily care. I mean, Sprint's a pretty big company, but yeah. I mean, I, yeah, I don't hide the fact with my team when I talk about stuff and yeah, it's Sprint's very interesting place to work. We have a lot of contractors and offshore and so yeah, but yeah, that's the thing too. Like, I mean, in my day job, I'm using Java.net C sharp. I'm not using any PHP. I'm not using WordPress. And so it's very, very easy for me to keep those things, those worlds kind of separate. You know, I do sometimes like my, what I do off hours as a developer, I try to bring and continue to move the Sprint team along and get, hey, there's these other ways of doing things that we might consider. But it's a bigger corporate environment. We have company standards that we have to abide by. So it's not always easy to do that. Yeah. Did I see the other day that Microsoft was buying GitHub? Yes, that is true. I saw it and I initially I'm like, but I think I'm encouraged by the fact, you know, seeing what Microsoft has done with .NET Core and moving a lot of things to open source, I feel like this move is falling in line with that. And so it scares me less than if it was, I mean, the only thing that I'm slightly concerned about is, you know, they've got their whole team foundation services, which I've used with Visual Studio stuff for work, actually my last job, but so I am slightly concerned like, okay, now they have like, to me, two competing products. And that's always the question. Like, I mean, I know a lot of people have moved away from MySQL to MariaDB because MySQL is owned by Oracle. I mean, Oracle bought Sun. That was the big thing, right? Like what's going to happen to MySQL? Like the whole internet like open source community uses MySQL. Well, then of course the MySQL developers came back and they reforked it and now we have MariaDB. And so like, now a lot, I mean, Google moved to MariaDB, you know, so I'm using MariaDB. I mean, I just moved in that direction too. So yeah, I mean, time will tell with the weight that Microsoft has, the funds, the resources, I mean, even the entire like Azure, you know, platform. I'm hopeful that this is all going to be a positive thing. I mean, even Visual Studio Code, right? I mean, that's a free tool. I mean, that surprised me like when that came out and that supports, it has, you know, support for GitHub and things. And so yeah, we'll see. I have a hard time believing that Microsoft making those kind of choices and that it's going to be some means to all of a sudden suck it all back in and it's all going to be proprietary and expensive again. Yeah. So, but yeah, like is GitHub at risk or is GitHub going to go away? I, yeah. Well, I mean, GitHub has paid. You know, they already have, it's, yeah, yeah, but what's going to happen to the free side, right? I mean, I've seen that before with other services. It's like they've changed and now the free, like, interesting Evernote, for instance. Like when they started changing what you got with Evernote and like, oh, if you wanted to have it on multiple devices, like my wife and I used Evernote on our phones and on our computer. And we've had the same account and it's synced across all the moon. They changed like, oh, well, I don't have a better solution for how we store stuff in Evernote. And so I guess we'll pay for a year. And of course now I'm stuck in, I've been paying because I forget to cancel and haven't fully moved on to other things or pulled my content out. And so yeah, so Microsoft, if they decide to change GitHub, we might find a lot of us caught in that too, where it's like, well, I got my stuff there and I don't know where else to move it. I mean, the nice thing about it is Git, right? So it's, technically it's decentralized. It just, that happens to be a one other location of the repository. So it could, I mean, there's a lot of, you know, the DevOps infrastructure, how things are tied together, connected to it, but there's other solutions out there. Like, I mean, Bitbucket exists. They've got Git, Assembla. They've got both Subversion and Git. I mean, actually I was going to mention with Assembla because they have Subversion, what I'm planning on doing is setting up some of my workflow. I've actually already created a repository for one of my plugins, an SVN repository that's gonna mirror what WordPress.org is. So I can test out my WordPress.org SVN submission process with Git. I can do that with Assembla. It's all mine. And then when I'm ready to actually submit to .org, I can submit it and I know, hey, this is all gonna work and I can continue to move forward. So, yeah. So there's a lot of other options out there, both paid and free. And I mean, that's one thing about Bitbucket that's a little, like I use both Bitbucket and GitHub. And one of the differences between the two is, GitHub, it's free for public repositories paid for private. Whereas Bitbucket, it's actually the opposite to a degree. I mean, actually they give you private ones for free. And so I use Bitbucket for like my actual, my local WordPress development environment is all in a repository using Composer that builds it all out. I actually have it in a private Bitbucket repository just because I've got stuff that's kind of like my own there. And I'm not necessarily ready to, it's using the WordPress skeleton build out. So, yeah. Sorry. I mentioned earlier I like to talk. And I also like to segue. You'll find out too. Any other questions? Yeah. Oh, yeah. Yeah, I've got that here. That's the one. WordPress, WordPress, GitHub plugin updater. It's out on GitHub. Yeah. It's pretty slick. It can do both public and private repos. You can give it a private repo key token so that it can access your private repos, whether they're your personal or like if you have a corporate GitHub repository. That's one thing too I've done is like my freelance in-digitals. I have an in-digitals company kind of repository that that's where all of like, that's going to be like the main release of the plugins. Then I've forked that to my own GitHub and that's where I'm doing my development work. Just like, I'm only one guy but I still like to operate in terms of like a team because in my day job I'm working as a team plus I want to have that environment set up. I want to accept if other people want to work and submit to my plugins. Like I appreciate that with the plugins or themes that I've contributed to, I can fork theirs and make changes, submit a pull request. I just love that open source kind of community. Any other questions? Yeah. Like for front end type stuff, for themes you're talking or what do you mean? So for plugin development, I mean I do use the WPCLI to basically scaffold out a plugin but I've been with the plugins that I'm working on right now. I'm kind of going more of the object oriented approach. So I move things to a source folder. I'm actually using Composer to build out my loading for my classes. So I am using that and that's the thing too is I use Composer for dependencies. I'm using it for unit testing stuff right now but my WordPress development environment actually uses Composer. There's the WP packages repository which basically all plugins and themes that are in the .org repository are available through Composer. So I actually use that. But that's the thing too. I have another plugin where I've got a particular PHP package and so I've got that in Composer as a requirement so it pulls that in. I'm not sure if that's exactly where you're going but yeah. Other than the scaffolding and kind of using that kind of more object... Like Tom McFarland, some of his plugins and Carl, how they've got them structured and doing things for a more object-oriented way. That's kind of where I'm following. Any other questions? Yeah. You're controlling the source control. You're controlling the plugins, right? Yes. Yeah. I don't source control an entire WordPress site. I know there are agencies where it's like okay we've got the entire client site is in a repository. To me, managing the source for the core WordPress core stuff is just... It's a waste of space. That's where my WordPress development environment... I'm actually using... There's a Composer package that actually installs WordPress core so my dev setup with Composer doesn't actually have WordPress core in it but as part of the checking it out and then running... I check out my repository then I run Composer update. It actually downloads core and installs core and sets all that up. Even if it was like a client site and I wanted to do something like that where I kind of have the client site with what plugins... I would probably use Composer if I were going to do that but yeah, for plugins... It's just the plugin is in GitHub. Yeah. Yeah, that's very different. Yeah, backups. Make sure you backup. Actually, even your dev environments... I ran into... I actually use... It probably sounds crazy. I use a Chromebook and it supports Android apps so I actually use Turmux which is basically a Linux container and I have MariaDB and Nginx and PHP the whole works plus I use Neo Vim as my IDE. Well, I had Google pushed out some changes. I use their G Suite, the free legacy version and my whole Turmux environment was blown away so I lost my whole dev environment and I hadn't done some Git commits or Git pushes and so I lost everything and so I need to have a backup for that. So, yeah. Yeah. Yes, yes it does. I'm pretty sure it does. Yeah. Right, right. Yeah, I would say the one for me would be more recently, it's the scripts that I wrote to actually set up my dev environment but from a deployment standpoint, I would say using code ship and having that actually pushing theme and plugin updates that I was using before, like that was always a huge time saver. I were out of time I will be at the happiness bar kind of at the end of the day. I'll be hanging around. I'll have my lunch here. I brought mine in so if you want to talk, I have more questions. I'd be happy to answer. Thanks.