Serving for the win – Deploys and hosting for the rest of us – Phil Hawksworth | Render Conf 2018


So let’s get into it. Hello and thank you
so much for having me. It is a real privilege to be here. I’ve almost made it to this conference
once before, as Ben mentioned but I’m really quite delighted to be here at Sock Fetish
Conf2018! It’s been an emotional day! I feel like I’ve let the side down, but that’s by
the by! Let’s see. My name is Phil Hawksworth. We’re not really doing Q&A, but I’m very happy
to take questions – I’ve got a really long delay on my slides. There we go. My Twitter
handle is just my name. So at least I can remember it. If you have any questions, comments,
disagree with anything, or you want to chat, and also come and grab me later on as well.
I’ve been making things on the web for kind of almost 20 years now, and the last nine
or so years have been at agencies, and the latter of those maybe I will abandon my clicker
and – there we go. The last of those was an agency called R/GA. My slides are really struggling
a little bit. But that’s fine. I was at an agency at R/GA for six years. In December
of last year, I moved over to work at a company called Netlify. When I was at R/GA, I was
always banging on about Netlify so I went and worked for them which puts me in a difficult
position now because there’s a worry that maybe this is going to sound like a sales
pitch. I will try desperately not to let that happen. In the spirit of that, it’s maybe
worth me putting in context Netlify with other companies that I might substitute into a sentence
describing them. I should put that up there in a slide with my competitors to make everything
is even and equal-handed! [Laughter]. Let’s do a better job. People talk about Netlify
as Surge, or Zeit, who do hosting infrastructure and automation, although we’re not competitors,
although we fit in the same space as people like Azure, or Google Cloud – a hosting infrastructure.
So, I will get into that in a little bit before before I do anything else, I have to say I
have had a lovely day, but I’m a little bit pissed off because, as we’ve gone through
the day, we have had wonderful talks, but the way we finish things off is we have had
Nadieh and then got me, and – hello! And then we’ve got drinks and socialising. It really
feels that I’m literally between a rock and a hard place! So, we will battle through as
best we can. This is about 40 minutes, a little bit less now, 40 minutes to talk about that,
and, to contextualise 40 minutes for you a little bit, in 40 minutes, light can travelling
719 million kilometres, and as we’ve all learned one thing from Harry’s talk, that’s under
2,000 laps around Saturn. You can take that home with you. That’s for you! [Applause].
I love that you’re cheering maths! [Laughter]. In terms of my track record, this is why I’m
anxious about this, because Nadieh’s talk is just so beautiful, and also fresh in our
minds, is the kind of energy and the inspiration from Una and the other talks as well, my track
record, as I say, I’ve been working in an agency and bitching about content-management
systems and getting excited about static websites – oh, exciting. It doesn’t seem very glamorous,
any of that, so, for this talk, what I really want to do is jazz it up a little bit. That’s
why I’ve gone with this title of serving for the win deployments and hosting for the rest
of us. That sounds exciting, I guess? In an effort to jazz it up, I will pull the wool
over your eyes and make it snazzy. I even put this tenuous, I don’t know! [Laughter].
We’re not talking about anything that is necessarily exotic or new. What I’m talking about in this
talk is really fundamentals. We learn a lot at conferences whether that is that captions
aren’t optional in this great accessibility talk we heard earlier on, or all of the security
vulnerables like the environment variable, which that – that gave me the “heebeegeebees”
when I heard that. That was terrifying. We learn these amazing things, and we get this
inspiration and we go away and put it into practice. It is really a waste if we just
confine all of these learning to theory or things we play around with. It is a waste
if we just confine these to our development environments, our local environments. It is
really important that the stuff we learn here and the stuff that we learn along the way
reaches our users and gets out there. And, in many ways, the way that we do that is by
a slight kind of change in mind set, and a change in process, and make sure that those
things kind of are up to snuff. Making progress, you’re thinking great, half an hour of slides
about process. I’m not sure if that is what I’m up for to finish the day. Let me see if
I can try and make it interesting and try and make it relevant for the end of the day.
So in the next half an hour or so, I want to talk a little bit about where it hurts
in web development projects and projects in general. I will try and do that by telling
three stories that explain some things that have gone well or not so well for me and what
I’ve learned, and then try and wrap it up with the kind of minimum sets and resources
that might be able to help. That’s the plan. So, where does it hurt is the first part of
that? Doing projects often includes things like clients, deadlines, often complexity
– that shouldn’t really be too much of a news flash for anyone. But these things can combine
to give us slightly sleepless nights at times. If we look at the perfect project timeline,
let’s break it down a little bit and see how things go from inception to delivery. So,
we start our project typically with a brief, and then we end with awards. [Laughter]. Are
there any questions! [Laughter]. Realistically, there is no perfect project timeline, sadly.
First of all, we’ve done no work here, which maybe that would be perfect, but we need at
some point to start doing some work, and, at some point, we have to launch that work
into existence. Before we can start the work, we have to have some kind of scoping exercise
– I told you it would be jazzy, this talk. A scoping exercise to figure out what it is
we’re going to make for the client or our customers. Then, before we can launch it,
of course, our customers are going to want to give some kind of final sign-off for that
which is probably going to come after some big nerve-racking part, the sweaty-palmed
review of the work. So, you know, with those kinds of things set up, we can start doing
the work and actually going through the process of making things and getting them into a state
that we can progress the project. After we’ve been working for a little while, getting into
a bit of a rhythm, this is usually where we rescope! [Laughter]. Yeah. I think we’ve all
shared the same pain. We figure out actually, we’re making something that’s not quite the
right thing. Let’s make the right thing now, so that we get on again, and our cadence picks
up, our pace picks up, it gets a little bit more frantic, trying to get to the big client
review, so we can review the work, we’re fine, and we get the sign-off after we’ve done some
more fixes after the review again to shuffle it into place. Now, this you will see these
blobs that are getting closer together now, because the pace is picking up, it’s frantic,
a little bit disorganised. That’s clearly in the wrong place. Sometimes, the ball gets
dropped a little bit. I don’t know why there is a lemon there necessarily! That’s again
the wrong thing in the wrong place. But it happens at crunch time. Things go awry. But
we try and scramble, get back on track. We do a last big push to get us to our final
sign-off which of course is not final sign-off after we get that, so then we’ve got to do
a few more bits and pieces. Then we launch, and then we’ve got a few things, fixes, and
we’re done. So this is, and this looks about right to me. But all of this kind of culminates
in a launch day which is nerve racking. This is stolen directly from MailChimp, this is
the button you press for a mass mail-out which summarises the feeling perfectly of sending
that big notification. This is what it feels like on launch day, it can be nerve-racking.
It often is. Yes, projects can be hard. Projects usually involve some kind of learning, and
they very often involve some kind of change. But, thankfully, things have been changing
for us a little bit that can make that a little bit easy. Infrastructure, for one thing. We
have had an evolving approach to infrastructure over the years. Again, if we draw another
one of these timelines, and think about where it once starred, you know, when I started
my career, I was pricing up racks and machines that would go into a secure room with cooling,
and fire-retardants and all of that stuff for onsite hardware that would serve a couple
of websites. Amazing that’s where it once of. Which meant to getting rack space in a
catered facility, and I’m not talking about rack space, I’m talking about physical space
in a rack in a catered environment where they would provide the network connectivity and
the cooling, and the power, and all of that other infrastructure, and you would put devices
in there. Then things started getting virtualised, and virtual servers, in this case, potentially
something like Rackspace – it gets confusing here! [Laughter]. But again we’re going from
physical more and more virtual, and now we are seeing more of a move to software as a
service, even where the point we are having functions as a service. We’re paying for cycle
time, for executing functions in someone else’s infrastructure. So all of this change in infrastructure
and the way that we deliver sites, this has brought about the possibility of all of these
different deployment and development conventions, so, it’s this approach that has really changed,
and that that can really, really help us. But, you know, nonetheless, it hurts when
managing change on projects. It hurts when you’re trying to manage the unknowable, because
you never start off the project with a full view of everything you need to know. The time
it usually hurts is at crunch time, as the pressure mounts, that right hand end of the
timeline with the inexplicable fruit. Saying that out loud, I’m looking over to see inexplicable
fruit arrive on the scene. [Laughter]. This is where the plan often kind of goes if the
trash at that crunch time, in the project. The question is can we plan for the plan going
in the trash? Can we offset that a little bit? I want to get into my stories. Story
number one. Was deploying on my first day. This happened to me not when I was working
at R/GA, a previous agency. Nonetheless, the first day on the job. And I arrived, and we
were doing a large-scale site deployment for a nationwide health care site. It was a big
project. It was one that I wanted to get right. Not least of all because it was my first day,
but also it was big in the public eye, it was a site that mattered. And so, before I
had been shown where the coffee machine was, there was a little panic, and my brand new
boss said this should have gone live on Friday – this was Monday morning – and so that statement
alone makes me anxious a tiny bit about the deploying on a Friday thing but we will leave
that aside just for a moment! The next thing that I was asked was, “Can you help the team
if I can out the deployment?” And I was fresh-faced, I was new to the role, I said, “Yes, sure,
why not? We can fix this.” And so if we look back at our timeline here, and you notice
our fruit has changed because we never know what that thing will be. It is completely
unknowable. What we were doing at this point is, you know, it was trying to figure out
the deployment just after the launch. Now, of course, it would be flippant of me to suggest
that that is what was planned. What really was planned was moving it to there! [Laughter].
Just seems reasonable, because that’s the hard stuff. That’s the stuff that you don’t
want to deal with very often. We will do it just in time. So that was the timing of that
which is anxiety-inducing. I want to talk about the deployment itself. So the deployment,
it’s a standard thing. We had a production environment that we needed to get a website
on to. And that was coming from a staging environment where the website currently was.
Now, the eagle-eyed amongst you will notice that the shape of the staging environment
and the things on it, it’s not quite the same as the things on the production environment.
But that in itself is bad. Obviously, we want those to be identical. Never be perfect facsimiles
of each other if the staging is to do its job. The reason that happened is because the
deployment process looked like this: two FTP windows and a mouse. A few people are fidgeting
in their seats, and rightly so! This was the moment that I could feel my buttocks clench
a little bit in the office. My first day, I was nervous about this. Of course, this
is troublesome, and, you know, what was happening, was that the developer would drag from one
window to the other, go to the browser, hit refresh and go “no”. And then do it again.
It was a bit anxiety-inducing. Then, after that wasn’t working for a while, the developer
– we will call him Bob. He started dragging files from his development machine to the
environment, and the same kind of cycle happened. And then Alice joined in from her. So files
were being dragged around all over the place. And at the crux of this, this isn’t down to
the faulted of Bob, Alice or one individual, it is the point of the problem of FTP as being
the mechanic for doing a deployment. This is tricky. Anyone willing to admit deploying
anything over FTP? Oh, there are a couple of brave souls. The thing is, that’s okay.
It still happens from time to time. The problem with that is is that it leaves us in an unknowable
state and often leaves us in the point where we don’t have a repeatable process. We don’t
know what we’ve done each time, so we can’t repeat our process and be confident that we
can deploy things perfectly every time. In terms of how did it get on? Did the site go
live? Yes, it did. I’m happy to say it did go live. Was it correct? Yes, it was. It probably
was! Honestly, I don’t think I can ever really know. The client signed it off, so … that’s
fine. [Laughter]. The big question is how did the next deployment go? We are seldom
finished with fixes and updates, and changes. Since we didn’t have a repeatable process
we were confident in, this is the big question – not ready yet. Maybe if I come back next
year, I will be ready to talk about that. Do I need a hug? Yes, I do. It was tough.
All is not lost. There were lessons to be learned along the way there which is nice.
The first thing is version control, which was being used at this agency, just being
used as a way to manage things locally. It was like a file store. Version control needs
to extend all the way to deployment if it is going to be valuable. As soon as you let
your guard down, you know that version control gets out of hand. The next lesson is that
human intervention is really undesirable when it comes to deployments. We were not good
at doing the same way every time. Get us out of the loop is always good. And the other
lesson here is that holistic deployments are far preferable to piecemeal deploys – this
notion of changing one thing at a time, and that changing the state of your environment.
That’s really something you want to avoid. Okay. I’m going to move on to my second story.
Which was searching for Syria. This is a project I worked at when I was working at R/GA. If
I can get this to play. Can I? My videos don’t seem to be particularly working up here, but
that’s okay. We will – is that? Oh, … . It’s a website. [Laughter]. So this is a website
that actually in real life rendered much better than this, I’m happy to say. It is a website
– this is going to make is really difficult if none of my videos work for some reason.
Never mind. So this is a web – this is website that involved lots of change along the way.
The purpose of this site was the to communicate the apply the of Syrian refugees to the world,
and try and humanise that plight, because, very often, when things like that come along,
the other side of the world, we don’t think about it, and we don’t realise that these
are real people that this is happening to, and so this is what this site was all about.
It was commissioned by Google, and it was in partnership with the UNHCR which is the
United Nations High Commission for Refugees. So, as you might imagine, a site such as this
from start to finish, when we look at that perfect project timeline again involves all
kinds of change. And there’s significant political sensitivity for this, not just in terms of
the content, but also how do the different companies – how are they perceived when they’re
making this site? Will Google be seen as trying to push their products by making a site that
conveys this message? How do you deal with it? It’s very, very sensitive. So, there are
lots of different stakeholders on a project like this, and they’re all quite sensitive.
And this was a project that had a huge global launch. It was going into lots of different
markets, lots of languages. It was another big’un. So it is again another one that I
wanted to get right, and, you know, more than that, this was going to have a huge launch,
and every now and again, this isn’t a good example of it because the link at the bottom
is for something different, but every now and again, Google would do like a home page
promo for your site. It doesn’t happen very often. It is usually a big thing. That usually,
how should I put this, creates a slight spike in traffic when that happens! It was a big
one. Definitely one that I wanted to get right, so, when we go back again to our timeline,
I didn’t want to be in this situation again, I wanted to do this a little bit differently.
So the first thing we did, of course, is we moved our figuring out deployment right back
to as close to the start as we possibly could. With that done early, we could feel confident
that even though it would get crunchy towards the end of the project – projects usually
do – we would at least be able to get rid of some of the outliers. Benedek said right
at the day, automate as early and as fast as you can when talking about WebAssembly.
That’s exactly what I would always echo. That was the whole point of this. The environment
that we were working on was Google Cloud Compute. This worked beautifully for us. I will talk
about that in just a moment. But I want just to mention what we were delivering because
we had to deliver a website at the end of this but along the way, we had to deliver
to the QA Team. They needed to see what was happening; the production team who needed
to see how things were progressing; at some stage we needed to deliver versions of the
sites to the translations teams who would be translating the content into different
languages; we had to deliver to the client so they could see what happens what was happening
and how it was progressing, and the client’s box office, you know they wanted to see that
as well, and launch this and deliver it to the general public. There are lots of times
throughout this project that we need to deliver this. We had this ambition of wanting to deliver
any version of the site at any time. We always wanted to be able to see a snapshot of the
site. We did that of course through our friend version Control. We decided to have a strategy,
wherever we tagged the code or the site in Git, that would automatically create a version
of the site which is a resource we can see at a URL. Now, I’m a big fan of URLs. I’m
a bit of a URL nerd. I think I’m amongst friends. I can say that. I have a habit of, when I
get to speak at conferences, I like to tell everyone that URLs all include this thing
at the bean aitch tee tee pee – there he Alex. There he is! There is the double meh! Once
again, that’s Alex Sexton’s fault that you’re all damaged by that! It heals me to share!
But, all of the tags would create a URL. They would create a resource that we could see
at URL. Let me show you a little bit how that worked. So, again, we got our development
environment, and we have a site that we need to get out to the world. Eventually, that
will go to a production environment, and this is the route we would take to get there. So
all of our changes were pushed into Git, and we had a continuous integration server, this
this case, it was Jenkins, monitoring Git, and whenever it would see a new tag created
on Git, some cogs would turn, it would build out a version of the site, and it would push
that to a stage the environment so we would have it there and share the URLs with the
team, so that he could see that, and, eventually, a determination was made, okay, that’s live,
we’re ready to go with that live, go and it gets pushed to production. So that is a flow
that works with version control at its heart, which made me feel a little more comfortable
than dragging things around through FTP. The way this looks, and sadly, this isn’t a screen
shot of the actual dashboard we have, because I took this after I had left the project,
and indeed the company. This is very representative of that. So this is in app engine, and, on
this project, what you can see is each of these instances of the site you can see the
version looks like a timestamp to me, and all of the traffic in this instance is being
sent to the latest version but the other versions live on. If at any stage you could decide
to route the traffic in its entirety to a different version or shake the traffic between
them. This is great because it means at any stage you can step back or forward through
the versions and put different things live in just a moment by just toggling which is
the live one. Realistically, this isn’t this scenario, this is closer to this where we
don’t have a separate staging server and a production server, we have one live production
environment, and, within it, we’ve got these different versions of the site that we could
choose which one, which one is live at any particular time. We can move backwards and
forwards, and what have you. So this is really nice, because it meant that all of our demonstrations,
all of our discussions, all of the tests, the issues that were created, the sign-off,
that was all happening against known versions of the site. Every version had a URL and we
could say to someone, “This isn’t working on version 0.0.9,” and they could see that,
look and see that. Known versioning for pre-views was just huge. So the lessons from that: addressable
and accessible build versions are just a huge win. They just relax everyone, and you feel
like you’ve got great visibility of what you’re working on. Deciding when and what to tag
requires some co-ordination. I wouldn’t necessarily do it quite that way again because we had
to decide, okay, this is a version that is good to go, ship it with a tag. Maybe I would
change that a little bit. And then, immutable deploys to the production environment remove
this uncertainty from launch day. This sweat y gorilla hand we had at the beginning has
gone now because the versions of your site are being served from your production environment.
All you’re doing is saying now this one is ready to go, and share it with the world.
That was the last thing there. I’m moving swiftly on. Now, this could get interesting
because I’ve got videos in here to communicate my point, and my videos aren’t working so
prepare for some hand-waving. The last one is Netlify, building Netlify. I joined the
company in December of last year. And so I got to see a lot of the work in building Netlify.com
on top of Netlify’s platform. Recently got a bit of a refresh. This is what it looked
like. I describe that as Netlify.com is a jamstack site hosted on Netlify using Netlify
to Netlify Netlify. Similar to Yonatan’s DevTools to see how they work, this is a little bit
inceptional, like, to figure out how this works. But that’s okay. Let me break it down
a tiny bit. This is the scenario we have – this is the scenario we had a moment ago talking
about the Google project we had a moment ago, the Syria project. Different to Jenkins running
the continuous integration and then Google Cloud Compute housing the buildings, the way
that Netlify works, it Netlify runs that continuous integration for you and deploys it to its
CDN in one thing. This is kind of nice because it means we have the get it-based work – Git-based
work flow I was craving all the way to production. Everything is based on Git activity which
is really nice. I also did something sneak bi-. I dropped in this word “jamstack” and
plenty of of people who went, “I don’t know about this,” which is reasonable. Let me describe
what that is. Jamstack is a term that is emerging describing sites that are built with JavaScript,
with APIs, with mark-up, to create something that is a static asset that you can put on
a CDN. That’s what that describes. I will unpack that a tiny bit to make the rest of
this make a bit more sense. So, lots of us these days, when we are building things for
the front-end, we’ve got some kind of build automation that we use in our local development
environments, whether that is something like Gulp, Grunt, WebPack or other build tools
you might be using. In this scenario, we will be taking markups, HTML, other front-end assets,
maybe using JavaScript as part of the build process itself or baking JavaScript in as
well. It is outputting this staticing, this site, this deployable entity that we can put
on a CDN and have that be served. The API’s part of that is that our build process could
be pulling in content from headless CMSs or other data sources, or pricing engines, or
all kinds of things. The point is that we have APIs that we can use to enrich the site
as we are building it to generate it. JavaScript could be used in the client as well. Once
we ship this thing, that could be another static asset talking to APIs directly. There’s
lots of flexibility and ways that this could work. This is what I’m talking about when
I use this term “jamstack”. In the face of Netlify, if you use the Netlify the admin
tools, that’s the static site that has been built with Hugo, or it’s a React app for the
admin that is right of it. That talks to the APIs in the background which talks to the
rest of the infrastructure, kind of the Netlify product and platform, if you like,. But the
things we are interested in here is just the website because that’s what is being built.
I mentioned that buildings are based on Git commits, so we have a history of every state
of the site. Now, I’m nervously pressing this button because I don’t think this video will
play so I would have to describe it. What could go wrong! This is the dashboard of the
Netlify account, and each one of these things is a site. Now, were I able to show you, I
could go into any one of those sites and we will see a deploy log. Each deploy is linked
to a Git commit. This is huge. It means every time we do Git push, and that will kick off
another deployment, just the same as when we were describing as I was describing in
our continuous integration with Google, and then it will create an instance of the site
that is there and visible for us to decide whether that gets promoted automatically to
production, or if we want to be able to roll back and forward between them. The other thing
that is key there is right there in the deploy, in the deploy logs, showing each instance,
is there is a link to the Git commit that actually created that deployment in the first
place. Right there in our history, you can say,”Okay, show me the site at this state”
it is on its unique URL, and, “Show me the commits that brought that bit”, which is huge
for the troubleshooting and bringing it forward. This might get more difficult. Who knows.
The other thing that is interesting here is that since the site we’re looking at for Netlify
is the stuff in white on the front, the stuff that has been baked out statically, it is
decoupled from the APIs and the product at the back, it meant that during my first week
there, I got to go to meetings where they had a retrospective, how things used to be.
This is the site maybe 18 months or two years ago. This is what it likes like. It is showing
the list of sites which is like the view we saw a second ago, and then drilling. A site
view itself. It looked like this, similar structures but looking differently. Then more
recently, it looks like this. These weren’t just screen grabs that were taken, what happened
was a member of the team just said, I will run the site now as it was in 2016. Just call
that up on a URL, and that URL had a static site talking to the same APIs, so all of that
content actually, you know, this one from a year or so ago, one of those is a project
we did for Smash ing mag which we did in the future from there. It is crazy that the same
UI can be talking the – different UIs can be talking to the same APIs in the background.
It’s kind of cool. It is because of this separation and this model. The other thing now, then,
this is going to be difficult to explain. Is that automation was based on the Git activity
as well. So, there’s lots of different actions that we take when we are managing a site with
Gits. We’re used to pull requests and branching and those kinds of things. What we have in
this environment is we can generate preview buildings from pull requests. Now, that’s
a bit of a mind-bender. And so, I will do my best to talk through this non-playing video
again. I’m going to desperately hammer this button! No. That’s fine. In the same way that
is pushing code to Git will trigger a build, and it will pull out the repository, run your
build for you and deploy it to the CDN, if someone creates pull requests, what we would
see here is that just creating that pull request which has not been merged but it is a pull
request created, we will spot that and spin up another instance, a build bot, and we will
merge over there that code, create a preview build of that, and deploy that for you as
well. That’s kind of hard to get your head around. That is creating you a view of your
site as it will look if you decide to merge that pull request. It is giving you a chance
to see the future before it happens. This is incredibly powerful and really quite liberating.
It gives us confidence in the future state of our site before we take any action on it.
Now, that kind of brings me to another video that I have to describe! How is everything
doing! I really wish we had caption ing on this! So, since we’ve got this ability to
build everything on top of the Git model, so we’ve got pull requests creating buildings,
commits creating build, branches also get their own buildings, and that enables a whole
other set of possibilities. This is not something that is necessarily unique to Netlify, being
able to build things on branches or pull requests, what have you. I’m using this to illustrate
this because it’s something I’m most familiar with. Something that is different for Netlify
is this ability to do A/B testing based on branch buildings. So, if I’m creating a new
feature branch because I want to be able to say I’m going to test out a bigger flashier
purchase button, I will create that in a feature branch. Automatically, I will get a URL built
out for me that I could send people to, and we will test against it. What we can do with
A/B testing because I can’t illustrate is we will be able to serve both of those things
up to users at the same time, so both of these things are out on a CDN, and then we can start
shaping traffic at the CDN to one version of the site, or the other, still under the
same URL. This is kind of exciting because it means you’re getting to do proper testing
of how the site performance under the different UI conditions without having to do anything
like DOM manipulation with JavaScript to change the state of that which often you’ll see in
A/B testing. Let’s move along to the lessons. Top lesson: test your videos before you go
on stage! [Laughter]. Second lesson, embracing version control conventions removes the need
to reinvent them. Now, what I need by that is all of the processes that you can use through
these continuous integration tools, Netlify being one and there are others, when you embrace
the conventions and build with those, it means you’re not having to recreate versioning and
do different things to preview, so you’re building on top of the conventions you have.
Reduced friction business agility and confidence. When a new version of a site is mundane, as
simple as doing a Git push and you don’t have to think about it, and if the ability to roll
back and forwards between versions of the site is trivial, it’s hugely liberating because
it means you don’t have the finger of deployed destiny. You can always interrogatory things
back and try things out with confidence. The last lesson is jamstack sites and the ecosystem
around it can go way beyond an experience which is static. People often ask me for an
example of that. The whole admin interface of Netlify itself, it moves a lot more than
I’ve shown here. That is a React app that is served statically, so you can do all kinds
of things with that. Maybe it’s a good thing that those videos didn’t play. Mind sets and
resource s I want to talk about. I’ve mentioned some of the resources. Circle CI is another
integration service that you can use. Software as a service. Jenkins is something you can
install and configure to run some of this automation for you. I would also say that
I mentioned jamstack briefly but you can learn more about that there and what that means
go get to resources. Also, the www.thenewdynamic.org is a great process and architectures to look
at. Things like headless CMSs and generators can help with the tooling, and there are sites
that can compile a bunch of those. Another aspect to this is serverless. I’m cautious
about saying that because someone will shout out, “There’s always a server.” Likewise with
wireless, someone pointed out somewhere there’s a wire! [Laughter]. But, that is another kind
of part to this equation, like the ecosystem of the tools and the services that you can
get to to bring the stuff to life, it is really starting to mature now, so Chris Coia put
this site together – the – I would encourage you to take a peek at that. Mind sets: it
will be little surprise that I say to you version control for everything from the first
piece of code that you write, right the way through to production is key, you know? As
long as it reaches all the way to production, you’re in better shape. I would also say that
it is wise to expose the red lights as early as possible. What a on earth do I mean by
that? As we progress to a project, everything is fine until we get “We need to to do the
deployment to production.” What does that look like? If we leave those challenges to
later in the project, they become big challenges and they happen at awkward crunch time, and
some of these things become a real problem and it’s difficult to solve, whereas if you
do that much earlier in the project where you kind of tackle the things that you know
you have to – that will be a challenge later on, you can chip them away one at a time.
Even then, at the end of the project, where some other curve ball comes up, it is not
happening at the same time as everything else, so it’s not unsurmountable. Another little
note on deployments. I like to kind of think of real value in making your deployment scripted,
making it automated so it is triggered by the events you normally carry out through
your processes. Making it real – that’s key. There’s no point doing deployments to a server
that is not like the one that will be ultimately serving your site. If you want to target your
real environment if at all possible. And make it first. Make it right back at the very beginning
of the project. We can always expect that projects will have times of chaos. There’s
no reason for us to let our poor processes be what creates that chaos. It will come in
anyway. A little note on expertise: it is an awfully full stack these days. We’ve got
a lot to contend with the front-end development we’ve got, the kind of sites that we are trying
to bring out to the world, the kind of experiences that we want, you know, the infrastructure
that is behind it – there’s a lot to take on. It is great to use the skills of others,
to use the expertise of people who take on one particular challenge, whether that is
database infrastructure, or hosting infrastructure, or whatever else. I’ve taken real kind of
inspiration from the day, and I think most of us will be in the same place. Whether that
is seeing these huge boundless possibilities with CSS that are coming, or thinking about
really creative ways that we can collaborate and communicate, it is a really, really exciting
time, so it’s nice to lean on expertise of others where we possibly can. I would just
leave you with the call to arms, really, to say let’s go and make beautiful things, weather
that means visually beautiful or they do a really good job. It is a fun time, I think,
to be working in the field that we are. I’m two minutes over, I apologise, but I’m done.
Thank you ever so much. The slides for this talk been will be available now. That’s all
from me. Thanks ever so much for listening. Thanks a lot. [Applause].

Leave a Reply

Your email address will not be published. Required fields are marked *