Summarized using AI

Lessons From Escaping the Dependency Upgrade Maze

Marko Ćilimković • September 11, 2024 • Sarajevo, Bosnia and Herzegovina • Talk

Lessons From Escaping the Dependency Upgrade Maze

In this talk, Marko Ćilimković, a seasoned software engineer, shares his insights on managing open-source dependencies effectively. He draws from his extensive experience, having spent approximately 500 hours maintaining over 20 applications with outdated dependencies. The central theme revolves around the challenges developers face when working with numerous dependencies that often lead to a chaotic upgrade process.

Key Points Discussed:

- Overview of Dependency Management:

- The speaker begins with an analogy of being in a maze caused by the complexity of managing multiple dependencies across various applications.

- Emphasis is placed on the significance of keeping dependencies up-to-date to avoid potential technical debt.

  • The Importance of Upgrading Dependencies:

    • Outdated dependencies can lead to security vulnerabilities, such as CVEs (Common Vulnerabilities and Exposures) and compatibility issues.
    • Regularly updating dependencies is vital as new features, performance improvements, and security patches are introduced.
  • Case Studies and Data Insights:

    • Ćilimković presents statistical data showing the number of Ruby gems and their growth over the years, illustrating how overwhelming the sheer amount of dependencies can be.
    • He shares experiences from infinum, where the team transformed their dependency management culture, resulting in enhanced project health metrics.
  • Processes and Strategies for Managing Upgrades:

    • The speaker outlines a structured approach for managing upgrades, which includes:
    • Mandated upgrades for dependencies, maintaining a consistent update cycle.
    • Prioritization of updates based on urgency, such as security patches before others.
    • Implementing automated tools like Pandabot to facilitate seamless PR (Pull Request) management in upgrading dependencies.
  • Maintaining a Healthy App Ecosystem:

    • Maintaining high code coverage and performing dependency triage to assess which dependencies need immediate attention can ease the upgrade process.
    • Documenting and implementing best practices in dependency management can minimize disruptions.

Conclusions and Takeaways:

Marko concludes by emphasizing the necessity of creating a culture of regular updates to dependencies within development teams. He notes that investing time in this practice not only safeguards the integrity of applications but also enhances team morale by reducing the stress associated with unexpected technical debt. The talk encourages developers to actively manage their dependencies for better application reliability and security.

Lessons From Escaping the Dependency Upgrade Maze
Marko Ćilimković • Sarajevo, Bosnia and Herzegovina • Talk

Date: September 11, 2024
Published: January 13, 2025
Announced: unknown

Open-source dependencies are double-edged swords: convenient when applying, but dangerous if left unattended.

In the last couple of years, we've performed maintenance of 20+ apps with severely outdated dependencies, and it's safe to say we've learnt a few lessons along the 500 hours we put into it.

Join the talk to learn:

* the fresh approach to updating dependencies that will help you stay ahead of the curve
* what does one team have to do in order to keep a healthy app ecosystem
* and how to pitch this investment to the clients.

EuRuKo 2024

00:00:10.960 okay everybody uh I guess we are ready it's 3:20 and 12 13 14 15 seconds uh if
00:00:20.560 anyone hears me back there we are starting please get around get
00:00:26.240 around um so yeah welcome everybody uh my name is Marco chilin kovic uh I'm a
00:00:33.559 software engineer at infinum for the past 10 years actually eight years sorry
00:00:39.520 but um I've been working with Ruby for uh 10 years so this is actually my in
00:00:45.800 August I think it was my anniversary
00:00:51.079 yay uh yeah Ruby is awesome uh yeah and uh I just wanted to
00:00:57.160 say that I'm really not a superhero when it comes to uh these kinds of public
00:01:03.120 speakings and everything definitely not on this scale like other people before
00:01:08.200 me were and uh yeah if you can feel it by my voice a little bit of uh tra is
00:01:15.200 here uh so basically I talk I've been talking you will indul indulge me for at
00:01:20.240 least a minute now to talk through it because I think really it's a it's a really cool uh presentation and I want
00:01:26.680 to get the voice back in control so so I've been talking to a lot of people
00:01:31.880 about this and uh they told me that the best way to actually get rid of any kind
00:01:37.880 of anxiety stress on and public speaking is actually to Simply impress your
00:01:45.360 audience so how do I impress my audience when there are developers that been in
00:01:50.520 this game for 20 30 years well uh I'm going to do a
00:01:56.920 backflip so we can actually you can make like
00:02:11.599 this I'm not going to do a backflip I don't know that
00:02:19.200 but what I do know is how to keep your dependencies up to date actually not
00:02:24.680 dependencies but many projects that use dependencies so let's get started thank you for end
00:02:30.920 me uh why did I call this actually a maze uh it's basically because when you
00:02:37.920 are using a lot of projects that have many many dependencies it kind of feels
00:02:42.959 like you're in a maze because uh you cannot really update Everything at Once
00:02:48.440 uh you need to be doing it uh more in a in a more structured way and sometimes
00:02:53.720 that's not really possible so basically we came up with a process of how to to
00:02:59.959 actually do that um we had a talk today uh like I think it was the after the
00:03:05.760 lunch break the first talk in the main track someone just said uh use the pandabot and while that is true our talk
00:03:12.720 is going to be uh delving a little bit more deeper into how to actually organize the process if you're inside of
00:03:20.360 a working for a company that has dozens 20 30 40 I don't know how many projects
00:03:26.920 and you have to keep all of them up to date for all for all the various reasons
00:03:32.879 so this is going to be our agenda um as you can see there is uh everything is
00:03:39.400 about the problem actually because this problem won't go away there is no solution for it that you just apply and
00:03:46.760 that's it it doesn't exist uh so let's start with revealing the
00:03:52.480 problem uh we live in the Golden Age of software development I think we all can agree on that and mostly so reusability
00:04:01.120 and I believe that there are a couple of you here that are actually Gem maintainers and owners and they are
00:04:08.000 contributing to the open source and don't fret I'm not here to tell uh all of the people here to not use gems and
00:04:14.599 that's it definitely use gems because they are practical they are convenient they are uh time-saving and they are
00:04:21.759 maintained by our beautiful community and which I really really really like because the community basically uh
00:04:30.000 follows a lot a lot of rules a lot of Standards the semantic version is is on par uh in in the 10 years I've been
00:04:37.000 working with no rule has been broken except for that one I think it was image
00:04:42.560 magic was yanked or something like that and it created a whole mess in the Ruby Community uh but yeah basically uh don't
00:04:49.240 reinvent the wheel so continue continue doing that what you're doing um we are
00:04:54.680 uh we usually when we do something especially with the big big big player
00:04:59.919 there like rails device um admin dashboard stuff psychi all of those you
00:05:05.600 definitely should be using you just add a single line of code you do some configuration changes you bundle install
00:05:12.120 everything and you get the code uh from people that have been in the game much
00:05:17.400 longer potentially and uh the other people actually found edge cases that they've solved everything is covered by
00:05:24.120 tests you save a lot of time with that so continue doing that please uh we also
00:05:29.479 have uh oh yeah who does Reddit here raise your hands not that many okay
00:05:37.039 uh there's a subreddit called the data is beautiful I love it uh and if anyone likes data uh the next couple of slides
00:05:43.520 are going to be amazing for you so uh I took a lot of uh information from Ruby
00:05:49.720 jems um if someone is historical and knows that Ruby jems came out in 2004
00:05:55.319 they actually have their public database from 2009 and and this graph shows how many
00:06:01.639 gems in total there are through the year so as you can see there's around
00:06:07.720 180,000 something like that gems and all of those are uh public so they you can
00:06:13.520 actually install them there's even more of them but you have to be careful because they were pulled down or yanked
00:06:19.759 or they they don't exist actually anymore so uh when you take a look at this data all of these gems are actually
00:06:26.039 here the count is exact uh uh when you then take a look at the spread over the
00:06:33.199 years as they were going uh as they were being released you can see that 2014 was the year that the most gems got released
00:06:41.919 and I came into the game here at that year um so yeah there's quite a lot of
00:06:48.639 them and that's good because our community is big and we are thinking
00:06:53.960 outside the box and we want to enable a lot of people to uh easily fix stuff
00:07:00.280 and that what that's what makes Ruby Ruby I think because uh one of the best
00:07:06.199 things about it is that you can basically slap a couple of gems there install them and you got a production um
00:07:14.440 production application in matter of days but the first problem that occurs
00:07:20.319 with uh using gems is the fact that when you install a gem a dependency it
00:07:27.440 doesn't just mean that you have one dependency as you all know a dependency usually has more dependencies and
00:07:33.599 sometimes those dependencies have their own dependencies so uh here is a little bit of data I just ran a rails do rails
00:07:41.199 new DOT and U there is like 15 hello uh so there's like 15 gems inside
00:07:48.440 of the gem file at the time of uh installation but in actuality there's 80
00:07:53.639 when you do a little bit of a more like an application like a month old a year old something like that you usually end
00:07:59.120 up in the area of 40 to 880 and in that actuality it goes around 180 to 220 uh
00:08:06.720 gems uh to Total gems in your gem file lock unique ones of course if you have a bigger app that has 100 and more gems of
00:08:14.800 course it doesn't go uh it's not that big of a jump but it does go uh up all the way to
00:08:20.360 300 um basically you need to to look at dependency as having some kind of weight
00:08:26.759 so if you find a g that does really little things sometimes you need to just
00:08:33.279 weigh the pros and cons if if it does have a lot of dependencies you can maybe not install it but actually Implement
00:08:39.800 your own uh thing inside of your own code base um it's basically like
00:08:45.160 organizing a trip if you imagine going by yourself wherever you want to go it's
00:08:50.760 just you it's very easy to organize uh you have your own requirements needs wants it's easy when you think about 10
00:08:58.720 people organ organizing it or actually you organize it for 10 people it's no uh
00:09:04.720 100 200 count me out uh yeah and dependencies uh
00:09:11.600 something that maybe some yeah probably a lot of you know uh but dependencies
00:09:17.399 evolve as our code bases do and the fact is at least as I've seen it because we
00:09:23.320 in in Phenom uh we get a lot of Legacy projects and a lot of these Legacy
00:09:28.399 projects come out dated using Ruby 2.7 uh or even lower than that even though
00:09:34.519 2.7 got end of life to four years ago something like that I think it 3.0 is
00:09:40.880 also going to be end of Life currently uh so that's like really really weird um
00:09:46.680 and rails comes at the version four or five something like that and that's just crazy because people are ignoring the
00:09:53.560 dependencies they just install them and they think they are a frozen State everything is good
00:09:59.720 um so yeah we need to think that the open source authors spend a considerable time time maintaining these gems uh in
00:10:07.640 their life cycle and they introduce new features bug fixes uh optimizations to
00:10:13.200 the performance and a lot of other things and uh we should be thinking about that when we are actually
00:10:19.240 developing and grooming our application or inside of our project and this can be
00:10:25.600 seen in this graph um our initiative that I'll be talking talking in a couple of minutes uh when I actually explained
00:10:32.640 the problem is using uh a process that we created and we only spend around
00:10:38.560 eight hours um per month and you can see that with each passing month which is
00:10:45.000 really kind of wow I would say you get the number of total dependencies around
00:10:51.920 60 70 and for each month they go back up so everybody is working like like
00:10:59.480 everybody's working that's really cool so um if you if you've been if you've been around in like 2019 2020 it was
00:11:07.079 really popular to find those blog posts at the end of the year beginning of the year is Ruby dead I think this gives you
00:11:13.680 a pretty clear answer Ruby is not dying Ruby is not going anywhere it's staying strong and it's still
00:11:21.000 beautiful um yeah then I will show you
00:11:26.040 something that we are not really proud of but you know everybody has their own shame. CSS and other files where you
00:11:32.760 keep all of your uh crappy code um just a couple of uh Marks here this is kind
00:11:39.720 of a dynamic I would say uh graph because it doesn't just go linear with
00:11:45.399 the time um yeah I added these just play buttons and for forward buttons so from
00:11:51.920 2014 to 201 and yeah the first 6 months of 2014 it was going normally um 20 14
00:11:59.720 in April we started this project we didn't update it and it was slowly
00:12:05.240 increasing and then you can get to the right part where things go a little bit
00:12:10.800 faster just because we don't have a big screen to actually show all of this and um remark these two the these three
00:12:19.000 actually bumps these bumps are the forward
00:12:24.199 downwards bumps so uh what we what happened here is that uh a feature came
00:12:30.120 that there was actually a different scenarios the first one was a feature came we wanted to use a new gem that gem
00:12:37.160 had a transient dependency that also had this a matching transient dependency from an existing Gem and we couldn't
00:12:44.360 install it because of the uh incompatibility issue so the only thing that we could move forward is actually
00:12:49.560 bump the gems and we were like at that point I mean I didn't I wasn't in infinum in that that part but uh I saw
00:12:56.120 that they updated the gem so that they actually can move forward uh the second uh I can't remember it
00:13:01.760 doesn't really matter but the third one was because image magic was yanked and
00:13:06.800 we had to actually uh bump that uh gem um so yeah this was actually uh the
00:13:12.560 situation which shows us that we updated the dependency the green line is uh a
00:13:18.760 little bit of a more uh of a of a spike toward down um like a drop uh because we
00:13:25.959 started actually with the initiative but since it's a project that hasn't been updated for 8 years uh it's really
00:13:33.079 difficult to update it but it's also difficult to update it because of the the own business logic and mostly
00:13:38.760 infrastructure uh which is out of the scope for this uh for this presentation uh and yeah this is just to
00:13:46.399 put everything into perspective uh the the the blue graph that you see is from the previous graph which is now an
00:13:53.240 updated project as we call it so some of you might be wondering why do we need to
00:13:58.320 care about the of dependencies if we have a project from 2014 that's working
00:14:03.440 right um so let's take a look at more graphs um this is a bit more dat more of
00:14:10.000 a data Rich um graph which shows uh all of the dependencies that we've been
00:14:16.680 working in 2001 uh at the point when we started actually
00:14:23.560 updating everything uh you can see that we have two outliers here those are really uh big applications that I think
00:14:31.440 also no one one was internal and another one was built from scratch in 2005 or
00:14:38.279 something like that so it's been quite around um and we didn't never basically
00:14:44.199 updated it and all of the other ones are around two the 200 Mark um but mostly
00:14:51.079 you should also uh focus on these ones because we found out that when you keep
00:14:56.240 your dependency count the total dependency count up outdated ones uh around 70 to to 120
00:15:03.360 130 um a lot of years can pass and we can um think of that project as being up
00:15:10.680 toate because it's really easy to set up on new machines uh it's really easy to keep it updated to um bump major
00:15:17.120 versions and stuff like that and this is the in the same graph
00:15:23.560 actually but a little bit expanded into 2023 you can see that all of these uh outliers around the 200 Mark are now uh
00:15:31.560 down to uh um between that range of 100 to 12 120 with the only outlier being
00:15:39.920 the same project as we've been discussing the that red line uh a couple of graphs before right this one the
00:15:46.079 upper one uh so yeah but I still didn't explain you the real problem right I
00:15:52.480 promised you that I will tell you uh that a project from 24 it still works so
00:15:58.000 why do we need to update uh the dependencies so let's actually
00:16:03.079 understand the problem uh we can actually look at it from two perspectives uh the positive
00:16:08.720 one uh half is GL glass is half full and glass is half empty so what happens when
00:16:15.000 you update dependencies as it says you get you get new stuff you get free improvements um I just pulled out
00:16:22.639 quickly all of the data in reals 5 we got action cable and API applications to keep our uh application ations smaller
00:16:30.079 in size uh then six we got action mailbox parallel testing action text
00:16:35.199 which was beautiful because I remember when I came in 2014 one of the biggest things was and rails was still then very
00:16:42.680 monolit heavy everyone was doing monolit and every application at least in our in
00:16:48.120 my older company we've been building these uh Rich Text editors and nothing
00:16:53.319 was working out of the box everything had some problems and action text came around and it's beautiful same goes with
00:16:59.800 multi-b support for performance reasons and R 7 I'm not going to even start reading it uh R 7 came with a lot of lot
00:17:06.640 of cool features and looking at from the other perspective uh what happens when you
00:17:13.240 don't update your dependencies well nothing at the first start like the first I
00:17:21.120 think I think a week I give you a week or two week stops nothing will happen
00:17:26.679 everyone is happy um the project kick off um the the client is uh very happy
00:17:34.600 with the speed of development with how quickly we came to production the first issue is then after
00:17:40.559 a week or two or three uh the first cve and also the opportunity for your pent
00:17:46.320 testers to actually try to catch it uh I really hope to actually find a pent tester that really knows their CVS and
00:17:52.880 doesn't just go into a dashboard enter some JavaScript with alerts and then refreshes the page and oh you have a
00:18:00.919 issue um so yeah not fixing cves or as they are known common vulnerability and
00:18:06.679 exposure uh involves quite a lot of risks like remote code execution data
00:18:12.080 leaks um SQL injection and cross- site scripting and basically just any user
00:18:18.760 data not being uh properly handled and uh in case some of these
00:18:23.880 things happen and you don't address them uh if you're not doing an application
00:18:29.960 just for yourself if you're doing it for a client um it depends of course on all of the legal protections that you've
00:18:37.640 placed in your contract with your client but what can happen is you could be charged with a breach of contract in
00:18:43.919 case an attacker actually tries to expose the data or do anything with
00:18:50.000 that data they can also terminate the relationship you're working with uh there can be fines um and and just in
00:18:57.120 general reputational damage so fix your CVS people um I hope you
00:19:03.360 know about bundler audit and checking it then I don't know uh a month two
00:19:09.480 months three months in in in the future things will happen as we've seen in that graph with those three uh circles uh you
00:19:16.480 can have a new feature request or anything that you need requires a new gem geming compatibilities can can
00:19:22.760 happen and you will spend not too much time but maybe sometimes more time than necessary to actually get your
00:19:29.520 dependencies up to date to support that feature uh
00:19:35.080 after three to four years something like that uh in my experience at least new
00:19:41.039 machines are coming that doesn't mean just new machines but actually also uh new developers joining the company you
00:19:47.159 gaining a new laptop which has all of these new uh Native extensions uh and
00:19:52.679 the compiler cannot actually install stuff and uh you end up with having to
00:19:57.960 update your dependencies and the last thing that can happen is uh your the OS
00:20:04.600 end of lifing uh unless you have your own server in in your own room and maintaining it if you're using ABS kok
00:20:11.159 or something like that uh a point will come where the OS version you install the system on uh is going to get
00:20:18.039 deprecated they will shut it down or whatever and they will tell you send you an email hey please update your system
00:20:23.559 and at that point you will have to call your client and tell him yeah you know uh we will have have to feature freeze
00:20:29.960 now this will uh last like two three weeks we have to get this up to date and
00:20:36.000 uh then things are kind of sketchy um not sketchy but tricky uh so yeah how much is the price
00:20:43.120 of ignorance and neglect depends depends on the project of course but two examples I took out is
00:20:50.440 um infinum and GitHub uh for one of our lications that we updated from rails 5
00:20:55.799 to rails 7 it took us around 500 hours that's everything like backend front end
00:21:00.919 changes because the APA was changing QA stuff like that uh and for github's example which you can find definitely uh
00:21:08.000 it took them from rails three to five uh one and a half years uh so hopefully this answers why
00:21:15.919 you should up be updating your dependencies on a regular scale uh cycle but what happens if you have many many
00:21:23.320 many projects and how how do you actually create a
00:21:29.080 process around this to keep your team wanting to do that and to keeping them
00:21:35.440 um motivated for that by the way if anyone recognizes this game um I salute
00:21:41.400 you uh we are now 30 to 4045 something like
00:21:46.440 that um so yeah we at this point we actually uh when we started this
00:21:52.480 initiative we definitely said we need to change our dependency upgrade culture and the processes and this is what what
00:21:59.520 uh came out of it circumventing the problem because there is no solution as I said uh there is just how to ease up
00:22:07.360 all the work that you have to do because it's a it's an ongoing
00:22:13.120 battle uh we uh separated it into chunks so that so we are going to go through
00:22:19.120 them uh quickly because I have 10 more minutes Jesus uh prerequisites please
00:22:24.880 keep your code uh the code coverage High uh you know simple cob uh keep it at
00:22:30.600 around 90 95% if it's possible if not as high as you go it's better uh so that
00:22:36.919 your tests break when you are actually updating the dependencies remove any private API usages I know it's cool I
00:22:44.000 know it's uh fun to actually dive into the gems and try to hack them P monkey
00:22:50.080 patge them if they're not uh if they're private or if they're not even doc if they're not documented so maybe if you
00:22:56.559 find something that's public Maybe they forgot to encapsulate it um remove all
00:23:02.000 of the undocumented API usages basically and of course uh Implement a disaster
00:23:07.200 recovery plan if things go right you can quickly switch back and uh do it at a
00:23:12.640 time when the client approves it so now that everything is in place uh first
00:23:19.320 category first uh topic is mandated upgrades that you need to do that's the most significant change that we uh
00:23:25.679 introduced small frequ but fre by- siiz chunks for upgrading all of the projects
00:23:31.880 uh it proved the best uh it just takes a little bit of inventiveness to be able
00:23:37.039 to get it to production faster and in a safe manner uh upgrade early upgrade often
00:23:42.960 keep it small uh dependency triage uh not every
00:23:49.000 dependency is the same uh so pre prioritize your upgrades there you have security updates rails upgrades Ruby
00:23:55.559 upgrades keep them in that order I would say sayfe security for we already went through it rails because it got a lot of
00:24:03.440 uh optimizations and a lot of features Ru be upgrades also the same uh reason
00:24:08.840 and then you have the all all of the other ones uh just to emphasize prioritize
00:24:15.640 your security updates please um then you can also scan the QR
00:24:21.200 codes now a couple of slides we'll be getting here uh so when you want to plan major upgrades please keep them in
00:24:27.679 isolation of this what I've been talking about is also going to be focusing on the patch and minor versions but when it
00:24:33.720 comes to major ones keep them isolated tell your QA what this does try to point them to the page that they need to um
00:24:40.799 test and even better you can do it yourself if the project manager allows it the extra time that's necessary for
00:24:47.600 that to do but when you have rails to actually upgrade for 5 to six six to seven seven um you can actually use our
00:24:55.080 public infinum handbook for rails upgrades it's got really Nifty things that you need to take care of and when
00:25:01.200 you're actually updating the major version of rails uh improve your stakeholder of
00:25:06.480 Wellness when I say St stakeholder clients they are probably paying I'm really I really don't believe that no
00:25:13.320 that some of you are not uh charging them for maintenance so when it comes to maintenance um keep this inside of the
00:25:21.399 maintenance uh we will go through a couple of um tools now to actually get you to a number how much for for a
00:25:28.600 project uh you should allocate uh hours per month or per week depends uh you
00:25:34.200 will uh see in in in a couple of minutes but yeah uh tell them about GitHub uh
00:25:39.840 tell them about the facts that will happen if you don't uh do anything about
00:25:45.559 the dependency if you leave them to R I would say um yeah we also figured that
00:25:52.679 tracking the dependency held so a little bit of gamification came inside here and
00:25:58.000 uh we wanted to know from a scale of zero to 100 some some something smart something cool uh to actually know how
00:26:04.880 much a project has from a zero to 100 and we came with revisor it's an
00:26:11.159 internal app that periodically Aggregates all of the Ruby dependencies from all of the projects inside of our
00:26:16.640 GitHub organization it it has a nice dashboard which you can filter with the projects and you can see the health
00:26:23.279 column uh the first one also gets a star which is very cool people are actually fighting about around it um and uh what
00:26:30.919 else can you do um yeah what it does basically that when we say health score
00:26:36.799 this is the formula that it uses not going to go too deep into it because it will take me another 30 minutes but
00:26:42.520 basically it takes all of the gems in your gem file it looks at how many outdated versions it's got it calculates
00:26:48.799 those it sums them up it also takes into consideration the prior priority of the gem so if it's rails it's high more
00:26:55.159 important if it's device it's more important there's a logic around it and then it adds up all of those divides
00:27:00.360 something some things happen and we get a number uh we also added uh select
00:27:08.120 notifications that we integrated with our project channels where our clients reside actually and a really cool thing
00:27:15.480 happened uh where we have clients that are kind of competing clients and they
00:27:20.960 know about each other uh that they are actually hired in infinum and uh
00:27:26.159 something happened uh they started actually asking how is that other company doing so they kind of got into
00:27:33.000 competitions this is the slack notification for a project that doesn't have CVS this is the one that has a
00:27:38.520 couple of them or one and this is one where you really uh have a lot of
00:27:44.320 them uh okay and after a while for auro we had an idea to actually extract this
00:27:51.919 calculating logic into a gem called polariscope you can scan this code here uh the only FYI is you need to use Ruby
00:27:59.480 3 uh actually install it using Ruby 3 you can go into a project and uh run
00:28:04.840 polariscope scan after you updated and it will scan your Ruby 2.x project and give you a score uh next feature is
00:28:11.840 actually going to be also to calculate the version of the Ruby because currently it's only gems so technically if you have a rails application using R
00:28:19.279 Ruby 2.7 or it doesn't have to be rails any kind of Ruby application you can have a score of 100
00:28:26.159 maybe um and what you can do if you have La laptops you can uh gem install
00:28:31.440 polariscope go into a into a repository run polariscope scan and at the end you
00:28:36.880 can uh tell me if you got 100 or close to 100 uh we also wanted to track proper
00:28:43.000 progress over time or regress uh to get some empirical data uh and this is what
00:28:49.480 gave us the ability to have a to basically glance how the project needs
00:28:55.000 to be updated how much it needs to be upgraded does it need a hours per month does it need two hours per month does it
00:29:00.720 need an hour a year uh and I have actually a an example of just once per
00:29:06.720 year but it's not a project actually uh for this we have gorama I'm
00:29:12.360 not sure where my Graphics is H doesn't bad it's a it's a graph uh
00:29:17.919 so garama is a public rails application that got released uh recently it's not
00:29:23.519 in production let's call it like that you cannot use it when you go to uh it's not like you need to pull it down and
00:29:30.600 use it actually yourself so give this to a developer if you're a developer um you can clone it there's read me
00:29:37.120 instructions on how to set it up and use it to actually get all of the graphs that you've been seeing uh before we go
00:29:44.480 into the pandabot uh I will just quickly go into the
00:29:50.799 terminal and this is going to be tricky now because because I first have to go out
00:29:57.440 of the application yes then people told me
00:30:03.519 don't code or don't write any code on your especially on your first but to
00:30:09.120 hell with it uh so I have a chart command because I didn't want to
00:30:15.840 remember the date when I started working with uh Wordle Wordle does anyone like
00:30:22.840 verle yes I hope you do because uh I created a ruby appc small Ruby
00:30:28.360 application that basically uh you can play verle with it because in 2022 I played a lot of verle when I was uh uh
00:30:36.600 during covid uh and I didn't want to play it once per day I wanted to play it more so uh you can uh when you set up
00:30:45.240 gorama you can just uh run uh from when you want to have uh the basically the
00:30:53.600 graph and just add the path of the Ruby
00:30:58.639 application that you have while this is running does anyone want to play a
00:31:05.360 little game no should I go
00:31:13.679 out okay we usually start with crane right oh then we have Pi o
00:31:22.760 nothing any cues any help no okay I added a Nifty
00:31:32.240 Helper and I won uh cool uh yeah this is going to
00:31:39.960 finish just now perfect oops Lo S I don't know who that
00:31:45.960 is okay and let's see what Happened Here Local
00:31:53.840 Host projects portal and this is what you get so basically
00:32:01.639 now we can Glimpse what happened so the first uh commit actually when I started
00:32:06.919 the date we had only one outdated dependency and as time goes by you can see there's months there's now there's a
00:32:15.600 year even gone and it's almost one and a half years and I only have 16 out
00:32:22.200 dependencies so what I can do is I can just bundle update everything now and uh
00:32:28.080 everything will be working still
00:32:33.559 sh okay so if I go back here we can go
00:32:39.360 polariscope scan not scan it does not take all of your data
00:32:46.600 and put it somewhere you can check the code it just does math so polariscope
00:32:51.880 can we get I think it's around 50 is good no I don't know 80 is
00:32:59.519 something that you should be aiming below 80 it's kind of
00:33:05.200 bad well that's going to be embarrassing if it breaks now
00:33:16.679 yeah that's because of the internet it always is very slow and very
00:33:25.440 bad okay uh until that run uh I will go back to my uh slides if I can find where
00:33:31.880 they are oh 59.76 it's usually faster I promise you try it at your
00:33:38.200 home uh okay go back to full screen and let's continue
00:33:47.519 so uh as I said major upgrades isolation all of the patch and minor versions you
00:33:53.639 can use the pandabot but how do you use the pandabot it's like the previous guy
00:33:59.320 said just use the pandabot but this is a really Nifty uh tried out on production
00:34:04.440 at least for our apps uh configuration which gives you this uh three monthly
00:34:09.879 PRS that are at automatic it includes explicit and transitive dependencies and the groups are rubocop dependencies
00:34:16.720 development dependencies and all of the non- major production dependencies uh
00:34:21.839 one um really cool hint as how to use that don't go to through all three PRS
00:34:29.639 cherry pick it to staging because conflicts in gem file locks are I would say almost impossible to resolve without
00:34:35.720 issues do it one by one go to production so basically the development and test
00:34:41.000 dependencies should not break production I really hope it never broke for our apps uh we really go quickly to staging
00:34:48.079 we deploy it we open up couple of apps smoke test it everything is working then what we do is go merge it to production
00:34:54.960 and then you go to the next PR you tell the pend through the comment at the panda reopen it will just close the pr
00:35:02.119 and open a new one with with the resolve conflicts you do the same thing and then you go to the third one that's it it
00:35:07.680 takes less than eight hours and the the rest is revenue um the other cool thing about
00:35:15.160 this is that all gem change logs are in one place so if you visit all of these PRS uh you will have the change logs for
00:35:22.359 every Gem and you can go through it if you see there is any breaking changes but of course if you have cic with G
00:35:28.680 GitHub actions or whatever you will see that if your specs are passing you're quite quite certain I would say quite
00:35:35.119 certain that you can actually go forward with it at least to staging that's it sorry about the three
00:35:40.599 minutes organizers sorry about everyone taking from the coffee break uh check out the following links um email us at
00:35:47.400 team. rails infinum decom uh we are looking for cool and uh smart as you all
00:35:55.079 all our developers Engineers to work with us and uh yeah email us if you find
00:36:01.160 anything cool or not thank you um we don't have time for QA so thank you
Explore all talks recorded at EuRuKo 2024
+39