00:00:16.860
great cool cool are we live we like hard to me as well Wow Cameron hear me hello
00:00:23.890
hello hello hi everyone sorry about the
00:00:29.619
late start there was a problem with the the computer machine at the front hello run my name is Keith this is mario and
00:00:36.790
welcome to Keith's Mario's guide to continuous deployments or a slightly
00:00:41.890
longer version if you're that way inclined why automatically deploying your master branch to production is a good idea which I think it's really safe
00:00:48.370
great idea well the best idea this idea yeah good idea works well this is my friend Mario the man to my right or to
00:00:55.120
your left he works at our place called envato may have heard of it they do themeforest net Tut's the whole suite of
00:01:02.770
products some quick fun facts about my friend Mario if you google how good as
00:01:08.229
cheese calm you'll see that here's the CEO CFO see CTO CMO see whatever yes of
00:01:17.439
how good is cheese calm top of Google check that side out to grow it's a great site and one day Mario hopes to be a
00:01:24.460
douche millionaire with the bitcoins yeah and the dose coins yeah so here is
00:01:30.460
I'm presenting with Keith today now Keith actually works on a startup called
00:01:35.740
grill box so bill box is a semi hosted continuous integration service so if you think something like Jenkins but with a
00:01:41.979
hosted you I so like Jenkins can't read any of your data and you use your own so workers so some fun facts about Keith
00:01:49.229
every single picture I could find of him apart from the one he gave me before he sings we eating a different apple product that as you can see as an iPad
00:01:56.110
and that is a sense or laptop so Keith also in 2007 one South Australian
00:02:01.270
magician of the year yeah we're not those pigeons weren't there when I thought I was dating you that much magic
00:02:08.259
one there wasn't there either that was that was photoshopped so Keith and I together worked on a few products where
00:02:13.480
we've come where we're going to show you some of the things that we've learned so we work together on a product
00:02:18.569
envato studio so invite us to do is a online marketplace for freelancers to sell their digital services so a lot of
00:02:25.109
the techniques that will be showing you today we've originally sort of tried them on and by d'souza begin with that
00:02:31.260
was about a year ago and we also have worked on desktop which is a wallpaper sharing site for the users drop boxes
00:02:37.739
are back end so all the stuff that we're showing you is actually practical advice based on the things we've worked on now
00:02:45.450
you may have noticed we have a bit of an accent maybe we're from a place called
00:02:51.560
Australia or commonly known to the locals as just strayer we call ourselves
00:02:58.260
straily ins drop the others it's easier to say we're a small island off the
00:03:03.900
coast of New Zealand this is kind of what it looks like Mario Mario here
00:03:11.040
lives in the bottom right-hand corner not in Tasmania we don't talk about that mob but he is from Melbourne and it
00:03:18.269
looks a little bit like this a lot of nice laneways I think Melbourne was voted the most number one liveable city
00:03:23.609
in the world yep yeah very nice you should all come visit you're all very welcome so back to the map this is where
00:03:29.909
I currently live Keith lives all the way over here so Keith actually lives about
00:03:35.579
2,500 miles away from me about four hours flight so I was raelia is very large Perth where he lives looks a bit
00:03:41.909
like this it's pretty much very much there yeah there's no I'm just got a frame yeah normally lives there but
00:03:47.250
there are some really beautiful beaches so for all of our presentations that we're doing abroad there are some
00:03:52.560
requirements that we need to do beforehand before we get to the serious stuff we have some fun facts yeah it's
00:03:57.900
by law we have to talk about this stuff so I choose the first fact I'd like to share with you is in 1954 Bob Hawke
00:04:05.900
skulls he drank two and a half pints of beer in 11 seconds putting him in the Guinness Book of World Records a few
00:04:13.049
years later we crowned him Prime Minister of Australia in the first police force in Australia
00:04:20.230
was made up of the the most well-behaved convicts at the time so you're doing less muttering today Chief of Police
00:04:26.650
Chief please the two animals on the national coat of arms the kangaroo and emu were chosen because they cannot walk
00:04:33.880
backwards of course I mean they can't
00:04:40.420
escape from this position of we have twenty percent of the world poker machines but only point three three percent of the world's population it's
00:04:46.990
quite depressing in the average lifetime of an Australian they will consume 165,000 eggs and lastly Australian
00:04:55.900
billionaire politician Clive Palmer plans on building a replica of the Titanic called Titanic 2 that's actually
00:05:05.410
true great time too alright so more back onto the serious business so can I get
00:05:11.860
some hands up in the audience so anyone who has an application in production who has some sort of test server or CI
00:05:17.440
server can I get your hands up please excellent great amount of hands keep
00:05:22.630
them up though can I get them kid give up so anyone who can I get anyone who ok
00:05:32.530
can I get anyone to anyone who automatically deploys on green bills to Russian to keep your hands up ok anyone
00:05:40.419
who's got your hands up you're fine you're golden there's some other great talks on you might get some benefit out
00:05:46.000
of those but we're primarily any constraint on anyone with their hands down so that's where we're going to start so first of all terminology so
00:05:52.930
there's two popular terms continuous delivery and continuous deployment they people tend to use them interchangeably
00:05:58.479
but there is actually a difference and we you can get confused very easily so the main difference is here so at the
00:06:06.250
top we have continuous delivery as you can see we do the normal process of pushing our code we run some tests on it
00:06:12.760
and then we have a manual step where we're deploying doing some sort of deploy so in continuous deployment which
00:06:18.850
is what we're talking about we automate that last step so any code that happens to hit your master branch will end up in
00:06:24.970
production through an automated set automated process yes so you might be thinking why would
00:06:31.269
you want to do continuous deployment sounds a bit sounds a bit yolo or yolo as many Australian it's like to see and
00:06:38.199
so let's talk about why you want to do a crazy thing yeah Mario number one is a
00:06:43.809
fast feedback in this new fandangled world of a/b testing and that sort of
00:06:50.379
stuff you know you want to get your code out to production as fast as possible like we can use some science and and and
00:06:56.469
try and figure out if you know when you're increasing conversions on trying to increase traffic on the website you may think if we change as one word here
00:07:03.279
we might be able to increase signups by twenty percent and those sorts of experience are really really handy but
00:07:09.339
you only pushes out to production really quick because if they I don't remem tall you want to get rid of them any quick so getting fast feedback from real
00:07:15.879
customers in production is really valuable confidence you want to be in you know that your deployment process is
00:07:21.849
is doing the same thing every single time and at Carly's that kind of leads into your predictability man you deploy
00:07:28.149
is are quite error-prone especially when you humans do it because if you've got a bug in production you want to get a fix
00:07:33.639
out to your servers really quick it can you know you're a lot of pressure your teammates are like why is there not in
00:07:39.489
production yet and and you can be stressed and you might skip a step in your manual deploy process especially if
00:07:45.399
you've got multiple environments like a QA environment of staging environment in a production environment so scripting and having this process automatically
00:07:51.610
done for you just kind of avoid most of those problems I wasn't my was running
00:07:57.729
short into a slide so I thought I would see what it would look like as a Venn diagram yeah but I don't think see what
00:08:02.829
I don't think this thing works at the Venn diagram the moment is just kind of open up overlapping circles I think
00:08:07.929
there's a thing in the middle you're supposed to put but i don't really know something yes so so here's a good slide
00:08:13.179
that you could take a photo of and show your manager and I'm sure that they would get on board with continuous
00:08:19.539
deployment and so as the vendor saying goes morrow you can't do continuous deployment without breaking a few
00:08:25.839
omelets so let's talk about the things that you going to need to do continuous deployment and these up things I think
00:08:32.800
they're coming up on the screen I can't see it did they come up yeah great not go back on oh wait up oh I know that's
00:08:39.759
all right fine so the first step of any continuous deployment is future planning when you get starting
00:08:45.910
to build a feature you should get a couple of guys in the room and talk about how you're going to build this thing you may think that it's going to
00:08:51.280
take a month and so the best thing you could do is try and break up that load those larger features into much smaller
00:08:57.070
features things that you can ship in a two or three-day cycle and so you take
00:09:02.170
this big feature you break it up into lots of smaller parts and by the end of all those small parts you've ended up pushing this much larger feature to
00:09:08.500
production you want to talk about how you going to deploy it with zero downtime I will talk about later what zero downtime actually is but sometimes
00:09:16.030
you may be introducing a new stack it's your technology so like you might be being ready sin or some other technology
00:09:23.170
you want to think about how you can push this new technology to production without bringing up a maintenance page and we'll talk about why maitenance
00:09:29.470
pages are bad and you need to talk about how you're going to handle database migrations another one of those things
00:09:35.860
that are really hard a few of them ever done zero downtime deployments before but they can be a real pain in the
00:09:41.830
bottom so we'll find out more about that later occurred of use this is how Bill
00:09:48.040
Gates Dakota views back in the day with paper it's a new tool you may have heard of it it's called github all the kids
00:09:54.100
are using it that's how we do code review these days with these things called pull requests and this is what a
00:10:00.160
pull request looks like and so when Mara and I going to start a feature I'll typically branch off master I'll do the
00:10:07.480
feature i push it up to github and get a pull request review and mayra will review it a couple of tools to aid in
00:10:14.140
this code of your process one of them is called Cain sometimes pull requests can
00:10:19.360
get caught up in talking about Ruby style and quotes and single quotes and this methods quite long these tools can
00:10:26.020
kind of help just get rid of most of those arguments and then you can focus on the talk talking about the design of the code instead of just like the
00:10:33.160
listener piggies yeah so Cain is a great tool and a rubric op is also a great tool and that will look at see if your
00:10:39.610
code looks like the what the Ruby style guidelines say that it should look like it Kane will actually statically analyze
00:10:44.830
your code so if you have any methods that are over a certain complexity you automate you'll get an error and if we
00:10:50.410
can integrate that into a bill pipeline it means that we're not actually deploying any curry that's subpar yeah yeah and then the next part of
00:10:57.660
continuous deployment is speech toggles everyone know what a feature toggle is knowing not know what a feature toggle
00:11:03.220
is great i'll skip these slides it's so
00:11:08.740
basically it's the act of wrapping a feature around a conditional and you can toggle it on and off without deploying
00:11:14.410
production the best way to think about fidget ugh was just keeping it really really ghetto so if you're deploying a
00:11:20.050
new feature to production or something a new flow for example maybe think about just hiding the button that takes it to
00:11:26.260
that flow you don't really need to think about permission systems and those sorts of things if someone can get to the new feature by the URL a little treasure
00:11:32.350
it's a nice little surprise good on them yeah they deserve the broken feature and
00:11:38.889
so you can just keep this really good to keep it really simple in the UI put a little flag around the button boom
00:11:44.920
you've done it so feature sogol a couple of tools to help you do feature toggles this one called roll out it's very very
00:11:51.910
simple allows use different backends like red s yeah more active record so
00:11:57.279
you can that's a very simple one to use a more advanced version of feature toggles is one can flip it's got a whole
00:12:03.819
bunch of percentage based stuff and more grouping controls of UI stuff as both know you I admin thing that you can plug
00:12:09.310
in so you control your future toggles by admin that's a handy tool to have a look
00:12:14.350
at yep so if we're going to be doing automated deployments we're going to need automated tests and the thing that
00:12:20.050
we want to do with that test is we want to write just enough tests and no more so we want to have enough confidence
00:12:25.720
that we're testing the right things but we don't want to write too many tests and the reason for that is we're now
00:12:31.120
coupling our tests with our deployment process so if we have five minutes worth of tests it means we can't actually
00:12:36.160
deploy 45 minutes so the the quicker we can get our tests the the more quicker
00:12:41.350
we can get that feedback cycle happening so a simple way to do that is to concentrate more on unit testing rather than integration testing contrary to
00:12:47.860
what was said earlier if you do want some more information about how to do fast testing if Corey hangs around grab
00:12:54.040
him he's excellent at this he did do a presentation at Golden Gate in 2011 so if you just said shower rails house
00:13:00.160
tests Corey Haines Golden Gate you'll get this excellent video which will do a really good justice another thing that
00:13:05.860
we're going to want to do is we're going to want to do these smoke tests so what a smoke test is when we after we do our actual
00:13:12.040
deployment we're going to run some tests to verify that everything works as is so traditionally in your when you're doing
00:13:17.410
manual deploys someone's role is to actually check that the deployment has happened successfully so after our
00:13:23.800
deployment finishes someone usually check and make sure things like you know does the homepage actually render just very simple things just to make sure
00:13:29.470
that not the for example the feature that we've just pushed out but does the app whole application break and we can
00:13:36.280
get you that with smoke test and we can start building up and not smoke test to get more confidence in at each deploy so
00:13:41.980
these smoke tests they run against a remote server and as I said they can be as simple as does the name of the
00:13:48.040
product appear on the homepage one cool thing is you can actually reuse some of the tests you're using so for example
00:13:53.500
you might have a login test that runs locally we can reuse that same integration test just pointed at a
00:13:58.540
remote server you can do that if you're using capybara for example and then we get we can reuse those sort of tests you
00:14:04.870
do need to obviously be careful if you're doing anything with destructive tests so for example if you have a test
00:14:11.470
that destroys to make sure that someone can cancel their account you obviously don't wanna be running that against a production environment so need to get
00:14:17.050
smart about how you do those things so zero downtime employees essentially the
00:14:24.040
zero down deploy is the act of pushing new co2 production without the user ever
00:14:29.140
noticing that the deploy happened at all one way to some some people use
00:14:34.990
maintenance pages to do this if you've got some back-end changes you need to make put up a maintenance page do the
00:14:40.870
production deploy and bring the matrons page down but if you're doing 20 if you're pushing to master 20 or 30 times
00:14:46.810
a day and you're automatically deploying master to production 20 or 30 times a day that's 20 or 30 times deploy is that
00:14:54.220
a migrate a man is paid to popup and that's going to be pretty crappy experience for your customers so figure
00:15:00.130
out a way to do that without the maintence page is quite tricky unicorn passenger humor all have ways to do is
00:15:07.510
zero downtime deploys if you're on Heroku you'll note that when you push to Heroku the next request after a ploy
00:15:15.430
will be slightly slower as the new Dino spin up one way to get around that is to use the Heroku
00:15:20.889
feature to enable this feature and you'll get zero download place and it will be much better experience it sort
00:15:27.579
of runs to diners then we'll swap one over after the after a certain amount of time yeah you can start serving your requests on the new diner once at a
00:15:33.850
police finish yeah if you want to know more about as you're down to deploy this is a great browse cast on it if you're just Google for zero downtime deploys
00:15:39.790
growls cast we get all the information as a rail scarce on it's great so next
00:15:45.609
is database database migrations now we mentioned database migrations earlier it's a it's quite a big part and the
00:15:51.220
reason why it's a big part is it's quite hard to do so let's take an example of a typical database migration that we might
00:15:57.609
do so here is a migration we're going to run against a user's table so you can
00:16:02.649
see we're removing the notes column and what you might do is for example we might send a pull request and we might
00:16:09.179
remove all the code touching that notes column and then we bundle that migration we run it we deploy everything's fine
00:16:15.339
but what you what you'll probably see happening is this so we're getting this
00:16:21.819
error from our database saying that the notes column doesn't exist which is sort of weird because we've already removed
00:16:27.910
all echo that's going to be touching the notes column but we're still getting this error so the reason why this error occurs is when your rails out boots
00:16:34.749
active record will actually inspect the schemer of the table that it's the model is for and all cash the columns that it
00:16:40.600
needs to use so if you do any inserts or any updates even though we're not explicitly giving us a value it will
00:16:46.059
still forcefully insert a null value into this column and that's how we're going to get this error so on user signs
00:16:52.209
up for example after this before the dyno restarts you'll get this error if a user hits the signup page so we need to
00:16:57.730
account for that some way the easiest way to do it is just put up a maintenance page so in our deploy script
00:17:04.149
we can detect any harmful migration so this is quite good if you have obviously a low amount of users you can detect if
00:17:10.990
you're running a remove remove table room of column change calm anything destructive and put up the maintenance
00:17:16.029
page and then for all other deploys we proceed as is the better way the hard way is to do your migrations last so
00:17:23.740
there's actually ways that we can get around that problem with the schema and if you check out hello Pedro has an
00:17:30.400
article about this exactly and it goes through all of the different migrations you can run and how to account for each
00:17:36.250
of each of them so it's essentially just telling the models that the columns that were going to look at Jonah include that one that we're going to remove the other
00:17:44.260
thing to be mindful of his database locking right so if I use a heating our applications and are running some migrations in the background our
00:17:50.560
database we might actually be locking on a row level or even a table level so if
00:17:56.650
we have any long-running migrations against an entire table and it's locked that table it's going to prevent users from right writing to it so we might
00:18:02.740
prevent people from signing up while we're doing a long migration so you need to be careful of these things if you're
00:18:07.960
using my sequel there is a tool called lhm which will help you do this if using
00:18:14.350
a better accusing another database you have to check out depending on the type of database so it varies so you need to
00:18:22.630
look up what's the best thing to do yeah so we're talking about automatically
00:18:28.840
deploy to production and sometimes sometimes happens I think that's a
00:18:35.230
nice way to put it yeah um happens all the time for example have you ever opened up your wallet if you will have a
00:18:43.480
catch on fire in front of your face I mean this happens to me generally most of the time and I think that proves my
00:18:51.550
point that should happen sometimes especially the first time I did that
00:18:56.590
face got burnt off Al's with that eyebrows for about six weeks not easy
00:19:01.600
being magician is it's not easy and so happens interestingly enough this
00:19:06.850
this picture here is a picture from Perth Airport and that's the screen that tells you when the flights are leaving
00:19:12.690
but now madison's you there's no keyboard that's useful and it kind of like the matrix really and so when
00:19:20.140
you're doing this sort of deployment what do you do when some it goes wrong the best thing to do is just roll
00:19:25.900
forward don't roll back and there are a couple of ways to to achieve the rule the roll forward just you can just fix
00:19:33.790
the bug because your deployment processes is automated you can just fix the bug bug put a PR up write a spec
00:19:40.570
right Russian test and then get a motion to master and then it'll just get a production by itself sometimes it's just
00:19:47.180
quickly to do that then to try and just do a roll back from production another
00:19:53.090
thing you can do is just turn the feature off because we because we do feature feature toggles if something's
00:19:59.030
not working quite right we can just turn the feature off and that works really well and I think you can do is get
00:20:04.820
reverted and deploy that's another great rollback strategy obvious doesn't work so well if you've got database migrations but if it's just a few code
00:20:11.540
changes then you can absolutely do that and in the worst case scenario you get the obvious thing and and just turn on
00:20:17.960
the maintenance page like if something's on fire at home you just pull the plug out I think I'll still be on fire after
00:20:25.580
that but you have your having a power going to it so that's right there be an electricity which will help okay that
00:20:31.940
was great the next thing about continuous deployment is application monitoring you want to make sure that
00:20:37.940
someone's watching your application when you're not and so a couple way to do that is using exception tracking
00:20:43.820
everyone should be using exception tracking if you're not then I suppose you should one of the great tools that
00:20:50.360
we use is bugs nag it just catches Ruby errors and emails you when you're
00:20:55.580
pushing co2 production every day you may introduce performance regressions your relic you've all heard of it you should
00:21:01.910
be using it if now another great tool is pagerduty if your app gets slower or you
00:21:08.450
start getting an increase in exceptions you can actually get paid duty to call you and let you know that something's wrong so if you've just pushed to
00:21:14.990
production you've gone to lunch you might get a call from page of Judah and you know that you've broken the site but
00:21:20.840
hopefully doesn't happen another good thing to track instead at performance metrics is maybe like signups signups
00:21:27.050
Perales sales / ala x per hour their business level type metrics let's say
00:21:32.390
you pushed to production and all of a sudden sign-ups have to drop by fifty percent over the last 30 minutes that
00:21:37.550
might be some it might be something you're interested in and so there's a great talk by David good leg called business metric monitoring which you can
00:21:43.880
check out and that'll tell you all about how to set it up in your application and it's worth why doing yep so if we go
00:21:50.660
look back and have a look at the ingredients so these are all the things that we're going to use to do our deployments so
00:21:56.359
let's mix them together and the in time to mix I love mixing love mixing so let's start off with something very
00:22:01.759
simple so here's what our build servers going to do so there's a couple flags at the top there just for printing out the
00:22:08.749
output and the other flag is just for if we have multiple commands it'll stop as soon as it hits one but it will stop
00:22:14.629
with one fails one fails but essentially what we want to do is we just want to use Heroku it's very simple here in this
00:22:19.909
example but we just want to push the Heroku so basically as soon as we get into master we're going to push tohoku so yeah this might be useful for when
00:22:27.229
you first start the app just to get something happening this is a simplest way to do continues to get the most get
00:22:32.479
away yellow Yolo whatever want to call it if you put this as your build script
00:22:37.789
on CI you've just achieved continuous deployment yeah but this is all you need so after you're probably in production
00:22:44.119
getting users hitting it you might want a bit more so let's add some more good stuff so now in our script before we run
00:22:51.080
our deployment we're going to check the static analysis of the code so by putting right quality in there that's
00:22:56.779
using that cane gem we can actually statically analyze the code and it means if you write a method that's too complex a production deploy just won't happen
00:23:03.799
and you need to fix it so it's a great way of making sure your Kirby stays clean like that after that we're going
00:23:09.349
to run our tests and after that we're going to do a deploy so now we've got the additional confidence of knowing that our tests are going to be running
00:23:15.950
as soon as I chester greene we dry deploy and then after we do our deploy we run an additional smoke test to
00:23:21.739
verify everything is good so this can just simply start off as does the homepage render can I click a link
00:23:26.830
simple things like that so this is all very well but we still don't have a huge
00:23:32.869
amount of sort of confidence we've got some liberal conference but it's still a little bit sort of cowboy ish so the
00:23:38.929
next thing we're going to add to our build script is we're going to add a different environment so here we're actually using a staging environment a
00:23:45.349
typically to what you'd normally use it for so after we run our tests and we verify everything is okay we're going to
00:23:50.389
do is staging deploy and then we're going to grab the same smoke tests and we're going to run those against our staging environment if those will pass
00:23:56.749
so if we can render the home page if we click a few links or whatever we've got to buy this point we're going to do a
00:24:02.379
production deploy and then after we do a production deploy we're going to run the same test so now we
00:24:09.370
have a good amount of confidence that our bill is going to work we're not going to break anything and then after we've sort of done that we can verify
00:24:14.800
that the feature works independently by flipping the flag on for certain users we when we worked on and brought us
00:24:21.760
together we actually had a smoke test that would buy something on staging so the actual marketplace it would run
00:24:27.100
through and use would buy something using like the sandbox and paypal for example so unless you could buy something on the site which is the key
00:24:32.950
purpose production play wouldn't happen which is really cool yeah so our deployment process now has tests and
00:24:40.120
when you start thinking about your tests as a pre-flight check to deploying a kind of lends itself really want to do
00:24:45.850
continuous deployment now we've got we've looked at all the things we're going to need to do continuous deployment we've looked at the actual
00:24:51.160
build script that we're going to use to get this thing to production let's mix it all together and see what it actually looks like for a proper flow so how
00:24:59.620
would you actually apply this so we do open your desktop at the wallpaper sharing website with Dropbox back in
00:25:05.640
Mario I've got a great idea for a feature what's a key I social buttons social media but yeah I heard about it
00:25:11.590
what do you undo I want to put them everywhere on everything let's see it and so I'm going to occlude this feature
00:25:17.500
up this is what desktop looks like with social buttons I've got twitter google+
00:25:23.880
the good ones I've got a I've got facebook to linkedin's ah i heard that gets your extra conversions extra
00:25:29.800
convert ground and so I'm feeling good about this change awesome I'm happy with
00:25:34.900
it yeah so this this particular changes in a in a branch behind a feature toggle I'm gonna push that to github and get my
00:25:41.770
review yep so what's going to happen is I'm going to be at my desk you know just writing some code or you know reading a
00:25:48.100
book about ponies one of the two I'm going to receive that pull request it's going to look a bit like this so i'm
00:25:54.370
going to review the pull request make sure everything's okay and then i'm
00:25:59.530
going to +1 it did it work okay so I've ever find that work locally it was fine yeah great that's awesome and so once
00:26:06.910
Matt once Mario is +1 the feature we hit the merge button and now this button here is not just merge proquest it
00:26:13.450
actually also means deploy to production which is pretty awesome the Bloods
00:26:18.610
runs that we ran before yeah it does the quality it does the test it does the stage and deploy it as a staging smoke
00:26:23.620
production deploy a production smoke and I'm feeling pretty confident that if all these things pass and it gets to
00:26:29.260
production then production is going to be sweet and it's a plug a build box
00:26:35.860
they start up that I'm doing yeah this is what that process would look like in bull box where you can split each each
00:26:41.710
part of the deploy process into multiple steps and have them all green and if it's all green the production is all green and I'm feeling pretty great
00:26:48.070
awesome so once it's on production nothing will look any different the
00:26:53.110
buttons will not be there but the code will be there what I the first thing I do is activate the feature for
00:26:58.929
developers because i'm a developer i'll activate it then i will start seeing the social buttons i think it looks great
00:27:05.559
yep then we might get someone to check over i might have a look and go yeah that's what it didn't in my development
00:27:11.110
that's all great yep yep so Mario's happy I'm happy my boss is super happy because there's two linkedin buttons and
00:27:17.140
i think at this point we deploy if we turn on over everybody yep and then that's it we've just deployed a feature
00:27:23.500
automatically without really having any sort of manual intervention it's great so that's awesome so let's have a recap
00:27:31.090
of the things that we we discussed the the qualities that we wanted from our deployment process so we've got these three qualities in a Venn diagrams so we
00:27:38.440
have our fast feedback our confidence and are predictably so let's let's step through each one and make sure that we've achieved them so the first one
00:27:45.309
fast feedback we're getting our fast feedback because we're making sure I test a quick every single time we merge to production we know that it's it's
00:27:53.799
going to every single time we merge to the master brave story we know it's going to happen end up in production a few minutes later so we've got our fast
00:28:00.280
feedback our confidence we now have an automated sweet around our deploys we now know that we can't actually it's not
00:28:07.540
possible using this process to deploy a failed test to production it just can't happen because it's embedded in our
00:28:13.540
process now we can't ship bad code to production as well because we have that quality check in there as well so any
00:28:19.870
complex methods any any any violations of them ABC complexity for example just aren't what can't get into production
00:28:25.419
which is great we now have more confidence and we have predictability so we've automated a manual process which
00:28:30.640
was which the arrow prunes so rather than a person doing it we've got a computer doing it which we know is predictable each each
00:28:36.000
and every time it's the same so we've achieved these three things so let's compare two different products so this
00:28:43.620
is a we've used some science here these are two different products that you they have about four or 25 developers each
00:28:50.279
they're both around about a year old and they both run a rail stack so very similar sort of products when we have a
00:28:58.139
look we you will notice that the product that we do continuous deployment on we almost average five deployments each day
00:29:04.080
and when we're doing manual deploys we're deploying much less so slightly less than two times on average this is
00:29:10.289
where the same two week period with the same number of developers on each project so you can see we're increasing
00:29:15.330
the amount of deploys we're doing so we're shooting much smaller chunks there's much much less chance of anything going wrong and so we should
00:29:22.860
have more confidence in what's happening anyway just to play more often so more stuff hits production quicker so if we
00:29:29.129
could leave you with anything today it's that you should always be continuously deploying thank you that's it niraj
00:29:57.220
you