 Hello, can anybody hear me? Yeah, is it fine? So, hi, I'm going to talk today about WordPress, WordPress deployment. I'm going to introduce myself first, then I would like ask you some things, a question about the deployment. And I'm going to talk a little bit about the goals of continuous integrity and continuous delivery of the process. Obviously the benefits and the requirements for using the DKD deployment package, and a short demo of how everything is working. I'm Iwairo, originally from Sofia. I live in Frankfurt in Germany. Currently I'm a technical team lead, so yeah, I'm standing here, my project manager, and I'm consulting her for my manager how we can build better sites, how we can achieve a good technical structure, and how we can accomplish all the projects in a good way. Most of the time I'm doing type three. I started working with WordPress in 2014. Apart from that, I love working with Zula. It's a search engine, and obviously DKDploy. 2016 I founded the company's business unit for WordPress. So now we are working also with WordPress and with the WordPress site. This was a quite hard step because we are type three agency, and I don't know, there's two words, and type three guys that don't like so much WordPress, but I love both of the systems, and I think WordPress is really great, and I would like to use it more. So I'm working at the DKD's Internet Service in Frankfurt. We're about 60 people in two offices from 15 nations over there. We love pizza. We have, first day we run pizza by ourselves, and we have our pizza oven. It's, I don't know, it's a cold or hot stone, specialized oven, which heats up to 350 degrees, something like this, a really special thing. Apart from that, obviously we are doing a lot of things, or a lot of technology, and after I saw this, or basically, a couple of years ago, six years ago, we started thinking, we're working with so much technology, so every technology has its own workflow, the upgrade process is there, different in every technology, and also obviously the deployment process is different for every technology, so we thought we would like to automate everything. So, automating means I don't want to do it by hand. So, I want to just run a command and do something. So I'm going to talk today about how we automate the deployment process, the NKD. But first of all, I would like to ask you, how do you deploy your code? How do you transfer a package, or let's say just one line of code from server A to server B, or from your local SCM one, your Git repository to the server? Maybe you can just raise your hands if somebody's using a deployment with that asset to be, so I mean really by hand. Anybody? Perfect. Git and SSH, or maybe with Capstan? Cool. What need, or, are the waters deployment tools? Okay. Do we have custom deployment tools? This is my favorite one of you. It's just working, I mean, yeah. Because the idea of building a website or product is, I'm a developer, I would like just to quote, and I don't want to care how can I transfer the code from A to B. Who of you is working with CICD process currently? I mean the continuous delivery process. So, I'll do quite a few benefits about this one. Continuous delivery. Benefits, high quality, high code quality, because everything is automated, I mean because we can really do automated tests. We can test our code for things that we don't think about. We have less errors by deployment times. If there are conflicts or something breaks, we get immediate identification of what is going on. And yeah, let's say we have, besides the first point, automated code for the test, we can do also a UI test, a UX test in the front end, and we can do it 24-7, because everything is automated and the continuous delivery process. So, the continuous delivery process looks like, we have a developer, developer changes anything, but it's something that commences to our Git repository. If there are conflicts, we immediately see it and we can do something about it. So, after that, we automate the process, what is watching our Git repository every five minutes, let's say, and takes the code from the Git repository and deploys it on, let's say, a staining server. Jenkins is a software which deploys everything. It's a wrapper for commands which can do this thing. In this case, this is our staining server, and in this case also, if there is some error, we can the developer gets immediate feedback, there is an error, do something. After that, I would like to have, or this in a continuous delivery process, I would like to have a UAT, so I use acceptance test. What about my frontend? Is everything still looking the same? It looks the same like concepted, I mean, this is everything paid, and we have the UAT test and then we can see everything is green, if everything is green, then we can deploy on production. So, going live, still, basically, we have to write all the UAT tests, maybe we miss something and maybe there is a test which is not so good, so we couldn't cover everything. And that's why sometimes I would like to do a rollback. In a perfect world, we can do it by just clicking one button or just by firing a command from the command line. So, and that's why we developed, six years ago, DQDeploy. What is DQDeploy? It's basically, it's an extension for Capstone. Extends Capstone by, Capstone is a remote server automation tool. Capstone includes already a lot of tools, like a lot of commands, like, just example, DB at default content, so you can deploy on your system, default SQL content or some database content with just one command. Another thing, you can deploy also automated, your assets, let's say, from one of your images folder, you want to, this is your default content, you want to deploy it on your server, not via SAPP, just with a command. And Capstone brings already a lot of things. So, we built a wrapper, basically, for Capstone, which, where we can extend Capstone by more things. And DQDeploy extends Capstone with a file term machine. You can easily say, yeah, I want on this file to have this term machine, and please check it on every deployment, because maybe some developer just connected to SSH to serve and change to one file, and I want to modify it every time that all my files are secure enough to work on the internet. More of DQDeploy, we have the rollback manager, it's quite easy really to make a rollback, you will see it in a live team, why it's so easy. And yeah, I've heard it from every deployment, I mean, currently deployment takes about two minutes, but it's of case, it's on some upgrade cases, maybe you need to deployment for, it takes for 10 minutes, so it's good to have a static maintenance page so that the user knows what's going on. So, as a DQDeploy brings a one-step deployment, so you can easily say CapStageStage is the name of your stage and deploy it. Take, package everything, and deploy it on your desired stage. The benefits are, yeah, we don't have so much human interaction, so we have less steps that we can miss, so I remember 2016, my first work was through Drake, I had to, I was working on changes, I modified 20 files, and then going live, I forgot about one file, and it broke everything basically. And yeah, here you don't have to do it, you don't have to copy it manually to a server. You don't have a manual SSH to the server, let's say if you wanna run a migration from A to B, or as Guy mentioned in the WooCommerce talk, maybe I wanna upgrade to the newest version and make the database migration, so the WooCommerce tables, database tables are migrating from the WordPress standard tables. And one of the best things basically for me is that I can easily extend it by more tasks. Maybe I need a, let's say, run a ES6 converter to normal ES in JavaScript, or maybe any Power or NPM and something. I can just wrap it inside the PQ deploy and tell them, take this, do this, and that. Project to a previous stage, this is the command. Basically, I'm missing a cap station name, it would be cap dev for development, or cap production for production, and that's it. What do we need for using the PQ deploy is, yeah, first of all, SSH server, SSH user to the server, so the good thing is we can work with any host time. We need only one user, SSH user, and there is no service side installation. We can work from our computer, from our local computer, and deploy something on our host time. Some user-fibred missions to the document route, yeah, the user should be able to write and modify a couple of folders. Locally, we have to have Ruby, Bounder, PHP 7, and we work with PHP 7 and Composer. Basically, that's it. And with this requirement, with this software, we can easily take the code and deploy it somewhere, and without, yeah, not so many errors, that's it. The workflow is like this. I'm doing my local changes, my local adaption. I put it to my repository, push it, and run CapDevDeploy, that's it. So, I wanna show, so I'm using a prebuilt background box where I already installed eqdeploy and eqdeploy PHP. In the next slide, I will explain what's the difference between the different gems. So, my work tries side. The first thing I would like to do is, yeah, let's add the user to the background. And CapDevDeploy, you can filter for tasks, for jobs, and that is my WordPress, this is a custom WordPress job for adding a backend user. I will explain how this everything is working. As you can see, we are using the WPC and I package, and we're uploading it, doing the task, and then moving it. So, then I can, there is my new backend, and I'm going to start it. So, I would like to, let's say, install a new extension, a new plugin. Eqdeploy, we're using Composer. Composer is a package manager for WordPress and for PHP, and the nice thing is that every package manager handles all the requirements for specific plugins. So, I'm going to install WooCommerce. I mentioned something about the new APIs, the Eqdeploy QCover for handling new APIs. We find, we're using the QCover in a gem, and I mentioned the host, the host could be basically any site, I think it could also test my local with new APIs on the Google site or on my production site. So, yeah, it just runs a basic test for, I'm checking, is there a title, for page title, is there some file from which as you can see, I would like to have some, I can do the json and um, only the system can access it and see it, and I have those things, and make the test changing anything, and it's pending on Eqdeploy. Everybody was fine, now one of the tests should be read, and such a scenario can handle, yeah, jobs like, every page has to have one H1 tag, let's say, and because I can check, if there are two H1 tags, that the test could read, and we can monitor a little bit the behavior of our editors, or we can establish the basic level of our sites, that we're using on the best practices. How it looks like on the server, on every server, basically. So, this is a lot of input, we have the current path, nice thing, this is coming from Capistan, Capistan basically, from Capistan, we have the current path, it's a simulink to the latest release path, in our release path, releases folder, we have a couple of releases, we can define how many releases we wanna keep, third is defined, five will keep, five will keep releases, and you can, yeah, just remove the simulink and change it back, or you can use also the Capistan rollback, we can deploy a rollback, command, that's it. Extending, if you deploy, and as I mentioned, it's easy, we will hold this, it's at any release of command, we are firing the CLI path, we are using a simulink code, we are using CLI commands, and just firing the create, and roll, and with this scenario, I can also copy my, complete line, and make the parameter for any rule of everything that I want, and that's it basically, I mean, this is the structure, if you don't want to use the problem with compositors that not every package is, inside of the packages, you can work also with your own package, but if you don't want to use compositors, you can do it also, because we can ignore it, take everything that is inside of the HEDocs, bundled it, and deploy it on your stage, that's it, so for plugins, in a compositors situation, we have to migrate the plugins, the WP content inside of the, okay, no, basically the core, we have to migrate it in a different folder, so because it just comes down to the final, so if we need a new plugin, then just download it, extract it, and place it somewhere there, and that's it, and then, couple of plugins. These are the gems, as I mentioned, we have the dkdplug core, because these are the basic analysis, it's not connected to any specific framework, dkdplug php brings a compository integration, .3.2 migration, .3.2 we were using on type three sites, so we can migrate to the database content, the clear cache, and so on, a couple of php class, so we can work with php, we have the dkdplug combo test gem, this dkdplug combo brings a couple of base functionalities and useful step definitions for working with you and his, and here you can also, in your local project cucumber file, you can also extend to step definitions, so maybe you need a custom step definition, you can do it and run the task, we have our documentation site, there are a couple of inputs, currently our WordPress package is still in the development, the idea is that we present this workflow, because the workflow is quite optimized for working with type three, and last year I mentioned, I would like to have it for WordPress, and that's why maybe you will have a couple of problems, but as you can see it's working, and I will publish in the next month, this package here for working WordPress, and in a custom post story, so you can test and try it, I will publish also a test folder, so a test background page, so you can easily install it, yeah, basically that's it. Yeah, questions, thank you, and I would be great if I can become, I get this with feedback about, is it, I don't know, is it good for WordPress developer, is it just type three things, and it's not interesting for you? Hi. And so you're a complete file, using the same login information from the environment, from the database, and in-statement, is it a complete file? Yeah, we can define different, I'll show you, you mean this one? The WordPress. The WordPress? We have one, that would be a conflict file, but we don't put all the credentials over there, we can show you this is also a really nice thing, we have here our shared folder, here we can store, let's say, assets, or maybe assets in the configuration file, where you can see our data credentials, and this file we're integrating in the default conflict, basically here we are merging the, according to our stage, to the depth, so I can take the, so, cap depth takes the depth file, cap integration takes the duration file, and I can put all my credentials for the database and everything inside of these two files, and that's it. Now, what do you approach to the WordPress, when you need to propose a bit of configuration, something that doesn't work for configuration support, or having some test content, or something like that? Test, test content, we can add, this is a great problem, I mean, also in tab three, we can work with default content, and basically we, in our team, can work with something like a golden master, so this is our test content. Currently in this package, there is no possibility to make a special daily migration, but we can download the database from your local environment, commit it together, or not, and upload it to integration with a couple of tasks, that's already possible. Sorry, it's already there. I'm sorry. It's already there. Yeah, yeah, it's already there, but this is coming from, as I mentioned, this is a Crabistana task, and you can see it here, it can be, yeah, you have here default content, you can separate the content and the structure, and just run cap depth, cap integration, cap production, add default content, and it takes your content from the default target, and the default target, and the same with assets.