 work constantly with your team members, your peers. So it means that all the work you're doing is constantly integrated in central place in order to get the result of the work of everyone if it's still working when you get all together or you get all the work merged into a single place. So we have continuous delivery. That is something like a step further. It's like to provide your work constantly to reveal by the team and the client or the client. So it means that you have a central place that you are doing continuous integration. I mean, you are putting your code with your peers in a centralized place and it's available for the other peers, the colleagues to review your code or review the feature, the functionality you are implementing. And also the client can be able to see and check if this is going to deliver the value that he's expecting. So then we go to continuous deployment. What the difference in between continuous delivery and continuous deployment is like a conceptual difference because it's like deploy your work constantly right into client server. I mean, when you are doing continuous delivery, it's not mandatory that you put your code in production. So continuous deployment, it means that when you finish something, it goes right through production. So you'll have to make a process that prevents the most possible errors in order to minimize the chance of getting something wrong in production because you're putting right to production. So let's see how can we do this. The main concept of deployment in my vision is that continuous in-coachure and because you have to have a process and everyone have to agree with the process and have to be disciplined to follow the rules that are agreed in order to make this happen. If you are not engaged with the process, if you're not really believing that you have to do this step-by-step in order to have a really nice feature or delivery, really value things to your clients, you cannot do continuous deployment. In my vision, it's like a culture, not just a process or some tools and things like that. So a really good starting point is the continuous deployment of steps. It was an article written by Eric Ruiz. He is the guy who wrote the book, The Lean Startup. So he posted it days before the presentation. He taught in the web 2.0. So he talks a little bit more deeply into the five steps of continuous deployment. So we're going to see these five steps. But if you want to see or want to know more about this, you can follow this link. So the first step is the continuous integration server. And it's the backbone of the process because it's the central place that you're going to do the continuous integration. So it's a place that you have control in order to run scripts and run mechanisms to prevent something like you have to check if everything is OK. So you're going to run the automated tasks. And the continuous integration server is the tool that enables you to do this. So we have all of the plugins and services or softwares that you can use in order to have a central place that you can control all the workflow in order to deliver this to the client. So the second step is the search control commit check. It's like you have to make sure that everything that you're delivering to your client in this way a meaning code, the code that you're committing in the repository. You have to check this and see if it's OK. It doesn't have any error or any problem of implementation or any problem that should be put into the production. So the next step is simple deployment scripts. What is this? It's not really automated scripts to be, but it's not mandatory that you have to start with this. You can start from a script, like a move script. So the main thing that is that you have to have steps that you are going and doing the same thing every time you deliver the code in order to prevent errors. So if you have to run the test before it, so it's one step. So you have to run your explanatory tasks or you have to pass static analysis for the code. So we have to make this a script. You can automate this also. But you have to have these steps this step by step in order to make sure that everything is going to be OK. The fourth step is real-time alerting. It means that you have to make tools that provide you information about the process in real time. So if a test fails, you have to be aware of this. You have to have time to take an action in order to prevent to put bugs in the product, in your website. So the real-time alerting is a mechanism that prevent or that make you aware of the problems and gives you time in order to take some reaction about that. And the fifth step is the root cause analysis or the five wise, what it means. It's like a technique that the guys from Toyota in Japan, they use this technique in order to just not to resolve the problem like a punctual problem. But you used to ask five times in order to try to find the root cause of this problem. So maybe it could be like my team members doesn't have the real, how can I say this? They are not understanding what the client wants. So it's not like just a problem in the code. It's like an interpretation problem. So the root cause normally doesn't is like the bug in the code, but it's like the context that involved this bug. So where to start? The main thing is to have a standardized workflow because it's the only way that you have to make sure that the things are going to be OK. So you have to make agreements with your team. You have to have work agreements. And what is work agreements? Who knows this term? Please raise your hands. So work agreements is like a set of rules that all the team agrees and follow. So it's like when you start to develop a project. I couldn't find anything, or I was too tired to go to bed. So what was I going to do? I had this problem, and I couldn't figure out what was going on. I was stuck in the valley of dirt. When you're a beginner and you're working on contributing to Drupal Core, you're on beginner's hill. So it's like you can guarantee the quality of the project or the success of the project if you have a team that doesn't agree with some basic rules. So you can imagine a developer that has his way of developing, and he doesn't do like, I can say dirty words, so I'm trying to think something that is more sought. Let me check. So he can be like things that are not good for the project. So he is trying to do SSH to the production server, doing something that's not right. So you have to make agreements in order to prevent these things, because the only way to guarantee the quality is to implement a workflow or process that prevents errors, because errors will happen. But you have to prevent more and more errors through the process, through the workflow. So a sample of an agreement could be coding standards. So in the Drupal community, we have coding standards. You can go in the link at this slide, and you can see all the standards that the Drupal community agree in order to develop the project in a way that everyone can understand the code and can contribute at the same way. So it's a really nice work agreement. Another example is everything in code, for example. So we have a problem, I think almost all of you know that Drupal stores almost everything in the database. And this is a huge problem when you're developing for enterprise clients, because you have to have environments and all of these processes that will try to guarantee quality. And everything code would be a really nice work agreement in order to prevent dumping the database from production to your environments every time or doing this stuff like these crazy things. So another good work agreement will be test-driven development, for example. We actually do this in Drupal community, writing code for the Drupal code. So you use this in your projects also, writing tests for your features. And it would be a really nice way to prevent errors and guarantee quality for the project. So I will start with the CI and or CD server. You can make your choice. I'm not here to say what the tool you have to use. This one is one of the tools that I know. Actually, at Taller, we use Strider CD. It's a continuous-dependent server written in JavaScript in Node.js. And we liked it because we used to develop JavaScript also. So it's easy to us to evolve the environment and add plugins and et cetera. But you can choose. It's your choice. There are ones that are like open source. There are services. There are proprietary. But the choice is yours. And the point is the difference in between the continuous integration servers and continuous deployment servers is the deployment green. It's like it's a way of developing or delivering things. So in the continuous deployment mindset, you have to have tests, automated tests, and also exploratory tests, et cetera. But you have to make sure that everything is passing. So it's green. That's why the phrase is deploy on green. So when all the tests pass, it's the green one because the word that is normally success in green. So the deployment green concept is that you should not deliver nothing if the test fails. And you also have to make the term that you call stop the line. If a test fails, you have to stop the line or the production line in the Toyota way of production, like in the lean process. In order to fix that problem, find the root cause of this problem and start developing. Because if it doesn't do this, this problem can continue. And it will be worse if it happens again. So I'll talk to you a little bit about our development workflow. It hasn't been, we have been evolving this. This is not like the final state of the development workflow or like the best way of developing things. But that's the way of we are doing right now. And it's working for us. So I would like to share with you. So we have this graphic representing the pipeline. So it's the process of developing and delivering for the client. We start developing in the development machine. We test this in the test or QA environments. We send it to the client in the user acceptance tests environment or the staging environment. And if everything is OK, it goes to production. So the development environment doesn't, it's not mandatory that it resemble the production environment. Because in some cases, you have to have a huge topology, merging a lot of services and tools that the development process will be really slow if you have to have all these things in the developer environment. But it should be nice, but it's not mandatory. The task or QA environment should not be resemble the production also, but would be nice. The UAT and staging environment, or if you prefer the pre-prol environment, this one must resemble the production environment. Because it's the last time you can see something going wrong. So it's like a copy of the product environment. So you can run performance tests or user tests in order to make sure that the feature that you're developing is the right thing or fits the expectations of the client. So this is the last time to see if everything is OK. So it must resemble the production environment. And of course, the production environment is the pre-prol environment. So recap, if you want to see or want to know a little bit more about the workflow or the setup or the requirements of these environments, you can follow these links right at the bottom of the slide. This is a really nice post about the development workflow. There are some environments that he advises or he use, but it's not like mandatory also. Actually, we are not using all the things that the guy wrote in that post. But it's a really starting point. So I really recommend you to read this article. So what about Drupal? We are in a Drupal call, so we have to put Drupal in this process. Well, in order to have this development workflow, we have to have our work agreements. And we are trying to have a standardized development environment or a developer virtual machine. And at the Drupal ecosystem, there's a lot of projects that are trying to develop a really nice virtual machine for Drupal development. So there is the Drupal work project called virtual machine, like slash VM. There's another one that ZVTEC build. There's a virtual machine from the guy that is the Drupal community called Perlingai. And also, tomorrow, at the sprints, we are going to continue developing Drupal Charm. Is that an environment in the Ubuntu Juju ecosystem? If you saw the presentation of Sebastian earlier, he talked a little bit about this. If you didn't do this or you want to know a little bit more about this, you can reach us at the sprints sessions. We are going to develop or finish developing the Drupal Charm. So I invite you to drop by and play with us. Another thing is Drush. You should use Drush because it makes your process faster. It doesn't have to click and point everything if you can use just one command line in the terminal. So it makes the process really fast. And you can make automated things with this. So you can create scripts that use Drush to run something into Drupal or with Drupal. Another thing, install profiles or custom distributions. So who knows what this means? You please can raise your hands. OK, so I will explain it for the others. It's like I don't know if you know Drupal Commerce or Drupal Commons or Open Atrium. All this software is Drupal Distribution. So it's like a set of tools packed in a single pack with Drupal inside for doing something specific for an industry or, for example, e-commerce or social networks. So you can use this concept to start your projects. You don't have to download every single time. You have to download Drupal and have to download videos and have to download anti-TPI and everything. So custom distributions enables you to make files. So you can use the Drushmake command to export the actual state of your project if you're already doing something. And it will be like an archive with all the modules and versions and where they have to be and the directory and everything. If you have to apply a patch, you can put this on the Drushmake file. So this is a way to automate this thing. So it doesn't have to do every single time you are developing with Drupal, download and install all the modules you're going to have to complete this project. So another module that I think everyone should know is StrongerR module. This module is used to export variables. So the information about the slogan or the site name or this kind of stuff, there is variables inside the database. So the StrongerR module is the module that offers you a way to export these things. Another one is Features. I think everyone have heard about Features. The Features module is a module that packs everything if you have, for example, a list of posts and a block at the sidebar, you can export these configurations in a single module that we call Feature. And this will be packed. And you can use this in other projects also. So it's a way to export your configuration and business rules into other environments or share this with your colleagues and so on. So it's like the main module used in enterprise development, Drupal development right now. We also have the Folconfig module. The Folconfig module is a module that enables us to export permissions because exporting permissions with Features is like hell. It's like hell because permission is something that changes. When you start a project, you can have some permissions that fits with these users. But as the project evolves, it can change. And the Feature will make sure that everything stays at that state. So if you export the permissions with Features, you can have problems. So there is the Folconfig module that export and enables you to change the permission. And it will just revert this configuration or this change if you actually go to the interface or run the Dresh command and ask for the revert. So it helps us in order to export permissions. And also you have custom deployment modules. What is this? It's like a custom module that you use the hook update. You can add the link at the bottom of the slide as an article, a really good article talking about this. So the main concept is that everything you are developing, you should use an update function in order to make sure that the configuration or the feature that you're developing could be replicated in a build, in another build, a new build. I mean, if you have a Drupal site here and you're going to have another server, you can't, but you should export a database, for example, in order to run builds in the continuous integration workflow. So the custom development deployment module, sorry, use the hook update functions in order to make the migrations. And also you can use the configuration management module that was developed for the configuration management for Drupal 8, but it already has a Drupal 7 version. And it's good because when you're using features, you have to export everything in a single pack. And sometimes it's not the best way to export these things. So the configuration management module comes to give you the possibility of exporting like single pieces of configurations. And it will be like, I don't know how to say this in English, and even in Spanish. So, well, I'll try explaining. It's like if you have to export, let's see, a view and a content type and that stuff, you can use features. So if you have a site that have a Nils page that lists all the Nils of the site, you can export this thing and the blocks and everything in features. But if you just want a single piece of that configuration because the other site has his listing and everything, but has just a little bit different. So features will not work as he was designed because it's like a feature that it's that state. So we should use features override modules in order to override that feature. It's a good way to do this, but configuration module may help you in these cases, for example. And also, if you have some better examples, you can tell me. We have also the UUID module, so it's used for exporting content. So actually, right now we are talking about content stage. Before, we are talking about exporting code and not content. So features is used to export content and it's not like designed to do this and that's why something can be wrong when you export content with features. But when you are doing this, you can use UUID module in order to make sure that the content you exported here will be the same because when you're exporting something in your development environment, you doesn't have like 100 nodes because you don't have to have this. But in the production environment, you have all the content. So the node 10 in your environment, in your development machine, is not the same or should be not the same at the content 10 in the production environment. So the UUID module creates another ID that is unique. So you can make sure that this content is the same as the content in the other environment because of the universal unique ID. We have also the Deploy module in order to do content staging. So the problem that this module tries to solve is the dependence of content. So if you export like a node that have a taxonomy term related to it, the Deploy module will try to back every dependence and deploy this to the other environment. Because you can imagine that I think the node is the important thing. But there's all of other things like entity relations and taxonomy terms and also maybe other things that I can imagine right now. So the Deploy modules try to solve this, packing the dependencies of the content you're exporting and delivering everything to the next step or the next environment. It can be used together. It's not like for the same thing. One, it's for the exporting code. This one is for exporting content. So it can be used in conjunction. And we have the WF Tools module. So it's a set of modules that is like, in my vision, is the way that community are going to be in the future for exporting content in Drupal. It was developed by Pfizer. And Guy also gave a session about this in another Drupal call. And actually, it fucks you on exporting content. But it's a set of tools. So it has a lot of tools that helps you to export content that Deploy module can deploy. Or it's not mature to do this. So this one is more mature in order to content staging. So I think it's a good choice if you are having this kind of problem for exporting content through environments. Actually, right now at taller, we doesn't have this problem. So the WF Tool is not like our expertise. So we're trying to study in this and trying to make situations that it should be the right thing to do. So it's like an advice. And we are not using it right now, using that right now. So related to deployment tools, WF Tool module, currently I'm working on Pfizer on that project. That would be the new system of the Pfizer to deploy Drupal sites. So currently, this module is not completed. The module in the community is not perfect to use. But I think the next, I don't know, three months, that would be a new revolutionary way to deploy Drupal sites. So keep posting on that. Congratulations, man. So now we start talking about the code. So we have to talk about Git. So we have to set your Git workflow in order to everyone works at the same and prevent problems. So there are some Git workflows that you can use. I will show the workflow that we use at taller. But it doesn't mean that that's the right workflow. It can fit with your team. So if you have not distributed team or a really huge team, you doesn't have to have the same workflow as us. But it depends on the project, on the team, and everything. So you have the centralized workflow that's more like the SVN way of developing or versioning things. You have a centralized place that all the code goes there. And that's the master place of the repository. And everyone commit to there. You have also the feature branch workflow that you have to make a branch. So use branches in Git in order to develop a feature, a new feature. And when it's finished, you merge back into the master branch. So it's a way to prevent the stable code from the new feature. So we start the development of the feature in a separate place. When you finish it and you write the tasks and everything, and everything's OK, you merge back into the master branch. You have the Gitflow workflow. And that is almost the same at the feature branch workflow. But the difference here is that it's like a methodology of developing with Git. So the guy who created this methodology or this workflow has some rules that you must follow in order to run Gitflow, to do the Gitflow workflow. And actually, we are using the Gitflow workflow. And you also have the forking workflow that you guys may be aware about the GitHub way of developing things. So you have your project, and you fork the project, develop your version of the project, and you make pull requests. So the maintainer of the original repository will reveal your code. And if it's everything is OK, it will be merged back into the original repository. We tried to use this. Actually, we were using it in other projects that is not Drupal projects. So it's good because you have more people looking at the code because you have to make a pull request. So someone have to check the code, reveal the code in order to approve this. So it's more secure. But it can slow down your process if your team is not used to work in this workflow. So you have to try. So the Gitflow workflow came to us by this article written for Vincent Driessen that was called a successful Git range module. So here's an explanation of the process. I will not explain this really deeply because I think it's not the factors of the presentation right now. You can check it out. There's links at the bottom of this slide to see a little bit more about this. But it's like you have the master branch and you have the feature branch and other brands to complete the release process. So it's a model to work with Git. And it has a plugin. So you can install this. The Gitflow plugin, you can check it out at GitHub or just run up to get to install Gitflow before using some Ubuntu or something like Debian-based operating system. So we have to talk a lot about Git Hux because Git Hux can help us to automate things in the process of the development because you'll have to write your code and have to commit your code and have to push your code. So every time you are running a Git command, you have a hook that can be fired in order to run a process. And you can use this for run the unit tests when the developer pushed the code for the repository. When the repository server received this code, there's a hook also so you can run scheduled static code analysis in order to prevent bad architectures or something like this. So you have client-side hooks and you have server-side hooks. The client-side hooks is the hooks that are fired in the developer machine, so in the client. So one of the hooks that you could use, it's the pre-commit hook. So before the commit, you run, like, LinkedIn or a static check for make sure that everything is in the code, follow the code standards. And you can also run automated tests like unit tests or other tests. You can also use the post-checkout hook. This hook is like warning or, like, and hook for alerts when you start working with too much people and too much features. And maybe let's think that the client de-prioritized some feature. So develop in this, and it's broken because you will stop at the middle of the development. So at that state of the code, some tests could be failing. So if you're using the post-checkout hook, you can run the tests or the critical tests in order to make sure that if you're starting with this state of the code, you already know that are something bad that you have to fix. And it's like a way to prevent you to keep just with your memory because you can forget things. So this is a nice hook to run critical tests against the code. And we have the server-side hooks. The server-side hooks is the hooks that runs when the code came to the server. So we can use the pre-received hook in order to also make coding stunts for check, run automated tests, or make branch preventions. And it's good because when you are trying to use a lean development process, you have this top-deline concept. So if everything or any of the tests failed, you can use the pre-received hook to prevent more code to go to the next step of the workflow. So you have the ability to prevent the other developers to still pushing code to repository, even if you doesn't fix the problem that you should fix right now. So it's a really good thing to start doing the top-deline concept in the development workflow. And you have also the post-received hook that you can use to run low-task or notifications for your developers. We at Taller use this like when we push the code, the repository sends us a message in our chat client. So we know that a deployment are going to be started. And we see all the tests facing or failing. So all this kind of stuff could be in a hook, in a GitHub. So you can run these commands or your script. And you can use this in order to be aware of what's happening behind the scenes. So it's like a really important thing, because it's something like if you're driving a car and you doesn't have lights, you don't have any sense of where you're going. So the approach is the way that we can use the lights of the car. It's the only way that we can be aware of what's happening. So it's really, really, really important. So about Drupal related to Git. There is a coder module. This module is used to run the coding standard stuff into your code. So it's also in the process of development. The Drupal development, the Drupal project development. So you'll have some standards that this module implements in order to run against your code. And make sure that everything is compliant with the coding standard, the Drupal coding standards. You also have the PR, PA review script that we are used for realm-like pattern preventions or prevent like injection or patterns that are already proved that are wrong. So this one also is into the Drupal development process. So every time you contribute with a module, you have to use this against your code. So if we are already using it in the Drupal project, why we should not use this in our projects? Because it guarantees the quality of the code. So you should use this. And you can use this into a GitHub. So this is important. And you also have the Drupal code quality module that actually is just a file that it's a hook for Git. So the file just call and command, address command. And you just download this module, open your repository, and go to the hooks directory into your Git repository, and put these scripts into your Git hooks. So it's a good way to start if you doesn't have anything. So now we're going to talk about automated tasks because that's the part that guarantees the quality. So I think the automated task is the only way that we have security and reliability for a continual improvement process. Because if you doesn't have tests to prove that the state of your project is good right now, you will not be like confident to put more code there. Because it's something like it's still working. Doesn't touch this. You know, you will be like it will prevent innovation because you cannot imagine what will happen. Or it's like this part of the code is like too complex. I'm not touched this. Let's take this in that way. So the test guarantee that you can factor your code. So it's the tool we have to guarantee the quality and able us to innovate or make optimizations into our code. So a really nice session talking about tests were in the Agile Brazil at the last year. And Joseph Yodel, the guy who created or coined the term of test-driven development, gave a session about tests. And he gives us the 10 tenets of testing. So I think we should follow these rules because he had a lot of experience doing tests. And it's like some obvious. So you should see this presentation. Another thing is that he calls the classic test-first development, or the classic TD test, and the real process. I mean, there are people that actually do TDD by the book. But I think in the Drupal context, it's like more difficult because unit tests in Drupal is low. So if you're doing units, your time, you have the slowdown of your process, if you're not proficient in doing this. And also because of your use in simple tests for the tool of BDD unit tests. So there's the workflow that should be used by the book of the TDD. And there's the pragmatic testing cycle that fits more with our reality at Taller right now. So we write production code first, and then we write the test for this. It doesn't mean that it's wrong or it's right. The main thing is that you have to have tests. Doesn't matter if you wrote this before or after the production code. So it's like we are busting some myths about TDD. OK, so using tests with Drupal, how can we use it? Right now in Drupal 7, we use simple tests. Simple tests, we're doing well, your job, but it's not like the best solution, I think. And naturally or organically, the community is changing the PHP unit. So Drupal 8 actually replaced the simple tests through PHP unit. So maybe you can use this in your next project using Drupal 8 for unit testing. And you also have BDD, the behavior driven development. So you have tests for checking for the behavior of the user. So in the Drupal community, the most common solution for this is the B-HAT project. And we have the B-HAT extension module in order to connect Drupal with B-HAT. We at Taller, we doesn't use B-HAT. We use B-ARBO, it's a BDD framework that we built up into the Cucumber project. So it's written in Ruby, not in PHP. But it created the concepts that B-HAT uses right now. So he has the gherkin language that is a language that the managers can understand in order to write the tests in a human language. So you write the test in a human language and then you write the steps of this test. So we liked this approach. And as we saw that Cucumber were more mature, we chose this. But it doesn't mean that it's a bulletproof solution. So you can use B-HAT if you're more comfortable with PHP, or you doesn't like Ruby, or something like this. These were the process we're using and the tools are used. Now before the questions, I would share my vision about this. And I think that in the evolution of the Drupal project, we have some points that makes us a really good continuous deployment process because all of the peculiarities of Drupal, like storing everything in database or everything. I think right now, with all the changes that Drupal weights bring to us, I think it will be really more easier to do this kind of workflows and implement this process in order to have the continuous deployment running like the right way. So I'm really excited about Drupal 8. I think it will help us really, really to minimize the barriers that we have right now using Drupal 7 in order to deploy the code right to the client. So I think actually right now, I'm really excited about the future of the project because I see it's more compliant with this mindset. So I open for questions. If you doesn't understand something or you would like to share your experience or if you are doing a better workflow or you have a better process, it will be really nice if you could share this with us. So another announcement is that all the sessions will be open for feedback. So if you do like this session or if it doesn't like this session, please give your feedback and it will help me to make a better session for the next time. So anyone have a question? I arrived a little late, so excuse me, you said this at the beginning of the session. First and everything, great session, thanks about it. Where could I get the slides? Presentation on the Drupal Clown website. So right when we finish this, these slides will be available on the Drupal Clown website. Someone else? OK, so thank you, guys.