- Full stack developers that want to explore the concepts of Jamstack pre-rendering and decoupling
- Everyone who knows the term but is unsure if the benefits are worth it
- Automation freaks and DevOps enthusiasts
- Agency owners that do not want to fall behind industry leaders










Learn what exactly Jamstack is, how it evolved over the years, and how it fits in your day-to-day development process.

Head of Developer Experience and Education at Remote

Cassidy Williams

WordPress Ambassador @ Buddy

Maciek Palmowski

Introduction

What is Jamstack?

What are edge functions?

How Jamstack differs from other tech stacks

Biggest pros

Rebuilding legacy websites

Cons of Jamstack

How to convince your manager about Jamstack

How to start your adventure with Jamstack

Favorite SSG or framework

Everything you always wanted to know about Jamstack (but were afraid to ask)

Maciek

Hello, everyone, welcome after a short break we had. And that's why we are back. And we decided that we will start after this break with something really great. So today we are going to talk about jam stack. And we'll answer all your questions that you have. And while I know a thing or two about JAMstack, because, yeah, it's, it's cool. It's interesting, it's all over the place. But I decided to invite someone who is so much better than me, not only in JAMstack, but also when it comes to doing PowerPoint presentation. Because Cassidy is also mean such an amazing person when it comes to creating PowerPoint presentations, if you ever had the chance to see her skills, really. And so Cassidy, tell us a few things about yourself.


Cassidy

Sure, I cannot speak as well for my PowerPoint skills. But thank you. For context. I did a PowerPoint once that basically just made it logo spin the whole time. And then I went into live coding so very professional. But anyway, my name is Cassidy and I'm a head of developer experience and education at Remote and I also do developer experience. With OSS capital. I like open source web dev and memes. That's that's a good enough overview, right.


That's true. That some Legos got some keyboards.


Yeah, yeah. So yes. And my name is Maciek Palmowski. I'm your one and only so favourite, by the way, because there is no other host here at Buddy. And yeah. And so before, we will get started with talking about, about jamstack. Let's see what we'll learn today. So first of all, learn what is jamstack and how it changed over those years. It maybe wasn't a long history, but they've already changed a lot. What are the biggest pros and counts of this approach? Because, yeah, there are no silver bullet, sadly, sadly, and how to start your adventure with Jamstack. Because there are so many ways to do it. So it's, it's really not not easy to pick the the best approach.
So also, if you like our webinars, don't forget to press the subscribe button on YouTube, you will be always informed about all new webinars that are incoming. And like I said, we are full of energy after this break. So there are some really cool, interesting coming in soon. So okay, let's, let's start with that basic thing. What is this JAMstack?


Great question, because I think the what is it? And then the how has it changed kind of is intertwined? Because it has, it has changed so much. So when JAMstack was first coined as a term, I forget the year I want to say 2015 2016, but don't quote me on it or


something like this, because I was I also had this problem when I wrote about and how changed over over those years. And I so Oh, but these are only few years.


It's yeah, it's and the thing is that and get into all kinds of things. JAMstack has changed a bunch, but the as as like a paradigm and things but it's not necessarily using new concepts. It's just kind of using older concepts that we've known and loved before but using them kind of in a better way with more modern technologies. And so what anyway, when the term was first coined, it was capital J A M stack. And that was because the J A M was stood for JavaScript API's and markup. And it was just solidly like use JavaScript and API's and markup to create a website. And it kind of focused more on static websites. And it evolved over time, because it kind of got overlapped with serverless. And then that method of developing sites where, if you don't know serverless, it means you don't have to care about servers, it doesn't mean the servers don't exist, it just means that they are not within your control, you create functions that live on a server elsewhere.
Anyway, all this to say JAMstack is not server side rendering. So you don't have to maintain a server of some kind to host a website. If it is a jam stack website, it's typically CDN first, and then pulling in, again, API's and and perhaps serverless functions and that sort of thing. And it's evolved over time, while still being attached to the core principle that you are compiling as much as you can upfront, and then pulling in data as needed. And it's this concept that, for example, if you were to build a mobile app of some kind, whether you're building Android app, iOS app, Windows Phone, a hub, something, something to that effect, I don't know what people are building,
you are building a lot of the UI into the app itself. And then if you need to query data, you kind of do that separately from the UI, realise, very rarely rendered on the fly with a mobile application, the with jam stack, concepts, methodologies, architectures, whatever you might want to call it philosophies. It's kind of treating the browser in a similar way where it's like an operating system, because the browser is very powerful like an operating system, you're building as much as you can up front, so that when someone reaches your application, they don't have to make so many different queries to API's, various servers and things. And so it's trying to run as little JavaScript as possible when the user gets to your page. And granted, JavaScript exists for a reason. That's, that's the J and jam. And JavaScript isn't necessarily a bad thing. But it would be good to do less JavaScript, because there's a lot of frameworks out there that ship so much JavaScript to the browser that if you have a slow internet connection, if you're in a remote area of the world, you might have to wait like a solid few minutes just to have an application load from the get go. And so again, compiling as much as you can upfront and pulling in data as needed. And that's the the high level version of what gem stack is. And when you think about how it's evolved over time, it kind of went from purely static to, again, pulling in data and content, but then also the kind of latest iteration of it pulling in data at the edge. And you might hear the term edge a lot. Also, I'm talking a lot, so cut me off if I'm talking too much.


Great. So the edge is not the Edge browser, as as one might think. But the edge is a concept of CDN that that has, again is not new. But it's definitely evolved and is a lot more accessible now. Where, with CDN, when you host something that's a content delivery network, you are getting just a web page from somewhere, you don't really care where it is, it was built up front and you just kind of get it you don't care where it is, when you are calling an edge function or pulling something from the edge of a CDN, that means it is getting the node that is closest to you geographically speaking, and depending on the provider that you use, that could be that's kind of vague on the one that's closest to you. It could be the city that you're in, or it could be the zip code you're in, it could be the country that you're in, kind of depends again on the provider. But that means that things can be served to you even faster, because it is physically coming to you faster and closer and stuff. And that's kind of been the latest trend with JAMstack is rendering things with Edge functions.


Yeah, and and as you said, the most coolest part will be rendering edge functions in Edge browser, right.


There you go. That's the most the most meta thing.


Yeah. But also the thing that I saw about the way how JAMstack evolve a bit because as you mentioned at first it it was very keen on this JavaScript part. And now I see that even even all those either generators or frameworks not build it in JavaScript, for example, Hugo, which is built in Go is seen as a, as a normal part of, of jam stack ecosystem. And even that, it has almost nothing to do with. With JavaScript. I mean, you can build websites that have has JavaScript inside of it.


But you could you could build something with rust, it could be built with any. Yeah, kind of like you say it. That's why it is no longer capital J A M stack. And now it's more just like jam stack with.


Yeah. By the way, the way how we spell this, I was even wondering just just a few minutes before, I was wondering, like, what, a bit differently. Yeah, what what happened, but I went to the official website, jamstack.org. And I saw, okay, right, J rest is small.


So I think that that transition is fully complete. But it was definitely very confusing for a while because we're like, wait a minute, I thought this was a specific stack are acronym and stuff. And the capitalization change is so minor, but it's trying to illustrate that it's not just like, this is specifically what you have to use. It's like the philosophy and architecture that people


Which is, which is totally different. When we think about different stacks, like for example, this LAMP stack, typical technological stack and technologies. Yeah, exactly. And, and I think that this is also one of the biggest things that how Jamstack differs from from many others, that it's mostly about the way how we are doing things rather than which technology we use. It's, I would say that, at least in my opinion, though, one of the most important things behind behind Jamstack is the fact of all those different technologies being decoupled from itself, you can interchange everything at any point. Rather than when we look at, for example, the website built in, let's say, Wordpress, we have this, this monolith that is built, and changing some parts like which database we would like to use, it's almost impossible when it comes to JAMstack. If our database has an API, it's simple. One day, we were using, let's say markdown files next day, we connected it to notion because it has an API or whatever we want, or we can connect it to workers that also has an API so so we can change all those small pieces of our of our of our application with ease.


Right? Well, and that's another illustration to kind of describe the decoupled nature is, if you have some kind of Castle, you could have like a knit castle that you made with it with where you where you intertwine all of these different pieces of yarn, let's say, or you could have a Lego Castle, where you swap out bricks by bricks
in a typical structure, and I would argue that you could do like monoliths style things with JAMstack. But in a typical non decoupled architecture, if you want to change something in the middle of this castle that you have knit together, you would have to undo all kinds of different threads and stuff to be able to get to that part you want to change and then re stitch everything back together. Whereas with a Lego Castle, you can kind of swap out a brick much more easily. And that's kind of the power of of leaning on decoupled API's from your user interface is that if you want to change some kind of database, kind of like you just said, you can just switch it, it's just switching which API that you use, and hopefully it shouldn't cause too much of a rewrite for the rest of the codebase


Yeah, probably. I mean, if it does, as in Lego, sometimes we have to put put out a bit more of the bricks to get on we need but still it's much better rather than just getting rid of of the whole set just to pick 1 little brick. Yeah, so we are already talking about this headless thing. So this is one of the biggest biggest pros when it comes to jam stack we are not so tied up to a technology we can we can interchange it much more easily. And
what are the other biggest pros of going going jam stack use it rather using jam stack? Yeah, you going jam stack? I said probably just so we could Yeah,


Right, do you follow obey?
I think the biggest the biggest pro, for me in particular is well, there's a few different ones. But this one that that comes to mind is because you're not server side rendering anything, you're not querying a server for information, it's just already built. It's much harder for your site to be bogged down and, and just kind of tanked because of too much traffic. And that was actually something that a real world example A friend of mine, her startup was working with a bunch of different streamers. And they decided to convert their website from a server side rendered website to a jam stack style website, where it was basically just a glorified HTML page that was rendered with a form and they wanted people to fill out this form. And they were working with some very popular streamers, and eventually worked with one of the most popular streamers on Twitch. And he said, followers, everybody go here right now and fill out this form. So I could send you stuff. And normally, when you have a server side rendered application, you imagine that's going to slow down to a halt, and eventually the site will go down. For them, the site didn't break a sweat, like, yes, there's bandwidth costs and everything. But it did not slow down or anything because it was already pre built on a CDN. And they're just like, This has never happened to us before. Typically, we're just like, Okay, we'll brace for traffic, and then hope we can like redirect people and load balance and everything. You don't have to do that, in this particular case, because there's no server to worry about it just their site ran without any sort of issues. And actually at jamstack conf. I'm not sure if it was last year or the year before. Someone similar did that. And I am butchering the exact people. But it was it was folks who are gathering data about COVID, and about the pandemic and illness and everything. And they used this architecture. And even though they were having 1000s of hits a day, to the point where millions of people were visiting their website, their site didn't break any sort of performance rules that like it, it just worked for everyone. And so I think that's that's honestly the biggest pro because if you know that your site isn't going to go down. Because some server somewhere goes down because of traffic because someone is is DDoS in you or something to that effect. That's enormous. That's that's such a big pro.


Yeah, that's That's true. I mean, I think I remember the case you mentioned about this COVID website, or maybe there was another because it was kind of a similar case, especially during the start of the pandemic. And I remember that one case it was, yeah, it was jamstack and database was Google, Google Spreadsheet, hosted somewhere, and it was just rebuilt every 10 minutes or 15 minutes. And that's it. I mean, it's really difficult to take down a server that only has one thing to do serve HTML website. And also, if we cover it up with CDNs, or things like this, it's it's almost impossible to do so I'm, in worst case, the Cloudflare itself will have some problems, right?


Depends on how you do caching and all that, you know. And I also think, to what what's nice about this is because you are building your website, it's it's very, it's almost like a state machine where every time you build your website, it's like a new state of that website. And so let's just say you do have a bunch of people hitting your website and you realise Oh, no, I made a typo or something is wrong, because it's state, a state of the website, you can just revert to the previous state immediately. And that like that's the joy of atomic deploys, and that's what that's called where every single time you create a build it is this atomic node where if I want to rollback I just say this is the one that I want to roll back to and it immediately pulls that up and then doesn't have to rebuild the site to that previous version. It just existed at that point in time and for site maintenance and again for quick reverts and stuff. That's that's so huge and awesome.


Oh, yes, that's, that's true. Because let's be honest, building websites is one thing about maintaining them. This is this is the longer part and taking much more of our time, and it's less fun, let's be honest.
And I would also add that when it comes to one of the biggest pros is the moment when you have to rebuild some very old legacy website that is just so old, and so legacy it's like covered with virtual webs.
and everything gets, it's like horrible. But the only good thing that that it has, it has the possibility to share us an API and share an endpoint so we can get the content. So we can still use this website and use some framework that we prefer the language that we prefer. And that just fetch the data from this website and give it the literally new coat of paint, fresh coat of paint.
And it's like, literally this this time, because we are just putting the new frontend, it's still using the old engine. But it will work. It will.


Rebuilding websites is easier when you do it this way. Because, again, it's good query and date of when you need to.


Exactly this separation of front end and back end. In such cases, it's, it's very useful. It's very useful. And but what about counts? Because? There? Let's be honest, there are no silver bullets. Yeah, I mean, yeah. From Poland, we are always trying to find things we don't like and yes, we I just like it.


I get it. And I think I think that is where it?
It depends. It depends on all kinds of things. And I see that Andrew in the chat said, Could you use the jam stack with the LAMP stack. You don't want to use a server. But some people want to use servers. And so depending on the language that you use, you might rely on servers and stuff. And so this is just an architecture that doesn't really make sense for you. A lot of times if you want to do personalization of your websites, and granted, the edge rendering stuff is helping with that. And so this might be something where we laugh at Sunday saying like, remember when we thought personalization was hard.
Right now, personalization is kind of hard with jam stack stuff, because so much is built upfront. And so you need to figure out your you need to think more about when do you want to personalise something, how do you want to hydrate a particular page, and you have to think about that, that extra layer. And also, if you are more of a back end person, this could or could not make your life more difficult. And once again, it depends on how comfortable you are with servers, how comfortable you are with front end, for a front end person, I think it's particularly great because I never want to think about servers. Again, I want to be able to just put the files built on the internet, and then query things and not have to think about it. But if you are dealing with monorepos, if you are dealing with a legacy system, kind of like you say, or if you're dealing with just things that you want to be server side rendered, for particular, things that you want to be server side rendered, like personalization, or,
gosh, there's so many cases that are just escaping my brain right now, to that effect. That is that is where the cons come in. Because it's it's something where when you render something on the server, you do get the benefits of like having the database right there and having it all built at once on that front, if you
are comfortable with that. And if you like having everything queried there, that's that's something that you just don't get as much with the jam stack. And I say as much because again, the whole edge rendering thing is new and and fancy. And I'm still learning it myself.


Yeah, but still I mean with.
I see also how many frameworks are changing, because for example, Gatsby, it's really started as a static site generator. And now it's changing more and more, to be more like nextJS. So all those server side rendering options, more more things when it comes to using all those API's in a dynamic way.
Yeah, I mean, as you said, it was it was mostly static site generators at the beginning. And right now, all the all those static things are getting more and more dynamic, which is it's really,


it's interesting. I think, probably the biggest con is that it's confusing, because things have been changing so much. And I actually recommend recently, last week, I emceed a conference front end test fest, and the closing keynote was by Jason Lengstorf, who's the VP of developer experience at Netlify. And he gave a really interesting talk on the future of just JavaScript frameworks in general not not jam stack. And some of his thoughts I thought were really interesting because he was talking about these trends.
As in his predictions for the future, and we'll see if the predictions are true. But some of the things he mentioned were, for example, more things moving to the edge, less frameworks that ship tonnes of JavaScript to the browser, which right now, like next is a very popular framework. Gatsby is a very popular framework. They both ship a lot of JavaScript to a browser. But all of these kind of new and upcoming frameworks like like eleventy, like Astro even Svelte and, and those sorts of things, they are shipping less JavaScript by default or no JavaScript by default.
And like with remix, it's it's edge first. And so all of these different frameworks, they're, they're going into this newer era. And granted, I don't see Gatsby are next going away anytime soon. But it's interesting to see that trend and shift towards more edge driven things more jamstack style things and less server oriented things.


Looking at the last Stack Overflow survey, we can see that Gatsby lost a lot of ground when it comes to the most beloved framework. Last year. It was it was in the top and right now it's it's a lot. Yeah, it dropped a lot. And I remember the discussion about it. And most people will just respond that Yeah, NextJS has happened. And that's it. But in case of shipping, JavaScript, to the front, and to everyone, NextJS doesn't solve the problem. But you mentioned Eleventy, which is kind of interesting, because it's, let's not say legacy, but it's kind of old.


It's old, but they only recently did their v1. And they only recently started supporting all kinds of edge stuff. And also, Zack Leatherman, the creator of it only recently started working on it full time. And so you're right. It's old, because it's been around for a while. But it suddenly is making a lot of changes to be a modern thing. And again, has someone working full time on it now. So that's why I kind of keep an eye on it. Because I've seen a lot of people pick it up saying, actually, this is exactly what I need. And Zach also did a demo recently, where he basically talked about how he was using this edge function style things to render images and use that in different static regeneration, which is basically rendering things on demand, but then caching it to be a part of the build. And his build times went from like, something like an hour to to like less than 13 minutes. So some, something wild like that, where it. It was such a testament to this style of building, then I'll be curious to see how it evolves.


Also, it's worth noting that Zach was always a total freak when it comes to web optimization and everything. He's very good. I I first learned about about him when he wrote this amazing article about how we should serve those first party fonts.
Yes, or which method should we use. And it was like a Bible on how to take care of this one small little piece of web serving fonts. And I remember that the updated constantly amazing work, and we can see that the approach didn't change, he is still optimization is one of the most important important things, things.
And yeah, we talked a lot about those cool things or less cool things for for developers. But there is almost always one more problem. It's called the managers. Because quite often when we come and say, Hey, we have this new cool technology, it's called, let's say, Astro, and we would like to test it and the manager will, of course, first ask how much does it cost? It's free. So okay, but the next thing will be how much time we will have to spend or something like this, because managers doesn't like to introduce new stuff. So how to
how to try to convince them to that the jam stack is, is a really good thing to learn. Maybe even not as the as the primary thing, but to have it in your belt of, of skills to use it together with others with other things.


Yeah, well, first of all, the O'Reilly book on JAMstack is free.
And so if you ever actually want to read in depth about it, read the free book, because you should take advantage of that. But and there's all kinds of great courses like Free Code Camp has a free course on it. And plenty of things like if the things are free, that's it's already
pros. Yeah. Well, and I also think I think proofs of concept go really far. And just to compliment Zack again, he's so good at making proofs of concept where he'll recreate a website in multiple frameworks and be like, look at the performance benefits. And when you, when you use that jam stack style of building, granted, you can create a performance website with anything, you could create a performing website with jQuery, if you really wanted to, it's that that's something that hasn't gone away. But
I think kind of just showing, if we were to improve this, look at look at our bundle sizes, look at how our accessibility might have improved look at how our first Contentful paint or whatever those metrics are called, have improved. And I think that's that's, the numbers don't lie. And that's, that's probably the best convincing way to do it. And also, if you, if that doesn't work, just kind of look at the trends of where web development has been going. Because it's, it's a very real trend. And when you're deep in the weeds of all of the Twitter, spheres and dramas and JavaScript frameworks and stuff, you'll see this drama, drama, I'm exhausted. But it's, it's
it's a direction that the world is going in. And it's something to consider, because as you are building this business and moving forward, you want to stay on top of the trends, because you don't want to become a legacy system that nobody wants to work on.


Yeah, I think that and especially the said, there are so many materials for free, I think that some managers should be interested that it may be, it may be a really, really good argument. Why, why to start? And
yeah, but still I the things that I quite often hear because I'm I'm mostly from the WordPress environment. Always remember that. One of the biggest arguments against was this fact, this was originally about the fact that everything is so decoupled, that in WordPress, we can have everything in one place, we can manage everything. And that is cool, because we have that we have total control. And when it comes to JAMstack, we, in many cases are have to build this application in one place, we have to have our database or databases, because it's kind of natural to have many sources that comes to our website.
For example, yeah, if we would like to use forms, maybe we'll be using, like Netlify forms, which is also a third party tool, and there are so many so many third party tools. So we are losing this control. And what do you think about this?


I totally get the argument. And I think that's something where
the and I've seen this argument and so many talks and fireside chats and blog posts and stuff there. There's pros and cons. And I think it really depends on your team, where do you want to be all or nothing. If you want to use WordPress, you can use headless WordPress very easily with this jam stack style of things. But let's just say you don't like how WordPress does forms. Just to use your example, with when you're using WordPress, you can kind of try to hack it to use something else. But if you use a more decoupled thing, you can just choose the form provider that you want. If you are using something headless, like I'll just use headless WordPress, and you want to use a database, you can choose whatever database you want. And if you don't like it, you can change it. And it kind of because it's separate, it gives you the flexibility. I think someone needs to create a startup to consolidate billing for all of these different things. Because you could either have one really massive WordPress bill or you could have just a bunch of smaller bills depending on what you're using with. And I think that that's one as featured as a one product. So it will look almost the same. I mean, this this was because for me to think that it was a bit strange, because there were many freelancers who are raising this topic, and I felt that this problem is a bit more I would say that more enterprises should have this kind of the problem because I know they are control freaks and I understand them because if you are a big corporation,


you want to be in control of all
your data. And on the other hand,
I don't see that corporations are having, or the big companies are having problems to start using catalyst because they are, it's even better for them that they can use one API for one website, one mobile application for like, everything. So
the problem that seems to be so enterprise is mostly raised by freelancers that just shouldn't care about that so much with


the multiple services thing is more of a business problem than a developer problem. I think JAMstack is much more that the concept is much more developer first, because developers are picky, and like to change their minds and decide certain things. And so this gives them the flexibility to do so. But if I were a freelancer, I could see it being like, I have to specialise in so many things to build this one thing, and that can be frustrating. But you could also think of it as I have all of these tools in my tool belt that I can use to solve a problem. And it doesn't have to be just I'm a WordPress specialist or something to that effect. I specialise in all of these different things. And I can custom tailor make an application for you with these various tools and pros and cons. Once again, I will always say it depends for something like this.


Oh, yeah, that's, that's, I mean, you just mentioned one thing about the business side, I mean, having all those things are all parts of our website. The database is stored, let's say on notion here, we have something else. Yeah, it can cost a bit more, rather than having just a small server. That is true. Yeah. Once again, depends on what you're building depends. Exactly, exactly.
Okay, and if you would start again, your adventure with Jamstack, like, how, how could you do it?


That's a good question. I am a big fan of react. And so I I've been using React since 2014. So very old.
And I think I, if I were to start my adventures over again, a lot of times when I look at jamstack, I'm just like, this is just web development. It's not anything particularly fancy. Because once again, it's it's
older technologies, or rather proven technologies, just that was more easily access edge functions. And that type of stuff has been available for years. But it's been very expensive and enterprise focused. And so it's more about easy access, I would probably say, I would be more flexible on tools, rather than going all in on the React side. If I were starting over now, because once again, I'm very comfortable with React. If you need me to build something with React, I can do it. I can kind of do that with the VUE, sort of do with solid js. And so I would probably be a bit more, a bit more not even open to new technologies. I was I would experiment more with new technologies are starting over.


So so so it's not the approach that first learn JavaScript deeply and then try those frameworks, but only when you like, almost fully understand most of the JavaScript concepts, just experiment, right?


Experimenting is great. And I and I will say I do think that it's good to understand the deeper JavaScript concepts because if you know JavaScript really well, and then something is broken in Vue JS, you can be like, okay, is this the frameworks problem or JavaScript problem, and you can solve that problem faster. But
you don't need to get started. I know some I was actually talking to a developer recently, who has four years of experience pretty experienced and a mid level developer, because they have only been using React and no, didn't really use JavaScript before didn't really go vanilla at all, just only use React. They didn't actually know how for loops worked. Which is such a base concept for me as a developer with a computer science degree and stuff, but they just never had to learn them. Because they always just use map and react and never had to think about it. And it was something that blew my mind. But at the same time, I was just like, you know, you've got done well, and you've been moving up the ladder at your workplace not having to know this particular thing. Good for you. Maybe you should learn it. Cool. Cool. Yeah.


I also had this this problem because while I'm in worker space, I started with PHP. So I first learned PHP let's say I learned PHP deeply right. And for me, it was impossible how many people are first learning how to use WordPress. And at some point, they are just starting to learn PHP. And it was right to understand you should know the basics. But right now I see that with the number of new frameworks of new tools just showing up every day, especially in the JavaScript world, I mean, I remember that moment, there wasn't a day without two new frameworks that will change the world.
Like this, right now. It's better it's only one framework per month or something like this. But yeah, it's really difficult to
to get a grasp of everything. It's it's really moving so quickly. And but on the other hand, maybe it's it's another argument for learning, learning the basics. First, it will be easier to jump from, from one framework to another.
But it depends, and I really understand why people like frameworks, they are so much easier to start, they solve a lot of problems for you, and why reinvent the wheel? Yeah, exactly. The problem is, when you stop using them,


and you win, then you're in the in the unknown, and you're like, Oh, no. Have you ever played the game code in the dark with with folks?


Okay, so this game, it's, it's very fun. Basically, you are given a picture or a screenshot of a webpage. And you and everybody around you opens their editors and just tries to build it from scratch, you have like one notepad file or whatever. And you just try to build it from scratch as much as you can. The HTML, the CSS, maybe JavaScript and stuff you do, as well as you can. And then after 15 minutes of not previewing your code, you just save the file, and then everybody submits it to a particular thing. And they open up all of the files and see who got the closest to the final screenshot. I used to play this a bunch. And it is very humbling when you're just like, oh, I need to work on my basics, as you see people's broken CSS and stuff. And I highly recommend people playing it if you get the chance, because it is so interesting to see how people solve problems or programme things in a particular way. And also you can see the reliance on frameworks where I remember, I played it back when I was earlier in my career. I played it with like my manager, and then a bunch of people on my team and I was the youngest on the team. And the most senior person on the team had been using React for so long that they were using class name instead of class, and all of their HTML. And so their their code and the darks mission was broken. And I was so satisfied. I was like, I know more than you. In this particular instance, for this one game, this moment in time, it was very satisfying. But anyway, I do think it's good to know the basics. Even though that's just a game. It's kind of an illustration of if you're ever in a situation where you have to build something from scratch, could you and I think it's helpful to be able to do even though it might not necessarily be a common situation.


Yeah, but I never knew this game. But then it really sounds really good. Sounds amazing. At this point, if someone asked me to write something in CSS, I'm just like, oh, do I have to?
Want to I don't want to I mean, I don't know hex colours at all. I mean, you you but I don't,


Yeah, and one of the last questions that I have. If you would have to pick a framework or a static site generator, what would be our top three? And why?


Great question. Because I've been debating this back and forth a lot lately for like some of my side projects that I haven't started because I've been stuck on the framework idea, because for a long time, my answer would just be either create react app, or nextJS. But create react app is very single page application style where it's all JavaScript on the front end to the point where if you have a slow connection, it just won't show up. And next, similar but different ships so much JavaScript to the browser, where if you want to use our image component, it's just so heavy that it's it's kind of a pain. And so I think for myself, currently, I want to experience experiment more with Astro and with remix. I did try playing with solid and I like it but it some aspects of it aren't intuitive to me. So I
I haven't I haven't played with that one as much. But I think right now, Astro and remix are probably the ones that I want to play with the most. Oh, yeah. Astro is also one of my favourites right now. It's, it's so nice. Yeah. And so simple and intuitive.


Yeah, yeah, exactly. I mean, because, like we talked about before, and I mentioned that JSX is not my thing. I just don't like it.
But, and when I saw the syntax of Astro, when you're just,
it's like, almost HTML, almost HTML with only few lines of something extra. It's, it's nice. And
yeah, now on second place, I would put Eleventy
Yeah, Eleventy does the same reason I really like the optimization part and everything. And the fact that they they're using those the syntax like Liquid with like something like this, which, for me, it's so similar to using twig or, or all those PHP style


There was a live stream that I saw recently, within the past couple of weeks from front end horse, where they interviewed the team of Netlify, because they just rewrote their entire homepage. And like the website, and it looks good, and it's got cool animations. It's got like Easter eggs in there. If you do Konami Code and stuff. It's cool. And it was all made with Eleventy and GSAP. And so it has all these beautiful animations and stuff. And it's so cool, because I think a lot of people think of eleventy is just like, oh, yeah, you can like throw markdown in it. And
there you go. It's a very static site. But if it's, it's powerful,


it's really cool. So powerful. You can connect like everything with it. It's amazing. Yeah, even read some time ago how to connect it with, with notion, for example, using notion as a database and everything. Yeah. And then yeah, it works. Again, it works and everything works. Yeah. I think that when it comes to this,
the way how to connect all Eleventy with all those other third party services, it's so amazing. It's so amazing. I think it's a bit a bit more clear than then in Astro. At least for me, I mean, you like store all the data at some point. And but still, both of them, especially for this low JavaScript on front end approach. It's really, really big kudos from for the creators, they are really doing an amazing job. And I already got this one question here. And it's so it's very important, I think, and how Jamstack affects accessibility? Because this is a very important question.


Great question. And I like very briefly passed over that earlier. But I think they're separate but are related in very good ways. You can build an accessible web application, in any which way you want to whether you are building a single page application or a jam stack style one or a server rendered one or anything. What I like about, again, the jam stack style is if you compile as much UI as you can upfront, that means that it is just that much faster for a screen reader to work through it or other assistive technologies. And it's something where because you are thinking about the browser first rather than how the server will render it, you could actually work with the window object and stuff and say like, Okay, I want to add certain key commands or certain abilities for people to navigate this website using an any particular technology they want to so it relates, but it doesn't necessarily change it. I think it's it's just something that you should always be thinking of when you're building.


Yeah, it also depends on the framework we are using because let's let's go back to Astro or Eleventy, they are just, they're static site generators, you get the HTML, there is nothing more accessible than well written HTML. On the other hand, when it comes to
those single page applications, it's a bit more difficult. It's more difficult it's much easier to break it to make it non accessible for everyone. So So yeah, like going back to the roots using HTML. It was always accessible. We just broke it at some point at
fancy. Yeah, we get fancy and everything because yeah, it will look so cool. If we and here is the long list of well, things we we did and later we are thinking how to fix it.
While we were we have everything working in the first place. Yeah, I also have a few more questions that that were asked when the people signed up. So for example, oh, we already discussed it a bit. But what are your thoughts about Hugo?


Hugos? If you know, Go Hugo's great, I've only played with it briefly, like not enough to have a good opinion on it. But everyone that I know who uses Hugo is just like it gets the job done. I have no complaints.


So yeah, because it's so fast. Go is fast. Yes, yes, I remember once, when I saw how there was a comparison between how much time takes building the same on the similar website in Gatsby in Hugo and then few other static site generators. And it was like, Hugo, with everything, just speeding up. Yeah, exactly. Just just like this. Another thing we got, it's a bit about static site rendering, can you run static site rendering without a dedicated node server.


You run it on a PHP server, somehow that part kind of confused me, server side rendering, you need a server of some kind. It can be it can be done with anything. But it could be a node server, it could be a PHP server, it could be anything. But server side rendering requires a server. You could fake it with serverless functions, which I have done.
And it works nextJS actually allows you to do that pretty easily, especially if you use it on something like Netlify or Vercel where you can create a serverless function and then just have that query a page and create a page. It works. But typically, if you want to SSR something, you need some kind of server. So whether you use a serverless function to serve a page or a node server, PHP server, what happens some point as the name stands, you will need to serve a server to render.


And last thing that I got, would you recommend this to a small businesses compared to say WordPress with regards to long term maintainability and complexcity?


It depends, once again, I think it depends on what folks are comfortable with what you are comfortable with, as a developer, what the business is comfortable with all of that it? It depends on you. Because I think once again, if if you as a developer are very comfortable with WordPress, and you can whip up sites and maintain sites with WordPress, use it. There are a lot of glorious websites out there that are still built with WordPress, I would I think it's like a majority of the Internet uses WordPress in some way. Most it's, it's 40, something 40 something percent 40 Something significant percentage of the Internet uses it. Nothing is wrong with WordPress, it's just your comfort level. If you are like me, where I left WordPress a long, a long, long time ago, because I didn't like maintaining it. It's just as maintainable for me to maintain a React website that uses a headless CMS of some kind.


I started converting WordPress into static websites just like this. I mean, I am like merging the the both both cool parts of two world. I have an easy to use WordPress to write content and I convert it to a static website and I store it on Netlify or something like this. And


I can say my I have a headless WordPress. Gem stack, almost. Almost Generally yes. Generally. Yeah. I think with with with this current definition, we can say that I'm a jamstack developer, alright. Yeah. Yeah, you could have parts of it is jam stack again, because it's not a particular stack you have to stick to it's just like, the philosophy that you are aiming for in how you build and use few lines of JavaScript. So there you go. It's perfect. Yeah, it's perfect.


Yeah, so I think we were really covered, covered a lot of things. When it comes to gems like at the beginning of
this webinar, we asked our users a question, do you use jam stack in your projects? And what's surprising most because 63% said, No, they aren't using jam stack.


Oh, sorry. I got one more question. I missed one. Because nextJS, Gatsby first one would be what cast someone? Oh, I think because I only listed the two frameworks


So this is where I become kind of a hipster. If I were again, building a website from scratch again, and in no particular order was Astro and remix, those are the ones that I want to play with. The third thing that I want to play with is doing react, and Vite together. Because Vite is is a build system. And that being my, my framework, and Vite has a way of compiling statically and stuff. And I kind of want to experiment with just using those because Vite so fast, and seeing if I could build a website with just those and still have all of the guarantees that Jamstack allows. That is probably not a good answer, and probably not for everyone. But that that is how I feel right now.


Yeah, because because I saw that video is really going strong. I saw that it's great that Laravel just decided to adopt it as as their main main asset builder. They're replacing Webpack, which is kind of what I really appreciate about sorry, go ahead.


No, no, go ahead. Go ahead. What I really appreciate about the Astro folks is they're they're very humble and great people were they're the same people who created snowpack, and Astro was originally built off of snowpack. And that's what they used. And even though they were maintaining both snowpack and Astro, they switched out snowpack for Vite. Because they were just like, we acknowledge that this is faster than what we build. And we'd rather go for the best solution rather than the one that we control. And I appreciated that a lot when they that it was a very like humble well written post about it and everything. And I think that is a good sign when developers are not just using what what they own and what they build. They're, they're going for the best solution they can find.


Yeah, that's the true and, and I remember the moment when when when they switch and eyes and I saw that the builds became really faster. At the beginning. I was wondering, what did I messed up? Because it's builded already, that something was wrong? Probably. something isn't working, because it's so fast. Yeah. Oh, and one because we missed one thing about about Jamstack, because
when it comes to building all those websites with, let's say, PHP, it's cool. You just put the file on the server and it's working. And with Jamstack, we have, we have to, let's say compile everything we have to build all the assets.
Don't you think it's this extra step can be overwhelming for some people.


Just having it's being compiled one way or another. It's just a matter of when, when you have something on a server, it's being compiled when the user queries it. When it's on a CDN is being compiled when you put it out there into the world. It's the exact same thing. It's just a timing thing.


Okay, yeah. Okay, so yeah, I think that we really covered everything I'm checking out. Did I miss something? No, I didn't. Yeah, so like I said, definitely the bit surprised me about this, our poll that most people said that they aren't yet using JAMstack in their projects. 63% said that they aren't. But the good news is, they are here they are listening. And, and I really wonder in about two months, what will be the answer? We will have to post this this. This poll on Twitter and ask. And how about now and also,


I want to throw it out there while we're here. The Jam stack community survey just came out. And if you fill it out, you get a free sticker. So I dropped it in the chat. There's a sticker. Oh, if that's true there says I get nothing from sharing this with you. I'm purely sharing it because I want you to get a sticker. Oh, that's That's amazing. I really love stickers. You can find it on jamstack.org Like in the eyebrow header but then I also just dropped it in the chat there. Okay, yeah.


So So thank you very much for saying all the things about gems like trying to bring up all the pros and some of the cons because they are they are here but they are not so they are not so horrible.


That's yeah, once again, build what you're comfortable with will kind of like what you said earlier. It's there's no silver bullet. So build, what you're comfortable with build what you can work with the fastest and what is the best for your users.The end?


Exactly. So thank you so much for joining us. And everyone. Remember in two weeks, Ryan Sullivan will be our guest. He will talk to us about how to manage multiple Wordpress scale because his company maintains like hundreds, hundreds of WordPress pages at once. And they are doing it without JAMstack. So really this is this is this is not an easy thing to do maintaining all of those websites advance. Also, don't forget to sign up to our Buddy CI/CD group on meetup you will be informed about all of our upcoming webinars. And like I said at the beginning, don't forget to subscribe to our YouTube channel because this is the really nice place to learn a lot about CI/CD About JAMstack about WordPress and about so many other cool things. So really, don't forget to press that subscribe button. Okay, so, Cassidy once again. Thank you so much. It was a real pleasure having you here. And thank you everyone for joining us. See you in two weeks. Have a nice day. Bye bye


- Website Owners & Managers looking for a more efficient development cycle
- Project Managers aiming to break down the silos between IT operations and development teams
- Drupal Developers that want to automate repetitive work and get code into production faster









Learn how to speed up the Drupal development cycle and bring more value to your customers with an efficient and effective DevOps process.

Chief Services Officer @ Cyber-Duck

Sylvain Reiter

DevOps Lead @ Cyber-Duck

James Anslow

Drupal Lead @ Cyber-Duck

Duncan Worrell

Countdown

Why Drupal?

What DevOps is all about

Benefits of DevOps in deployment cycle

Deploying Drupal to AWS with Buddy

Deployment to other types of hosting services

Useful applications of Buddy in CI/CD

How to master Drupal deployment cycle with a proper DevOps process

Hello, everyone, welcome to today's webinar. Today we are going to talk a bit about how to master Drupal deployment cycle with a proper DevOps process. As you already know, I'm more of a WordPress guy. That's why I invited a whole team of Drupal specialists to help me, guys. Tell us a bit about yourself and about about Cyber-Duck.


Sylvain

Cool. Hi, everyone. So yeah, we're from Cyber-Duck. We're an award winning digital transformation agency based in the UK. And we've been growing organically for the last 17 years now, working mostly with Drupal and Laravel to deliver software as a service application and CMS solutions for clients, mostly, mostly in the UK, both in the private and public sector. And, yeah, it's been it's been amazing. So I'm Savannah writer, the co founder and chief delivery officer, I come from a technical background and gone through through the stages of deploying website manually via FTP to kind of building the whole dev team and growing the agency with a lot of experts, which brought me along today, then can gems or to you.


Duncan

Hi, I'm, I'm Duncan Worrell I've been with Cyber-Duck for about almost three years. I'm a Drupal technical lead. So I'm the person who has to rely on my colleague here, James to set up pipelines for me and Buddy, so I can deploy things easily. So I'm very reliant on DevOps. So I'm here on our supporting capacity to try and answer any specific Drupal questions anyone might have over two days.


James

Thanks, Duncan. You make it sound so easy, Duncan, but I see it the other way around. You see, I see that I'm here to support you to get your code into production. So that's your team synergy. Yeah. So hello, everyone. My name is James. I'm the technical lead for DevOps at Cyber-Duck. spend my day to day work, engaged in engineering effort and helping DevOps seem to support our software engineering functions to deliver code into production faster.


And my name is Maciek Palmowski. I work here at Buddy as a WordPress ambassador and the regular webinar host. So before we'll get started, if you like our webinars, do not forget to press the subscribe button on YouTube face to this, you will be always informed about some new upcoming webinars, and we are really doing quite a few of them lately. And also, if you have any questions regarding Drupal, DevOps, or whatever our discussion will, will lead us today. Don't hesitate to use either YouTube, LinkedIn or Facebook commands to ask them we'll try to respond to as many as possible in the end during the q&a session. Okay, so let me start with the first question. Why Drupal? I mean, looking at the market shirt. Drupal has about 1.3% and looking at the numbers WordPress Shopify week square, Squarespace and Joomla. So why did you pick Drupal?


Yeah, I can start on the I guess the more like the business side thinking about it from from the end users or the other clients and then my colleague can take on the tech and environments but yeah, look, we decided the time was several years ago to start with Drupal. We tried actually a bit on WordPress as well and other of the shell CMS is but as the agency groove realised that a lot of the projects were becoming more complex, and sometimes the clients requirements are a bit vague, where, if it's just a corporate website, it's might start small, saying, Yeah, we just want a few pages and explain about us having an online presence. But that was fine. 1015 years ago, nowadays, websites are much more interactive. There's much more connectivity with third party systems. A lot of the marketing team rely on marketing automation tools. And a lot of the more technical team wants to connect with CRMs and ERPs. And there's, there's been obviously a lot of advances in the digital space. And those complex requirements needs an enterprise ready platform. And we were just pushing the limits of WordPress felt like that as we got bigger clients. Some issues around the security and regular updates being WordPress being the most popular platform in the world is also probably the most attacked and invulnerable. So some of our corporate clients or even government bodies quickly moved away from that. And Drupal is the platform of choice in the UK, specifically the UK Government pushing a lot on the digital everything on UX and agile and on the technology side, promoting open source very heavily and and Drupal is one of the most used platform. So the answers a lot of the business requirements, it complies with a lot of the top level and corporate requirements. So we felt that was the best platform and it's proven us right in the last few years, we've grown exponentially and having a lot of Drupal projects coming in. So that's from the business side.


From from a technical point of view, I I was running a business at the time, and I had to decide on on a CMS and I looked at several services, including WordPress, and Joomla, and some others. And I settled personally on choosing Drupal. It seemed to fit my use case, I needed to create lots of different types of content. And Drupal seemed to do that out of the box. I think with with Drupal and WordPress is a conversation we could talk about probably for hours. WordPress is easier for sure. It's certainly easier for someone off the street to pick up and use Drupal is quite hard. But that that, that means it's also more powerful, I believe. So you end up in a situation where pretty much the Sylvan says you could start a website with WordPress and and there's been plenty of surveys done this that as you become more proficient in WordPress, become more and more frustrated with it. And the opposite is true with Drupal. The opposite is true. Because when you first start using it, you're you bang your head against the wall when things are difficult. But the more you use it, the more you love it. And Drupal recognise that that Drupal 10 comes out in December this year. And one of their big, big pushes is to make it easier out of the box. And that's very, very squarely aimed at the WordPress space at the moment. So for me, group, Drupal is a more powerful platform, arguably. But on with that you you have a very good community that sits behind you is obviously very obviously open source, which a lot of UK government contracts or mandate, they you have to use an open source solution. And it's also very scalable, very performant. And very secure. And I know these are all buzzwords, but again, demonstrating demonstrates the coming say that were true. You know, I every tonight there will be a security update for Drupal if they found anything. And they have a whole team of ethical hackers constantly trying to break Drupal. And that's not just Drupal core, it's it's Drupal contributed modules. So I like the fact that it's so dynamic. I like the fact that it's complicated, because that complexity gives me the potential to create some really, really good websites for our class. So that's that's why I like it. 


Fantastic it's a really good point that Duncan makes about the complexity, I think that we you know, certainly in terms of engineering, many of us have experienced this paradigm whereby, you know, there are tools out there that make the simple things simple, but then when you try when you try to apply them to the complex challenges, they actually make it more complex. It's kind of you know, that that kind of classic paradigm really, that there are tools you know, that make simple jobs simple but make more complex jobs as soon as you want to move outside the kind of confines of the functionality you're into kind of uncharted territory. Whereas, you know, certainly from the work, I experienced the teams that Cyber-Duck doing, it seems like, you know, the Drupal space, we have a good a good framework to, to build functionality according to, you know, the Drupal community's ideas, but we also have plenty of scope to build our own, you know, tools and processes outside of that, where necessary, and that includes things like partnerships, you know, partnering with companies like Acquia, to provide cloud services, and the kind of benefits that they provide, we can talk about that a little bit later.


Okay, so, like, our topic says, we will be talking a bit about DevOps processes. So why do we even even need DevOps? I mean, apart from using this really nice buzzword because DevOps is so cool, right?


Yeah, so I think I can talk to this one. Still, when can tell us why he thinks it's important to so we can hear both sides. So yeah, so So my background is mostly an engineering really software engineering, and infrastructure. And so I kind of, you know, have more of a kind of traditional engineering point of view on this, but, but also, you know, understand the history. So, you know, say, five or 10 years ago, the kind of the traditional paradigms in, in this industry, in software engineering are that there are two independent and distinct teams, which are working towards common business objectives, but quite often have different priorities. And those two teams, as the name implies, would have been development and operations. Right. So the job of development is to build functionality build software, move quickly produce features, add value to the business, that's one side of the coin is the development. The other side of the coin is the operations. The people in operations, their responsibilities are, keep systems running, maintain stability, you know, change control processes that are very rigid or beneficial to them. And so these two competing forces have often had a kind of siloed approach to their common goals, developers produce software quickly, and want to get it into production in front of the business users quickly, to deliver value quickly. operations teams want to maintain stability, so they can be more resistant to change, and less willing to push regular changes, because of the processes that are involved in doing that. Quite often manual rigorous reviews. So this is where DevOps comes in. It's the amalgamation that coming together of two different kinds of effort really, the coming together of development and operations developers and operations people really in a in a kind of, in a culture of DevOps. So the key function of any DevOps team, any DevOps engineer is to empower their colleagues to deliver functionality to the business as quickly as possible. In Cyber-Duck, for example, we have a DevOps engineering team who work with every team in the business, front end developers, back end developers, you know, design, user experience, QA, these teams all working together to deliver change quickly. And the main way we do that is through culture, is by embracing the culture of DevOps, which is a kind of spin off of agile and agile principle, to deliver value quickly and to the business. And you know, the tools and processes that support that are pretty kind of ubiquitous across across different disciplines. So, you know, if that means, for example, automation, we can apply that automation to our back end development, to our front end development, or testing to our server deployments. All these areas can benefit from the DevOps culture, without needing to be a DevOps team, so to speak themselves, we imbibe the culture and the business and then everyone has the value of it.


I really liked that you are talking about DevOps as a culture inside of the company, rather than what some tried to say that those are tools. Those are specific roles. Now it's all about about the culture about the way how we work. So yeah, I fully agree with you.


I think you you quite often find that it's a really interesting point, you quite often find that in the teams who see DevOps as a as a as only a specific job role. They tend to actually be not really doing DevOps, they're just doing ops, right. Yeah, exactly. Exactly. It's like we took operations, we took these rigid structures. We applied some cool tooling to it and we're calling it DevOps. but it doesn't work in reality unless you have the culture and, you know, to be perfectly transparent, you know, one of the main challenges with the culture is, is delivering that culture to every part of the business. It's you need complete buy in on every level, you need buy in, from stakeholders, from directors, from people in positions of management, and in engineering, in customer relations in new business, you need buy in completely throughout. Because if you don't have it, and what you end up with, is you end up trying to shoehorn the DevOps process at the last part of the process. And then it just doesn't, it just doesn't work. There's frustrations throughout. So you know, my experience is that the best DevOps businesses embrace that culture and invite it into that into the core of their being into their strategies, business processes, their identities, and they live it and breathe it. They don't just say you go do DevOps, right? Yeah, doesn't really work like that. You could call that person an automation engineer, perhaps, but it's not DevOps.


Yeah. What about the business, the business side of DevOps?


Yeah, for me, main reason is DevOps is the ability to scale and scale kind of safely or confidently. Because yeah, we all started, I guess, as kind of web developers in our bedroom, kind of deploying our first websites. And when you are alone, it's fine. You have you work on your own code, you then can explain can push to FTP, and like, you've managed all of that you have to control everything and you do the front end, the back end, you create your hosting account, and you have to do your DNS things. And then that's fine when you're on your own. But as soon as you have a bigger project, or you start building your team, or can have multiple developers start working together, it's not it's not scalable. So DevOps allows you to minimise risk and increase efficiency, minimising the risk by automating some of the steps. So yeah, deploying code by FTP overwriting each other up that it's prone to many errors. And I'm sure we've all done them where you forgot to deploy a file or you don't lie, the right changes to the right config item or something missing somewhere in your pipeline. And so reducing human errors through automation is one of the main business benefits. And the other one is maximising efficiency. Because with the rise of cloud technologies, we don't have to wait two weeks to deploy dedicated servers in Iraq, or you don't have to wait for the next release. Like some some clients still have like, a yearly release schedule where if you want something deployed in your app, you need to wait another six months for the next deployment cycle or something. So again, the efficiency of applying those that automation and the automated testing all of the benefits of DevOps, bring confidence to the team, and just the developers, but also the management, that things can move much quicker. And you can deploy testing environment with almost every day and the deployment to production is one click and so many benefits that the efficiency just go through the roof. And that's why we're using it on every single project.


So if we could sum up, what are the benefits for each group for developers, for clients, for managers? How would you say,


Let me talk about developers. I haven't spoken for ages. I think for developers, we've covered much of it, it's repeatable processes. As a Drupal developer, we want to develop a Drupal solution. Normally, we'd be doing that on our local systems, our Mac's or whatever we're using. So but to get that stuff deployed, we don't want the hassle. We don't want that. Okay, how do I do deployment, but what we want to do is is, is have a pipeline set up where we can click a button, and it does it, it's a repeatable pattern that we know is the same every single time. And we know we can go into testing so we can do our QA cycle. We also want that same process to be in place when we deploy to our staging environment. So we can perform user acceptance testing and clicking the same button with the same pipeline gives us a great amount of confidence that we're going to deploy exactly the same thing in exactly the same way. So we can test it. And also, of course, have the final deployment into production when we go live. So it gives us a repeatable pattern. Something that theme Silva mentioned about being able to spin up new instances quickly, that that hasn't been around for very long. You know, I guess we're talking about cloud instances. So I need a new service seminar. I don't want to do that really. I can lead up to DevOps, and then they can repeat the or effectively clone a pipeline for us. And we know this is going to work exactly the same as every other pipeline we deploy. So so forth for devs it allows us to concentrate external development. But it gives us a huge amount of confidence that when we do deploy stuff, that it's going to every single instance in exactly the same way. So that's the biggest benefit, I think from a development point of view.


And businesses had before the increase the frequency of release, I guess, would be the main, the main benefits, like were mostly still need to wait for the developers to do their part. But in terms of releasing features to product or to an application, any system really, it's, it's the guarantee that there is an automated deployment process, there is a roll back step I've been involved in. And again, all of that takes time to build over time. It's not, it's not, it's not one tool that will do all of that. And so that James was mentioning this Agile methodology and this notion of continual improvement, so you can always improve your process with from the dev and the ops side as well. So that is just part of this agile culture, agile methodology to continually improve the process and make it more efficient, more secure, more scalable, and bring more confidence to the business.


And what about clients? What are the biggest benefits from


For clients, that's a good good one as well. I would say lower costs overall, even though it's a bit of a higher investment is kind of traditional roles. Additional tools that you might need to subscribe to, to quit see at the beginning is a bit of a Yeah, the initial phases requires a bit of upfront investment. But from again, I've been we've been doing it for what four or five years now, benefits, you just kind of get are amazing. And you make whatever it invested the original investment was you make that up in the first couple of months, probably in your first few sprints, it already pays off, because yeah, it saves time, the developer can focus on building actual features and not having to worry or repeat deployments that are failing. So yeah, again, higher efficiency, lower cost and more confidence,


Lower risk, isn't it, we're talking about lower risk risks to the, if you're reducing your costs, increasing your efficient efficiencies, you're reducing your risk of the business running out of money for your projects, also, the risk of having a deployment go wrong. That's the worst thing, you make a deployment goes wrong, it just doesn't happen anymore, we've got a large amount of confidence, particularly as we're deploying with the same pipeline across different instances, we've tested it on two or three different places. So it reduces the risk for live deployments. And that's reducing risk is always good, it's one of those things, you don't notice until you lose it. You know, having a pipeline that works every single time, you can be a little bit ofay about it. DevOps is easy, we just hit the button and it deploys those those pipelines have been developed over, you know, years of experience. So good DevOps team knows how to set up a pipeline well knows how to create the server correct in the first place, knows how to put all those all those things that start with CF in front of Things Cloud free, cloud front. So on Cloud Foundry, happens on all begin with all those things in place, so you don't have to worry about them. And that decreases the risk to the business which ultimately saves money. And I guess we're talking about isn't it making things more efficient.


And we've ever had, we interview the client actually last year about the DevOps process that we applied and why they selected us to run it for them a global kind of corporate website. And he's saying as it was more from from the IT side, but client side, that trust is earned with confidence. Unfortunately, in being in it, he was struggling to connect with his marketing team was kind of owning the product, because was delays in releases. There was a discrepancy between environments, so they were testing something in UHD. And that was fine. But on production, it stopped working, or it's not working, behaving the same way or some of the jobs or the config were different. And then every time it couldn't really answer you have good answers for the marketing team saying like, yeah, it was just it did fail sometimes and complete lack of confidence. And, and yeah, everything was was taking longer, it was difficult to add new features, and it's just very overall very inefficient. With DevOps that applied throughout the whole lifecycle and rebuilding kind of migrating to AWS and building a proper pipeline. And applying the agile methodology now they're they're in a much better position and him being in it is almost not involved anymore. The marketing team runs it and they deploy when they give us the go ahead for the deployment, it's happening without it involvement. So very happy clients.


Yeah, I can, I can understand that. Okay, so I think now it's time for the part that most of us are waiting for. So how do you deploy Drupal using body? Let me share your screen already, James, because I know, now the scene is yours, go for it.


Thanks. So, as Duncan said, quite rightly, you know, when we're running deployments to web sites for clients in Cyber-Duck, it's usually actually the development team that running those deployments. It's not it's not the DevOps engineering team. You know, the, the whole purpose of DevOps, as I said earlier, is to empower business users to deliver, you know, quicker. So, you know, we like to build automations as much as possible and use those automations to allow our developers to release their own code. I think everyone's made really good points about kind of, you know, standardisation, automation, or the benefits they provide. I think it can't be understated, how beneficial is the single click of a button. through automation, we can enable a consistent release process by anyone, you know, the kind of the days of centralising that knowledge and that control in a silo. And all the risks that come along with that. They're they're kind of long run with DevOps, certainly in Cyber-Duck. So, yeah, what I'm showing you today is, is a website, it's a website for the Commonwealth Secretariat. Obviously, very well known public institution Cyber-Duck, built this website, for the Commonwealth Secretariat as a project, it's obviously based on Drupal. Hence being used as a demonstration for today.
The tooling that we use for this is for the DevOps aspects, this is hosted within AWS. So we're using many of the AWS well known services like easy to to provide us with Compute and load balancers. We're using rds, for example, to provide MySQL database service. And we're using many of the other supporting services to like the usual ones, s3 for your file storage, and I am for your identity and access management. So how does Buddy tie into all this? This is the question, well, if you take a look at our pipelines in Buddy, this is the user interface through which developers can deploy their code. Within Cyber-Duck, we've got a few different environments for this particular client. And if we take one of them, for example, we can see that we've got a history of the different runs that were executed against this environment. This is the testing environment for this client. Building this within Buddy, for us is a simple case of using the interface that we see here. And quite often copying the existing examples we have for other clients. If we look at the steps that are actually required to build and launch a site, a Drupal site onto AWS, it's really straightforward. And there's lots of scope to add additional steps and functionalities as required. So in this case, this is the most basic example, which is each of the steps being executed sequentially in order. So first of all, we're performing our composure steps. So that's, you know, instantiate composure, you know, instal our dependencies, run config checks, etc. All of those things are executed within the step here. I can click through to it, and I can get more information about that step. You can see, for example, that this manual steps that we're taking here, and something that's interesting to note is that all of these steps are being executed within containers. So we know that we can change the container that this is running within and tailor the specific step to the functionality. In this case, we're actually using our generic PHP container that we built within Cyber-Duck with many of our common dependencies to run our composer instals. So first step is composer. The next step is we execute our front end build, we're installing node packages, running builds, you know, building our assets, which are ultimately going to be deployed to to AWS. From there, we're configuring AWS. So this means within within Drupal, we've obviously got different config files. And the conflict files vary depending on the environment. So if we're running locally, we have local development credentials. If we're running in production, we have production credentials. And in this case, we're swapping out the config files within the artefact that we're generating to ensure that the application will run in production that things like database connection strings are in the right place URLs are set correctly, and so on and so forth. As this is a testing site, we have some HTTP Basic auth in front of it. This is just one of the steps that we take to protect the non production environments from web crawlers who would otherwise index it and you'd have your testing site appear on Google, not a particularly sophisticated security mechanism or anything. It's a public site after all, just a means to keep it out of search engines in a simple, consistent way that we can use across projects because it's in our pipeline. The main two steps which perform the majority of the heavy lifting are actually templates, which we use directly from Buddy. We're using technology within AWS called Elastic Beanstalk. Elastic Beanstalk allows us to provision compute environments and have great benefits like auto scaling, automatic security updates, automatic monitoring, automatic rollbacks, of problematic releases, all these kinds of quite, you know, enterprise grade, sophisticated compute features of cloud environments, can come out of the box in Buddy when we deploy through their pipeline.
Once we've deployed the code, we monitor it, a key part of the process is, in the cases of our clients, we have fault tolerant, highly available cloud infrastructures, what that means, really, is that everything has multiple, redundant copies. So if you take the kind of traditional service paradigm, which is what we'd call compute, that's got redundancies, we're running multiple different Compute Engines across multiple Amazon availability zones. So there's redundancy both geographically and also within the technology. And it also allows us to scale to meet demand as required, we can add additional servers additional compute capacity to meet increased traffic demand, particularly important for a public site. So this is our monitoring step monitors the release of our code as it's gone into AWS. And then in this case, the Commonwealth is using the Cloudflare service, which is a very well known kind of all in one networking service company who are providing, amongst other things a web application firewall for security, content delivery network for performance, and a number of other kinds of routing and auditing based services for the site. We want to clear the cache from that, obviously, after we've run a deployment, things usually change, we want users to get the latest version of the site. So again, we use the built in Buddy integration to achieve that. And then within Cyber-Duck, we try to encourage communication, especially with our automated tools. So whenever a deployments run, we're popping a notification into our Slack channel, just to let the developers the engineering team know that a deployments been executed. And we give the output of that whether it's been successful, or there's a challenge that they need to review. This is all information that's fed back every time the deployments run. It's worth saying that these pipelines that we're executing here, whether they're production, staging, testing, or even a CI pipeline, a continuous integration pipeline, which would be run every time an event is triggered. These can all happen either manually or in an automated fashion. So if, for example, you had a testing environment, and you wanted to deliver deliver value very quickly, you might configure this pipeline through the settings, so that it will run on any action that your developers take. So if a developer adds a feature, that's bleeding edge, and they want to get it to testing as quickly as possible, we can use buddy's built in functionality to make this pipeline run as soon as a change is committed to the to the version control technology to get. So the developer makes that change. They committed to get they save it, they push it and then straight away the pipeline is moving that into the testing environment to get it in front of internal stakeholders or testers for example. What does this actually look like when you're running it? Well, I mean, we can we can run it, it's really simple. You click run, you scroll to the bottom, you run. It's running. Right. That's, that's the deployment. So the process, James, sorry.


Let me just ask you one question, because this is, this is one question that came in our comments. And it's really about the thing that you said, Does the monitoring, deploy monitoring tools or just monitor if the deployment went? Okay.


Good question. So, the monitoring is Yeah, So to clarify, the monitoring is not monitored, deploying monitoring tools, it's monitoring the the rolling release that Elastic Beanstalk is carrying out. So that's monitoring to make sure that the current release happens successfully. The monitoring tools is a separate thing again, which just just to clarify the distinction, we're using Buddy to provide the pipeline, which allows us to move code from our development environments into either production or non production environments. The monitoring is monitoring to make sure that that release happens correctly within AWS within the cloud environment, that it doesn't roll back. If it actually has to roll back, you get what we see here. The see the first one has got a red cross against it. We executed a production deployment, there was a challenge, it was rolled back. And as part of that rollback, we saw that the monitoring flag that there was an issue here and an engineers working on that. So yes, that is monitoring the deployment, that's not monitoring the infrastructure. As far as infrastructure monitoring goes, many tools, we can probably talk about that more in a whole nother talk. Yeah, we use a fairly diverse set of tools for monitoring depending on the needs, most of which are, you know, fairly well known in the industry, many of which are specifically within AWS, if we're using AWS. And, you know, yeah, how are they configured? Probably another topic entirely. But we're, we're using infrastructure as code so TerraForm to build infrastructure for clients, which also then feeds into the reproduce, reproducible and cost transferable value that we can deliver.


Okay, yeah. So, at the moment we are waiting for for the deployment. Yeah. Because I always remember that that beanstalk can take a while.


Yeah, so so the way that this is possibly a digression, but I find it quite interesting, the way that Elastic Beanstalk works is you it's a platform as a service, right? We might have heard this term before pas, there are many different platform as a service offerings out there in the in the tech industry. You could you could use Azure, you could use web apps, you could use Elastic Beanstalk on AWS, you could use platforms like SSH, you could, you know, the Cloud Foundry is another common one that we use. There are lots of different choices out there for a platform as a service. But the fundamental principle is that you provide it with a artefact, usually a, you know, a website, and it takes care of deploying that to the infrastructure for you. So it reduces, again, reduces the management overhead required, and increases your time to deliver because you're focusing on building pipelines to deliver content, not on maintaining complex infrastructures, you abstract that infrastructure away and use the automation tools to enable that. So that deployments completed now, deployment to our testing environment is done. Cash has been cleared, cleared, notification in Slack. So that's it, we're done. We've run our deployment. It's as simple as that.


And what happens if something if something fails?


So it depends. It's a complex question with a complex answer. It depends on what step it fails. So if, say the composer instal step fails, the pipeline is configured to just exit at that point, because nothing's actually been changed outside of Buddy. In that case, we can just run it again or correct the problem and debug it. If it's the actual AWS deployment step that fails, then AWS will roll back the version that has been deployed and return us to a safe state. So the idea is that we want to in all cases, fail safe, we want to fail close. So if there's a failure, we roll back with automation. The advantage of that method is that if a failure occurs, which let's face it, you know, things happen, then we always know that we're going to be left with a working functional site, we're not going to be left in a broken state. That behaviour is all configurable within our pipeline. So if we go for example, to our actions, we go to composure, we can define what happens when an error occurs, what do we do? You know, do we carry on do we stop? What are things like timeouts? Do we auto retry? These are all options that we have to configure straight here within the user interface.


Okay, and so another question I have is a bit more related to what other house hosting companies about for from AWS, are you using?


Do you want to talk to this silver or shall I talk to this? Alright, go ahead. Okay. So, historically Cyber-Duck, were using Rackspace, which is a well known kind of UK based consultancy company providing mostly kind of physical hardware but also more recently, cloud services and consultation I think, you know, Rackspace are pivoting now towards cloud as well. But kind of historically, it was more kind of bare metal servers, you know, physical machines and racks. And that worked very well for Cyber-Duck, you know, when the relationship began, and it's worked very well for a long time. But as we've adopted more DevOps principles, those kind of traditional relationships didn't work. So well, we needed direct hands on with the cloud platforms themselves as our internal engineering teams grew. So nowadays, we have a small relationship with Rackspace. But for the most part, we're working with AWS with Microsoft on Azure. We're working with Acquia on their various cloud platforms. And there are a few smaller engagements as well Laravel Forge, for example, where we're doing larval development, but the main kind of three really are AWS, Microsoft, Azure and Acquia. Were with I think, all three right, silver partners with partners, Microsoft,


they on three, so depends on the client's requirements, or what's best suited for a job, basically. So yeah, with the software relationship, some client wanted the, the no code editor of Drupal, to kind of drag and drop landing pages and blocks on pages and the Acquia sites Studio is a great product for that. And and obviously, it's bundled within the, their hosting services, you get one or the other comes with it, or you need the other one when you buy studio. So we kind of bundled that. And yeah, just did have minor tweaks to our deployment process was a question actually, in the chat I saw as well from selling about the Acquia deployments. I know James had prepared some some for that. You explain a bit about the BLT tool and how he's kind of hooked that up? On the Acquia side?


Yeah, I don't, I don't know, whoever was paid to ask that question. It's a great question, because I actually prepared a very small example of that. So yeah, so you know, Acquia is providing us with BLT tool, which is the build and launch tool, you know, accurate as a company are offering many, many services. Now, some are focused around kind of infrastructure and, and cloud computing, some are focused around software consultancy and, and everything in between really. They're providing also some, some pipeline functions. And while in this case, it was actually more beneficial for us to stay for the most part with Buddy for those functions. And we can probably talk more about why we chose to stay with Buddy for those pipeline functions in a minute, but for now, I'll simply say they provide lots of different services. And so for us as a engineering team as development team, it's very important to understand, you know, when you've got that many services at your disposal, which ones actually best meet the needs and the needs of the client. So in this case, we chose to use BLT to effectively build an artefact and push it up to Acquia Cloud where Aqua would then handle the automated deployment of that onto the infrastructure that they're managing. So in this case, we've got a we've got a pipeline, which is running the BLT tool. Effectively, the the first few lines are kind of internal housekeeping. But within a Docker composure, we're basically just running these two commands, which is just a straight up composer instal. And then using BLT using the artefact deploy command specifying the branch we want to deploy to. And that will take care of the deployment for us. I don't have a live demonstration prepared of this one. But the kind of process for BLT in this case is that it will, it will take the artefact that the kind of the code base it will it will sorry, I will take the code base create an artefact from it running optional kind of hooks and scripts, it will create an artefact and then push it up to a remote Git endpoint. And then once it's in that remote Git endpoint and event is triggered, and accurate handles the deployment of that into the environment that we specified. There's lots of other things going on within BLT, it's well worth reading the documentation. We're using BLT more in local development as well to enable some cool features that we don't have with other frameworks. So things like you know, linting on commits and checking of checking commits for kind of quality and some some testing and local platform hooks, all these kinds of things. We're using BLT for locally as well. That's kind of our scope of Buddy.


Yeah, but I don't I mean, at the end of the day Acquia is just another flavour of Drupal. So it's very much part of this discussion. Accurate has a way of doing things pretty much it's very, it's a very opinionated in a technical sense of the word. So when we first started using Acquia, a couple of years back, we didn't suddenly have to look at our DevOps pipelines and say, Oh, how on earth are we going to fit those with how we want to do it, there was some discussion at the time about the best way to do it. But we definitely have a good way of doing it now, which I think Gaines is talked about. So it's, it's a different way of deploying. But the same is true of some other platforms we hosted, we also host our platform, but sh, and also, government UK pass is another hosting solution. I'm personally quite involved with on a daily basis across two or three different projects. So yeah, there's there's, there's always a way we, particularly with Acquia, we wanted to carry on doing some of the things we were doing on other projects. So again, we have a constant approach across many projects. But also use those BLT tools to make best use of the great things Akriti provides. So it was quite a bit of a hybrid approach we used with


it now. Okay, yeah. Tell me, because, James, show us some basics of how you deploy Drupal. But I know that every CMS has some quirks every CMS needs some polishing near the end. So how does it look like with Drupal? Probably Duncan, we'll help


you with Drupal. And then if you read read the documentation, again, why of deploying a Drupal website is you take it back off the copy the code up. And then you have to run a run a number of commands either from your browser or from the command line. Most people here listening who are familiar with Drupal, hopefully I've heard of Drush, which is basically the Drupal command line interface shell interface Drush. So what we what we typically do for deployments for all of our Drupal websites is we have a post installation hook in Buddy, that runs three main commands, and that hopefully most people will be familiar this week. So we've run Drush update dB, which allows us to run all our update hooks with about allows us to tweak the database, delete files, those sorts of functional changes you want to deploy as part of your software update. We also do a couple of configuration inputs. Configuration imports can be configured so that they're different for each environment. So you'd have one for testing, one for staging and one for production. So we'd run that twice. The reason we want it twice is often the first one does most of everything. And then the second one tidies everything up. And then we the fourth command we run is we do a cache rebuild. So yeah, Trash Trash car. And we can build that build those train to the pipeline, which means we end up with what we're after with a one button deployment process. And we can look as James James jumped into the deployment. And what I love, what I love about Buddy, is that user interface is so intuitive, you won't need any training to use Buddy. So you can come into each one of those steps and see what it's doing. You'll see the error messages in there in red, you know that? It's good. We, I did a deployment this morning, a half past seven this morning with a big government project. And, and they they come on to the meetings with us. And they watch us to do the deployment through Buddy. And we go into those things. And we show them Buddy. It gives the client a huge amount of confidence that, that yeah, we that's what we saw last time that that's what what we're expecting to see. And it's like some of the commands just showing a code. But when you're running deployment, and clients can see the progress going through and nothing red. And moving on to the next step. It gives them a large amount of confidence. And we're more than happy to show trans Buddy from a personal point of view, I just love the way Buddy looks. It's it's great. And very occasionally we've we've been you've made a change and we've gone without like that and you can there's a chat icon, bottom corner, I've gone into site. I don't know what you've changed, and they said a few people have said that well said we'll change it back. And lo and behold a couple of weeks later, it's fixed. And that's for me and I know this is a this is a Buddy webinar. But that's it very responsive, just just to make small changes to make our lives easier checks in the face, as I say. So, to answer the question that there is a whole lot of post installation that happens in a Drupal project, we can automate that through by the pipeline's


interesting question from Mark just now then Ken, would you give the client you did this morning the release? Would you give them the trigger to deploy? Confidence in Buddy for them to do it? Yeah,


we could do. We don't, as it happens, we have quite a sophisticated runbook for this client. They're a government organisations we have, we have a lot of checkpoints we go through, but we also share the runbook with them. So they can see us, you know, saying, Yeah, dun, dun, dun, dun, dun, dun, quite near the bottom, it's deployed through Buddy, hit the button. So it's, it's a long...


We do do that for some clients. So we have specific cases where clients approached us for DevOps Services, you know, if they want to help us to use our knowledge to apply to their business to improve their delivery, they've heard about the benefits of DevOps, they'll come to us and say, you know, we'd like you to consult with us on how we can improve our release processes. DevOps culture, will actually build pipelines for them in Buddy, you know, maybe even build infrastructure using infrastructure as code tools like TerraForm. And we'll build the AWS environment for them. And we'll build the Buddy pipeline. And they will perhaps have their own development team, their own software engineers, and will kind of build those tools, educate them on the culture, provide the consultancy, and then kind of hand it over to them. And they then do run their own deployments through the through the tooling. So I think the answer is like What Sal said earlier, right? The best tool for the job, and also the case that each, each organisation is usually different, right? So different people, different companies need and want different things. And so what's really important is the flexibility. This is something that we've not kind of really touched on. But it is very important to us as a company that Cyber-Duck that Buddy allows us to deploy to any platform, you could imagine, really, with any kind of technology, you could imagine. If you can script, if you can automate it, you can use Buddy to deploy it to enable that process to enable the DevOps culture within your business. So for example, if we're deploying a Drupal site to Acquia, or a Laravel, app to AWS, or anything in between, right, we can use Buddy to enable common workflows that allow us to do those things. So we don't have to use Azure DevOps for the Microsoft Azure stuff. We don't have to use code commit on AWS, or pipelines, we don't have to use Aqua pipelines, if we don't want to, we can kind of contain our knowledge and our processes within one location, and then just build out integrations as required. I mean, most of them are out of the box anyway, with Buddy. So


yeah, and if if needed. Also, it's also very easy to change this one block. So for example, you were using AWS, but at some point, you want to switch to Azure, or whatever. So we are just changing one block and the rest of the pipeline stays almost the same. So this is also something something great. And tell me, because we talk about deploying things, but how else do you use Buddy? What else do you automate using it?


I'll jump in really quickly. Some of the some of the things we use it for. Strangely gov.uk Pass has no no ability to create cron jobs. So we have periodically running scripts on our Drupal websites that effectively replace Cron. So that's, that's one thing we use. By default. James has already talked about an a CI CD. We also use it for obviously, running automated testing, which is triggered based on commits, and things like that, so that you can use it for a lot of things. The deployment I was talking about earlier on the slide is a bluegreen deployment. So there's a there's an ability in Buddy to come to a point and pause and say, Are you ready to continue? And at that point, our client goes in does a smoke testing. Yeah, we're happy to swap over. We click a button, it stops two instances over blue green swaps. I never know which ones which blue, green or green blue. Anyway. And again, it's automated. So we know it's worked. It just it just brings us a huge amount of confidence, working on jumping in about anything else James testing, or


we're using a few we're using it in a few different places. I mean, we kind of in some cases, we're almost using it as a kind of drop in for services like AWS lambda where we want serverless compute right? So there are cases where so give you a really solid example and Do we use a very well known off the shelf software as a service product to host our Git repos? I don't think it's super private. We use Bitbucket for many of our projects. And one of the main challenges of using Bitbucket cloud for, for us has been that there's no kind of, you know, being a software as a service product, there's no kind of out of band backups of that, right. So, you know, Atlassian is obviously a huge company. And you know, we trust in them in their software as a service product. But at the same time, we wanted that guarantee that we could have a local offline out of band backup of all our Git repos, you know, if something catastrophic were to happen to Atlassian, and I'm sure it never will, but build redundancies into your systems and all that, we wanted to take an offline copy of our backups. So what we did is actually built a Buddy pipeline, that would execute on a cron using Docker, and built a very small kind of micro service in Laravel in PHP, to enable us to query the Bitbucket API, pull away copies of each of our repos and zip them up, encrypt them, transfer them to an off site backup location. And we do that on a cron, every month within Buddy. So that's a really good example of how we're using it not just for deployments, we're using it not just for continuous integration, not just scheduled tasks on platforms that don't support it, but also to support our business operations. That's almost an IT function, you know, we're kind of, we're empowering every part of the business really using Buddy as a tool. So it's been very versatile for us.


And then there's new been Google Lighthouse released an API recently as well. And we're looking at ways to automate accessibility testing performance testing, because there is an API endpoint, we can write a script and trigger it with, Buddy. So on top of the, the AWS monitoring tool, you could also run a post deployment check on performance or accessibility or pre deployment, probably I would say for for accessibility, like render the code and make sure everything is still compliant. Or you could have those triggers either pre or post deployment to to add additional confidence to the business in other areas, security pen test as well potentially make sure we don't think something was we started exploring as well. So it's something you could run as well to make sure that every deployment you're not opening up a new vulnerabilities. And that's, that's all the future we're looking into. Now,


James mentioned, we use it for our own backups, but it's something you can also you could allow devs to take a backup of service as well, from from Buddy, you, don't you try and keep devs away from the shell and the live system bases and all that. But quite often, you will, you will need a local copy of the production database or certainly a sanitised copy of the local database, we tend to employ a solution where we will clone from production to staging and part of that planning process. We obfuscate the data, but and then without the devs to get very easily to those staging backups, which they think then they can bring locally. And they know they're working on the most recent copy of the database. So all those things can be done in in Buddy. Now the latest it's a tool, which is created for deployments, you can use it for a lot more.


Yeah, I mean, I can tell you that at some point while playing around with IFTT I connected Buddy to Spotify and every time my push to server succeeded plate I have the Tiger I mean after to push us a bit annoying but yeah, I did it I did it work. So when it comes to practical use cases, I think my my was the least useful. But if someone needs to it's it's really possible and


implement that on all our all our Buddy quite nice, James, raise a ticket. Hold on. I'm


just gonna Duncan's access Hold on. With great power comes great responsibility to use a cliche.


Yeah, exactly. But that was true. And said, because you you mentioned a bit about accessibility. And I was thinking, what else are you thinking about implementing in your in your pipelines? Because yes, this accessibility thing, this is something very important. I can tell you already that it's that Buddy like plays really nicely with X CLI. So this is this is the first example and this is also a great way to start testing applications. But what else?


Yeah, it says the main the main thing is security, accessibility and performance. already, because it impacts now SEO impacts kind of most of the business metrics. It's the law for accessibility from all public institutions. There's a thing, there's a lot more improvements we're looking at on the front end as well in terms of compressing things, caching assets. But yeah, there's, again, there's, there's a lot of tools. So we need to find what works best for our process, start, start small, do build a proof of concept, and get management and clients on board. And then we can expand our services on that which inflates build one and reused many times once as Genesis playing once we once we've done it, we can clone it to all our other clients. So being great benefits for everyone.


Yeah, yeah, I mean, I really can't wait, when you will start adding those things that we'll have for sure. Next topic for it for a webinar, right? Evolve, how to evolve your pipeline during during the year or our months. We have some questions from from from the audience that we got before from from the signups. So I think it's time for for for the q&a. So let's start with this one, what is the best deploy process


I would start I would say it's whatever works for you, it really depends on what stage of the journey you're on. If you if you're still deploying manually, then the best one would be one that saves you time or one that gives you more confidence. So you don't have to feel like the next release is going to be the most stressful part of your week, or have to wake up in the middle of the night to fix something. So just start start small automate the most time consuming and the riskiest part of the process or whatever it could be. And, and yeah, that would be that would be the best one for you. But obviously for for our more advanced and corporate or public sector deployment when we've been improving them for for several years, then that's going to be continually improving. So thing that's that's it's hard to say which one will be better with the Lord invest in the future.


Like James said at the beginning, don't DevOps, the term came from the agile methodology. And in Silvan, sort of said the same thing they're effectively is that the best thing to fix is your biggest pain point, or the things that that thing that keeps going wrong the most, or the thing that which you have to struggle around scraps of paper and work out how to do things, automate those things. And I'm a big believer in in constantly changing one thing, and seeing whether it works. And if it didn't work, you back it up. So the best deployment process is probably the next one you're about to write. Because you should always be constantly improving. Agile is not about being nimble, so much. It's about constant iteration of constantly improvement. So the next best deployment process is the one you're gonna write tomorrow.


Yeah, that's that, that's for sure. The next question we have, how to ship database changes using Drupal.


We've sort of already covered that, that's the update DB script, which we can run as part of post installation. So Drupal has a really good mechanism for running post update hooks. And those post update hooks sit at module level and indeed, a core level. So basically, what happens is you can write a script to PHP script with a particular designation. And when you do the deployment, Drupal will look through all those scripts and go run that one that run that one, I've run that one, I've not won that one, I run this one. And it basically gives you a list of all those it's about to run, and then it will run them. So you can use those scripts to do all manner of things all manner of things. A good use case is a a contributed module might change the database schema, and it needs to move some columns around into the new schema. And that will happen automatically when that module updates in Drupal. So you may not even know that change is about to happen. But running the update DB script, just automates that process. And because we're automating that running of the update DB script, as part of the Buddy pipeline, then all those things will happen automatically. And of course, you can write your own custom scripts as well which run as part of that process. If you need to do any, any housekeeping or creating content automatically. You can do that as part of the custom module, custom update. It's, it's barely into Drupal, and it's initiated through the Buddy pipeline.


Understand Yeah, so in short, it depends, right? Yeah, or favourite? It answer for everything. And the next thing, how to break the traditional engineering habit to a DevOps mindset for engineers and management. Yeah, this is this is really something interesting.


That is a few points. I guess, for me looking, I guess from the top would be, as I said, it's it's a bit of an investment. And there might be some, some pushback because it is, it is a change. And maybe James can talk about the cultural element did at the beginning, but it's about bring bringing confidence, sediment, the main thing that the way to break is to, to break that mistrust, I guess, or to change the habits is to show the benefits like because you can have even the tiniest step added to your process that can make a huge difference. And, as I said, or pipeline have been built for for several years, but start small, like show, show them show show your team, how safe and how much better it can be trust by automating the most painful element and, and that's, that could be the beginning of change. I think that's, that's, that's how it started at Cyber-Duck. And that's how we were explaining it to clients. And yeah, it is, it is a change, but you don't have to, you don't have to send the whole company on the on the three weeks training and the whole kind of culture will take months or years to build. So just start small, that's one one, start with the development manager or the marketing team or, and then then it will climb up to the rank and permits the other departments will be my my answer.


Yeah, it's basically spot on it. Just Just to reiterate, really, and re emphasise what you've already said Silver's that, you know, I think the first and most important thing to consider when we're talking about changing, the way that we work is that you need that buy in on every on every part of the organisation. But But perhaps most importantly, you need it from the kind of management and the leadership teams in the business. Because, you know, DevOps, as we said, as we've said, it's becoming a bit of a broken record now, but DevOps is a culture. And so you need to adopt that in every part of your business process. So if we take the traditional, like the agency example, DevOps culture has to be a part, you know, part of the marketing effort, or part of the new business effort as a part of the kind of initial exploration and scoping efforts. And then, you know, many steps down the line, it has to be part of the technical efforts in, you know, kind of release engineering and development, and so on and so forth. And then post release support and refinement. So, you know, if we, if we try to approach this as a thing of kind of, how do I swap from tool a, tool B, you know, we're only ever going to get limited benefit, you know, if you if we're thinking in terms of how do I swap from FTP to Buddy, we've got a small piece of the pie. But we're missing out on the whole cultural change that can really benefit the organisation. If we tackle it as a cultural shift. First, as I say, that requires, perhaps most importantly, buy in from company leadership, because they'll be able to, you know, work with the kind of work and kind of set the agenda for the teams in the business and the kind of strategic plans of the company.


And I think it depends on the organisation as well, it could be, I was thinking like how it happened at CyberArk. That was bottom up. So there's the team on the ground, struggling with deployment and through r&d, and just a general interest in kind of exploring new tech and just changing the next JavaScript framework or the next, the next fancy, fancy language. They we realise that, so that yeah, they started implementing it on one project. And then that came up through the ranks of the company and say, that makes sense and to reach the CTO. So yeah, we should do that more, and then saw the benefits of it. And then clients loved it. And then it became a whole gem centre, it's part of our marketing strategy. And everyone is, is raving about it. So that was bottom up. There might be situation where the new CTO coming in plays straight from the top. And there's been a legacy culture where engineers might just, you know, go trend meals dive like I've been doing it for 10 years. That's, that's right. I can continue doing it and resistant to change, but then the CTO say, now we need to move to the cloud, we need to implement DevOps. And then there might be some resistance but the best teams are the one that embrace that change. And at some developers might disagree and leave but if it's if it's the right decision for the company, Then you'll be left with a good team, wherever everything's aligned and, and the team will learn new things. It's very exciting as well as developer might get bored of doing always the same thing or that's innovation is also very exciting. So that's that could be also from from the top and then going down to the dev team, but depends on the company, right?


Yeah, well, I totally agree. Because every time when I try to explain people, how to start implementing CI/CD, the first thing I always say, and this is something that I always repeat, I emphasise is never ever try to implement everything at once. Because when you start reading about CI/CD, you will find about deployments about unit testing, functional testing this and that. And this is overwhelming, this is scary. And the moment when you try to implement everything at once, when you don't have this culture you don't have. You don't have a habit of writing tests, you don't have a habit of automation, nothing of it, it will just crash and burn. And the only thing that you will waste is some time and the money you'll spend on some applications that should help you out automate this step by step.


Yeah, I agree, I think I think the changing one thing isn't important. It's a good, it's a good way of doing things. If you change two things, and you're processing proofs, you have a pretty good guess that no one of those things work or possibly both of them. If you've only changed one thing in your process gets worse, you know, you need to abandon it. But you might be in situation when you change two things, and it gets better. But if you want one of those things made it worse. So changing one thing and small incremental changes to processes. And this works in life as well as technical delivery is a good way of working out what brings the most benefit. And that is agile at the end of the day, isn't it, we're talking about small incremental changes that bring the biggest value. And, you know, DevOps is a commerce isn't overhead, you have to have that function in your business. And that overhead is only worth it, if it brings value. So you know, you need to know you need to know, need to make sure need to have competence yourself as a business that the DevOps task DevOps changes you're putting in place, or making a big difference to your business. Otherwise, how would you know what progress are a second DevOps?


True, true? And the last question we have is, What would you say is the most common blocker to business DevOps processes?


could be in terms of the kind of deploying that inside the company or business processes? Yeah, it could be either the, the lack of understanding, I guess, where it could get quite technical, as you said, when talking about that. So under the lack of understanding where again, they've been doing it, and why not be very efficient, but they haven't seen better. So that's, that could be one way of resisting that change. Or the other way it could be, it's too overwhelming, because you've just Google DevOps tools or something as this diagram with 150 icons, and you don't even know where you wouldn't know where to start. So,


I mean, when you when you when you Google for DevOps, you see these these arrows that did go infinity. So what?


Yeah, that's that explained the whole cultural thing around kind of the process at all stages and continual improvement that then can explain so I think that would be the most common Blocker with that either lack of understanding of the benefits of it, or it's overwhelming and resistant to change. That doesn't explain earlier just need to start small and show benefits and then can only grow from there.


Yeah, I think that that whole, people are generally scared of change. But you have a situation these days where 510 years ago, you can have one developer doing their coding locally FTP it up to a piece of metal on a rack, somewhere in a note in a in a in a server farm, things have changed. We have much more specialists these days, generally, not just in technology. So I, I lead teams that develop develop Drupal websites, I didn't actually do much development anymore. And I think you because we have the cloud and all these amazing tools like Amazon and all these platforms as a service, that you inevitably end up with people who have to be specialised in those areas. And that is a culture shift, which I guess James has already spoken to. So it's that reluctance to do change. If you don't change, you will just get left behind. So there is a certain amount of specialism you have to buy in, whether that's through recruiting or training, depending on the size, your business or outsourcing. But change is always hard. But but check change has to be for good reason. And convincing the people with the purses to open those purses and to spend them on the right things is, is it's not hard, but it certainly needs evidence and this sort of webinar, hopefully. Take that punch.


Yeah, so. Okay, so this was the last, the last question we have. At the start of the webinar, we launched a poll on YouTube and the here are the results. The question was, is Drupal, your primary CMS and 73% of our viewers said, yes, the triple is their primary CMS. So, so yes, that's, that's, that's really good. And it's also nice. And it's really great that the rest also stayed until the end to listen, something about not the primary CMS but to learn something new to progress. And, yeah, so. So this is, this was really great. And before wrapping everything up. Remember about our Buddy CI/CD group on meetup.com You can follow us there and you will be always informed about upcoming webinars. And like I mentioned earlier, subscribe to our YouTube channel. Thanks to this, you will be able also to get informed about the upcoming webinars and you will have access to all the other things that we already already made about mostly about CI/CD DevOps and but also, we also had a webinar about accessibility. So this is a really great place to learn something new. So, guys, thank you. Thank you very much. I really enjoyed listening. I mean, I will be one of those 26% of people for whose Drupal is not their primary CMS, but I really enjoyed it. I learned a lot. And so like I said, Thank you, thank you very much. And I really hope that at some point, we will do a part two of this right. Definitely. Okay, so, so the last thing we can do is just wave goodbye and thank you everyone for listening. Bye. Thank you. Bye bye.


- For WordPress developers who want to streamline their development
- For Agencies that don’t want to spend their time fighting with the infrastructure  
- For bigger teams that want to work on multiple features at once








Learn how to benefit from using Buddy together with Pantheon’s Multidev environment to work on multiple new features at once.

Developer Advocate @ Pantheon Platform

Jose Castaneda

How is Pantheon different from other WP hosting services?

What is a Multidev environment?

Example repository that we're going to use

What is Terminus?

Connecting Buddy and Pantheon

Setting the variables

Working with the .gitignore file

Creating a new Multidev environment

Running tests

Moving code between environments

Different ways to use the Mulidev environment

Using Pantheon’s Multidev and Buddy – a perfect WordPress development combo

Hello, everyone, welcome to yet another Buddy webinar. Today we are going to talk about one of the best combo development combos there are, Buddy and pantheons multidev environment. Because I am not such an expert as my guest, I invited Jose to help me a bit explaining what what this multi level environment is. 

So how's that before we'll jump into all the things related to pantheon? Tell us something about yourself.


Jose

Yeah, um, besides the fact that I have rainbow hair, obviously, Jose Castaneda. I work at Pantheon as a developer advocate. I've been at the company for the last almost three years. It'll actually be three years in July. Before that, I worked over at web dev studios. 

And this was actually how I got introduced to Buddy, which was awesome. And I was like, Oh, my God, I love this. I want to use this later on.


So yeah, my name is Maciek. But mostly I constantly work here at Buddy as a WordPress ambassador, and also a regular webinar host. 

So today, we are going to cover quite a few topics. So first of all, why is Pantheon different from other hosting services? Because it is different. What is this Multidev environment I mentioned before, and how we can set up Buddy to work together with with multidev environment. 

Okay, so before we jump in to the topic, remember, if you like what we are doing here, if you like our webinars, don't forget to subscribe to our to our YouTube channel. Also, we posted as a poll on YouTube, about are you using multidev environments. So please respond, it will be great. And yeah, I think I think that's it, it's time to it's time to talk about pantheon. Mult dev environment. So Jose? First of all, how is Pantheon different than other WordPress hostings. 


So one of the ways that it's different is that we actually have the three environments, we have test, we have Dev and we also have a live environment. The really, like cool part about it is the test and live environments are actually locked down. So they are get versions of, of course, the dev environment. We also do have other features we also use. One of the things that I really liked using a lot of the time is Quicksilver it's kind of like the WordPress hooks, but for the platform. 

And then we also, of course, have the multi dev environment, which we're going to talk about today, which is a phenomenal way of testing features testing stuff. And one of the cool ones that I've seen so far is actually testing design options. Someone actually decided to completely redo their site on a multi dev environment, their design was completely different than it was awesome.


Yeah, and the cool part about the multi dev environment is that the only thing similar that I saw was Netlify or Vercel, where every time when we deploy something to a branch, we get this pre preview URL or whatever it's called because it's it's named a bit different based on which platform we are using and I Oh, this was always something I missed. And in the WordPress environment, I really remember that if I'm not wrong, Aaron Edwards from WPM, you dev mentioned that they have something like this behind the scenes.


So this is something they use with multiple, so there is a slight limitation, at first, there's about 10, that you can actually create, but you can reach out to support and ask them to increase it, which I think is 25 or 30. I can never remember off the top of my head, but I want to say it's around that area. But that's one way of doing it.


Yeah, let's let's let's be honest, having 10 staging environments at the time should be enough. Because if you are not handling, handling, dealing with your features, 10 of the time, you have a bigger problem, rather than just not having quality them before. So sort of that's true. 
Okay, so I think that enough of theory, let's start showing up what, how many they have looks like. So let me share my screen. So a custom question you can respond in the comments. Is the font big enough? Or should I increase it? I don't see and come and see it, but we will see it, the moment that someone will, will say that the font is too small. Okay, so as you mentioned that Pantheon always uses git get somewhere. And yep. So that's why I created here, a repository that is based on on the Pantheon WordPress specification, and that there is only one difference, this dot Buddy folder, and in this doc Buddy folder, we will have a script that will let us create a multi dev environment. Each time we will push something to production, it there is quite a bit of code. But the most important thing is that it uses this tool called Terminus. And Jose, could you explain what is Terminus?


So terminus at its basic is essentially the API for the dashboard, but on the command line, which is amazing to do, because oftentimes, we as developers don't like to touch, you know, a graphical user interface. And we're just like, oh, all these shiny buttons. What does it do when it breaks? We're more familiar with like, you know, sudo, do this, or Command do that? Right? That's essentially what Terminus is. It's a basic way of running commands. For the dashboard.


Yeah. Yeah, exactly. That's the problem with Terminus is that while it has a lot of possibilities, you really need, in most cases, some kinds of bash wrappers to make everything working, because, like I said, it's powerful. But you also need to learn how to how to use it. For example, here, this is the simple example, we had to create a function, the tax is the multi def already exists. And so we have to list all the environments and check if the if the one we are we are using right now is already created or not. If not, we will be creating a new environment. So as you mentioned, this is kind of an API for the dashboard. So let's take a look at the dashboard because this is also something so as you mentioned, we have those three environments, we have the dev test and life. And if we would like to push something between the environments, we would have to deploy it using using either dashboard either specific terminal command. And here is the most important part of the day, the multi Dev. Okay. Single all the all the environments that are that are already created, you can delete them, you can merge them, you can see which of them are ahead which are behind. And what's most important, you can, at any point, just see how they look like, at this point. This is our site. That's it, it's working. And we can update the database of each of each environment separately. So we can test many, many things. The way we want.


So this is this is something that really it's like the beauty of the whole containerization system. That's why it's like It's all contained within one little thing.


Yes, yes, exactly. Exactly. So. So okay, so like, it's like I already showed you this deploy script. So now let's take a look how it looks like. How it, how does it work. So I already created the Pantheon action, because the creating a new environment always takes a bit of time. So I decided that I won't show you how to create the the new website or things like this, because it would only take us time which which we are limited in. And we'll start with this deploy to pantheon. Action. So the pipeline, and it consists of two action. First of all of this is terminus, multidev, and second is pushed to pantheon. So first, let's analyse them. And then we will create some change in the code and see how it's working. So this terminus, multi dev will do only one thing in reality, it will just run this deploy script, first, it will authenticate. That's why first, we have to remember to instal Terminus. By adding this in the environment. The cool part about terminus, it's so well documented, that if you just visit the documentation, just follow the instruction Ctrl C Ctrl V, and you should get everything working. So really kudos for the great documentation. 

Next thing, here, you can see that we are using this terminal terminus, authenticate login with machine token. And the machine token is another thing that is always needed to be set up. As you can see, we have quite a few variables. First of all, we have the get URL. This is the URL of the Git repository that the Pantheon is using. Because overall, we will be sorry, here, you can see the connect the connection info, that's this


chart. The cool part today is on that one, there's actually two different locations you can get it from there's that connection. And if you actually look on the development development mode as well, there's a little pop up that shows in there. So if you cause connection, and then clone with Git, that will also give you that same Oh,


Welcome to Buddy Webinars!

Recorded Webinars

Tell us what you want to learn next!

Everything you always wanted to know about Jamstack (but were afraid to ask)

How to master Drupal deployment cycle with a proper DevOps process

Using Pantheon’s Multidev and Buddy – a perfect WordPress development combo

Why website performance matters

How to automate CI checks for PRs in WordPress delivery

How to automate Gutenberg block development in WP projects

How to supercharge testing with Pest PHP

E-Commerce Automation for DevOps Pros