Muuda olemasolevat süsteemi ohutult

Tuvasta muudatust ümbritsevad liidesekokkulepped

Olemasoleval tarkvaral on väljakutsujad, salvestatud andmed, ajastatud tööd ja käitusprotseduurid. Mõned sõltuvused pole muudetavas failis nähtavad. Agent võib teha kohalikult õige muudatuse, mis rikub üht neist kokkulepetest.

Enne teostust tuvasta mõjutatud andmete lugejad ja kirjutajad. Uuri marsruute, taustatöid, aruandeid ja väliseid integratsioone. Kontrolli, kas teised meeskonnad või vanemad kliendiversioonid sõltuvad praegusest käitumisest.

Palu agendil näidata selle kaardi tõendeid. Otsingutulemus on kasulik lähtekoht, kuid dünaamilised kutsed ja välised kasutavad süsteemid võivad vajada sõltuvuse kinnitamist vastutajalt.

Muuda praegune käitumine vaadeldavaks

Halvasti dokumenteeritud mooduli puhul lisa sihipärased kontrollid käitumisele, mis peab jääma stabiilseks. Need kontrollid kirjeldavad praegust kokkulepet. Need ei tõenda, et kogu olemasolev käitumine oleks soovitav.

Kui praegune käitumine on nõudega vastuolus, pane vastuolu kirja. Ära säilita turvaviga ainult seetõttu, et test selle talletas. Hangi otsus, mis eristab kavandatud käitumist veast.

Kasuta realistlikke mittetundlikke testandmeid. Kaasa vanad andmestruktuurid ja puudulikud kirjed seal, kus neid võib esineda. Ainult vastloodud andmetega katsetatud uus skeem võib migratsiooniprobleeme peita.

Vaata üle versioonidevaheline üleminek

Vaata väljamõeldud ümbernimetamist customer_name → display_name. Kohene ümbernimetamine võib juurutuse ajal vana rakenduse eksemplari rikkuda. Mõlema faili uuendamine ühes pull request’is ei muuda juurutust atomaarseks.

Etapiviisiline lähenemine võib säilitada ühilduvuse:

1. Lisa uus väli vana eemaldamata.
2. Määra, kuidas uued kirjutused hoiavad nõutavad väärtused kooskõlas.
3. Täida olemasolevad kirjed jätkatava protsessiga.
4. Kontrolli täielikkust ja lugejate käitumist.
5. Vii lugejad üle uuele väljale.
6. Eemalda vana väli alles siis, kui selle kasutajad on kadunud.

Täpne meetod sõltub andmebaasist ja kirjutusmustritest. Topeltkirjutamine võib tekitada vastuolu, kui üks kirjutus ebaõnnestub. Vajalik võib olla andmebaasitehing või muu selge sünkroonimismeetod. Ära rakenda näidet süsteemi garantiisid kontrollimata.

Martin Fowler kirjeldab seda üldist üleminekut paralleelse muudatusena, mida nimetatakse ka expand-and-contract’iks. Põhiidee on ühilduv üleminek enne eemaldamist.

Kavanda taastamine rollback’ist eraldi

Koodi rollback taastab varasema rakenduse versiooni. See ei võta automaatselt tagasi andmemigratsiooni. Vana versioon ei pruugi uusi andmeid mõista. Hävitav migratsioon võib eemaldada teabe, mida koodi rollback ei saa taastada.

Määra iga sammu taastamistoiming. Jätkatavat tagantjärele täitmist võib olla ohutu jätkata. Vale teisendus võib vajada parandamist säilitatud lähteandmetest. Hävitav toiming võib vajada kontrollitud taastamisprotseduuri.

Küsi, kes vastutab taastamisotsuse eest ja kui kaua taastamine võib võtta. Ära käsitle väidet „meil on varukoopiad“ tõendina, et taastamine täidab teenuse nõude.

Hoia muudatus ülevaadatav

Erista teemaväline korrastamine funktsionaalsest muudatusest. Lisa pull request’i ühilduvusplaan, kontrollitulemused ja eemaldamistingimused. Märgi koht, millest alates rollback vajab lisatööd.

Agent saab aidata kasutavaid süsteeme uurida ja migratsioonikoodi ette valmistada. Vastutav inimene peab endiselt ülemineku- ja taastamisplaani heaks kiitma. Lõplik kavand on ainult üks osa ohutust muudatusest.