 How's everyone feeling today? You're still fresh despite the fact that it's a little bit late and a little bit hot in Singapore today Well, obviously not inside luckily So welcome to my presentation so I'm Niels Let me tell you a little bit about my background. I was born in Germany Many years ago lived in Holland for a while moved to Indonesia three years ago. So technically I'm a neighbor of Singapore For the previous three years. I was a WordPress freelance developer Done multiple customizations on WordPress.org WooCommerce I wrote plugins created themes. I'm organizing WordCamps in Denpasar and in Ubud Next week. I'm actually organizing the WordCamp in Jakarta and capital of Indonesia. So feel free to join by and Since probably two months. I'm working for automatic the company behind WordPress which is fantastic and as the previous speaker already said we totally treat our Employees not as assets, but as friends and and and we share Love and happiness amongst the team and I think that's that's very crucial in order to to become a really successful company so that you don't really see employees as as Someone who just has to do the work but but really as a as a friend So today's talk is about D-Tab so it's a little bit more technical I want to share some insights from my experience as a developer and the thing is what does D-Tab actually stands for So D-Tab is an acronym for D as development T for testing a for acceptance and P for production. So what does that mean? Who in here is a developer? Please raise the hands Okay, so we have a couple of developers Who face the situation that you get an urgent call from a customer? You need to adjust something you log in you make the change and you end up with the so-called widescreen of death Sounds familiar Right never touch a running system. It's always tricky. So the thing is why should you use a D-Tab environment in first place So I'm talking more about how to set it up. But the thing is oh I'm not loud enough. Okay. Thanks. So why should you use a D-Tab system in first place? Wouldn't it be much easier just to log in and do the change? Well, the problem is that there's always that risk that you actually Bring down the site and especially if it's an e-commerce site Which has a high turnover? You don't want to to to bring that site down at any given price So the system needs to keep running so the first thing you can do is what starting developers do They log into the system. They make the change. They bring the system down. They have to explain the customer that they Kind of mess it up. Nothing works anymore Customers frustrated clients of the customer are frustrated probably the developer starts to get sweaty and and and Worry is about losing their customers. So it's not really a good relationship the next level towards a full D-Tab environment is if we integrate an additional step and Even beginning developers figure that out relatively soon So a better approach is that you actually take your project offline So on the left hand side, you can see the D which stands for development Whereas on the right hand side, you can see the P which is the production environment So usually when you when you work on a client side, you clone the side Take it down to your computer, which also has the benefit that you can work offline So if the internet connection went down Which now and then happens in Indonesia, especially on Bali You can still work on the project and once that project is running and and and you implemented all the features as Required by the customer. You can technically upload it to the server. So that's a much better approach than to Operate on an open heart and and and by touching the production system the problem is That scenario it could work on your local machine and as soon as you deploy it You can still bring that server down Probably you have different software versions. You have some library dependencies You have different PHP versions. So there are a couple of cases that can actually happen which still lead to an issue so Example number two is a much better scenario than the example Number one. I just see that I messed up the numbers. Sorry for that So that is a much better scenario But it's not perfect yet. So the next step would be If we integrate an additional stage So now you can see we have a development environment, which usually is my local machine From the development environment. I push all my changes to a testing environment and Once everything is tested and works according to the specifications, then I push it further to the production environment The big advantage of having a testing environment is usually my testing environment runs on the same server as the production environment So I'm using the same libraries. I'm using the same Server settings. So I know when the tests actually succeed I can push it further to production and it might not affect anything That is a DTP. So now the question. What is the DT AP DTAP environment? so and a DTAP environment is Highly recommended when you deal with sensitive data So this is how a DTAP environment looks like. So you have the development in first stage Once the code is is implemented you put it to stay to testing. So on testing you can run All kind of tests to see if it works Once these tests succeed you push it further to an acceptance environment The acceptance environment is not for you as a developer, but it's for your customer so your customer can run extensive checks on the functionality and see if everything works according to the specifications without touching the production system. So the production you Let the production system run until all the tests are done by the customer. So as a developer I can play around with the with the testing environment. I can deploy at any given time without affecting the customer. So and Once I push everything to acceptance then it's up to the customer and then I don't touch the acceptance system anymore Once the customer approves all the changes these changes can then be pushed further to the production environment And to give you an example when to use such an environment I created an application for the university in Amsterdam the hospital so they have thousands of patient records and They want me to to create the application, but at the same time they don't want to give me access to their personal records Which is logical like I don't need to know these these data and these are pretty sensitive data. So what we did actually is I Put all my changes from development to testing once they're tested I gave a sign to the IT department the IT department then pushed my changes further to acceptance And at the same time they took the real data from the production environment and pushed it back to the acceptance environment So I at any given time I could never access the acceptance environment but on the acceptance environment my customer could actually check the System and the new functionality. Sorry for that Could test the implemented Functionality with the real client data So there are a couple of strategies how to do that. I already mentioned one of the strategies So how to deal with with with changes how to deal with content how to deal with commits We always say changes go up Content goes down So that means when I implement a new feature I start from development Then I push it to testing then I push it to acceptance and then it goes into production at a final stage With the content I do the other approach. So the content The latest version of the content is always on the production version. So from production I actually push that content down to acceptance from acceptance down to testing and from testing down to development Of course, it depends on the customer. So in that example with the university in Amsterdam They only push the data from production to acceptance and then they make a cut and I say, okay We don't push these data any deeper Because then we release we lose control of these data. So you need to come up with your own test data But if you work on a regular project It's always a good idea when you start development that you make a dump of the database first and take that content all the way Down to development Implement your features and then push your features all the way up to production So there are a couple of naming conventions I developed over time. So you do have development testing acceptance Production so usually I use the subdomain DEF for development For testing, I usually use alpha for the acceptance. I usually use beta And I don't really use www because it's simply a subdomain some customers like it because it's Little bit more traditional and it looks like a real website. I had a couple a few customers who told me. Oh, there's a www Missing it doesn't look like a website to me Well in that case you just add a www and This is a slightly different naming convention I also use DEF in in in that scenario for testing you can use testing for the acceptance environment You can use acceptance or you can use staging Yeah, and and with the development you can add a www if required That's the end of my presentation, but I'm happy to answer all your questions you have Thanks for your patience Yep So my question is how do you manage all the four environments at once? Do you use any kind of tools or what? Yeah, I'm using a plug-in called all in 1wp migration, which is For me it works best because I can create a dump of the entire system and move that that dump around Usually I create an SQL export from the production system Which I bring down to my development environment and then I implement the features and from there I simply create a dump and an import these dump on higher levels So for me they works best It always depends on the environment friends of mine. They also use vagrant or to use Docker and and they use automated scripts But to me personally wp or all in one migration that that is my secret weapon Yeah, I think there's a question in the back Just in regards to the same That same issue. What about dealing with we commerce and live order sites in terms of pushing data To so from a acceptance server straight to a live server because obviously you don't want to overwrite any live orders And things like that which can become quite troublesome. So you're only pushing part of a database Yeah, that's a very good question when dealing with a WooCommerce system I usually don't push these data around because you're absolutely right If I create a dump now and I push it back in a week I would technically lose all these data. So when dealing with WooCommerce system, I don't create full Dumps, but I simply commit the single changes So yeah, it's a little bit more tricky and then I really need to go through my my git history and see okay Which files did I actually change and I manually? Yeah at these files. Yeah After I make it back up first Anymore questions Yeah How do you do all the commits to different environments and all that because like this something which like I'm not very familiar with So maybe we can go into a bit more detail about how exactly do you do the committing and stuff? Yeah, so the question is how do I deal with version control wide? so I'm using bit bucket Which is kind of a replacement for github the beauty of bit bucket is that it technically has the same functionality as GitHub with the difference that in github You can only use it when it's open source so everyone can access the code which if you work for a for a paying customer You usually don't want to open up that code and and have that project available to the entire world But I use git all the time and I Truly believe that that the more commits you do the better it is so I don't Implement massive features, but I break it down into really small User stories or small requests. I implement just a single request at a given time I commit it and then I do the next one and the next one and the next one and that gives me the Flexibility that that when something breaks I can always do a rollback to a given stage and I can also kind of cherry pick different commits So does that answer your question? Yes, thank you. Can I ask another question? Like you make use of any continuous integration or continuous deployment tools? At the moment not The thing is I was a one-man army and my projects were Rather small. I Totally agree that that continuous development and continuous integration is a is a very important role In my projects it was it was Yeah, not necessary is the wrong word, but I never really used them. Do we have any more questions? No, okay, then thank you very much, and if you have any more questions about WordPress automatic By the way, we're still hiring you can find us in the front at the automatic table and Enjoy the rest of the day. I hope I see all of you at the after-party and make sure Don't miss the contributor day tomorrow because tomorrow we as far as I know we work on the core We work on the theme. We probably do a couple of translations And if you really want to get your hands dirty with WordPress and see all the ins and outs I can highly recommend come tomorrow and see how it actually works under the hood Thank you very much and enjoy the rest of the webcam