Een algemene gids voor het upgraden van Ruby in je Rails-toepassingen

Het is midden december, wat betekent dat er over slechts een paar dagen een nieuwe versie van Ruby wordt uitgebracht. Zelfs als je niet van plan bent om je Rails-toepassingen op dag één te upgraden naar de nieuwste versie, is het nooit een slecht moment om te beginnen met het plannen van je volgende upgrade.

Waarom Ruby upgraden?

Elk jaar introduceert het Ruby-core team nieuwe functies om de taal vooruit te duwen. Soms zijn dit nieuwe programmeer constructies om uw leven als ontwikkelaar makkelijker te maken. Andere keren resulteren deze veranderingen in prestatieverbeteringen en algehele betrouwbaarheid. Is het niet geweldig wanneer een beetje upgraden je Rails-app sneller maakt, of wanneer een nieuwe functie in de taal een voorheen complexe aanpak vereenvoudigt tot een regel of twee code?

Ruby-releases gedurende het jaar bieden ook belangrijke beveiligingsupgrades voor de taal, die doorsijpelen naar je applicaties en de mensen die ze gebruiken. Ervoor zorgen dat alle lagen van uw applicatie veilig zijn, is net zo belangrijk als het vermijden van SQL-injectie en cross-site scripting kwetsbaarheden. Het bijhouden van ondersteunde Ruby versies is de sleutel.

En soms, wordt u gedwongen door een afhankelijkheid, of een afhankelijkheid van die afhankelijkheid. Misschien heb je het wel eens meegemaakt: je wilt een bibliotheek van een derde partij in je app integreren, maar dat kan niet omdat het een nieuwere Ruby vereist dan die je op dit moment gebruikt. Besteedt u tijd aan het forken en back-porten van de bibliotheek om uw oudere code base te ondersteunen, of upgrade u uw code base om gebruik te maken van het huidige Ruby ecosysteem?

Wanneer Ruby upgraden

Nieuwe grote versies (bijvoorbeeld, 2.2, 2.3, en 2.4) worden traditioneel elk jaar op 25 december vrijgegeven. Kijkend naar de laatste paar grote Ruby releases, kunt u beveiligingsondersteuning verwachten voor een bepaalde Ruby tot ongeveer drie jaar na de eerste release.

Zelfs bij conservatieve projecten, vind ik het prettig om ongeveer een jaar na de eerste release naar een bepaalde versie van Ruby te upgraden. Dat geeft tijd voor bug fixes van die release, maar ook voor gem auteurs om de nodige updates te maken die nodig zijn om een nieuwere Ruby te ondersteunen.

Wanneer Ruby niet upgraden

Een woord van advies: Upgrade Ruby-versies niet op hetzelfde moment als een Rails-versie-upgrade! Zelfs als de versie van Rails die je wilt upgraden een bepaalde Ruby-versie vereist, upgrade en release je Ruby-versie eerst en pak dan de Rails-upgrade aan. Je bent geneigd om je algehele upgrade veel moeilijker te maken als je probeert om het allemaal in een keer te doen, in plaats van in stappen.

Ik heb redelijk geluk gehad met het upgraden van meerdere versies in een keer – bijvoorbeeld van Ruby 2.1 naar Ruby 2.4, maar andere pogingen om dit te doen hebben me problemen opgeleverd, zoals van Ruby 1.8 naar 2.0 gaan. Wanneer u twijfelt, breek de upgrade dan op in kleinere stukken. Ik vind incrementele upgrades bijna altijd soepeler verlopen dan grootschalige benaderingen.

Get ready

Voordat je een upgrade doet, is het een goed idee om je in te lezen over wat er nieuw is-features, fixes, deprecations, en dingen die gewoon helemaal niet meer zullen werken. preview versies van Rubies komen maanden van te voren uit, en veel bloggers nemen de tijd om te onderzoeken wat er nieuw is – dus zoek op what’s new in ruby x.y om een idee te krijgen van wat uw collega Rubyisten vinden. De nieuws feed op de officiële Ruby website plaatst ook aankondigingen van elke release, samen met wat er nieuw in is.

En, zoals bij elke upgrade, wilt u een zo grondig mogelijke test suite voor uw applicatie-zelfs als uw eigen applicatie code niet veel veranderingen nodig heeft om aan de nieuwe Ruby te voldoen, kunnen uw afhankelijkheden diepere veranderingen hebben ondergaan. Of misschien hebben ze problemen met de nieuwe Ruby versie. Neem de tijd om uw testsituatie te herzien. Gebruik SimpleCov om gebieden te identificeren die weinig dekking hebben. Probeer de gaten op te vullen, of op zijn minst handmatig die gebieden een beetje meer dan normaal te testen. (En als je hulp nodig hebt om met testen te beginnen, ik weet een vrij goed boek over het onderwerp, wink wink.)

Hoe Ruby te upgraden

Om te beginnen, installeer de doel Ruby op je ontwikkel setup, met behulp van de Ruby versie manager van je keuze (of via een Docker image, als dat je ding is). Zie de instructies voor RVM, rbenv, en chruby voor details.

Nu is een goed moment om ook de nieuwe Ruby versie te specificeren in uw .ruby-version bestand, en/of in uw Gemfile (voorkeur van Heroku). Hoe dan ook, je zal waarschijnlijk een oude waarde vervangen door een nieuwe. Controleer de wijziging door de directory opnieuw te laden:

$ cd .$ ruby -vruby 2.4.2p198 (2017-09-14 revision 59899) 

Naar aanleiding hiervan installeer je Rails en de andere afhankelijkheden van je applicatie in de nieuwe Ruby-omgeving:

$ bundle install

Dit is waar het lastig kan worden, vooral als je gem-versies gebruikt die de nieuwe Ruby niet ondersteunen. Ik heb dit op twee verschillende manieren benaderd bij upgrade projecten. In sommige gevallen heb ik individuele gems geupdate tot alle afhankelijkheden kunnen installeren. Met nieuwere versies van Bundler werkte de conservatieve updatemodus, die voorkomt dat gedeelde afhankelijkheden ook worden geüpdatet, goed voor mij.

$ bundle update --conservative

In sommige gevallen kan het nodig zijn om de conservatieve modus te gebruiken en vervolgens individuele gems te upgraden om andere wijzigingen aan te pakken. Bijvoorbeeld, bij het upgraden van een app naar Ruby 2.4 eerder dit jaar, moest ik de simple_form gem apart upgraden om een deprecation aan te pakken.

Met alles geïnstalleerd, ben je klaar om je testsuite te draaien! Zorg er eerst voor dat hij opstart, en let dan op fouten en deprecatie waarschuwingen. Als u zich heeft ingelezen over de nieuwe Ruby waarnaar u gaat upgraden, dan zouden de fouten en waarschuwingen u bekend voor moeten komen, en hopelijk heeft u dan een duidelijk pad om ze aan te pakken. Negeer de deprecatie waarschuwingen niet! De waarschuwingen van vandaag zijn de mislukkingen van morgen. Neem de tijd om nu op te ruimen, terwijl je midden in een Ruby upgrade zit.

Met een goede testsuite, vrij van deprecation waarschuwingen, wil ik de app lokaal draaien, en de Rails console opstarten, en controleren op andere deprecation waarschuwingen in het development log. Dit is vooral belangrijk als SimpleCov gaten heeft gevonden in je test dekking. Als je nieuwe waarschuwingen (of fouten) opmerkt die niet in je bestaande tests naar voren kwamen, doe dan je best om nu dekking toe te voegen.

Gefeliciteerd, je applicatie is geupdate naar een nieuwere, ondersteunde Ruby! Uw volgende stappen zullen variëren afhankelijk van hoe en waar uw applicatie wordt ingezet in de wereld. Platform-as-a-service providers zoals Heroku en container-gebaseerde implementaties maken dit relatief eenvoudig Als je je eigen servers hebt, heb je waarschijnlijk iets meer werk te doen, zoals Ruby, Rails, en andere afhankelijkheden op de servers in kwestie geïnstalleerd krijgen. Dat valt buiten het bestek van dit artikel.

Als dat eenmaal is gebeurd, kun je echter wat rustiger slapen, wetende dat je Rails applicatie gebruik maakt van een moderne Ruby. Bedankt voor het lezen!