rond dezelfde tijd dat Git populair werd, werd de trend voor het schrijven van webapplicaties met behulp van object-relational mapping (ORM) bibliotheken ook bekend. Het belangrijkste idee was dit: aangezien ontwikkelaars wijzigingen in code kunnen aanbrengen die gemakkelijk terug te draaien zijn met Git, waarom kunnen ontwikkelaars niet hetzelfde doen als het gaat om schema wijzigingen? Immers, elke redelijke nieuwe functie omvat code en schema wijzigingen. Zo populaire frameworks zoals Rails en Django toegevoegd ORM en database migratie (ook bekend als schema migratie) als onderdeel van hun aanbod. Maar database migratie als een concept is niet beperkt tot populaire web frameworks. Er zijn zelfs standalone database migratie software bibliotheken zoals Flyway en Liquibase. Kun je je voorstellen dat je granulaire wijzigingen in het schema kunt terugdraaien terwijl je je code schrijft? Te vaak vind ik dat artikelen over databasemigratie niet bespreken wat het betekent om er actief een te doen, als ontwikkelaar. Ik wil dat hier corrigeren. Met dat in gedachten geef ik jullie vandaag een overzicht van wat databasemigratie inhoudt en hoe je dit kunt doen in een actieve ontwikkelomgeving. Ik zal dit opsplitsen in drie secties, die betrekking hebben op wat er gebeurt tijdens het migratieproces, de gemeenschappelijke tools die worden gebruikt, en de valkuilen die kunnen opduiken tijdens databasemigratie. Dit moet een beginnende ontwikkelaar de tools om snel te leren van de belangrijkste ideeën achter data migratie en ook leren potentiële valkuilen te vermijden bij het gebruik van database migratie als onderdeel van zijn of haar ontwikkeling toolbox.
Wat Gebeurt Er Tijdens Databasemigratie?
Nu u weet hoe database migraties tot stand kwamen, laat me u vertellen wat ze eigenlijk inhouden.
korrelige wijzigingen worden gegenereerd als afzonderlijke scriptbestanden
ik noemde hoe databasemigraties in principe korrelige wijzigingen in uw databaseschema bijhouden (en soms ook in uw gegevens). Deze korrelige veranderingen worden meestal gereflecteerd als afzonderlijke scriptbestanden. Op die manier worden uw gedetailleerde schemawijzigingen weergegeven als code die kan worden vastgelegd met elke versiebeheersoftware. Dit is een voorbeeld van een migratiebestand in Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
niet alleen kunt u migraties als zelfstandige bestanden hebben, u kunt ook het huidige databaseschema als eigen bestand hebben. Dit staat meestal bekend als een schemabestand.
databasemigratie Scripts zijn Gereedschapsafhankelijk
haal het databasemigratie script in Ruby uit ons eerdere voorbeeld. Hier is nog een database migratie bestand van de onafhankelijke bron controle voor de database software Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
dit keer is het bestand in XML-formaat. In feite kan Liquibase migratieveranderingen (of wijzigingensets, zoals ze ze graag noemen) produceren in meerdere formaten zoals XML en JSON. Dus tenzij u uw databasemigratie in SQL-formaat wilt handschrijven, zijn er geen echte normen voor de manier waarop de migratiebestanden worden gemaakt. Natuurlijk kunt u uw eigen aangepaste database migratie scripts schrijven in de SQL bestanden. Maar waarom handgeschreven en per ongeluk bugs te introduceren als je gebruik kunt maken van tools om de database migraties automatisch te genereren?
Hoe voert u een databasemigratie uit?
nu weet u wat een databasemigratie is. Je moet ook weten (tenminste conceptueel) hoe je een database migratie uit te voeren. Helaas zijn er helemaal geen standaarden voor databasemigratie bestanden, wat betekent dat we niet te veel in detail kunnen ingaan op hoe ze te maken. Met andere woorden, hoe u een database migratie uit te voeren is sterk afhankelijk van de specifieke tool die u gebruikt voor de taak. In deze sectie zal ik de twee meest voorkomende manieren behandelen om een databasemigratie uit te voeren.
Optie 1: Gebruik een Framework / taalafhankelijke bibliotheek
Als u een populaire taal gebruikt (Ruby, PHP, Python, enz.) of framework (Rails, Django, enz.), dan zijn er goed gedocumenteerde bibliotheken voor data migratie binnen het universum van het kader/taal gekozen. De populaire web frameworks zal natuurlijk komen gebundeld met de database migratie functies. Afhankelijk van de instelling kunt u zelfs de native databasemigratie omwisselen voor andere bibliotheken binnen de gekozen taal. In dit scenario genereert u de migratiebestanden meestal met de opdrachtregel. Soms moet u de aangepaste code handmatig schrijven voor sommige wijzigingen, zoals gegevensmigratie of zelfs hoe u de wijziging zelf kunt omkeren. Anders dan dat, de bibliotheek gekozen binnen het kader/taal vrijwel zorgt voor dit voor u.
Optie 2: Gebruik Onafhankelijke Database-migratie-gerichte Software
in sommige gevallen wilt u software zoals Flyway of Liquibase gebruiken die alleen fungeert als Broncontrole voor uw database. Door dit te doen, vermijd je opgesloten in een bepaald kader of taal. Dit betekent niet dat je nul lock-in hebt. Neem bijvoorbeeld Flyway, die goed werkt met verschillende databases zoals Oracle, MySQL en MariaDB. Als u geen gebruik maken van Flyway ‘ s Java-gebaseerde migratie (die u vergrendelt in Java en Flyway), kunt u uiteindelijk met behulp van SQL-gebaseerde migratie (die u vergrendelt om uw keuze van de database en Flyway). Het goede nieuws is dat Flyway en Liquibase beide relatief eenvoudig te gebruiken zijn. Zij, ook, bieden een command-line manier om de migraties te genereren en laat aangepaste codering om de database schema migraties vast te leggen.
de beste optie voor u kiezen
hier is mijn mening over het kiezen tussen beide opties. Ik heb de neiging om te zien dat de meeste ontwikkelaars kiezen voor Optie 1. Meestal is dat omdat ontwikkelaars al een voorkeurstaal / framework hebben, dus cognitief gesproken, voelt het niet alsof ze (nog) een ander stukje software leren. En de lock-in (in het geval van Optie 1 zou dit het kader en de taal zijn) is geheel vrijwillig en gewenst. U kunt pleiten voor Optie 2 als uw team zich niet volledig heeft gecommitteerd aan een bepaalde taal of framework. Waar u ook voor gaat, vermijd het wijzigen van uw keuze onnodig halverwege de ontwikkeling. Database migratie is niet een gebied waar het veranderen van de tools levert u enorme voordelen. Het grootste deel van de voordelen komen van het simpelweg opzetten van database migratie in de eerste plaats.
de gevaren van databasemigratie en hoe deze te vermijden
in het vorige hoofdstuk heb ik de twee belangrijkste soorten hulpmiddelen voor databasemigratie behandeld: framework/taalafhankelijke en standalone software. Beide types zijn eenvoudig te gebruiken. Nu, Ik zal drie best practices aanbevelen als het gaat om het daadwerkelijk uitvoeren van een database migratie. Deze tips pakken het belangrijkste gevaar van database migratie: u wilt voorkomen dat het maken van onomkeerbare veranderingen.
Kies een Database migratie Tool en houd je eraan
ik heb dit al kort gezegd, maar het is de moeite waard om te benadrukken: Ik wil waarschuwen voor het maken van onnodige wijzigingen aan de toolset gewoon omdat het cool is. Bedenk dat database migratie scripts zijn afhankelijk van de tool die u gebruikt om ze te genereren. Er zijn geen goede normen voor deze scripts. Als je dat echt wilt, kun je zelfs je eigen in SQL statements schrijven. Dat introduceert zijn eigen set van problemen; bijvoorbeeld, uw SQL scripts zijn waarschijnlijk in staat om database afhankelijk. MySQL queries werken mogelijk niet in PostgreSQL, en vice versa. Dus ofwel bent u opgesloten in uw database migratie tool, of u bent vergrendeld in uw keuze van de database—of in sommige gevallen, zelfs beide. Er is geen duidelijke voordelen aan het schakelen van uw toolset vaak, dus mijn suggestie is om een database migratie tool te kiezen en vasthouden aan het. Er zijn betere dingen te doen met je tijd dan je wielen onnodig draaien.
Verwijder rijen of kolommen alleen als u er absoluut zeker van bent dat u
nodig hebt als het gaat om migraties, kunt u ze meestal omkeren wanneer dat nodig is. Typische database migratie tools kunnen omgaan met eenvoudige omkeerbare veranderingen. En zelfs als ze dat niet kunnen, kunt u eenvoudig uw eigen aangepaste code toevoegen om te helpen bij het omkeren. Bijvoorbeeld, in Rails, voeg je gewoon de code toe onder omkeerbaar.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
de moeilijkste veranderingen om te keren hebben meestal betrekking op het verwijderen van materiaal: met name het verwijderen van kolommen of rijen met gegevens. Als uw database veel gegevens bevat, kunt u uiteindelijk een aanzienlijke hoeveelheid aangepaste code moeten schrijven om te proberen uw wijzigingen om te keren. Dus als u overweegt gegevens uit uw database te verwijderen, wees extra voorzichtig. Dat soort wijzigingen zijn moeilijk ongedaan te maken. Andere moeilijk om te keren wijzigingen zijn het hernoemen van kolommen en het wijzigen van het datatype van een kolom die al gegevens bevat. Een vuistregel die ik graag gebruik is deze: je moet bijna nooit Kolommen verwijderen tot de volgende major (je kent semver, toch?) release. Deze regel geldt zelfs als ik kolommen heb die ik niet meer wil gebruiken. In plaats van kolommen te verwijderen, zal ik in de kleine versies aankondigen welke kolommen in de toekomst worden afgekeurd. Als het tijd is voor een grote release, zal ik die columns dan helemaal laten vallen. Op die manier verminder ik de kans op het uitvoeren van een toevallige, ongewenste verandering die een verschrikkelijk proces zal zijn om met de hand te keren.
implementeer Feature Flags
een andere uitstekende strategie voor databasemigratie is het implementeren van feature flags, vooral wanneer u een groot team hebt en meerdere mensen proberen verschillende features voor dezelfde codebase te implementeren. Volgens Martin Fowler, feature vlaggen zijn ” een krachtige techniek, waardoor teams om het gedrag van het systeem te wijzigen zonder de code te veranderen.”Sterker nog, hoe groter je team en hoe complexer je codebase is, hoe meer feature flags schitteren. Functievlaggen helpen risico ‘ s te beperken als het gaat om databasemigratie. Proberen om de veranderingen te ontwarren wanneer u bepaalde functies terug moet draaien, kan een echte nachtmerrie zijn. Functie vlaggen werken net zo goed of u wilt maken kleine of grote database schema wijzigingen. Bij het gebruik van functie vlaggen, Ik adviseer u streven naar meer frequente en korrelige veranderingen in het algemeen. En je kunt echt zien hoe feature flags uw ontwikkelingsproces helpen wanneer u een enorme schemawijziging uitvoert. Gelieve nog steeds streven naar deze enorme schema verandering te breken in kleinere, dunne plakjes. Je hoeft niemand te imponeren met hoeveel je kunt persen in een verandering. Het is beter om beveiligingen toe te voegen aan uw ontwikkeling praktijken door het implementeren van alle drie de aanbevelingen die ik heb gesproken over in deze sectie.
conclusie
ontwikkelaars hebben alle tools nodig die ze kunnen krijgen om hun leven gemakkelijker te maken. Database migratie is een van die must-have tools voor de ontwikkelaar toolbox. In de toekomst, Ik voorzie dat het gebruik van database migraties zal evolueren van een ontwikkeling best practice naar een ontwikkeling standaard praktijk. Mensen zullen naar je kijken grappig voor het niet gebruiken van database migratie helemaal. Toch is het belangrijk om in gedachten te houden hoe database migraties kunnen averechts op u, met name voor moeilijk om te keren schema wijzigingen. Wees absoluut zeker van die veranderingen voordat je ze live laat gaan. Als u nog geen databasemigratie gebruikt in uw proces, waar wacht u nog op? Het is gemakkelijk om te starten, en je kunt het zelfs halverwege je ontwikkelingscyclus toevoegen. Je zult dankbaar zijn dat je dat deed. Want als de dag komt dat je je wijzigingen terug moet draaien en de wijzigingen betreffen de database, zul je wensen dat je iets had om je te helpen dat in enkele seconden te doen. Database migratie is dat iets wat je zou willen dat je had.