 So thank you everybody for coming. This is Drupal 8, Don't Be Late. We are going to talk a bit about a project that we've done in Drupal 8, some of the things that set the stage for it, a lot of talk about what it was, and a good deal of lessons we've learned, number 42, late. So yeah, let's get right into it. So we'll start with the obligatory, who are we? Evan, you wanna tell us a little bit about yourself? Sure. Hi, my name's Evan Lieben. I'm the Director of Digital Communications at Memorial Sloan Kettering Cancer Center. So as Frank alluded to, we've got this project in Drupal 8, and about 10 days ago we launched two websites, MSkcc.org and Sloan Kettering.edu. And we're gonna talk to you a little bit about those sites, some of the digital strategy behind that and sort of the reasons for why we pursued Drupal 8, and thank you all for being here. Hi, I'm Frank Fabrera. I'm the CTO and one of the founders of phase two. We worked with Evan and his team to build MSkcc.org in Sloan Kettering.edu. I was involved early on the sales and strategy around it, and helped to support our teams as they made their way through the murky waters. Hi, I'm Michael Adieu. I'm the Head of Strategic Accounts at phase two. I was involved in the MSk project in oversight and technical leadership and helped bring this project from concept to actual delivery. Well, so before we start, we think that the time has come to start considering Drupal 8, but before we really get into it, I wanted to just kind of do the show of hand things to see where people are. So how many people are actually using Drupal 8 right now? Small handle, there you go. One hand in the back. Yeah, small handful. So how many people are in production with Drupal 8 right now? Four hands, two of which are on the project that we were on. So who's currently running a Drupal 7 site in production or in development? Yeah, most people. What about Drupal 6? Drupal 5, there you go. Hey, there you go too. All right, Drupal, four point something. Four points, nobody. Okay, good, good, that's good. All right, so like I said, we think now is definitely the time to consider it. We're gonna go through a lot of the reasonings rationale behind that and kind of the decision points that might help you guide you through that process. So one quick more raise of hands of just folks who have the D6 site. Are you in the process of considering D7 versus D8? Sort of show your hands. Okay, great. So I just wanted to sort of take a step back and talk a little bit about content and how content has changed over time. When the internet first started, we didn't even have the World Wide Web, we had things like the Kermit Protocol and Gopher and then Tim Berners-Lee gave us the World Wide Web and from most of our experience, it was text and images and then came on the scene was multimedia and we have YouTube and now pretty much, I'm sure everybody has a Netflix account and listens to streaming music on Spotify and then we have web applications like Basecamp and Trello and Salesforce and now all of a sudden our contents become our social media streams where we're getting what our friends are doing, what are we doing and we're generating content, we're consuming content and then now we have devices. We have Fitbit and your content's being shared and you're competing with your friends on who can do the most steps. There are devices that you can plug into your car that will give you information about your fuel efficiency and how well your car is performing and even the thermostats in your house are content generators now and so you're consuming this type of content. So our definition of content over time has tremendously changed and so it's very important that you have a platform that's going to be able to grow with those changes and be able to adopt to that. So not only has the content itself on the web changed but how we're consuming this content has changed dramatically over time. Last year I think the broad consumption of web content online has shifted to primarily over mobile devices. If you have a property that's servicing younger demographics that change probably happened two or three years ago but that's a broad trend where people are not using PCs anymore to consume content primarily. They're using their mobile devices, their tablets. So that's changing. Over the top I was just thinking today I was doing a quick count of how many devices I have in my house that can stream Netflix to my television and I sort of lost count around 16 devices. So if you think about it, it's sort of just popped up. Now we have all these different devices that can stream video content over the internet into our television sets and over the top is sort of a big growth area that's just sort of popped up into our lives but it's really a unique way that we're consuming this content and it's a unique opportunity where cable companies are being disintermediated and it allows content creators to basically be their own television networks and it's a pretty exciting time for folks to do that but it's a change of how we're consuming our content and just to sort of give an idea now we have wearables. As somebody I was with the other day has an Apple Watch, Google Glass is another way that people are starting to consume content and as time has gone on it's really changed. I haven't, we have the mention of things coming up. I don't know how many people here have an Amazon Echo. Nobody? Okay, one person, wow. I have an Amazon Echo and I love it. Keep it in the kitchen and you can take voice commands but there's going to be much more of this as time goes on. We're going to see all these devices have capabilities to be able to pull things in from the internet and provide information and so how we're consuming content is really drastically changed over time and again with that change means we have to be there. Our platforms have to be able to provide content on these channels. Yeah, so trees address the, well I feel that Drew's addressed a lot of this in his keynote yesterday when he was talking about how the world's evolving and he sees it as going from pull to push. I mean basically what it all boils down to is that the experience around the content that we have and consume needs to change and is changing. We have to better serve our audiences. We want to be where they are and get the content there and it's not just content it's now content and context as well so what they're doing, when they're doing it content has to be relevant like he said get next best experience and from the side of phase two what we're seeing is that clients aren't building websites anymore they're basically building what amounts to content pipelines and various distribution channels for doing this. They're trying to centralize platforms but also maximize the reach of all the content that they have and this is driving a lot of the changes and Drupal 8 plays into this a lot. And the question that you have to ask is in your business these changes are happening around us and to the people who are in our audience regardless of whether or not you are changing to remain relevant for them so the question is could you be disrupted? And we need tool sets that are built for tackling these challenges. We feel that Drupal 8 is a tool set that is very uniquely positioned to help organizations address this. You know it has to be like I said earlier it has to be centralized you have to be able to manage it very well and if you are not getting your content to your users where they are and when they need it somebody else will and somebody else is probably already working towards doing that so it's important to start thinking ahead and understand how your business needs to shift and what support you need from the tool sets in order to do that. So we were having a discussion when we were working on this presentation and the whole idea was don't get left behind and when I went to Google and tried to search for an image this came up and it's hilarious on a lot of levels one of which is it only got 4% on Rotten Tomatoes but the description on Rotten Tomatoes was the best it said left behind hath begat a further scourge of devastation upon Nicholas Cage's once proud filmography and I think that's true but again ask that question is the same thing about to happen to your business and what can you do to prevent that? Are you becoming Nick Cage? Don't be Nick Cage. So again, Drupal 8 and the question is now the time to start using it and spoiler alert like we said before there are five people in here that are currently using Drupal 8 in production and I think that's great these people are early to the scene and they're doing a lot to help get Drupal 8 out to everybody else especially those who are evaluating it or are gonna have to redesign or rebuild a six or seven side in the next year or so so why is now the time to consider Drupal 8 and these are all just really good reasons why we think it's ready or it's able to be done it's already being used in production so we have people who have proven that they can take this code base which many might consider to be a little too unstable to use but obviously people have found a way to get stability there and to go live and it's a great challenge but it's totally possible. When I say the stack support for all the required components I mean things like integration with Varnish and Memcache or Redis and database layers and all of these things like that's all there it's all usable we did a lot of work to help get Memcache and Redis up to Snuff for Drupal 8 as well as other folks in the community and we've proven that all the standard stack components that you generally need to scale on the web today are also available in Drupal 8 and ready to be used. Less dependence on Contrib I'll let, I think it's Evan talk about this a little bit later but we're using a tiny fraction of Contrib modules that we've used previously Core does so much more and provides so many more facilities that you can write a little bit of custom code and that rid you of the need to have a collection of five Contrib modules to provide the 15% of functionality you actually need and then a bunch of custom code to hide the things that you don't. So Core takes you a much, much longer way and that's a really positive thing. So when I say fully recap the benefits of the platform lifecycle Drupal 8 isn't even released yet obviously but even when it is it still has a lot of runway many, many, many years. If you look at Drupal 7 it's been out since 2011 I believe like January 2011 and we're in 2015 now and it's gonna have support for years after Drupal 8's release. So there's a really long timeline to recoup your investment in Drupal 8. I mean just to sort of get an understanding of that Drupal 7 came out before HTML5 and CSS3 were a standard. So we've come a long way and Drupal 7's obviously come a long way as well but Drupal 8 really is the future. Yeah and that's why we say use a tool built for today's web in the future. I mean it supports the way that we build sites the way that we get content out there. Drupal 8 is built with support for that. It's some of its ideas were from a few years ago but it's been evolving and features still get into Core and things like that. So we're in a good spot with a good tool that's built and is designed to be flexible to allow for the flexibility that we didn't foresee with Drupal 7. It's now kind of built into Drupal 8 to allow the variation in the things for the way things change. And when I say become part of the solution the earlier you get in if you're in early enough you can still actually get features that might matter to your business into Core if they're relevant for Drupal as a platform itself. Once it's released it's gonna be a lot harder to actually get features in there. You can get bug fixes but maybe not get features. And another thing if you get in early think about how much talk there is this year about Drupal 8 and how few people when we raise our hands are actually using it. People are hearing a lot about it and they want to work on it they just don't have the opportunity. So if you're there doing things with Drupal 8 you can attract the talent that you want to come work on Drupal 8 and push it forward. It serves both you and them and that's a great thing. And also Drupal 8 does things more in line with what the broader PHP community does. And so as we're struggling to keep up with Dynvand with the Drupal resources we have by doing things more in line with the broader PHP community there's an opportunity there to bring in people who primarily work on Symfony or Laravel or some of these other platforms and bring them into the Drupal community so that they can help contribute into that space. So I want to share with you a little bit about why we decided to take on Drupal 8. We've been getting a lot of questions about that since we arrived here. A lot of like, are you crazy? What are you doing? Why did you do that? But there's one interesting thing about that is when we set out to do this in April of 2014 but we started with phase two then but there was actually an effort prior to that back in probably a year before April 2013 where our lead developer Jacob Rockowitz who came into our office and we were talking a little bit about the future of our website and that time we were in Drupal 6 and he came up with this phrase, D8, don't be late. And it's kind of been like our sort of what we've been rallying around for the past couple of years. And so that really drove us to get focused and start thinking about Drupal 8. And so it's actually a lot more than that and like I said that kind of got things started. So just real quickly about MSK, we are a cancer hospital. We're located in New York City. We have one single focus and that's conquering cancer. It's all we do. And so if you think about, so at MSK we have this culture of innovation and we're really inspired by the researchers and clinicians at MSK that do their work and they regularly push boundaries to generate new knowledge and they continually develop new methods. And that's really interesting to us because my group sits in the communications department and we're just, all of our colleagues are always talking about what this researcher did, what that clinician did and they always have these breakthroughs and advances and it's like, well, maybe we can do that too. Maybe we can push the limits. And what they do is about making a difference. It's about changing people's lives and for them it's changing the way the world treats cancer. And we're inspired by that relentless effort and we're driven to do the same in our space. So if you think about what is being done at MSK, you wanna be able to push the boundaries yourself. And some lessons learned from our colleagues at MSK about innovation. You may not know where it's going and you may not know if it'll work but you have to try and you have to push that really far and you have to push it as far as you can. And that's what innovation's all about. So at MSK it's more about a collaborative focus and you could refer to it as a community focus. There's multi-center studies for clinical trials that span different institutions and so when I'm being treated with in New York City, you may be being treated with in Los Angeles and so we take that data and we put it together and we try to find new ideas, new ways to push progress on delivery of care and treatments. And so one thing that Dries talked about on Tuesday was sort of like how we come together and not on our own to develop new ways to do things. And so like things started to connect here. Like we took a look at our focus, our strategies and we said, well, how does this relate to Drupal and to the community? And we asked this question, like why is community so important? And we're all trying to solve similar problems so we can leverage our work, we can leverage other people's work and we can allow bigger problems to be solved. And in the community whether it's patient care, research, education, Drupal, it helps to drive innovation and there were just so many strong and compelling parallels here for what we're doing at MSK to the Drupal community. And one thing Dries talked about caretakers and freeriders and it's the caretakers who really helped to drive innovation. So we thought, this is great, we wanna be in this space, this is what we wanna do when we wanna push this forward. So I mean that's great, that really focuses on innovation and generation and new knowledge but that wasn't quite enough for us. We said we need to think a little bit more about the strategic priorities at MSK and all the things that we do and all the things that we think about. And so it's patient experience, it's access, it's talent recruitment and it's financial sustainability. And so as we examined that and pushed toward Drupal 8, we realized that all of these actually line up with what's happening in Drupal 8. So if you think about patient experience and access, Mike talked about this earlier, being able to serve personalized experiences by pushing content to users that we know they want and so we don't have authentication on our Drupal 8 sites right now, but we may one day. And so that was really about choosing a platform that would power us to do that. Talked a little bit, I won't repeat myself here but just being in D8 on the cutting edge of technology and everything I said about innovation and generation of new knowledge was really exciting to us. Talent recruitment, this was a big one for me. When we assessed Drupal 8, I thought, Drupal 8 can really has an opportunity to broaden the talent pool and the reason for me was with the use of symphony and object-oriented programming, I felt that there's developers who probably scoff at Drupal and say, well, I do symphony and object-oriented programming, I'm not even thinking about Drupal, it's not on my radar. So they're not here today and they'll learn about it soon and they're gonna come in here and they're gonna start working with us and pushing this forward. And I thought that was really exciting. Financial sustainability, when we knew that we were doing a redesign, well, actually every project that we've done, every update that we've done at MSK to our CMS has always been coupled with a redesign. So we felt that back in April, 2014, if we're gonna do a redesign, well, we don't wanna do it in Drupal 7 and then launch in April of 2015 and start thinking about Drupal 8. We need to be financial stewards and we need to watch what we spend and it didn't make sense to us. We felt like there was more value in funding a core contributor who's Jonathan Hedstrom at Phase 2 to help push this project along for us rather than spending all the money on a redesign, just strategy and design, spending all the money to migrate to Drupal 7 and then having to do it all over again. It didn't really work for us. So the adventure begun and we successfully launched two sites about 10 days ago. We saw an opportunity and we seized it. So a little bit about this site. I mean, this is not a brochure site. This isn't your blog. It's not your company website. This is a major Drupal 8 enterprise site. We went from 114 contrib modules to nine using Drupal 8. We serve seven personas. We have related content, faceted search and a list of endless prediction tools, multi-server cluster, data aggregation, LDAP, data synchronization to apps. It's a pretty big site. So Drupal 8's flexibility really helped to simplify problems for us. We can centralize logic into services, override controllers without hacking core. We created YAML forms. There was no web forms. There's still no web forms available for Drupal 8. So we created web forms using YAML. No panels, so we used HTML template expansion. And there were many D8 module upgrades that only took us a few days of work. And a couple of examples, Redis, Memcache, and NodeOrder. So what else did we gain from Drupal 8? And I think if you ask everybody, Jake and Toby, who are here today, and Jonathan or Brad and Reed or Mike, they're gonna have different answers. But for me, what I saw, which was so amazing, was the developer velocity. And once they got past that learning curve, we were able to fly. And so this project, I said, it began in April of 2014. We did not get the designs. We didn't start the design process until September. And so this was a really, really rapid process. And I think Toby and I were chatting this morning and he said it took about three weeks total of the project. And it was probably one to two weeks in the beginning. And then over the next month or two was probably another one to two weeks. Just to get down the way things are being done in Drupal 8, and architecturally it's different, but many concepts are still there from previous versions. So it wasn't too big of a lift. And finally, on this slide, MSK was able to participate in making Drupal 8 better. And that's going back to Jonathan Headstrom and the work that he did to push forward Core. So yeah, there were lots of surprises. Core features weren't as done as people believed them to be. And one example is the views couldn't filter by date range. Pick a date, but not a range. And I think actually the biggest surprise here, and I won't read through all of these, is that there wasn't a release by now, or by the time we started. So I think that to us, having been so much talk about Drupal 8 over the past few years, when we set out to do this, it wasn't there and ready for us. So that was probably the biggest surprise. And so some trade-offs we made with Drupal 8. There weren't many contrib modules, lack of best practices and practical knowledge. And we did a session yesterday and Brad Wade was talking about something that he needed to do. And he went to Google to go find the answer and he couldn't find any answers. So I mean, that really hurt us a little bit. But historically, Drupal is very well known for their documentation. And we trust it'll all be there, but it's kind of the trade-off that you make when you go through this project. You realize that you're gonna have to lead the way a little bit, find out things on your own. All right, cool. So let's get into a little bit, thanks, you talked a bit about the lessons learned and things that kind of surprised us and didn't. We wanted to break down kind of the lessons learned a little bit more so that we could go through them. I'm not even sure I'm gonna be having about 20. Yeah. So 20 or so lessons learned and I'm sure that we're missing some of them and the team could probably fill in on many more. So heck of us if we miss a couple here. So yeah, I mean, so we broke it down into sections. This first one we were gonna talk a little bit about managing kind of core and contrived like the code-based stuff and how that all shook out. So what we found to be invaluable is dedicating a person to core. It probably sounds obvious or simple or whatever, but we had Jonathan Hedstrom basically focused on core and he was basically he was clearing ground. Anytime an issue came up, a bug or whatever, they could throw it to him and he could research it, he could find patches, he could re-roll patches, he could create them and then he could also shepherd them to make sure they actually got into Drupal 8. So as of yesterday, directly from this project, there were 57 patches that were contributed and then committed to Drupal Core. Beyond that, there were hundreds of issues that he'd worked on, just either marking them re-roll or working through needs review. He said that the oldest issues that he came across that were in needs review were four years old. So that means that somebody made the effort to create a patch for Drupal 8, put it in the queue, marked it needs review and it sat there for four years before anybody even looked at it. So he went through and he basically created a list of the needs review when he started at the oldest one. It was four years old and by the time he was done about maybe a month or so later, he had that down to about four months. So things are now sitting at most four to six months in the queue. And yeah, sometimes you have to code and work around bugs in Core too and he was able to help with strategies around that and just generally be a wealth of knowledge for the team that was actually trying to get all of this hard work done. So that was really key. Schedule for regular upgrades to Core. Obviously there's betas that get rolled and things like that and it's important to not get too far behind. So you have to plan to regularly migrate between releases and the thing that made it a huge challenge is that there are no, there's no migration path currently from beta, from one beta to another. We obviated a lot of that we got rid of that because Jake actually wrote a decent module that would allow us to just take the content from the Drupal 6 site and just re-import it. So a really good migration process kind of helped us around the fact that there was not a good internal beta-to-beta migration process. Yeah and the thing is don't let your, don't wait too long because every day there's more commits to Core so every day your active stable code base is accumulating debt from the currently moving ahead head. So stay as up to date as possible and then realize that at some point you're gonna have to say we're not upgrading because we have to release in the next couple of weeks or a month or whatever. And I think right now, am I correct? They're on beta seven? Beta seven, yeah. Which beta eight and nine are basically the same thing so and there's beta 10 now. So two versions back and that'll get knocked out. Right and there's a decision to be made about waiting for the beta-to-beta migration path or release candidate or jump on the next beta. Yep. So one of the lessons that we learned in the early planning on this, we did an analysis of the contrib space in D8 and some of the early planning was do we wait for contrib to catch up and hope that it catches up to when we need it or do we not and we learned very early on don't wait on contrib. You just can't. I mean, to give a good example, features which is a phase two managed module wasn't ready so even our own modules weren't ready so you have to be able to account for either jumping in and help pushing it along like we did with some of the stack components like Memcache and Redis and LDAP or coming up with novel solutions to get around the fact that these pieces of functionality are not available in the contrib space for you. But the good news is because so much is in core, your necessity to depend on contrib is much lessened and as Evan said earlier, the D6 site was 114 modules and the D8 site has nine modules and honestly out of those nine modules maybe three or four of them are actually necessary for the functionality of the site. I mean, that's just a huge differentiation between the way things were done in previous versions of Drupal versus D8. Yeah, so when you think about, I don't know how many were here for the Drupal set, the six to seven upgrade, but seven launched in January, I think there wasn't a lot there and we were writing a lot of custom things over again and it wasn't until views actually got upgraded which was about six months later that the rest of contrib followed by. So it was nine to 12 months before Drupal set after Drupal seven's initial release that it was actually usable by most people and that timeline almost doesn't exist right now because you can start using most things right away. And just to kind of clarify, features actually does have an alpha release now. There was I think a session on it yesterday and you still need it for certain use cases. Yeah, absolutely. So the next section is we're gonna talk about just addressing some of the risks inherent in working with alpha slash beta software since this project started before the, I think was the D8 beta? Oh, it started before alpha. Alpha three, okay, so. Thank you. It started very early. So one of the things that it was interesting as early on is, and this is something that Jake did to really start to get sort of momentum on this project and something he talked about yesterday in the other session and it's available online. We'll have links at the end is using prototyping to mitigate risk and really what he did was he focused on getting some content out of the D6 site, getting it into the D8 site, getting that content to render. Don't worry about the theming. Don't worry about all that stuff. Just martik is fine and just get that prototype working and then work on that prototype to prove that it's possible. And from there, he used that to garner consensus to continue to move in this direction and get us towards a D8 launch. Yeah, I also add that all of us are accountable for what we do and our jobs. And so to show that this could be done in a prototype was a big deal in MSK because it just gave us the strength to keep moving forward and it got tremendous buy-in within our department just to be able to show it that this is working and we can do it. And so some of the engineering, the interesting engineering aspects of this project was in the migration process and YAML was extensively used a lot in that, but I think one of the points that Jake made earlier is, especially even earlier on, is just doing SQL bulk inserting from one to the other, maybe doing some mapping as the tables, layout change. That's completely valid early on to prototype what you're doing. So really prototype to make sure that you can mitigate the risks that are inherent in working in this type of software. Yeah, so obviously the next one seems super obvious account for the learning curve. We found it was totally true that while it took everybody a while to get up to how things are done in Drupal 8, they certainly made up the time later with how fast they were actually able to get things accomplished. So when you're planning a project on Drupal 8, expect the first few sprints to go a lot slower than you anticipate and then if the team does the right job and picks up the best practices and figures things out, expect their velocity to increase as the project goes on. The way that Drupal 8 is built, OO, services, symphony, things like that, it allows you to do a lot more with a lot less code. You can extend core classes, just override methods. Even just creating modules, there's so much less boilerplate that you have to write, which means there's less things to go wrong, less bugs to track down when there's less boilerplate code that you make and it just overall increases the velocity there. It also lessens the surface area of what you have to test. So if you're taking an object and extending it, you can test that extension and not have to test the whole module. One of the other things here is sometimes you have to unlearn the way things work in six and seven and not make the assumption that they work the same way in eight. One interesting conversation within this project as we were talking about setting up Memcache and talking about how traditional D6 and D7 setting, each node knows about each other's nodes Memcache to be able to clear the cache. Well, in D8 it doesn't necessarily work that way. You can do cache invalidation in the backend and the database, and that was something that was sort of Jonathan Hedgstrom brought up to Toby and I and something we just didn't know about. And so sometimes you have to, even something as simple as setting up Memcache is different in D8. So the approaches are different. You have to learn the different approaches for the new technology. A big one here, which isn't obvious and wasn't as, don't assume that you'll know what will go well just because people talk a lot about things and how mature they are or how long they've been around. It doesn't mean that they're gonna work for your needs. What Evan mentioned earlier, date module's in core, views module is in core and that was all great, but they weren't working together. And you would just normally expect that they were probably working together if they were both in there. So these are things that you just have to account for. So it's just really important to kind of have plan B's and C's and don't just blindly go ahead saying, I know that these things are gonna work, just know what you're gonna do if they don't. And over time, you'll kind of figure out what will work and what won't and you'll have much better confidence in knowing that you can tackle the challenges that appear. I mean, and one thing that we learned in this project is even something like the stack of what version of PHP, what version of a Memcache that works completely well in D6 and D7, we had problems in D8. And so you have to be cognizant of the fact that just the stack alone, something that you might take for granted on other builds, you have to be able to assume that that could not necessarily work in D8, you might have to make changes to your stack. And that was a lesson we had to learn. Yeah, I mean, Memcache and PHP 5.4 were having seg faults and couldn't figure out what was going on and an upgrade to 5.5 and they just magically disappeared. But there were a lot of steps between that and making the decision to go to 5.5. It was not a finger snap. Yes, it wasn't not a finger snap. So we spent a lot of time trying to make it work in 5.4 but being flexible and being able to even change something in your stack like your PHP version can really help alleviate some of those issues. Next section we kind of call pulling it all together because it's a lot about teams and collaboration and every build, while there's lots of code powering it, there's also lots of people involved. So one of the interesting things about this project, if it wasn't sort of complicated enough trying to launch a site on alpha software slash beta software, was that the way that the front end was done is there was actually, I would say three distinct teams on this project. There was the MSK team that includes Jake and Evan and some other folks. There was the phase two development team but then also working on the front end side and doing some content strategy work was Digitas and the way that the front end was designed was that it was built as a standalone prototype and from that standalone prototype that was used to get basically buy in or consensus or basically being able to validate those designs are good for the client. And from there, that was throughout a build process migrated and brought into the Drupal 8 site. And so some of the things that really helped there was twig. It's extremely powerful and it really helped out a lot in helping build out the front end, especially when there weren't a lot of layout options to be able to lay out pages in Drupal 8. There was no panels at the time and there still probably isn't panels right now. Plans. Yeah. One of the things that we really, we did do is take advantage of some of the newer front end JavaScript tool sets such as Grunt. We used Grunt tremendously throughout this project. We used Bower to manage front end dependencies and SAS and a bunch of other JavaScript tools. And if you watched the other session that was earlier there's a lot larger discussion about the tooling in the front end. And so one of the interesting problems that we had out of that project was that there were these front end components and I won't sort of get too deep into it but the solution to be able to do some of these layouts is the solution to be able to actually take these very rich HTML components and put them even in the body of the content which is a difficult problem to do when you have production people putting this content together was that Jake built this sort of service object that allows it to take in simplified HTML that production people can put in there with a specific targeted class and then expand that out on rendering to a much more complicated HTML layout. And in the database the simplified HTML stayed in there. The production people can manage the very simplified HTML but when it's expanded you can get super rich things like this call out here where that's actually in the body of the content. And there's a number of different components in there that give the editorial team tremendous flexibility and having you can talk a little bit about it. Yeah, so we have a lot of news on the site and just, you know, there's 25 to 30,000 nodes and so there's just a lot of content and, you know, for the ability for a web producer or a writer or an editor to go into the site and just put in some really simple HTML and it renders this, you know. So that approach really helped us to, you know, to speed things up in the production process and it also shows that you can have like very non-technical people going in here and into the editor and just dropping in this very simple HTML and rendering, you know. Yeah, I mean, if you could speak a little bit about sort of the initial estimates of what it would take for the tile template pages. Yeah, so we have, you know, one of our, one of the templates, about, you know, like eight to 10 templates on the new sites and one of the templates is a tile template and so we were, you know, we were up against time and the time was really tight for this project and so it was about mid-March and we had approved designs for this tile template and planning to launch in April. And so, you know, Brad and, you know, other folks at phase two leading the front-end integration looked at this and said, well, it's gonna take us about 20 days to integrate the, you know, five to six variations of those tile templates and so through, you know, through this API we were able to knock that down to about three days and so it just, you know, it really helped accelerate the project and push it forward and get us to launch. And the nice thing about that system is it's extensible, it uses twig templates under the covers and so it's extremely maintainable as well. So with that, I mean, I talked a little bit about sort of how there were different teams on this project and so it's really important to actually have the teams very cohesive and have the collaboration very tight. Again, one of the unique prospects of this project was that there was this front-end team that was out there building these prototypes and then there was a front-end integration team that was taking those, having an automated build process that builds the front-end prototype, pulls some of the assets over into the Drupal build and so what that means is there's a lot of coordination that has to happen between those teams and what we've learned when you have something like that is that sometimes you can leverage twig and you can take the sort of perfect HTML given in the prototype and you can do that kind of 90% of the time. But 10% of the time it's easier to just take the Drupal default of a view or whatnot and give that to the other team and say, can you please use this as the basis? And that was a good lesson learned that sometimes there's a give and take between team coordination and sometimes it's fine and Drupal's very malleable and sometimes it's easier to not fight Drupal and to just say use Drupal's defaults as the starting point and that helped us out a lot to get over a bunch of things that would be difficult otherwise to accomplish. Yeah, another lesson is when you're transitioning across a code base that is in active development and we mean the entire code base there's a really big chance for regressions as you move forward and every time we would upgrade there would be lots of things that would break and one of the very smart things that the team did is they built a large suite of tests to basically identify what was breaking when you would go. There was something like 50 plus test suites that would run and you'd upgrade core underneath the code base and you'd run the test and basically they would all break and then you at least had indicators of where to go. Look, you see why each test breaks and you determine is it an API change, is it a data change? Where did everything fall apart? But we can't overstate how important it is to have comprehensive tests to really exercise the code base to know where things break because being able to find them, like if you're just relying on meat space and you do a new build and people just start clicking on your site and following links and submitting forms you're never gonna find all of it and it's gonna take days and days and days. So automating that through PHP unit and Behat and other things like that really go a long way for you. And PHP unit in Drupal 8 allows for much easier testing. You could mock things if you need to so you don't have to test the entire code base. And like Michael said earlier, it's a lot easier when you're just overriding something on an object. You get the test that comes with it and then your override just has to test the thing that you've changed. You don't have to write a test for the entire component all over again. So you get a lot more, you get like a force multiplier there. And just one of the sort of long-term great benefits of the way that Drupal 8 is structured is because there's this dependency injection container testing something like an email service has the ability to pull up that live service object and replace it with a mock object so that you're not actually generating emails when you're trying to do tests. So there's a lot of opportunity within Drupal 8 to really expand test coverage and to do a lot more with testing that would be a little bit more difficult to do in six and seven if not almost impossible. So we used a lot of, there was a lot of build in this project and there was a lot of migration in this project. And so one thing we learned very early on is to automate as much as you possibly can and do it as soon as possible. You want to maintain the automation as opposed to have to hand do things because especially when things break you're gonna be doing it over and over again. So automation is key there. And in this project we used a combination of Drush but we actually used grunt quite a bit in a bunch of the different processes. And it's actually a really good tool and works really well with Drupal to do a number of different things within the build process. There was actually a session on grunt Drupal tasks that you can go see, I think it was from yesterday. And so one of the unique things again about the fact that there was this front end prototype and then there was this Drupal build repository was that we had a build process that would go and build that prototype project and then take and move things from that build into the Drupal build. And so that was all automated. So there was a lot of complexity in there and grunt was really up to the task along with Drush to be able to do things like that. And then that allows you to, as you're launching those into different environments you can manage that through sort of a Jenkins process and be able to really automate a lot of this stuff. Yeah, so we talked about automating things and managing your dependencies really goes a long way towards enabling automation. So like you said, Drushmake is used to build the Drupal site. It actually now has YAML support for make files although that wasn't used here. NPM is used to manage the dependencies for grunt. Bower was used to manage dependencies for the front end and then grunt was actually used as that tool to materialize the site and to build the front end to kind of manage the whole packaging process. So YAML has gotten us around a lot of different potential potholes in this project. And so one of the big key pieces of functionality as we were starting to build out the site was there's no web form module. And the MSK site has a tremendous amount of web forms. I don't even know how many forms we need. 200? 200. So there's about 200 web forms on the site and we didn't have a way to actually build web forms. There's a form API but there was no real way to actually design and build those. And so Jake built a module called YAML Forms which allows production people or developers or anybody to define a YAML document that defines what that web form should be composed of and that it takes that YAML configuration and then generates the underlying web form. And what that allowed is that the lift to allow the team to be able to build these web forms was much lower without having to actually build a big GUI or basically rebuild the entire web form module from D7 to D8. And so that got around a very, very big challenge of how do we provide this functionality to the site without having to take on a tremendous lift. And one thing we did find out is that non-coders can use YAML. And with a little bit of training, it's pretty simple and pretty dependable and maintainable for folks to use. So it's an interesting way to provide an interface for folks to be able to configure a system and to create content. It's also used quite a bit in data migration and serialization and one of the interesting things that was done on the project is on the D6 site. The YAML Symphony component was installed on the D6 site so that it could export out content and data into YAML format for the D8 site to be able to ingest. And when this project started there wasn't, the migrate API wasn't there, there's no migrate module, and so YAML was a very good sort of lingua franca to be able to get the data and the content into a format that's easily digestible and easily generatable for the system. And so that's definitely an option in the content migration part and ways to get data out of your D6 and that D7 site is to install that Symphony component and start to use that in order to output YAML data to be able to be ingested into D8. Yeah, and another really big lesson learned is that you shouldn't treat your migration as a second class citizen. So a lot of times it's easy to say, well, we're just going to use this migration once. So let's just throw it together quickly so that we can get some content from one site to another and we're going to throw it away. We won't need it after launch. And while it's true that you might not need it after launch, developing on Drupal 8, there's things changing all the time. So you're constantly having to upgrade and modify your migration scripts as core changes as well. So spending some time and having a really good, solid, bulletproof migration process that you can work with over time to modify as core changes and as your site changes and being able to do constant migrations and blow things away and re-migrate them. I mean, that's just, that's key. And it was really useful to both help validate content coming in, but also validate that the structures of the data were correct and things like that. And the migration part of this project was really unique and I would definitely recommend checking out the other session. That's the link is at the end of this presentation. But one of the interesting things with how the migration was approached was that the migration happened continuously throughout the project. And what that allowed for is that there wasn't the sort of editorial blackout period or this double entry period. And in some ways, it's super unique in the fact that even things like IA changes would happen on the D6 site and the migration process would begin into the D8 site. So some of the actual active development that happened on D6 and got pulled into D8 through the migration process. And that's certainly a unique facet of this project and the approach to get this done. Yep, no site would be complete without environments and places in which to run. So we'll touch on a couple of those. So make it really easy for developers to get set up. If you don't have something that's bulletproof, things can be obviously really fragile between different people's computers or environments and things could break. And you spend a lot of time trying to get that all in sync and you're up against a big enough challenge anyway working with Drupal 8 and making sure that you make progress there. So don't waste time on development environments. Get something set up early, make it consistent, and go with that. And try to keep it as simple as possible. I mean, some of the challenges we had is having the VMs be able to connect to VPN, having this long build process and getting that set up on everybody's machine just took a lot of time. And so certainly you want to simplify it so to get your developers productive early. Sure. Don't neglect your server environments. I would say try to get your servers up as early as possible. We sort of got them up more towards the end of the project and I wouldn't advise that. Server environments are a tricky thing. And even between sort of dev stage and production, things can change. And even if they're built on images and using Puppet or Ansible or something, they still have unique little differences. And so those types of bugs with environmental issues and environmental configuration are really hard to track down. So try to get your environments up as early in the project that you possibly can and start getting those builds done on those so that you can ferret out those issues and not have to deal with it right prior to launch. Yeah, and that leads into how small differences can cause serious issues. Close enough doesn't really work. If you really want to have consistency between your environments, they should be running all the same components of the stack. They should be running them on the same versions. Ideally they will be running in the same configuration. So if you have your database on another server, you want at least one environment before your production environment that has database on another server. So you need to get that set up and tested and be able to deploy to those things as soon as you can and minimize the variation between them. And then even little things, like on the same servers, if you're hitting it with a pre-production URL and when you cut over to your production URL, there can be issues, so have ways of testing those things. One thing that we learned is that load tests, they're great and they're great indicators of your environment and how it's going to stand up, but it is not a guarantee that even if your site does well under load testing, that under production traffic, it's going to be the same. It's just not the same thing. And so even if we even took production traffic logs and used those as the basis for the load test and still under production load, things change, things are different, and so just realize that load testing isn't a guarantee of anything. And one other thing, even when you're launching, what you perceive as a low traffic time, sometimes it's great, but sometimes as we learned, as we launched, a large university had a pretty aggressive spider that I guess was turned on roughly around the time when we were relaunched and started to aggressively start to index the site at, you know, and I think it generated 96,000 page views within less than an hour. So even when you think you're launching at a time that you have low traffic, prepare because you never know if somebody's gonna have a spider starting to index your site pretty aggressively. Yeah, so how can you get started? We have just a couple of considerations for when you're trying to decide should you go droop later or not. I think that it's really important that you pick the candidates carefully, like which project you might do or which site or something. I mean, you have to have a little bit of tolerance for risk, you know, things can go wrong and your stakeholders and your team, they have to be kind of ready to deal with that. So if you have a fragile team or really, something's under immense scrutiny, you might wanna reconsider or just see what you can do to mitigate some of that risk. No short timelines. I mean, it's hard to predict. Like we said, don't make assumptions about what'll go right or go wrong, but you know, it's hard to predict what'll happen. So if you have a really tight timeline and really hard pressure there again, it might not be the best choice. Have the right team. I mean, this would not have been possible at all if we didn't have the team that we had with the expertise they had with the support that they had from the organizations. You know, having, you know, even though Drupal 8 is vastly different, knowing Drupal is very important. So having that experience, knowing, you know, knowing the differences, it's really important. You have to have quick learners and problem solvers. You know, you have to have people who can, you know, do profiling to spot performance problems. You have to have people that are like empathetic and really good at working with each other. You know, things can get really stressful and it's important that, you know, you have people that come together and are on the same team. If you have a highly dysfunctional team, I don't recommend, you know, working on unstable software to try to go into production. It seems really obvious, but you know, it's something to keep in mind. And, you know, get really involved in the community and make connections. And this is a great conference to do all of that because you'll need people's help, whether it's to review patches to help get them committed to core or if you're just banging your head on something, being able to jump into IRC and reach out to someone you might know, I mean, you can even reach out to people you don't know, but, you know, just to be able to ask for help from people that know more is just really important. So, you know, the outreach effort is really important there to kind of bring, you know, not only the support of your team for each other, but also, you know, having the community support you in your site as well. So this is some additional information around this project and the link for the Adventures in Drupal is the other site that gets a little bit more into the tech details. But here are some links to additional information about the site and about the project. We don't have a ton of time, maybe a minute or two, but if there are any questions. Gonna come up to Mike, thanks. Hey, Don. This question is more for Evan and it's not meant to answer the actual question, but it's more about how you were setting the expectations above you. What was the contingency plan or what is the contingency plan since DA is still not released in terms of a breaking change that might get into DA at this point? Sort of like a fallback? If they were to pull out views all of us, I mean, that's not gonna happen, but if there was something that was not easily recoverable, you'd be stuck where you are. Yeah, I mean, I think we're pretty comfortable where we are in Beta 7 and we feel like we're pretty stable. You know, we'll be looking for the upgrade path to see if we can continue to move forward with Drupal, but I mean, I don't think there's no contingency plan to fall back on anything. We feel pretty comfortable with where we are now. And again, one of the benefits of being in early is that you have a little bit more say to help try to guide Drupal to where you wanna be. So if the potential for something like views to get pulled out of Drupal 8, you have that opportunity to at least weigh in before that decision is finalized where? Yeah, my real question is more about setting the expectations above you. For people who aren't, they're not necessarily in the weeds on this. They don't necessarily get the nuances of it. I mean, we could all sit around and kind of talk about what we do. Okay, so the process that we went through to push forward in Drupal 8 was really transparent at MSK. And there was large collaboration just on the MSK side with team members outside of our department and a large learning process for what we're doing. So we've been very open about the risk of Drupal 8 since the start, because we didn't just talk about this earlier as far as you don't know where things are gonna go and you don't know how things are gonna work out, but you just gotta keep pushing. And so we continue to push that forward, knowing fully that there could be some major issues, but as I said, we were very transparent about that. Thanks. Cool, so thanks, everybody. We have to actually stop right now because there's a panel coming up here, but we can answer some questions off on the side or something, so thanks, everyone. Thank you. Drupal 6 or 7? Drupal 6, yeah. So what was your team's side? We had, well, there's like the...