 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. You 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 I mean, 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 with 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, 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. 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 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, 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. And digitals.com, that's where you'll find most WordPress stuff and links to my GitHub and what not, which is there too. I've contributed to a lot of WordPress things. Even some of the plugins you may have heard of WordPress SEO, the host one, I've been contributing to that. Seriously, simple podcasting, I've contributed to that. And 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. But, and while I've been doing a lot of that, and the hot topic these days is the word DevOps, right? And so really, this talk is kind of about what is DevOps? What does it mean? And then how to start applying that. And I'll kind of go through a little bit of some stuff that I've done over the years in that realm and then two with WordPress specifically. But really DevOps, it's a software engineering culture and practice that aims at unifying software development and software operations. So 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. And there's a site, an article called revisiting what is DevOps by Mike Lucides. And in there he says, it's always easy to think of DevOps or any form, 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. But really DevOps, it's 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 operation side. So really DevOps, it aims at shorter development cycles, increased deployment frequency, more dependable releases, and close alignment with business objectives. I mean, really the point of implementing DevOps practice is about saving time, money, resources, and being smart about that. And 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. And we have servers that it runs on, but we're not the administrators of our servers, we're not the administrators of our databases. So we have to interact with them. And even there, we have challenges of there being this disconnect of, well, we're doing this thing, well, okay, well, we don't support that. And so working together to have this kind of cohesive environment where all the teams and pieces are working together. So time is valuable, so automate all the things. So we hear a lot about automation with continuous integration and DevOps. And that's the focus. And 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. And so 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 gonna do some automation to make things, give me more free time, right? But the reality of it is we start working on code and just you want to do this automation, well, then the automation takes over and then the real thing that really gets done. So sometimes there's a disconnect between what we need to do for what tools we use. I mean, even ramping up in like, okay, what's the hot new tool? Well, what time are you gonna 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. And when I talk about releases, I mean, this is like, if you're a business and you're actually selling plugins, selling themes, or even if you're just doing stuff on WordPress.org, or even just for clients, if you're doing custom plugin or theme development for clients, how do you get things fixed? How do you get things deployed in timely manner with quality? So in terms of an increased productivity, we're talking about developers, designers, testers, 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, okay, sometimes I don't, 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, oops, sorry. Bridging that gap between, go back, thank you. Between what the different groups are doing. And so 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 gonna 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 just 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, 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, there's you 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 gonna be open to collaborating? Are you gonna document how people can contribute? So all those things are workflows and processes. And 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 we can, 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, it's like 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 wanna submit it to WordPress.org. It's like I wanna 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 gonna 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 site. We're gonna do it once a month, you can have things in place to basically identify it, fix it, and 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, 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 in 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, like 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, that's 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. 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 appreciate it 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. I mean, that's where I started, even using things like Travis CI. I noticed, hey, this plug-in, 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 plug-in 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 plug-ins. So I'll also give you an example. There's a plug-in 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 plug-in, 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 plug-in 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 plug-in 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 plug-in, nobody else has to deal with it. And I'm like, I'm gonna go through and I wanna test it all and make sure I can evaluate and say, hey, this is what it's gonna 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 mess detector like I mentioned. And the current version of the mess detector that I'm running actually requires PHP 7. So, of course, the act of running that failed all of my pre-PHP7 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. And 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 gonna test this WordPress version and this PHP version. But I'm not gonna do the mess 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. Okay, is my CSI build saying use the coding standards. There's like one job that does the coding standards, the other ones don't. So it's like, it's all configurable. And then you can see, I've got After Success that I'm actually running, there's a service called Code Cove 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, have something they can 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, oh, 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, sorry. 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 originally, I actually had this when the build would pass and be complete. I actually used 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, OK, 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, OK, being able to figure out, OK, 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 do I do? Well, OK, what's 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 what I'm going to 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 pushing it out there for user testing or I want to see interact with it and whatnot. And especially for your production builds, and this would be 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 I'm 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 like 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, 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, and I can run all that locally before I ever even commit. Then when I commit, then the test automation comes into play. 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 in all those different environments. That's the one thing too, 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 things like 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, 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. 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 plug-in theme update via a plug-in. So there's a plug-in I started using, I've got it in the resources, but there's a plug-in that's a GitHub plug-in, and you can install it in your WordPress install, and you can directly install plug-ins or themes from GitHub, and it manages that, and looks at it, and you can switch branches, you can update the plug-in directly from GitHub onto your site, and that's one way, like right now, I've got a client site that, the WooCommerce site I think I was talking about earlier, I actually installed that plug-in on their site because a free WordPress plug-in that we were using, I actually made code changes too, and it it's a .org plug-in, but I submitted a pull request, and I'm waiting for those code changes to actually be accepted by that free plug-in, but I needed those features in the client site, and so I'm going to support them, so I'm pointing that plug-in to GitHub, to my GitHub version, and that's what's driving it, once it gets submitted then I can just have it, you know, install from the WordPress .org repository. That's another way of being able to deploy your plug-ins and themes, and the other thing too is deploying, you know, your plug-in theme updates to WordPress.org, and you know, again that's all pretty much done through SVN, so once you've gone through, I'm not going to 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 plug-in or theme accepted, then regular updates are all going to come through SVN, and there's a lot of good resources out there. On my slide deck here, I've got them all listed out, you can get them online too, for the services, plug-ins, there's scripts that will automatically, you know, deploy and take your Git however you want that, you know, want specific tags that used, or specific branches, you can configure it to do that, and then it will 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 I was going to talk anyway, so any questions? Yeah. Have you ever heard of a get lab? Get lab? Yes, yes. Yeah, I did just see even some recent articles about that as well, I haven't used get lab, but yeah, it sounds like a pretty, pretty nice setup. Well, and actually what I saw recently too was they are now supporting total local installs of get lab, so you don't have to, you know, 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, get lab, you know, 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 get central repositories. I mean, that's nice about get to in general is it's decentralized version control versus SVN, you know, I tell you, I don't know how many times I've had felt the pains of SVN at work when I use get at home. It's like, I always, my co-workers give me a hard time because like, oh, you always talk about get. It's like, hey, you should try some time. It's way better. But again, it's way better to me. Like for me, it's way better. I appreciate a lot more. But yeah. Any other questions? Yeah. How does your company know that you 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 know. 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 in offshore. And so, yeah. But yeah, that's thanks to 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 say, 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. 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 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 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, has, you know, support for GitHub and things. And so, yeah, we'll see. I don't, 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? Is GitHub going to go away? I, yeah, well, I mean, GitHub has paid. You know, they already have, it's, 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 we synced across all of them when they changed, like, oh, well, I don't have a better solution for how we store stuff than 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 want else to move it. I mean, the nice thing about it is Git, right? So it's technically, it's decentralized. It's just, that happens to be a one other location of the repository. So it could complete, 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 going to 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 going to work and I can move on 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 the 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 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 and 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 and 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 team plus I want to have that environment set up so like 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 you know I can fork theirs and you know make changes submit a pull request and I just love that open source kind of community so any other questions? Yeah, like for front end type stuff for like sit for themes themes you're talking or what do you mean? So for plugin development I mean I do use the WPCI 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 you know I move I move things to a source folder I'm using I'm actually using Composer to build out my loading for my classes so I am using that and that's the thing too I use Composer for like dependencies I'm using it for like unit testing stuff right now but my WordPress development environment actually uses Composer there's the WPCI could just deposit which basically all like plugins and themes that are in the dot org repository are available through Composer so I actually use that but that's the thing too like 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 that's exactly where you're going but yeah I don't 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 so and their questions yeah yes yeah I don't I don't source control like an entire WordPress site I know like I know there are you know agencies were like okay we've got the entire client site is in a repository to me managing the source for like the dot the core WordPress core stuff is just it's waste of space that's where like my my WordPress development environment I've actually using Composer there's a Composer package that actually installs WordPress core so I don't my my dev setup with Composer doesn't actually have WordPress core in it but as part of the you know checking it out and then running I check out my repository then I run Composer update it actually downloads core installs core and sets all that up so like 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 to do that but yeah for plugins yeah I'm just it's just the plug-in is in in GitHub so the entire way so it's more like backing up yeah yeah I mean yeah that's very different yeah backups make sure you back up actually even your dev environments I ran into I actually use a probably sounds crazy I use a Chromebook and it supports Android apps so I actually use Turmux which is a 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 a 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 get commits or get pushes and so I lost everything and so like I need to have a backup for that so yeah yeah um yes yes it does I'm pretty sure it does yeah right right yeah I would say the the the one for me would be these more recently it's the scripts that I wrote to actually set up my dev environment but for from a deployment standpoint it was I would say like using code ship and having that actually pushing theme and plug-in updates that I was using before like that was always a huge time saver so I were out of time I will be at the happiness bar kind of 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