00:00:10.559
well hello everyone and welcome to my
00:00:13.360
talk on an upgrade handbook to rails 8
00:00:17.439
and welcome to
00:00:19.439
Toronto
00:00:23.599
welcome welcome to the largest city of
00:00:26.279
the true north of almost 3 million
00:00:29.560
people and that's not including the
00:00:32.920
greater Toronto area as you can see here
00:00:36.640
lot this means that there's a lot of
00:00:38.800
people and they need to get to a lot of
00:00:41.920
different
00:00:43.320
places more than
00:00:46.079
600,000 rides on the Toronto subway the
00:00:49.680
TTC occur on a average day and you may
00:00:54.239
have enjoyed a ride on these things in
00:00:57.320
the
00:00:58.480
city in Toronto we have three Subway
00:01:01.960
Lines which date back to the
00:01:05.760
1950s but and many people in the city
00:01:10.119
including myself aren't super Satisfied
00:01:13.759
by the
00:01:14.960
service on average the TTC records an
00:01:18.920
annual average of 20,000 Subway delays
00:01:22.400
that means there's over 50 per day and
00:01:26.320
only 14% of Transit rides are considered
00:01:30.799
on time so you're going to be late
00:01:35.640
everywhere so why is the TTC so
00:01:41.759
awful hold on to that thought we'll get
00:01:44.920
back to this we're here to talk about
00:01:47.799
ruon rails and not the Toronto rails
00:01:51.320
here um but before we get into that let
00:01:53.920
me introduce myself I'm Jenny I'm one of
00:01:57.520
the three million people that live in
00:01:59.439
Toronto
00:02:00.759
and I'm also very experienced into
00:02:03.520
running into Subway closures and
00:02:07.280
delays um I work at Shopify on the uh
00:02:11.360
rails infrastructure team and Shopify
00:02:14.720
being this uh City sponsor there's a
00:02:17.519
couple of us here so don't be afraid to
00:02:19.720
say hi and we're also hosting the
00:02:22.800
closing party at our office so I hope
00:02:26.040
you are hyped for
00:02:28.480
that and
00:02:30.800
yes get
00:02:34.000
hyped and but speaking of hype we're
00:02:37.280
going to cover some hype things all all
00:02:41.239
about ruby and rails upgrades we're
00:02:44.000
going to touch on how to upgrade rails
00:02:47.120
in an application and its benefits we're
00:02:50.680
going to upgrade a an app to the latest
00:02:54.840
release and I'll be talking about how
00:02:57.599
Shopify Mass upgrades rail
00:03:00.480
across the
00:03:02.080
company um here's the QR code for the
00:03:05.080
slides if you want to follow along uh
00:03:07.840
but they'll be at available at the end
00:03:10.120
of the talk
00:03:13.360
too so how the heck does someone upgrade
00:03:17.799
rails in an application the rails guys
00:03:21.040
gives a great overview on how to upgrade
00:03:23.799
a rails app to the next minor version
00:03:26.519
I'll be doing a very quick walk through
00:03:28.959
for those who AR aren't as
00:03:31.200
familiar um there's some prerequisites
00:03:33.760
before you start to upgrade rails um and
00:03:37.280
the first one is you need tests to pre
00:03:40.720
to prevent unexpected issues going into
00:03:43.439
production tests are the first line of
00:03:46.000
defense which can tell you what parts of
00:03:48.680
the app may need changing because of a
00:03:51.120
change in
00:03:53.120
rails make sure you meet the minimum
00:03:55.959
Ruby version required for uh rails 8 uh
00:03:59.959
be
00:04:00.920
3.1 and the first step of the actual
00:04:03.760
process is to move to the latest patch
00:04:06.680
version of after your current version so
00:04:09.799
if you're on Rails
00:04:11.840
7.1.0 you will want to move to
00:04:16.000
7.1.4 you can do this by editing the
00:04:18.720
version in your app's gen file and
00:04:20.759
running bundle
00:04:22.440
update then you'll need a fix tests and
00:04:25.479
deprecated features and then you would
00:04:28.560
move to the latest pack cash version of
00:04:30.759
the next minor version by bundle
00:04:32.919
updating again so if you're on Rails
00:04:36.320
7.1.4 you would want to move to
00:04:40.320
7.2.1 seems pretty straightforward
00:04:43.000
forward so far but that's not all when
00:04:45.880
you upgrade uh to a new major or minor
00:04:49.280
version you would need to run the update
00:04:52.039
task bin rails app update this will help
00:04:55.800
you with the creation of new files and
00:04:58.000
changes of old files in an interactive
00:05:00.800
session to update to the new templates
00:05:03.880
and defaults uh you may need to take
00:05:06.360
some time to review the differences
00:05:08.840
between uh overwritten files to see if
00:05:11.600
that's something that should be kept for
00:05:13.560
your app or
00:05:14.960
not and lastly you'll want to configure
00:05:18.000
framework defaults one of the FI uh
00:05:21.039
files the update task produces is the
00:05:23.680
new framework defaults
00:05:26.120
file uh this includes many commented out
00:05:29.120
configurations
00:05:30.600
which in which you would need to
00:05:32.080
uncomment each one to make sure they
00:05:34.880
work in your app once they are all
00:05:38.240
uncommented then you can update the lad
00:05:41.319
defaults to the latest
00:05:43.680
minor um so here are the summary of the
00:05:46.880
steps it's not the most simple process
00:05:51.520
um and it can take quite a bit of time
00:05:53.919
if there's a lot of broken tests or
00:05:57.360
deprecations so why do we even bother to
00:06:00.600
upgrade like upgrading to eight if
00:06:03.160
you're on rail seven let's go back to
00:06:07.160
why the TTC is so awful one reason why
00:06:11.800
there's so many delays currently is that
00:06:14.440
there are reduced speed zones this is
00:06:17.720
because maintenance has neglected to a
00:06:20.520
point where track repair is required in
00:06:23.240
those areas and it's just unsafe to go
00:06:26.000
at a normal
00:06:27.560
speed and the busiest Street car line in
00:06:30.240
the city is closed from June this year
00:06:32.919
to the end of year for track and
00:06:35.440
electrical upgrades and the replacement
00:06:39.120
buses for them are a lot slower
00:06:42.479
especially during rush
00:06:44.680
hour the TTC lives by doing big repair
00:06:49.039
and upgrade projects when they have to
00:06:51.919
and rely on quick bandaid fixes to keep
00:06:54.680
on running these upgrade projects causes
00:06:58.319
more user dis satisfaction to already
00:07:01.479
poor Rider
00:07:03.440
experience so what does better look like
00:07:07.919
in Japan uh they are known for their
00:07:10.720
efficient and reliable Railways they're
00:07:13.599
reliable because they do maintenance and
00:07:16.360
upgrades daily at night keeping service
00:07:19.280
on time and avoiding long periods of
00:07:24.000
closure to be a first class City the
00:07:27.240
city's infrastructure needs to be first
00:07:29.759
class first class cities tend to attract
00:07:33.000
people and they are happy because they
00:07:35.280
can move around the city
00:07:37.639
fast transit systems are just like rails
00:07:41.720
apps if you don't upgrade rails in your
00:07:44.639
app and your version becomes end of life
00:07:46.960
you aren't getting backports of SEC
00:07:49.360
security and buck fixes in your app and
00:07:52.479
that's not keeping your sa uh app safe
00:07:54.960
and up to
00:07:56.360
date it might be easier in the short
00:07:59.240
term to rely on monkey patches or
00:08:02.360
creating solutions to fix these bugs but
00:08:05.960
to a point apps are forced to migrate
00:08:08.479
due to one reason or another uh this app
00:08:12.240
in rails
00:08:13.479
3.2 um uh Heroku couldn't support it
00:08:18.120
anymore and this maintainer was worried
00:08:20.800
that it's going to take super long and
00:08:23.080
will cause many
00:08:25.840
outages and like previous releases rails
00:08:28.919
8 is going to be super exciting you
00:08:30.840
heard it from dhh himself there's so
00:08:34.240
many new features to continue making
00:08:37.200
working in rails a a first class
00:08:40.640
experience this includes comml and solid
00:08:43.800
Q by default rails LSP Dev container
00:08:47.800
setup and much
00:08:49.760
more and this all will attract more
00:08:53.080
developers and very happy
00:08:56.680
ones so to summarize why should you keep
00:09:00.600
your rails version up to date so to
00:09:04.560
prevent to be so you're not going to be
00:09:07.000
the TTC of rails apps you want to keep
00:09:11.200
our rails apps safe and reliable prevent
00:09:14.760
costly large upgrades and promote a
00:09:17.600
first class Dev
00:09:20.440
experience now that we know how to do
00:09:23.040
rails upgrades and why they are
00:09:25.200
important I'm going to share some things
00:09:27.560
that you may encounter while upgrading
00:09:29.839
to rails
00:09:31.040
8 um the rails 8 is um going to be
00:09:36.240
released or is released soon um is
00:09:40.399
already released as dhh mentioned um but
00:09:43.880
a lot of those features were also
00:09:45.880
released in 7.2 in August uh this
00:09:49.640
includes um default Progressive web
00:09:52.480
application files Dev container
00:09:55.959
configuration Omas rubocop rules and
00:09:59.560
many more um the deprecations in 7.2
00:10:03.839
will raise warnings and will be removed
00:10:06.680
in rails 8 so you're probably wondering
00:10:10.399
what deprecations are there what should
00:10:12.519
I expect to be removed to make it a
00:10:15.360
little bit more fun we're going to
00:10:16.839
upgrade an application from 7.1 to see
00:10:20.560
what you can encounter in your apps
00:10:23.360
we'll explore some interesting dications
00:10:26.320
and framework defaults so you'll know
00:10:28.640
what to expect to when you get your app
00:10:31.720
one step closer to rails
00:10:34.720
8 before we get started a little context
00:10:38.240
on the app itself I create an app that
00:10:40.839
tracks TTC service
00:10:43.920
alerts um it scrapes the TDC alerts on
00:10:47.600
Macedon and you can see the posts in the
00:10:51.120
app and we can um sort these posts by
00:10:55.800
events and you can see if one is if they
00:10:58.920
result D or not and uh on the dashboard
00:11:02.720
you can see with the uh ongoing alerts
00:11:06.079
with and the current WEA I can determine
00:11:09.440
if I should take the TTC or I should
00:11:12.959
like get an Uber to where I want to
00:11:16.519
go so the app is on
00:11:20.720
7.1.4 um and when we upgrade to the next
00:11:23.959
minor uh there's some deprecations and
00:11:26.800
changes when we run the test
00:11:29.760
one thing you may run into is changes if
00:11:32.240
you're extending your rails
00:11:34.240
console um I to demonstrate this I
00:11:37.519
created a Feeling Lucky command that
00:11:40.480
you'll never forget um I have a demo
00:11:44.000
I'll run it for you quickly now oh okay
00:11:49.600
who this is
00:11:54.639
dramatic Never Going To Give You Up
00:11:57.399
never going to let you down never gonna
00:11:59.920
run around and desert you never gonna
00:12:02.440
make you cry never gonna say goodbye
00:12:05.839
never gonna tell a lie and hurt you yeah
00:12:09.200
so that it's a great command when you
00:12:13.040
for when you want to feel lucky I guess
00:12:16.399
um anyways um how I do this is I extend
00:12:20.959
the rails console methods with the
00:12:23.000
feeling lucky
00:12:24.440
module but in rails 7.2 uh it is
00:12:30.079
doing so in rails 7.2 is now deprecated
00:12:33.720
this is because IRB introduced official
00:12:36.800
API to extend the console instead of
00:12:40.040
hacking with internal parts of
00:12:42.880
IRB the API allows you to create helper
00:12:46.399
methods and commands um a helper method
00:12:49.880
should be used if you want to do an
00:12:51.600
operation that returns in Ruby object
00:12:54.760
and a wet command should be used to uh
00:12:57.720
for non Ruby related things like utility
00:13:00.720
operations and displaying information so
00:13:04.279
for my feeling lucky operation I can
00:13:07.320
define a IRB command with a category
00:13:11.680
description and an execute method and
00:13:14.880
register it to my
00:13:17.440
console and now works and it displays
00:13:20.279
the category and description in The Help
00:13:25.279
menu uh rails has migrated to use this
00:13:28.320
API and some requires may also be
00:13:31.120
deprecated if you're requiring them in
00:13:34.040
your app or gem so if you're requiring
00:13:36.720
that helpers or app file you should
00:13:39.000
change them to you uh include uh require
00:13:42.320
the methods file
00:13:44.760
instead another change in 7.2 is that
00:13:48.320
there was a change in active job Q
00:13:51.120
adapter
00:13:52.440
configuration previously if you set a q
00:13:55.279
adapter that adapter would be used in
00:13:57.839
some tests but in integration act uh
00:14:01.759
action mailer and active job tests it
00:14:04.959
will still use the test adapter this
00:14:08.040
caused weird Behavior if you expected
00:14:10.600
the application adapter in all your
00:14:13.320
tests in previous versions of of rails
00:14:16.880
but in 7.2 the adapter is now consistent
00:14:20.279
through all test now uh this may break a
00:14:24.040
couple tests if they were built around
00:14:26.240
the test adapter though so in this
00:14:29.399
System test that uses assert in cued
00:14:32.399
with uh it fails since the helper
00:14:35.839
requires the test
00:14:38.399
adapter but you can set the adapter to
00:14:41.279
test in the test config to easily fix
00:14:45.440
this in 7.2 when you run tests rails
00:14:49.199
will Now notify if a test doesn't have
00:14:51.800
an assertion this is pretty simple but
00:14:54.839
is very good since not having assertion
00:14:58.600
can indicate if a test is
00:15:01.079
broken like in this example I want to
00:15:04.000
test if a resolved uh event record has a
00:15:07.759
resolution record Associated but if
00:15:10.680
there's no events to begin with then the
00:15:13.920
Sur is never reached and the test should
00:15:17.199
be
00:15:18.120
fixed sometimes you may have a test to
00:15:20.759
make sure an operation doesn't error
00:15:24.240
like in this console test where I want
00:15:26.399
to make sure that running the feeling
00:15:28.399
lucky Comm doesn't explode uh doesn't
00:15:32.240
explode when I run it um you can wrap
00:15:34.959
assert nothing race to demonstrate this
00:15:38.839
intent uh the preference of Sy uh enum
00:15:42.519
syntax has also changed and now there's
00:15:45.959
a deprecation uh to using keyword
00:15:49.120
arguments for using the name uh using
00:15:52.399
keyword arguments for the name and value
00:15:55.240
and rails prefers you to use positional
00:15:58.199
arguments
00:15:59.440
instead uh this syntax is better as it
00:16:02.720
prevents requiring underscoring option
00:16:06.079
arcs to separate enum
00:16:09.360
definitions and lastly not really
00:16:12.079
related to my app since it's on 7.1 but
00:16:15.600
I want to call out that there's some
00:16:17.680
last few deprecations regarding uh rail
00:16:21.639
Secrets uh rail Secrets is quite old it
00:16:25.720
was introduced in rails 4.1 where you
00:16:29.360
have a secrets. yo file and you can
00:16:32.160
Define Secrets per
00:16:34.600
environment and
00:16:36.839
5.1 uh rails introduced encrypted
00:16:39.839
secrets and when enabled and ran the
00:16:42.279
setup command it will generate uh key
00:16:45.720
along with a encrypted version of
00:16:48.199
secrets.
00:16:50.160
yaml but in 5.2 dhh introduced a
00:16:54.600
completely different name to Secrets
00:16:57.440
called credentials
00:17:00.240
it allows better Secrets management by
00:17:02.639
allowing different credentials files per
00:17:06.360
environment um and rail Secrets have
00:17:09.199
been deprecated since and features are
00:17:12.439
slowly being
00:17:14.079
removed in 7.2 read encrypted Secrets
00:17:17.959
configuration has been deprecated and
00:17:21.039
calling rails application Secrets have
00:17:23.880
been removed completely so this is the
00:17:27.120
time to migrate to credentials by
00:17:29.880
running the credentials edit command um
00:17:33.240
to get
00:17:34.880
started okay we're done with some uh fun
00:17:38.240
deprecations and changes that you may
00:17:40.160
run into I'm going to quickly run
00:17:42.600
through some notable file changes when
00:17:45.200
you run the update command that I
00:17:47.280
mentioned
00:17:48.280
earlier uh you'll get a suggestion to
00:17:50.799
configure Puma Dev which is the golden
00:17:53.679
path to develop multiple rails apps
00:17:57.000
locally and there's a changed to the
00:17:59.799
default Puma threads from five to three
00:18:02.880
uh through discussion and testing from
00:18:05.440
um rails um members three threads had a
00:18:09.200
good balance between throughput and
00:18:11.760
latency and now uh you'll see a new
00:18:14.799
public view for unsupported browser
00:18:17.640
template as dhh mentioned in his keynote
00:18:21.400
u in rail 7.2 you can Define what
00:18:24.880
browsers your rails app can support by
00:18:27.080
setting allow browser in your
00:18:29.400
application
00:18:31.679
controller nice um let's go through some
00:18:35.400
new framework uh some notable framework
00:18:38.320
defaults uh when you run the uh rails
00:18:41.559
update command there's a configuration
00:18:44.919
to incue jobs after transaction commit a
00:18:49.200
common mistake uh with active job is
00:18:52.120
that it'll inue jobs from a inside a
00:18:55.120
transaction causing them to be ran
00:18:58.799
before the transaction is committed and
00:19:01.159
that would cause weird errors but now
00:19:04.520
active job will automatically push in
00:19:07.159
queing the job uh in queing the job to
00:19:10.159
after the transaction is committed and
00:19:12.480
drop the job if the transaction is
00:19:14.880
rolled
00:19:16.600
back and lastly another default is that
00:19:20.400
wet is enabled by default um wet is
00:19:23.760
Ruby's jit compiler that has been
00:19:25.720
available since 3.1 and has shown to
00:19:28.960
improve latency by 15 to
00:19:33.039
25% so this is what some of the things
00:19:36.200
you could expect on your upgrade Journey
00:19:38.720
there's a lot of changes that I didn't
00:19:41.440
have time to speak here but hopefully
00:19:43.520
you'll have a better understanding um
00:19:46.320
when you start your
00:19:49.120
upgrade now I'm going to go through how
00:19:51.600
Shopify is able to keep up with these
00:19:53.799
rails upgrades across the company at
00:19:57.480
Shopify we have hundreds of rails apps
00:20:00.200
outside of our core monolith this
00:20:02.440
includes internal apps and other
00:20:05.039
Merchant facing apps uh this includes
00:20:07.640
like a app that would allow Merchants to
00:20:10.480
sell um bundles instead of individual
00:20:14.559
products and um an app to help create
00:20:18.200
logos for your
00:20:20.320
business uh these are Justus AIC here
00:20:23.200
these are standal low apps and not
00:20:27.200
microservices a few years ago we had 20
00:20:30.480
different versions uh rails versions
00:20:32.960
running on uh we have 500 applications
00:20:36.640
running on 20 different versions with so
00:20:40.000
many different versions it makes it
00:20:42.200
difficult to estimate upgrades across
00:20:44.720
the company and get a handle of security
00:20:47.919
issues from older
00:20:49.919
releases there was no expectations for
00:20:52.799
apps to upgrade on a regular basis as
00:20:56.000
mentioned before the more versions that
00:20:58.240
an app is behind on the harder it is to
00:21:01.200
get them up to date and for devs that
00:21:05.039
wanted to upgrade their apps uh the
00:21:07.360
steps were a bit unclear uh to go
00:21:10.720
through um many just upgraded the jet
00:21:14.279
like ran bundle update without migrating
00:21:16.880
the low defaults and many told the team
00:21:20.720
that was a painful
00:21:23.279
process so we got two areas of
00:21:26.679
improvement how can we make sure that
00:21:29.480
all our apps are up toate and how do we
00:21:33.360
make rails upgrades just easier for
00:21:36.840
Developers for the first point we
00:21:39.360
introduced a upgrade calendar for Ruby
00:21:42.240
and rails upgrades with the upgrade
00:21:44.880
calendar we can expect apps to run on
00:21:47.600
the latest minor each year for apps that
00:21:51.440
fail to meet these expectations will
00:21:53.799
start a deletion process or escalate to
00:21:57.559
create an up upgrade plan for apps that
00:22:00.080
we can't
00:22:01.880
delete this eliminates the ambiguity of
00:22:05.720
when to upgrade and allows teams to plan
00:22:08.360
for upgrades and allocate resources to
00:22:11.480
do
00:22:12.559
them it also gives a good opportunity
00:22:15.440
for teams to audit if their applications
00:22:18.600
are still being used or if they're
00:22:21.559
impactful if it isn't instead of
00:22:23.640
proceeding with the upgrade they can
00:22:25.679
just uh start the archival process
00:22:29.840
for the second point the more
00:22:31.760
interesting point how did we make rails
00:22:34.360
upgrades easier for
00:22:36.720
developers um to make the steps clearer
00:22:40.039
uh we created an internal gem called
00:22:42.159
rails
00:22:43.159
upgrade uh remember the rails upgrade
00:22:46.320
guide mentioned in the beginning of the
00:22:48.960
talk this gem essentially is a command
00:22:52.080
line script to automate each of the
00:22:55.159
upgrade steps outlined in the rails
00:22:57.919
guide by running rails upgrade once you
00:23:01.080
installed the
00:23:02.880
gem then it'll figure out the next
00:23:06.240
action that is required to upgrade your
00:23:08.440
app make the changes and provide any
00:23:12.000
context or followups uh needed before
00:23:15.360
the changes should be
00:23:17.880
merged the gam consists of steps similar
00:23:21.520
to the steps of the Rails upgrade guide
00:23:24.640
and each step has a met and a meet
00:23:27.640
method uh to determine if a step was
00:23:30.720
already met already or and if not meat
00:23:33.799
will make the changes and commit it to
00:23:36.360
the
00:23:37.720
repo so for uh for the upgrade to latest
00:23:41.360
patch
00:23:42.400
step met we'll check if the version in
00:23:46.520
the G file lock um versus the P the
00:23:50.200
patch version by fetching the rail specs
00:23:53.080
from ruby
00:23:54.400
gems and for me we'll have we have a
00:23:57.520
version upgrader object that would
00:23:59.799
update the G file uh and run bundle
00:24:02.960
update on uh for
00:24:06.679
rails one interesting step I like to
00:24:09.200
call out is the auto correcting
00:24:11.840
deprecation steps as we saw when we were
00:24:14.679
upgrading uh 7.1 app there were
00:24:17.360
deprecations that could be solved by
00:24:19.760
simple syntax change or it could be
00:24:22.159
deleted instead of wasting developers
00:24:24.799
time to manually fix them we can
00:24:27.640
statically auto correct them for example
00:24:31.200
a deprecation from 6.1 to replace URI
00:24:34.919
parser to URI default parser we can use
00:24:38.880
the syntax tree to correctly identify if
00:24:42.480
a constant URI that's calling parer and
00:24:46.520
replace it with the default
00:24:49.720
parser um this is an example of the
00:24:52.480
output of when you run rails upgrade uh
00:24:56.000
it shows the steps being run and outputs
00:24:59.000
the changes it
00:25:01.080
committed to leverage this genem though
00:25:04.039
we hooked it up to a rails application
00:25:06.799
that we call solid
00:25:08.880
track it run it tracks all of shopify's
00:25:13.000
rails apps and their versions runs the
00:25:16.480
rails upgrade command and opens PRS and
00:25:20.000
it does that on a weekly
00:25:22.720
basis uh this is what solid track looks
00:25:25.559
like and you can see the overview of the
00:25:27.880
versions of rails that's being run uh at
00:25:31.240
that apps are on and when you go on an
00:25:34.120
app uh go to an app page like solid
00:25:37.000
track itself since it's a rails app it
00:25:40.080
shows when an upgrade run was called and
00:25:43.399
the
00:25:44.720
result a run consists of a GitHub
00:25:48.320
workflow um that boots up the
00:25:50.440
application and runs the rails upgrade
00:25:53.120
command it takes the output and opens a
00:25:56.960
PR um this makes it easier for
00:25:59.799
developers to know exactly what to do to
00:26:03.520
correctly upgrade their rails app if it
00:26:05.799
looks good um they'll follow the steps
00:26:09.080
and merge and ship the
00:26:11.720
pr so with the upgrade calendar the
00:26:14.919
rails upgrade jam and solid track we now
00:26:18.880
have uh 400 rails applications 100 less
00:26:22.880
than what we had before and they are all
00:26:25.559
on 71 or later
00:26:29.080
and developers are grateful that rails
00:26:32.679
upgrades are
00:26:35.080
simplified so to recap we have gone over
00:26:38.919
the rails upgrade process and why they
00:26:41.600
are important some fun things to look
00:26:44.480
forward to fixing when upgrading your
00:26:46.720
app to the latest version uh and how
00:26:50.640
Shopify upgrades at scale um that you
00:26:54.200
may want to take back uh to your company
00:26:57.880
but if there's one takeaway that um
00:27:02.600
there if there's one thing that you
00:27:03.919
should take away from this talk is to
00:27:06.760
keep your rails up to date um and this
00:27:10.559
may be harder for earlier versions of
00:27:13.640
rails but um and in the more recent
00:27:17.360
versions it's a lot easier to upgrade so
00:27:20.919
um if you're on a really old version um
00:27:24.200
spend that effort and it will get easier
00:27:27.399
as Eileen mened mentioned previously if
00:27:29.520
you're running on Rails
00:27:32.159
3.2 um your problems are 10 years old
00:27:36.120
and you don't want to be the TTC of
00:27:39.440
rails
00:27:41.200
apps I'd like to thank everyone that
00:27:43.480
helped to make rails upgrades better at
00:27:46.240
Shopify and those who help me with this
00:27:48.799
talk and happy upgrading um here's how
00:27:52.559
you can contact me and slides and feel
00:27:55.360
free to come up to me and talk thank
00:27:58.200
thank you
