Muuta olemassa olevaa järjestelmää hallitusti

Selvitä muutoksen ympärillä olevat sopimukset

Nykyisellä ohjelmistolla on kutsujia, tallennettua dataa, ajastettuja töitä ja ylläpitokäytäntöjä. Kaikki riippuvuudet eivät näy muokattavassa tiedostossa. Agentti voi tehdä paikallisesti oikean muutoksen, joka rikkoo jonkin näistä sopimuksista.

Tunnista ennen toteutusta muuttuvan datan lukijat ja kirjoittajat. Tarkasta routet, taustatyöt, raportit ja ulkoiset integraatiot. Riippuvatko muut tiimit tai vanhat client-versiot nykyisestä toiminnasta?

Pyydä agentilta näyttöä riippuvuuskartalle. Hakutulos on lähtökohta, mutta dynaamiset kutsut ja ulkoiset käyttäjät voivat vaatia omistajan vahvistuksen.

Tee nykyinen toiminta havaittavaksi

Huonosti dokumentoituun moduuliin voi lisätä rajattuja tarkistuksia toiminnalle, jonka pitää säilyä. Ne kuvaavat nykyistä sopimusta. Ne eivät osoita kaiken nykyisen toiminnan olevan toivottavaa.

Jos nykyinen toiminta on ristiriidassa vaatimuksen kanssa, kirjaa ero. Tietoturvavirhettä ei pidä säilyttää vain siksi, että testi tallensi sen. Hanki päätös, joka erottaa tarkoitetun toiminnan virheestä.

Käytä realistisia mutta ei arkaluonteisia fixtureja. Ota mukaan vanhat datarakenteet ja puutteelliset tietueet silloin, kun niitä voi esiintyä. Pelkästään uudella datalla tarkistettu skeema voi peittää migraatio-ongelman.

Tarkasta versioiden välinen siirtymä

Kuvitellaan sarakkeen customer_name vaihtaminen nimeksi display_name. Suora uudelleennimeäminen voi rikkoa vanhan sovellusinstanssin deploymentin aikana. Kahden tiedoston muutos samassa PR:ssä ei tee julkaisusta atomista.

Vaiheittainen muutos voi säilyttää yhteensopivuuden:

1. Lisää uusi kenttä poistamatta vanhaa.
2. Määrittele, miten uudet kirjoitukset pitävät arvot johdonmukaisina.
3. Täydennä vanhat tietueet jatkettavalla backfill-prosessilla.
4. Tarkista kattavuus ja lukijoiden toiminta.
5. Siirrä lukijat uuteen kenttään.
6. Poista vanha kenttä vasta, kun kukaan ei enää käytä sitä.

Tarkka menetelmä riippuu tietokannasta ja kirjoitustavoista. Dual write voi tuottaa ristiriidan, jos toinen kirjoitus epäonnistuu. Tietokantatransaktio tai muu nimenomainen synkronointi voi olla tarpeen. Älä sovella esimerkkiä tarkistamatta järjestelmän takuita.

Martin Fowler kuvaa yleistä menetelmää nimellä parallel change eli expand-and-contract. Olennaista on yhteensopiva siirtymä ennen poistamista.

Suunnittele palautuminen erikseen

Koodin rollback palauttaa aiemman sovellusversion. Se ei automaattisesti peru datamigraatiota. Vanha versio ei välttämättä ymmärrä uutta dataa. Tuhoava migraatio voi poistaa tietoa, jota koodin palauttaminen ei tuo takaisin.

Nimeä palautumiskeino jokaiselle vaiheelle. Jatkettavan backfillin voi ehkä käynnistää uudelleen. Väärä muunnos voi vaatia korjauksen säilytetystä lähdedatasta. Tuhoava toimi voi tarvita todennetun palautuksen varmuuskopiosta.

Kuka päättää palautuksesta, ja kuinka kauan siihen saa kulua? ”Meillä on varmuuskopiot” ei vielä osoita palvelun palautumisvaatimuksen täyttymistä.

Pidä muutos tarkastettavana

Erota asiaan liittymätön siivous toiminnallisesta muutoksesta. Lisää PR:ään yhteensopivuussuunnitelma, tarkistukset ja poistamisen ehdot. Merkitse vaihe, jonka jälkeen rollback vaatii lisätyötä.

Agentti voi tutkia käyttäjiä ja valmistella migraatiokoodia. Vastuuhenkilö hyväksyy silti siirtymän ja palautumisen suunnitelman. Lopullinen rakenne on vain osa turvallista muutosta.