Droši mainiet esošu sistēmu

Atrodiet līgumus ap izmaiņu

Esošai programmatūrai ir izsaucēji, glabāti dati, plānoti uzdevumi un ekspluatācijas procedūras. Dažas atkarības nav redzamas failā, kuru vēlaties rediģēt. Aģents var radīt lokāli pareizu izmaiņu, kas pārkāpj kādu no šiem līgumiem.

Pirms īstenošanas nosakiet ietekmēto datu lasītājus un rakstītājus. Pārbaudiet maršrutus, fona uzdevumus, pārskatus un ārējās integrācijas. Pārbaudiet, vai citas komandas vai vecākas klientprogrammu versijas ir atkarīgas no pašreizējās darbības.

Lūdziet aģentam parādīt šīs kartes pierādījumus. Meklēšanas rezultāts ir noderīgs sākuma punkts, bet dinamisko izsaukumu un ārējo datu patērētāju atkarības var būt jāapstiprina atbildīgajam.

Padariet pašreizējo darbību novērojamu

Slikti dokumentētam modulim pievienojiet mērķtiecīgas pārbaudes darbībai, kurai jāpaliek stabilai. Šīs pārbaudes apraksta pašreizējo līgumu. Tās nepierāda, ka katra esošā darbība ir vēlama.

Ja pašreizējā darbība ir pretrunā prasībai, reģistrējiet pretrunu. Nesaglabājiet drošības defektu tikai tāpēc, ka tests to ir fiksējis. Saņemiet lēmumu, kas vajadzīgs paredzētās darbības atšķiršanai no defekta.

Izmantojiet reālistiskus, nesensitīvus testa datus. Iekļaujiet vecas datu struktūras un nepilnīgus ierakstus, kur tie var rasties. Jauna shēma, kas testēta tikai ar jaunradītiem datiem, var slēpt migrācijas problēmas.

Pārskatiet pāreju starp versijām

Aplūkojiet izdomātu pārdēvēšanu no customer_name uz display_name. Tūlītēja pārdēvēšana var salauzt vecas lietotnes instances darbību izvietošanas laikā. Abu failu atjaunināšana vienā pull request nepadara izvietošanu atomāru.

Pakāpeniska pieeja var saglabāt saderību:

1. Pievienojiet jauno lauku, nenoņemot veco.
2. Nosakiet, kā jaunās rakstīšanas darbības saglabā vajadzīgo vērtību saskaņotību.
3. Aizpildiet esošo ierakstu jauno lauku ar procesu, ko var palaist no jauna.
4. Pārbaudiet pilnīgumu un lasošo komponentu darbību.
5. Pārvietojiet lasošos komponentus uz jauno lauku.
6. Noņemiet veco lauku tikai tad, kad to vairs neizmanto neviens komponents.

Precīzā metode ir atkarīga no datubāzes un rakstīšanas paraugiem. Dubulta rakstīšana var radīt neatbilstību, ja viena rakstīšana neizdodas. Var vajadzēt datubāzes transakciju vai citu skaidru sinhronizācijas metodi. Nepiemērojiet šo piemēru, nepārbaudot sistēmas garantijas.

Martin Fowler apraksta šo vispārīgo pāreju kā paralēlu izmaiņu, ko sauc arī par expand-and-contract. Galvenā doma ir saderīga pāreja pirms noņemšanas.

Plānojiet datu atjaunošanu atsevišķi no koda atgriešanas

Koda atgriešana atjauno agrāku lietotnes versiju. Tā automātiski neatceļ datu migrāciju. Vecā versija var nesaprast jaunos datus. Destruktīva migrācija var noņemt informāciju, ko koda atgriešana nevar atjaunot.

Katram solim nosakiet atjaunošanas darbību. Atkārtoti palaižamu datu aizpildīšanu var būt droši atsākt. Nepareizai pārveidošanai var vajadzēt labojumu no saglabātiem sākotnējiem datiem. Destruktīvai darbībai var vajadzēt pārbaudītu atjaunošanas procedūru.

Jautājiet, kurš atbild par atjaunošanas lēmumu un cik ilgi tā var aizņemt. Neuztveriet „mums ir dublējumi“ kā pierādījumu, ka atjaunošana atbilst pakalpojuma prasībai.

Saglabājiet izmaiņu pārskatāmu

Atdaliet nesaistītu sakopšanu no funkcionālās izmaiņas. Pull request sniedziet saderības plānu, pārbaudes rezultātus un noņemšanas nosacījumus. Atzīmējiet punktu, pēc kura atgriešanai iepriekšējā versijā vajag papildu darbu.

Aģents var palīdzēt pārbaudīt datu izmantotājus un sagatavot migrācijas kodu. Atbildīgajam joprojām jāpieņem pārejas un atjaunošanas plāns. Galīgais risinājums ir tikai viena drošas izmaiņas daļa.