 Good morning, everybody. Thank you guys for coming and Excited to see a lot of people here talk about something you've probably never heard of and that's pretty awesome Welcome to workflow tools for the win at Pfizer Present today are me and myself. I'm Tim Holt and Dave Hall So I get this thing started All right, let's talk about who we are. I'm Tim Holt work for aquia as a technical consultant in the professional services division Prior to that I worked at Warner for five years and ran their Drupal and Magento platforms Also am a Drupalist I Am a systems architect For usually for high-level type stuff. I also specialize in large-scale migrations and You know, I get this a lot Especially people at Drupal con that have had a little too much to drink it like midnight. I'm not trees Here's Dave Hi, I'm Dave Hall I'm an IT consultant. I currently work as a web platform strategist at Pfizer. I'm a Drupalista. I Really enjoy hacking on web apps I'm a CIS admin and I'm generally known as a fat opinionated alternative to SVN So Before we get started actually whoops, I actually have to go through this to keep the Pfizer lawyers happy So I'm going to be talking about all kinds of stuff today But Pfizer may or not be using what I'm talking about. They may not continue to use it and if you do anything that I talk about here today and It causes you problems as your own fault for being stupid for listening to what I had to say So tune out now So, okay. Now the lawyers are happy. I can get on with the presentation So some of you may think that Deploying code content and configuration in a coordinated way through multiple environments is the thing of fairy tales Well today, I'm going to tell you a story. That's actually real not a fairy tale So once upon a time a Little boy called Dries lived in Belgium. I'm not sure how old he is but This is Dries with his little pet bunny rabbit and While at uni Dries had a little baby called Drupal and his Dries's little baby Drupal started to grow up and Like many kids Drupal started doing odd jobs here and there in high school Drupal got a part-time job Eventually Drupal went to university and after graduating Drupal got a job in the media and You know serious media your organization started adopting Drupal oops One day a big corporation rang Drupal and offered Drupal a job on the first day Drupal turned up for work But it was clear that Drupal didn't quite fit in Drupal was used to doing everything on production One day the boss called and told Drupal to go buy some new tools. Oops Sorry about the dodgy clicker Drupal started searching for new tools and Unlike most times you buy stuff on eBay Drupal's new tools arrive the next day and Drupal's boss was impressed and They deployed happily ever after and that's the end of our story. That's the end of our session. Thanks for coming Okay, so what was in the toolbox that made Drupal's boss so happy? There was UUID which is universally unique identifier Drupal 8 core has UUID baked in for Drupal 7 it's in ConDrip and what UUID allows us to do is to track a piece of an Entity from between multiple environments So in dev it might be node 3 on stage it might be node 6 on pride It might be node 5 and we need a way of identifying the node through those multiple environments and To move them between the different environments. We use the deploy module which uses UUID and Services to be able to push the content between the environments We use drush on the command line because drush allows us to revert features run database updates Do all that stuff that you get RSI from if you do it clicking a mouse Then there's features for exporting configuration. I'm assuming that pretty much everyone in this room knows how features work So I'm not going bang on about it Then there's git all the code and configuration is kept in version control Then there's the rules module which allows us to react to things happening within the system and most often that's triggering Jenkins jobs and Then we have custom entities for keeping track of everything These tools allow Drupal to do things very differently and now I'm going to hand over to Tim Who's going to talk about how Drupal does things differently? All right. Thanks, Dave. So let's start when Drupal is a little bit younger code goes up and Content came down now. You guys probably recognize this workflow if you've worked in Drupal for any amount of time the dev stage production three environment scenario is what we're pretty much used to and we're also used to creating code either locally or on development and then Promoting that code through different environments up to staging then up to production ultimately on the flip side Usually we create content directly on production If you are doing a small site or a blog you just write a piece of content and publish it You might be more sophisticated and use something like workbench moderation, which gives you a really great Approval and workflow process if you're really sophisticated you might look into something like SPS Which is built from the CSI initiative that LSD sponsored and a being able to preview your content in context again This all happens on production The challenge is that this created a little bit this creates some problems, right? Drupal realized that looking at content on staging a little bit difficult, right? Because if I'm putting all my content in production, and I got to sync it back to staging I may not do that very often. I might have other things on staging that I don't want to wipe out etc So looking at content on staging. It's difficult Another thing is there's not an easy to read log of every change that I'm making So if I'm committing code to git then of course, I've got my git commit history, right? I've got branches if I'm using a good branching model, which we all are But I've got you know I've got all my code in one spot But my log of changes on my content is completely somewhere else, right? It's if I'm doing revisions if I'm using workbench moderation That's it's not a really easy way to see it And even if you create a view and have a consolidated place to see it It's still very separate from where my code changes are Drupal also had difficulty looking at a single change on its own I think we've all had this scenario where we're developing Probably three or four different features locally and then we're ready to push that up to staging because we want to see it on staging And we might be showing two or three features on staging and then somebody comes along and says I just want to see this one Change I don't want to see these other changes then we go through a big process to try to figure out Okay, I just want to get that single change on staging and and again. It's difficult Also realized that hey, we can't bundle content and code ages together Let's say I've got a code change that it introduces a new content type How do I test that well? I'm going to be putting creating content on my local machine Then when I go to push that to staging I'm going to be creating test content again on staging then I have to push that to production before then I can Engage my whole content workflow of creating unpublished nodes and draft states and all that kind of stuff So again, it it's very non-intuitive Deployment is often an all-or-nothing event We all use staging the right way, which is that We push all of our changes to staging and push that wholesale up to production every time, right? Yeah What often happens is again You'll have four or five changes sitting on staging and all of a sudden somebody says oh We have to get this one change up to production So you end up doing a lot of work to get that one change out and push to production Where that's usually your first test of pushing that single change Anywhere is when you push to production And that's because deployments can't really be easily tested if you're trying to do single changes Also another challenge is different permissions and configuration per environment aren't really possible Right. This all made Drupal pretty sad. He's got kind of a sad face there Gets me a little choked up. Okay. So Drupal decided to change how things were done So this is a different workflow and you'll notice we've we've changed a few things here We've added a new environment You'll notice in the pink called integration and then we've added multiple dev environments And I'll get into what that looks like in a minute But the big idea here is that we've taken both code and content and we've decided to push them in the same Direction so we have a consistent workflow for both code and content Drupal discovered that arbitrary sets of changes could be bundled together And then we decided to call this a job So now with a job Drupal can take a content change and a code change and put them together So they can promote them through environments at the same time Now Drupal can also approve the changes in the job every step of the way and log what's happened And this is important because if you want a single consolidated place where you can see Here's where my code changes in my environment. Here's who's approved it and also the same exact workflow for content Then this is what you need essentially think of workbench moderation for your code Drupal also gave each job its own dedicated sandbox and this is also a scenario I'm sure we are all familiar with developing in a completely isolated sandbox now Drupal can preview content in context on any environment a Great thing too is Drupal can now push several jobs to the staging server But only push a single job up to production when it's ready and a bonus Drupal now test deployments at every step along the way Because we're doing this in a coordinated fashion Deploying to your integration environment deploying to your staging environment deploying to your production environment is the exact same process And so if you have a hiccup you'll have it at integration Drupal can create edit preview and push content all without logging into production This actually gives you the opportunity to do hands-off deployments in Drupal for both code and configuration and content All right now let's tell another little story here Drupal has a little cousin and I'm not talking about backdrop Drupal's let's call Drupal's cousin's name is a job 123 So Drupal needs to make sure that job 123 is safe on its epic journey through the environments So start to start with Drupal job 123 started off as a something just as a twinkle in somebody's eye probably someone from the marketing department and So what happens first Drupal spins up a new dedicated sandbox just for this change and Let's we're gonna put it at someplace called job 123 dev dot site dot com This is essentially a full copy of the production environment for this site In its own dedicated sandbox where developer can go and make changes Then what happens next Drupal creates a job 123 get branch checks it out on the sandbox So my sandbox is immediately ready to start committing code to a branch that's dedicated again to this particular issue Drupal then creates a job 123 deployment plan to track the content changes What's great about this is we use the deploy auto plan on the sandbox to essentially any change that we make to any entity On the sandbox then gets added automatically to the deployment plan So it's kind of it's called auto deployment plan and if you look at the description It says it auto magically add stuff. It is it really does that. It's pretty cool This enables if you're a content editor and you're just going into edit content on your sandbox You don't even have to think about it. You just save stuff and then it automatically adds to your deployment plan So Drupal then goes in and makes changes to the content or the code or both in the sandbox again We can bundle them together So once it's done now job 123 is big enough to move up to the next environment which we call the integration environment So what happens here Drupal merges the job 123 get branch into the integration get branch and pushes it up to the integration Server in this model. We're assuming that every environment has a dedicated get branch So the integration server is always running your integration branch the staging server is always running your staging branch The production server is always running your production branch. So then Moving code in is just simply merging branches into those branches Then Drupal triggers the job 123 deployment plan to be pushed up to the integration server again This is done by a drush and Jenkins We push not only the plan up, but we actually move the plan So we don't just deploy the entities, but we actually copy the job 123 deployment plan up to Integration so from integration we can then deploy it again to the next environment So once everything's on integration Drupal just sits back and looks at the changes that have been merged into the integration server And says you know what job 123 is ready to take the next step to the staging environment In a workflow tools This is done by a little button that says propose for staging or propose for integration which you'll see in a minute Once it's on staging the exact same merging and approval process happens before being pushed to production And what's great here is again all of the statuses of my job are tracked by Drupal So I can tell it a glance Whether a job is sitting on my integration server whether it's sitting on my production server Whether it's sitting on my staging server and who needs to come along and approve it to get to the next point Drupal can tell at a glance which jobs are in which environments which are ready for approval all from a central management console And this is a very crude graphic to give you the idea that we can have multiple jobs sitting in individual development sandboxes And we can push certain ones of those up to integration certain ones up to staging propose a single one to go up to production This management console is the heart of what workflow tools is It's a Drupal site that provides the workflow and the Window into seeing this process work So meanwhile Pfizer heard about what Drupal could do now At Pfizer and Drupal worked pretty hard Drupal ran about 300 sites or so at Pfizer and Each wing each week brings around three new sites to the platform Pfizer really needed Drupal's new tool box and Drupal's boss at Pfizer was impressed Alright, so I'm going to hand it back over to Dave to walk you through a demo Yeah, so that's enough talking about what WF tools is I'll actually show you what it looks like now So this is the Site screen so we support multiple sites If you've got a network of sites you can manage multiple sites through the one interface so I'm going to go into Advil and On here, it's just got some basic information about the Advil site and Now if I want to add a new job, I would go into the add new job Before I go create a job and stuff I should show you that these are all Entities so we have a job type and Within that job type. It's a fieldable entity. So if we want to add any additional fields or Change the order of the fields or anything like that. That's all controlled through the normal fields UI so the whole idea with WF tools is that it's not a System where we impose on to you the system. It's a framework So you're able to add additional fields or change when certain events trigger in the workflow process It's very flexible I could spend hours talking about how to configure it, but I'm just going to run through with a pre-configured setup today So I'll actually switch to the video Because the Jenkins jobs actually Take a little while to run That was something I was working on earlier Where's my video gone? Okay, so so Here I'm on the Advil page. I go over and click add new job Sorry for the people up the back that it's a bit unclear The video will be online so you can watch it again later So now I go in and add the details of the job give it a name then the external reference and Some details the external reference is completely pluggable. So say you use a ticketing system You can put in the ticket number and it will actually link through to the ticket in the UI and Here it's pre-populated the site for us down the bottom as well This was recorded over the hotel Wi-Fi. So things were a little slow So now it's Created a new job and then I could create say 20 jobs all at once and then when I'm ready to start work on one of those jobs I'd hit the start button and What that will do is actually kick off Jenkins job. So rules will pick up that the Job has been started and it'll kick off a Jenkins job to go build a completely new doc route on Sandbox server for us So it'll clone production and it'll check out a new branch based off production It'll clone the production database. It'll copy all the assets from production as well. So it's a completely isolated setup So here it is creating the branch So exciting watching someone else drive Jenkins, isn't it? So here it's that job's completed. It's successful and it's showing that the new job for branch has been created and then that actually triggers off the deploy sandbox job and For those of you who like watching grass grow I've got the extended version of this video where it deploys the whole thing. We'll just have a quick look at what it does here So this Is actually running on cloud base which is a hosted version of Jenkins You can run it on any Jenkins instance or you can use your own CI server It's completely pluggable and so now it's copying all the code over to the server There we go and It's It's finishing off the running of the job here It's creating the new deployment plan and everything so it automatically tracks everything As the changes are done and we've got success down the bottom and now we go over to our Job for that dev dot WF demo Give it a sec and It should load There we go. So there's a completely new instance of our a cloned instance of Our production site. I can log into it If you want to Again, it's completely pluggable. You can write a plug-in so you can use drush ULI or something So the person just hits a link in the management node and it'll log them straight in so you don't even have to worry about creating accounts So we log into the site Then we go create some content I'll create a basic page There we go. We'll put the title in put the body in Include a typo. You've got to have a typo in a live demo And then hit save in a second. We'll have a new page There's a page and now next I'm going to Place a menu block using the context module. So we'll go do that so There's the existing context We'll add the block. So I'll add the navigation to sidebar second We'll save that and then we'll go to the command line and actually export Re-export the feature First we'll show that it actually works and then we'll re-export the feature exports the feature We'll diff the file And then we'll commit our change and push it up and I'll just show you that the Node we created was tracked by the automatic plan. See the random pages In our plan. So it's like it's looking over your shoulder all the time So this is the site. Whoops. I've still got the video at double speed. I'll go back to normal speed so we've got the branch here and this will show us the diff of the change and There was a block taken out and the navigation block added and now we'll go back to the management node The right instance of the management node There we go And now we'll propose for integration and again that will kick off a Jenkins job First I need to propose it So I asked someone to review the changes the whole idea is nothing gets to the next environment without someone reviewing it and Put a comment there. So the reviewer actually knows what they're being asked to look at the theme that we've got here is called start work and At the moment we're in the final stages of polishing it We will be releasing the start work theme and all of the WF tools enhancements in the coming weeks So pretty much everything you see here will be freely available. And now this is the reviewer they're Making a comment and approving for integration, which in a second will kick off our Jenkins job and We'll just Speed things up a little bit here because You didn't come for a presentation on watching grass grow So there we go. That has successfully deployed Videos doggie edited. There we go. Yeah success and Here we go. We will refresh our stage site Give it a second and there we go the navigation block has been added to the right side and I'll just check what the URL is and Then go have a look at the page to show that that's deployed as well. Here we go. There's our Random page. So That's how easy it is to move stuff around with WF I'll just go back to our Presentation So this really moves from that all-or-nothing big releases where you know You bundle up all you code changes on to integration and then do the weekly update or whatever it is to the website This actually allows you to move towards a rolling release model which gives you code Content and configuration moving through those multiple environments in a coordinated way Which really allows people to go from an idea to production in an afternoon with multiple levels of sign-off So that's pretty much it. I Always say they all deployed happily ever after which is the end of our story So we've got a bit of time left for answering questions So has anyone if you do have questions, there's a mic there in the middle So just come down and we'll do our best to answer them And if you want to learn more or connect with us, there's the details. We'll leave that up during questions Thank you. My mind is kind of blown right now. This was like really really cool Thanks, so I have two questions first. I'm trying to relate this proposed workflow to what I'm used to which is develop on local push to dev through staging to prod and It kind of seems to me like these dev instances are kind of like the new local where you're actually developing content or something like that So what would be the can you explain? The relationship between integration and staging. Yep. So first the the dev sandboxes Like if you're making small changes and you're comfortable on the command line you can just go in there make the changes and commit it and push it up like you saw in my demo and also you can make all the content changes because you actually need to track the The changes for deployed to be able to deploy it But you are free to work locally And you can pull the database down from the sandbox server work locally make all your changes push it back up it really depends on how Developers are used to working and how comfortable they are doing that type of thing the reason why we have the multiple We have integration which is pretty much for the devs to integrate their work and check it and make sure it deploys properly and then to get it from we get it to preview which is then for business people to go Have a look at it and go. Yeah, that looks awesome I'm going to approve that for pride and it also means that we test the deployment Multiple times before it hits pride because you don't want to have the first time you're testing a deployment is When it's going into production But the whole system is completely flexible like if you wanted to have eight environments to push things through I'd think you're crazy, but you could do it if you wanted the minimum is three you need dev You need an integration you need pride, but that preview step Just make sure that you've really got things nailed before it's going through to production Yeah, and for a place like Pfizer, you know There's a hard requirement that production and staging or preview are exactly identical In every way so the integration environment gives you essentially a second staging environment to really for again for the developers to actually Check and make sure that they're getting what they what you expected That makes sense. Yeah, definitely relate to that with you know, the the the clients really wanting Staging, you know, they don't want any hiccups on staging They want to be able to go in there and see exactly how it's going to be and dev it or I guess in this case integration is a great place to Give a trial run. Yeah, and also like if you do a git merge onto integration and you've got a conflict You resolve that but you want to make sure when it goes to preview you don't have a second conflict Because you know if it goes to prod the prod deployment breaks and then, you know, you've got to get superglow out which isn't much fun Sure. Thank you. Okay. And second question is let's say You know my my dev shop or or maybe even just on a specific project with a specific client. We were interested in Integrating some of these workflow changes Do you see it as flexible enough to allow kind of a slow or partial adoption to where Let's say some content is still being updated and changed on production And also, let's say, maybe some developers are still Just creating feature branches if we you know follow git flow or whatever And are still, you know pushing those straight to Either integration or staging without sort of using the the whole Jenkins workflow of creating a sandbox. Yep You could look at doing that like the whole thing is that WF tools is a layer that sits on top of a whole lot of best practice tools. And so You can pick up individual components from that and use it I just strongly believe that WF tools Ties together a lot of best practice in an easy to use way But you are like one of the things we're going to be doing at Pfizer is trying to retrofit this to hundreds of sites. So it's not, you know, you go from You know nothing to having everything running on this in one day, it's a whole process It's a lot easier with Greenfield site. So Yeah, and another thing too is that This model basically eliminates the idea of pushing a database upstream at any point So your site has to have at least some groundwork in place to make that be able to happen I mean, so we've done a lot of work with deploy to make it compatible with lots of different entities Lots of different node types third-party modules so that we can push lots of things reliably via deploy, but That's a pretty big limitation So if you're if you're used to even from like dev to stage pushing a database up Like you you need to be able to have your site Architected in such a way that you can put everything into code or everything's deployable So because again, we never push a database upstream. Yeah. Yeah, definitely Really great presentation guys. Thank you so much. All right. Thanks. I was fun delivering it Questions and first one is about the mergers and merge conflicts How do you resolve them and on which state you notice them? Okay, so Part of this like I firmly believe you can't solve all problems with technology You need your team Like understanding how things work and also to not do stupid things So, you know, they if they try to do a deployment and they get a get conflict the deployment fails They will be able to go through the log and go, okay code mergers failed. I will do a merge of What's causing the conflict into my branch? Resolve that conflict and then push it up So it's just the same now like if you're doing feature branching and there's a conflict you have to Resolve that manually anyway. Yeah The part of the other idea too is that we we try to bite off small changes with these jobs so that in theory you have a little bit less of a shot of creating a conflict if You know what we try to piece things out into small small pieces I you know when you obviously are first developing a site then you right now We're just developing an entire site in a single job and then pushing that up for the initial version But generally as the only place it happens where you've got a lot of complex things happening in a single job And by keeping it very segregated it helps ease that transition and obviously you still need to communicate So, you know Pfizer has oftentimes has different vendors working on the same site and so There's still communication required between the teams on some level to say hey We're fixing this or updating this piece of content over here. You guys don't mess with it over here You know, so I there is there's still like the old-fashioned side of it like Dave saying we can't completely solve everything With the technical solution, but that that approach helps at least a somewhat to you're not going to ever eliminate The possibility of a conflict, but you at least help mitigate it a little bit by biting off smaller chunks Okay, that's clear and another important thing is how we roll back in this scheme Under this model the only time you roll back is if you Have a deployment that completely breaks an environment, which Given that you're deploying through multiple environments. You should never break prod in theory I know but as we all know prod Can there's always a risk, but this tries to minimize it But say you get something all the way through to production It's been through multiple reviews and someone goes oh though That word instead of there being spelled T. H. E. Y. Apostrophe re it should have been T. H. E. IR then You just create a new job and run it through the process again Like once it's got to prod that's it. It's life Yeah, and one other thing that we actually haven't talked about yet But that we're still in progress on with this solution is a way to Have dual environments running at every point so in theory We're obviously, you know, we're doing integration and preview and prod all on aquia But the idea is that we've got a we've got two prod environments a prod one and a prod two You're always deploying to the inactive Environment and then running smoke tests to make sure like yes This is good and then we'll flip the domain name using an API call so that now We're now pointing at the the inactive one that got the deployment is now active that gives you a chance to if that fails That gives you a chance to a stay on the active one that was still working or if you switch and there's a problem You can switch back and we're still determining like what the hard rollback period is for that like okay after 24 hours Then we're we're good But that also helps mitigate the risk a little bit For really complex deployments. Yeah, that's the standard blue green deployment model I think I need to like be more specific for example We do weekly releases and we gathered some features and let's say I have a feature with new content type So I push the changes in the code with new feature and also I push some demo content so people can review it and that's like one package that I go for and In the end of the week everyone was planning that yes, it's feature ready But last moment we found some bugs, but it's already there and we need to roll back that specific feature And we need to roll back also content related to that feature if in case of the code I can understand that that just changes. We just remove some code. How about the content? So this is solved by the job model because you no longer have the big weekly release with everything bundled up into A release each single thing gets deployed to the next environment when it's ready so You know that your feature which may it may be decided that it's not ready Then it just doesn't get propagated to the next environment Yeah, and that's also part of the advantage of having individual sandboxes for development So in theory, you know in theory we've laid it out where we want the business people to be approving do their final approval on Staging, but that doesn't mean that they're also not looking at your sandbox and making sure that a you've actually done what you know As a developer you've done what they're asking to do that you've created the content that you need to be created So we we still fully expect that there's some level of approvals and oversight going on in the development sandbox Where it can be isolated on its own and so hopefully if you've had it checked there Then you've checked it on integration. You've checked it on staging by that point staging You really want to catch anything, you know, and at that point if if you haven't caught it by the time you've gone to production Then that's where you roll another job and update it and fix it at that point or there You know roll back the code or you know, they're obviously there's some manual things If you're in an extreme emergency that you need to take something down that you can get into production and take something off And I'll publish some content or whatever. Yeah, it's designed to stop those. Oh my god moments with things And then one other thing I should mention too So one of the other things that we've been doing a lot with deploy is not just to deploy by default Always deploy to the default revision of a node or an entity So that doesn't really work in this model So if you've if you've used deploy where you've got a single content server And then you've got a single production server and you're keeping track of your revisions like on your on your content server And then you're just pushing the final up. That's okay But that's not the way we're doing it here is we're essentially at some point destroying that content staging server Because the dev sound box is at some point go away So what we're doing is they're actually pushing every single revision up through production So your production if you've created five revisions of a node on your sandbox all five of those revisions go up to production You see them all so if you're in an instance where I have to revert a piece of content back through your visions All those revisions are available to you on prod as well Another thing how big jobs are I mean some bug fixes can be pretty small and they should go fast Yeah, it can be like One character change can be a job or you can have a whole new section of a site It's it's really down to how you want to organize your work The smaller the job the faster it's going to go through So there's an incentive there to break things up into bite-sized chunks and just push them through Thank you very much Michael so yeah, I'm just trying to come to grips with the Con the moving moving content around we're doing Content delivery with node export so con con this the model that you just said this the staging site production site Content to code and then run it through the pipeline And then there's in Drupal 7 with you you ID is not really fully baked all the way through and so you have certain things of like Content type that has a taxonomy field multiple select and the taxonomy terms don't have you you ID by default I think and then you have how do you like as you move all right? No, that does actually work. So what happens is You you ID? Translates the you you IDs on the fly. So you've got a node with a taxonomy term reference when that Node is being deployed by the deploy module using web services. I'm not talking about the You ID features module. I don't advocate using that but when you export the Entity with Deploy it goes and has a look at what all the dependencies are for that particular entity and converts the dependencies IDs into you IDs and Picks all of that up and deploys it through in a coordinated way So it does it and then on the other end it grabs all the you you IDs of what's coming in and goes is this new or existing? If it's new it creates it if it's existing it updates it right this might be less the distance between node export and And deploy right because a node export does the same thing that you described except I think that you have to Kind of like help it along the way in certain areas Well, we've been doing a lot of work too on adding you ID support for different entities some stuff that aren't even really entities But just adding support so that you know, it's all done with the entity you ID like load or pre-save or save hooks So it's easy to define like a custom module and say I mean we did this for instance Yeah, for instance with web form. So web form is not something that you know It's not real entities like web form components aren't entities web form validation rules aren't entities But we needed a way a ton of the sites at Pfizer are built on web form So we needed a way to be able to deploy those successfully And so using the the pre-save hooks and the load hooks Where on the load happens on the source server. So at that point you're translating any hard-coded NIDs into the you ID and then on the flip side when you're saving it on the destination site You're translating it back to the new one on the destination server and that's not perfect And it was never intended to be perfect, but it does work And so you can take things that aren't actual Revisionable entities and still deploy them and have it work predictably So the whole system is kind of based on that And was never intended to be perfect So something like web form was never intended to be perfect because we really want people moving to like entity form For instance that supports. It's a revisionable entity out of the box So I mean that's actually a great segue to like some of the things that I think if you guys want to get involved One of the things that we're doing on Friday is we're going to try to have a WF sprint as part of the sprint We're have a table there and the other thing is you know this system and honestly like a lot of The SPS system as well if you guys are familiar with that these things really depend on like good solid Revisionable entities in contrib and so that's something that I think you know as we move forward as a community I think we all want to work towards Making everything worked that way The more the entities that work with UID and are revisionable the easier it's going to be to do this kind of stuff and also, you know, one of the things that we're working on is really just kind of like a a Safelist essentially of modules that we know work with this and obviously there's some that don't yet There's some that we're really interested in making work. There's other ones that you know It's just going to be really difficult to ever make it work seamlessly so without a whole bunch of you know rewriting So we're trying to put that list together We've got a list internally at Pfizer already that we're trying to use And we're going to publish that it's soon on the website So but but that's that's an area that we're all got to continually work on to make this stuff really seamless and also with Drupal 8 coming CMI is going to make configuration deployment a lot easier Having you UID baked into core is going to make things easier that and web services In core there's all this stuff that's going to make stuff so much better for this model in Drupal 8 But we want to still make Drupal 7 really solid So when it comes to rolling this out for Drupal 8 we understand where the pain points are and try to fix those The stuff that can't be fixed in 7 we want to fix for 8 so Awesome stuff. Thanks. Any more questions? Left your speechless great So that means you should all click the link here and go say really good stuff about us And if you hated our session Close your eyes. Don't look at that slide So if there's no more questions will wrap things up and Yeah, we're here for the rest of the week and as Tim said we're going to have a table at the code sprint just to You know roles and patches tests and patches and that's for the complete WF stack So you ID deploy WF tools itself So yeah come along and help make it better Thanks guys. Thanks