 So, hello everybody. I was lunch today. I haven't had mine yet. My name is Robert Douglas. I'm with the company Platform.sh. That's actually a product that's built by the commerce guys. And I want to talk to you today about an aspirational philosophy that I'm developing for deploying web applications. And it's called OCD deployment. Because if you spend a lot of time in your life building something big and important, when you actually want to launch that something, be it a website or something more tangible, it's fairly important that you know what the outcome of that's going to be before you put yourself in the launch position. So, when I speak of a web application, I mean three things. I mean, first of all, code. And we're very familiar with code being at a Drupal conference. Probably some coders in the room. We know that you have to deploy your code to deploy your web application, but actually code doesn't do anything on its own. It also needs infrastructure. And the infrastructure that is used to run not only Drupal but web applications in general has become more and more complex over the years as we've added specialized caching servers and services, specialized search servers, data analysis servers, analytics stuff. Maybe you've got streaming servers, transcoding servers. Depending on the nature of your application, there can be quite a lot of infrastructure. Also, given the global nature of many websites with distributed caches around the world. Yeah. And of course there's data. If your application doesn't have data in the form of a database, uploaded files that represent images or documents that have been uploaded to the application, or the derivative data is like the solar index or the search indexes that are generated to work with that data. If you don't have that data and you don't have the infrastructure, then your code is useless. So when I speak about a web application, I'm actually talking about the trifecta of code infrastructure and data. And if you don't have all three of those in one specific state that is known to work, then you actually have an unholy mess of a broken application. You have the movie before. So deployment also means the moving of those things, code data and infrastructure between local environment, dev, stage, prod. And we're all familiar with these concepts of moving the application through some stages to get it on its way towards deployment. But in reality it's not dev, stage, prod. It's more like this, right? And depending on how many developers you have, that becomes exponentially more complicated. So given all the variables and factors that are involved with, you know, making sure that your code, data and infrastructure are in the right place, I want to make sure and help you not become threatened at the existential level when you do your deployment. So what does OCD stand for? It stands for orchestrated, consistent and deterministic. And remember this is an aspirational idea for how your deployments should go in an ideal world. I'm going to use examples from my product, platform.sh, but I'm not going to claim that we solve all of the problems that I put forward. This is more of a framework for you to use when you think about deployment and think about your build versus buy decisions, whether you're going to do Ansible Docker local or you're going to look for a company that helps you with that. And when you evaluate what that company actually offers, do they get you to OCD deployment? So orchestrated means, in the dictionary, planned to produce a desired effect. In the world of web applications, orchestrated means provisioning servers, provisioning storage and network, launching and configuring services on those servers, deploying code and data, and monitoring maintenance, change management along the way after you've got everything set up and doing that across many environments, as we saw before, because you just don't have a production environment, you have dev staging prod and all the permutations thereof. Orchestrated also means, in the case of Drupal, if you want high availability websites, which are a must these days for any business critical application, then you need things like HA Proxy, Nginx, PHP, FPM, MariaDB, Postgres in a cluster configuration, Elasticsearch with triple redundant nodes, Redis, Memcache for caching. And as you see from the alphabet soup and the number of services there, even before you get into esoteric stuff like MongoDB or an OJS, or heaven forbid, you're trying something really cool, like PostgresQL, then orchestrating this really becomes a big challenge. So here's the first example from platform.sh. On your road to orchestrated and consistent and determined and stick deployment, platform.sh gives you as a developer to specify the services that you need running in your application in a very easy to read YAML file which is familiar to anybody who's working on Drupal 8 to begin with. And you say you want MySQL, you say you want Redis, you say you want Elasticsearch or MongoDB or Postgres, and you say how much storage that needs and then you push that to get and voila, you have all of the orchestration with all of those concerns, storage, network IO, backups, recovery, everything taken care of, and you have that at a per environment level. So for your Git branch, and only your Git branch at that moment, you've got MongoDB and nobody else does, but when you merge that into another branch, then that branch will also have MongoDB. So that's the orchestrated part. Orchestrated also means setting up things like mount points or cron or backup schedules, guess what, those are just YAML files as well. So moving the orchestration, the control of orchestration to the version control level, so something that you can store into Git and something that your developers, without being cis admins, can actually influence with just a couple of lines of code is the aspirational goal that Platform.sh provides in terms of orchestrated, deterministic and consistent deployment. You have a wide menu of services that you can choose from, wider than any other offer that you can find at this conference at least. And we deploy onto a number of clouds. Our home base is AWS, but if you have clients who have a lot of Azure credits to burn through, then we can deploy there as well. So consistent, acting or done in the same way over time. So this is how you deploy. When you want to deploy to your local development environment or your staging or testing environment, how do you do it? Well, the world is showing us as it consolidates through many technologies and many different industries that the most consistent way to deploy anything these days is through Git push. If you try OpenShift, you get push. If you try Platform.sh, it's the same thing. Deployment is simply Git pushing whatever you've done in your repository to whatever environment you're deploying to, and that will do the OCD deployment on that environment. And the nice thing about having that consistency is that you have portability across your developers. There's no deployment workflow. You don't have one person who's used Puppet, another person who's used Ansible, another person who knows Chef inside and out. You just have developers who are using a tool native not only to their own day-to-day existence, but to the development workflow you've set up as a team, Git push. And finally, consistent means that you use the same tools to deploy on every environment, that you know deploying from one environment to the next is not only done the same way, but it has the same result. And it's not just the code that you're moving around, but you're always testing everything, every step along the way with actual infrastructure and actual data. So one thing that's really hard to do in this respect if you're doing, you know, if you're trying to build something like this for your team is the data management. Docker's kind of made it easy for us to spin up services that work really well, but what Docker hasn't really solved is getting that 100 terabytes of images from your live server and the 10 gigabyte of database and the solar index that you've got already to go from the production environment down onto your staging or down onto your local. And the example to give from platform.sh there is that we have a really cool file system level technology that will guarantee that you've got your new environment to test on in one to two minutes, even if you're dealing with 100 gigabytes of data, it doesn't really matter, it goes really fast and it's its own copy of it. So you can start working on that environment as if it's its own thing in just a couple minutes. It makes the cost of integrating the branching and merging Git workflow to your entire infrastructure and your entire application really cheap. It means your developers will make lots of branches and test things out on a feature level and demo things to your customers at a feature level rather than having to pack them all together on some staging server and hope that one person's feature didn't break another person's feature. And that's just there's no dramatic demonstration of what I said. So I just put a screenshot of platform.sh there. Let's move on to deterministic though. What does the D and OCD deployment stand for? It means deterministic. It means for every event there exists only that could cause no other event. It means when you deploy in an OCD deployment, you know that it's going to work the same way every time. There's only one outcome. Now, what does that mean exactly? So we have a concept that for every Git hash there's only one application can be launched. That means it's impervious to changes in Drupal module updates. It's impervious to whether your composer resolves different dependencies. If you're pulling in stuff with npm pip or ruby gems that you need for compass, sass, less, bower, grunt, whatever platform has all those things but once you build your application one time successfully, then it actually stores that on a read-only file system. That's what will be deployed every time you move it through different staging, development, and finally production environments. That means that if you successfully build your application and test it on one environment, when you move it into a new environment it's not checking out new code, it's not calling Drushmake and getting new stuff from Drupal.org. You're going to have no surprise views upgrade that you hadn't counted on. You're going to get a byte-wise copy of the proven tested file system containing your code so you know your application works exactly how it should. And like I said, platform SH example there is that these days applications are oftentimes built beyond just the code that you've written yourself. You might be using Drushmake somehow to get stuff from Drupal.org, but in Drupal 8 and in other PHP applications you're also running ComposerJSON or ComposerLock files to get Composer dependencies. And you know, with compass and less and sass less and sass, then you already are familiar with either Node or Ruby dependencies that you need to pull in and actions that you have to take to prepare what equates to code like CSS derivatives. That's actually code, but you're preparing it with these dependencies. Those dependency versions can change. The output of the compiling process can change. With platform you have absolute bitwise deterministic deployment making sure that if you've tested your code on one environment it's going to be consistent across all of them. And that's kind of obvious that you use well, what's obvious is that you use the same services and code for every environment, so it's really important that your PHP version is the same your Nginx version is the same, my SQL version is the same, that the same code. But what's less obvious in a deterministic way is that if your production, if you have a deployment into production that you're aiming for, you need to be able to repeat this deployment many times to test it to make sure it's going to work. And if you actually get to production day and it goes wrong in any way you want it to be reversible as well. So a deterministic deployment paradigm will actually let you reverse a deployment, not just by checking out a new version of the application, but actually resetting things to how they were across the board, across infrastructure data and code. So OCD deployment is not a mysql dump and a mysql import because that takes way too long. Gigabytes of data in your database will take hours to import and export. It's not our syncing for your uploaded files and it's not re-indexing solar. If you have any of those steps built into your deployment or when you're setting up your development environments then you've got the risk for inconsistent data in your testing and you're going to have inconsistent results when you deploy. So here's my last example, it's a video it's just setting up a new project on platform.sh. When you get going you've got the choice between Drupal, Symfony, WordPress, but you can actually run any PHP application on platform.sh right now. I'm going to go back and choose Drupal because that's where Drupal gone after all. Let's show Drupal 8, that's the nice next thing. You can just click it there and what that'll do is check out a Git repository from GitHub that we've got as an example starting point. You can provide your own whether on GitHub or you just push it up yourself and now you're about to see the world's fastest D8 installation. It's amazing how fast it goes. It's like you can install D8 faster than any other application. Boom, there it is. As a D8 site now we're going to do an entire development workflow where we're going to theme that site. So we're going to start by creating some branches for an agile workflow. We're going to use the button up there to create a branch off the master. The master is the live site but you're going to want a staging site to test that on. This is just your workflow that you're deciding on. It doesn't have to be called staging. It can be called anything you want. It's a Git branch but it's also an entire copy of the application with infrastructure, with data, with code. Then I'm going to repeat for some more branches. I'm going to make a sprint, I'm going to make some feature branches and as you can see you literally get a copy of your application for every single branch that you have and you get repository for every developer that you're working with. That gives you a lot of flexibility on the type of workflow you pick and then I'm going to go into one of those and one of them is theme fix so I'm going to go check that out. I'm going to show you in the video, I forgot about this the fine-grained access level permissions so you can easily work with outsourced companies or freelance developers or different teams by giving them access level permissions at different points in your workflow. They can go off and do their own agile process but you've still got a gate check like a pull request if they're going to bring their code back into your mainstream, that platform enables them to have all the advantages but you still have to approve their code. Then I'm going to use the platform CLI tool that's a symphony console app to get my project for local development. I can choose from all of the branches that I've got up there I choose the theme fix one, grabs my code, does the build process on it, if they're composer JSON dependencies it'll resolve them, if there are other dependencies from like Drushmake files it'll get those. I'm going to go in I'm building this project with a Drushmake file so that I can keep the code that I use from Drupal.org, separate from the code that I'm actually maintaining in my theme and my modules. I'm just going to add a nice, beautiful well-designed theme from the Drupal 8 repository and I'm going to push that up to platform, just get add, get commit, get push that's the consistent deployment mythology and this is an actual deployment of my application onto my theme fix branch. The whole team can see what I'm doing in real time and then I'm going to be able to go in and test that version of the application with my new get push on this branch for that commit and see the happy results of that wonderful theme that I made. So, come on video, catch up to me. There it is, there's the URL for that branch. Go enable that theme and prepare to be amazed. Go back to the home page radiant. So, that's a well-themed Drupal 8 site with um, yeah nothing else to see there. So, that's the video and just in summary the benefits of an OCD deployment are you get a deployment that's simple to execute, testable over and over and over again, repeatable so you can do it many times, even going into production many times if needed and reversible if it doesn't work because when you invest in building something big and important no matter how tangible is or virtual it is when it's time to launch it it feels really good when it goes right the first time. Thank you very much. It's a big boat. It's like it's almost like a birthing process, right? Not quite. No, the sound's turned off. It really is, believe me. Hello, everyone. Thanks for joining us. Thanks, Robert, for the handoff. We're going to be talking about MailChimp MailChimp and Drupal in particular. Before I get started I want to introduce Nate Ransom. He is the API liaison from MailChimp. I'm actually left zippin. I am with ThinkShout. I'm the CTO and founder and so you may be wondering initially why is ThinkShout here when we're talking about MailChimp. What we're going to be talking about is ThinkShout's unique partnership with MailChimp in building and maintaining the Drupal MailChimp integrations. We're going to talk a little bit about the story of that partnership and some of the successes we've had and our roadmap and if there's interest in time I'm happy to do a quick little demo of some of the new features that we've been working on. First of all, I'm assuming that most people if you guys are here you probably know what MailChimp is but just in case you don't from the Chimp's mouth MailChimp sends more than 8 million emails every day you probably heard their adorable commercials from serial where they say MailChimp but they're a really, really fabulous email service provider. They make it really, really easy to send emails to lists of people, really elegant tools for building your campaigns and managing your statistics. They've always had a really innovative feature set and perhaps most importantly from our perspective is they're really just great community citizens. They take amazing care of their customers and all their partners like us. We work primarily in the non-profit sector and we just think that sector in particular is very, very well served by MailChimp. Not only do they take really good care of their clients but it's a really great value too. You get like a ton of emails for free before you start paying and after that it's also really reasonable. Here's a bit of a history of the MailChimp modules. So this is MailChimp the module. If you guys have questions about MailChimp the service, I can kind of do my best to speak to them but, you know, Nate could probably chime in too if we have any questions about that. One quick back step though. Another reason that MailChimp is such a great partner to work with in terms of these integrations is their API. And this kind of Nate's kind of bread and butter but they've you know, as far back as 2008 when I first started building out these tools, you know, they have far away the best API to do these types of integrations. So even, you know, to this day not to name names but some of their leading competitors still don't have near the type of tooling available to be able to build these seamless integrations which we think are so important. But I won't name names. Alright, so created the initial version of the module back in 2008 and at that point I had my own kind of small company doing a lot of contracting work and I also had what I like to call a case of shiny object syndrome so all these like startup on the sides that didn't go anywhere or mean anything but they were kind of fun and one of them was something called Mom Hub and it was a social networking site for moms. I had a new child at the time so it was kind of a topic that was near and dear to my heart and we needed to have email capability. It was kind of like a Google group type of clone to focus on moms and play groups and stuff. So we wanted to you know, even back then I was working a lot with Drupal. I thought Drupal was a great platform to build a startup on and I needed robust email capability so I went ahead and wrote a module that integrated MailChimp with Drupal and it basically allowed you to automatically subscribe people to listen MailChimp so you could then send out emails automatically. Great, it kind of scratched my itch but believe it or not Mom Hub didn't make it and I quickly shut that project down but the module lived on and started to grow in popularity and kind of right around the time when it had about 500 people using it which you can see on the timeline here is around 2010 I was busy running and growing my own business and I kept getting all these people asking me for support in the issue queues and so I reached out to MailChimp and I said hey, I think this is a really great opportunity here. What do you guys think about supporting the development and maintaining this module and adding a bunch of great new features to their credit again even back then it's forever ago internet years, they saw the opportunity and they started sponsoring the development of that module and it's been a really great partnership ever since so I don't need to read this off here but yeah we kind of basically keeping up with Drupal released the first version of Drupal on Drupal 7 we did a complete rewrite leveraging Drupal 7's entity system so that we could do a lot more cool features and it was familiar when Drupal 7 came out that was the first time you could have custom entities in Drupal so it wasn't enough that you could have your Drupal users be subscribed to MailChimp lists there were other types of data in Drupal that you also might want to synchronize with MailChimp for example we wrote RedHand which is a native of Drupal CRM so there's a concept of contacts we want those contacts to be synchronized with Drupal maybe when somebody comments there's also first class objects in Drupal so maybe when you leave a comment you have the option to put in an email address so you could automatically add people to a list leave a comment on your website another common use case so any type of Drupal object could get synced with MailChimp when we did that rewrite so in 2012 another product came out called Mandrill so Mandrill is also a product of MailChimp and it is kind of a sibling choice so MailChimp is for email campaigns so if you want to send your typical newsletter you get in your inbox that's something that you'd use MailChimp for Mandrill is a transactional email service so this is really more if you have an application that needs to send emails you want to use a tool like Mandrill other options in the field are things like SendGrid Amazon has a service called I think it's SQS SES thank you so well even in Drupal 7 it has a really nice abstraction to its mail system where you can use any tool you want to send email all this implements the mail system interface so by default Drupal sends emails using PHP's native send mail functionality which means that your web server is sending emails so that kind of works fine until it doesn't which is usually in a hurry if you have any type of meaningful application that you're building so the problems you have with just sending emails using like your web server is you have problems with deliverability, lots of corporate firewalls and complex spam rules nobody's going to know that what your web server is authorized to send email it might be flagged as spam it can be hard to craft really beautiful email templates that look good across all those many many different mail clients that's something else that Mandrill helps you with and perhaps most importantly it gives you accountability for those emails that were sent so every email that goes out you know who received it, when they opened it if they clicked on any links so we brought all of that functionality including the activity tracking into Drupal so if you want to have reliable email and send beautiful templates and do tracking and everything else all you got to do is basically turn on that module put in your API key and all of a sudden your site will start using Mandrill for sending emails and another neat thing we did with that is your site sends all different kinds of emails everything from password resets to user registration confirmations to order receipts perhaps so because you pay per usage on that you may not want to use Mandrill across the board for all the emails that you send so you can actually go in and granularly select which emails you want to use Mandrill for and perhaps your password resets which maybe you don't care about so much you can go ahead and use the native functionality for that let's see alright so I'll skip ahead a little bit so finally we're also excited to announce that just this week we released the first version MailChimp for Drupal 8 that's not up there on Drupal.org it worked great we're really excited about that and if I have time here I'll do a bit of a demo and show you guys how that works too that was a lot of fun alright so a little bit about our partnership basically what we do is we get together with the MailChimp team, Nate and Christy and we do kind of quarterly planning what new features does MailChimp have coming down the pipe that we want to integrate into Drupal what are we hearing from the community in terms of what you guys want that we can add so we kind of put together a project plan we also do ongoing support so basically every week we've got a block of time that we spend working in the issue queues fixing bugs adding new features that people ask for and just providing support and of course documentation is a big part of that as well so it's great to be able to have that opportunity to not just build new features but really support the community on an ongoing basis we're pretty obviously biased because of our great partnership with MailChimp but we really feel great recommending MailChimp to most of our clients because not only is it a great service on its own but we know that it has such a great mature and stable Drupal integration that it's a really solid choice and MailChimp likewise promotes integration through their channel so they've got an integration fund and they have a website where they list all of their different tools that they've integrated with so you can find it there as well we promote the tool together at conferences we're really lucky to be sharing a booth with MailChimp here this week we spent some time together at the big nonprofit technology conference a couple months ago so that's a really fun way for us to kind of promote our work together and this is kind of my cheesy slide representing a bit of a virtuous cycle so this is really a situation where it's kind of a unique win for everybody MailChimp gets a bunch of new clients using their service they get really great recognition for all the work they're doing supporting the community the Drupal community gets a huge win because they've got a really well maintained and strong integration with a great service and things out we get some work out of the project but even much more importantly it's just such a great story for us to be able to tell that we've had at least a lot of goodwill on our part alright so what are the results it's a little bit of a snapshot of the user statistics from Drupal.org since the history here doesn't go back to 2008 but we started working with them there were about 500 people using the module and I checked this week there were 22,000 so that's some pretty spectacular growth and it's been linear and keeps going up and I think that speaks a lot to the success of the partnership alright so real quick I've got a few features I'll talk about excuse me I mentioned earlier that you can automatically manage the subscription to lists so if you have people register on your site they'll automatically get added to for example like a membership list in MailChimp when somebody creates an order through Drupal commerce they can automatically be added to lists when users get deleted they can be removed from lists and you can do list segmentation based on the attributes of the entities that you're describing to the list so let's say you've got users and you've got like a taxonomy term describing what part of the country the users are in or maybe you just use the zip code field so you could create segmented MailChimp lists and send different targeted emails based on the attributes of your Drupal data and that's all automated behind the scenes when you look when you go to edit your profile for example you can see whether or not you're subscribed to a newsletter you can go ahead and subscribe to the newsletters and I'll show you that in a minute you can map any Drupal data to merge fields in MailChimp so if you've got your first last name in email and zip code in Drupal and you've got merge fields like that in your MailChimp list to do segmenting that data gets automatically synchronized and another use case a bit different from that is just creating forms for people to sign up for your newsletter so this is more common you go to a website it's an anonymous visitor you say hey sign up for our newsletter so those forms get automatically created they can be created in blocks or in pages and all of the merge fields that you have set up in MailChimp will automatically get translated into Drupal form fields four minutes got it I mentioned creating pages, blocks or both you can create MailChimp campaigns with your Drupal data so this is a really great feature so what we can do here is if you've got a bunch of content in your Drupal site and you want to send that out to your list subscribers you actually go into the interface in Drupal create the campaign and automatically embed the Drupal content using a token system it's basically an input filter so you can put like content you put in some random text or images and then embed your actual Drupal content and there's an interface to do all of this and then maybe add some more content in text and then you actually go ahead and pick what list you want to send that to and click send so it can really streamline the managing of your newsletters and the people who manage your content on your website also manage the content in your campaigns you can go ahead and send those campaigns within Drupal and view the statistics on those campaigns and I mentioned that and you can build list segments using ViewsBulk operations which can be really handy as well alright the roadmap we're going to release a stable 1.0 version on Drupal 8 right now the alpha 1 is out MailChimp came out with a brand new API just in the last couple months so we're going to re-architect the module to use the new API and the new features it makes available we're going to integrate with MailChimp Commerce 360 which is MailChimp's e-commerce tracking system so maybe integrate that with Drupal Commerce so when you have a shopping experience in Drupal Commerce you can segment your users in MailChimp based on what they're doing we're going to port mandrel to Drupal 8 as well so at that point take a step back and reassess the module and feature set for what we call the Drupal 8 world so much like what we did when we wrote the module for Drupal 7 we didn't want to just do a straight port we wanted to actually step back and see hey do the new features afforded to us in Drupal 8 create some opportunities that we can take advantage of and make an even better integration a funny quote here about monkeys from Henry James reminder about the sprints tomorrow please go if you are going to be around and if I have a minute or two I can answer questions or do a quick demo alright so this is a Drupal 8 site I got spun up if I could make that menu disappear that would be great alright we're going to go into web services configuration here we have MailChimp so you can see here we've got global settings and campaign so I mentioned the campaign feature I can go ahead in here and quickly add a campaign I'm not supposed to do live demos somebody told me once so let's see how this goes alright so here we are saying we're going to send this campaign to this list we have the option to segment it I'll skip that the from email the from name here is our MailChimp template we'll just do something here called monster and here are those content sections I mentioned so here is the content and we can inject our own page from the site so here is some test content we have we can use a teaser and sort of the whole thing we insert the token and that should basically work to create the campaign save as a draft darn it so now we can preview it and save it actually all from this interface so that's one quick feature here is the list I mentioned so we have one list on MailChimp which we pulled into Drupal to make it available and real quick here are the sign up forms I mentioned so if you take a look at this here you can basically create the sign up forms as entities in Drupal so you have a lot of flexibility in how you use them right here I've just created something called newsletters sign up you can see here I can choose to make it available as a page and or a block you can specify the URL the label, the confirmation message and here you specify which lists you want to show up in that subscription form so it could be more than one list if you choose and you can choose which merge fields within that list to display and you got a couple other nice affordances you can specify so I do have that set up already so if you look here on the main menu of my site I got a big newsletter button when I click on that I sign up for the newsletter as an anonymous user browsing the site the other way you manage your subscriptions is so this is my user settings on this Drupal aid site if you see here I've got a newsletter subscription field so that's actually a field type that the module provides and if you look at the settings on this field type this maps to a specific newsletter and what this lets you do then I'll skip ahead because I know where I'm set at time so if I go to my if I go to my profile page down here this is that newsletter field so if I'm registering for the site or editing my profile I can go ahead and subscribe to that newsletter just by clicking on that button and as a matter of fact I'm going to show you guys something so this is my profile on Drupal.org and if I go ahead and edit my regular profile page if I go ahead and edit this profile you can see down down down down here I've got an option to subscribe to a number of newsletters well the exciting thing here is that Drupal.org is actually using the MailChimp module as of a few months ago so all of these newsletter subscriptions are actually managed by MailChimp through the Drupal module and the neat thing is is nobody knows when they're editing their profile that MailChimp is even involved in the mix it's a completely seamless experience and it's really nicely performance and works very well the final piece of functionality if we have some time okay I think I'm out of time and I'll call it there alright I'm getting the choking sign alright thank you and I think we'll be at the we have a booth downstairs we'll be there probably at least for a little bit longer if you guys have any questions I want to combine say hi, thank you oh and thank you for the excellent info I've used MailChimp for signups get the RSS feeds from our site and I had no idea what I was doing and it was very easy to do so it was very successful but I'm new to MailChimp and I still have a lot of questions I'm not really sure what it is is it a service is it a module I guess it's both from what I understood there's a MailChimp service you get an account there it's the module to do all the Drupal stuff that's with it but is it a paid service is it free software I got a lot of questions sure is this so MailChimp is a platform it's a web service and it's a stand-alone thing but ThinkShot has basically wrapped the majority of the MailChimp functionality into a single Drupal module so while they are kind of different ThinkShot has done an amazing job at kind of taking the essence of MailChimp and then making it easy for Drupal users to use MailChimp within Drupal okay so if I'm using the module that ThinkShot was lovely to make I mean really you've done an excellent job so that someone who doesn't know what it is could use it but you know I'm Drupal friendly but is it when I'm using that module is this free software or am I going through a service and I'll have to pay for something that I don't know about sure so MailChimp offers a free plan it's up to 2,000 subscribers and 12,000 emails a month and so as long as you're within that threshold everything's completely free forever we do we do have paid plans but unless you explicitly sign up put in your credit card details and like sign up for one of those paid plans you are free to use MailChimp for as long as you would like awesome it's beautiful thank you for getting together and making it even more beautiful thank you could I ask one more just a quick one the AWS backend this is for Robert the OCD thing do you have to use Amazon to use the OCD deployment so the home base for the development environments that we have is always going to be AWS but for deployment for the production site as I mentioned you can host your production site on AWS or on Google Cloud or on Asia or even on a number of other public cloud providers around the world so we have like Scandinavian or Swiss specific clouds that we provision on so you have a lot of geographical choice about where your production site is hosted right but it's all cloud things yeah doing it in your own infrastructure or on private cloud is not one of the options yet okay I'll vote for that thank you but first I wanted to know if you could help me differentiate the two services I have experience with MailChimp sending email mostly through the UI of MailChimp I rarely use the module but what's the differentiator between MailChimp and Mandrill and why would you make a choice to use one or the other or both at the same time I maybe I misunderstand sure so MailChimp is typically email service for business so you would have a list of contacts of people that you want to stay in touch with they all get generally the same information you can track those results but people opt in and opt out whereas Mandrill is more of like a transactional so or action based service so if someone signs up to your website you want to send them some sort of confirmation email you can do that with Mandrill the password reset that's also done with Mandrill so instead of using your own on the server you can use Mandrill more robust exactly and then Mandrill also integrates with MailChimp so then you can make or you can segment your list based on people who open Mandrill emails or didn't open Mandrill emails and that sort of thing so there's that connection between them exactly thank you and I had another question about platform I came in a little late but is there any integration with Aquia's environment to maybe use their repo and perhaps pull down and create branches off of that at the time there's no direct platform Aquia connector that would move your site in between those two infrastructures you're probably best thinking about them as competing services but it's really easy to deploy a website onto platform you push your code into the Git repository there you move your database into it you move your files into it and then you're ready to go hundreds of sites on Aquia in a multi-site environment there's a two gig repository I'd be happy to talk to you about that and how we could maybe move you away from multi-site which I personally feel is more of a liability than a boon my point of view with Drupal multi-site is that it was a way to share code base between multiple sites but Git actually does the same thing and you tie a bunch of sites together at the hip when they don't need to be using multi-site whereas they'd be better served in most cases by putting them on individual site infrastructures but doing your code management centrally and deploying that using Git unfortunately I'm the wrong guy to speak with about that I will say to the further clarification of your first question the concept of a transactional email is really important especially for commerce you really want to make sure that your mail transport authority whether it's mandrel or SES or SendGrid has a great reputation because for example you want your product order confirmations and things like that and your invoices to reach their customers it can be disastrous for e-commerce if you're not using a mail transport authority with a good reputation and Platform.sh natively integrates with mandrel for that very high reputation mail because we need a very high reputation mail transport authority and when we did our evaluation from the API standpoint there's absolutely no question who the leader is in the crowd he didn't come here knowing I was going to be here and say that but their API is hands down the best so save yourself the trouble searching just use it what kind of advancements what's forthcoming in integration specifically like it's been a while since we went through this previously we were using kizumi for mail chimp sales force integration is there like a sales force integration with Drupal that could also talk to mail chimp or anything like that just for tracking donors and potential donors for a nonprofit well I can speak to the Drupal integration but sales force directly talking to mail chimp I'd be happy to talk with you after this session I'll let you I think it's valuable we also maintain the sales force the current version but at least and that offers a really robust bidirectional integration between Drupal and sales force so that includes any potential mail chimp or mandrel data because those are all entities and Drupal can be synced with any object in sales force so the three x branch of the sales force suite is really active and would work great but that doesn't speak directly to mail chimp integrating with sales force the actual sales force mail chimp integration tracking in sales force when they're opening campaigns things like that what we ran into with the problem with kizumi was we had a two way push and it was just flooding our sales force account with junk basically people had no intention of ever donating that kind of thing and there's an api limit on sales force that you were probably running into api calls yeah so we do have a kind of newer sales force integration called mail chimp for sales force it's just an app that you install within sales force right now it doesn't do a whole lot of syncing as far as activity goes that is something that we've looked at and we're trying to figure out a sane way to convey that data in sales force without blowing up your api limit so if you have any feedback or any special requests that you would like to see come find me and I would love to get that information really quick I wanted to follow up on Robert's point about mandrel and activity tracking I had a good chance to mention this specifically but one of the features of the mandrel integration is that you can enable mandrel activity tracking for any object in Drupal so for example Drupal users so when you're looking at your user tab if you have the appropriate permissions you get an additional local task there to view all of the email activity for that user so if you are for example doing e-commerce on your site and you got a customer who gets in touch and said hey I never got my receipt you can actually go to their profile and look to see every email they've been sent and whether or not they opened it so it can be a really useful feature for those types of projects so we use both mandrel and mailchimp I have at previous companies as well and I've never seen a really good solution for managing unsubscribes for people that unsubscribe from your mailchimp list to like not send them emails from mandrel either if you guys have a so that's kind of a tricky one to answer mainly because if someone unsubscribes from your email newsletters they don't necessarily want to stop receiving password reset emails and so because there's that blurry line there we don't automatically enforce that on the mandrel side Mailchimp does offer webhooks to alert you when someone unsubscribes and depending on their unsubscribe reason or type you could then take that information and then essentially blacklist them from the mandrel side of things as well that's not something that we offer natively so that would be something that you would either have to roll your own or maybe there is someone out there that makes that process a little bit easier but like I said it's such a kind of murky area that we don't take an absolute stance on that we do something similar we use the webhooks and we just like flag them as don't email as long as it's a password reset email versus transactional action based campaign but yeah like like I said it's kind of a weird thing and each kind of mandrel and Mailchimp user has their own specific setup so for us it's difficult to say absolutely never send this person email so