Saugiai keiskite esamą sistemą

Nustatykite su pakeitimu susijusius susitarimus

Esama programinė įranga turi ją kviečiančių komponentų, saugomų duomenų, suplanuotų užduočių ir eksploatavimo procedūrų. Kai kurios priklausomybės nematomos faile, kurį norite keisti. Agentas gali pateikti vietoje teisingą pakeitimą, kuris pažeidžia vieną iš šių susitarimų.

Prieš įgyvendinimą nustatykite paveiktus duomenis skaitančius ir rašančius komponentus. Išnagrinėkite maršrutus, fonines užduotis, ataskaitas ir išorines integracijas. Patikrinkite, ar kitos komandos ar senesnės klientų programų versijos priklauso nuo dabartinio veikimo.

Paprašykite agento parodyti šio žemėlapio įrodymus. Paieškos rezultatas yra naudinga pradžia, tačiau dinaminių kreipinių ar duomenis naudojančių išorinių komponentų priklausomybes gali tekti patvirtinti atsakingam asmeniui.

Padarykite dabartinį veikimą stebimą

Prastai dokumentuotam moduliui pridėkite tikslingų patikrinimų aplink veikimą, kuris turi likti stabilus. Šie patikrinimai aprašo dabartinį susitarimą. Jie neįrodo, kad kiekvienas esamas veikimas pageidautinas.

Jei dabartinis veikimas prieštarauja reikalavimui, užfiksuokite prieštaravimą. Neišlaikykite saugumo klaidos vien todėl, kad testas ją užfiksavo. Gaukite sprendimą, leidžiantį atskirti numatytą veikimą nuo klaidos.

Naudokite tikroviškus testinius duomenis be jautrios informacijos. Įtraukite senas duomenų struktūras ir nepilnus įrašus, jei jie galimi. Nauja schema, išbandyta tik su naujai sukurtais duomenimis, gali paslėpti migravimo problemas.

Peržiūrėkite perėjimą tarp versijų

Apsvarstykite išgalvotą pervadinimą iš customer_name į display_name. Tiesioginis pervadinimas diegimo metu gali sugadinti seną programos egzempliorių. Abiejų failų atnaujinimas viename pull request nepadaro diegimo atominio.

Etapinis metodas gali išlaikyti suderinamumą:

1. Pridėkite naują lauką nepašalindami senojo.
2. Apibrėžkite, kaip nauji įrašymai išlaikys reikiamas reikšmes suderintas.
3. Papildykite esamus įrašus procesu, kurį galima paleisti iš naujo.
4. Patikrinkite pilnumą ir skaitančių komponentų veikimą.
5. Perkelkite skaitančius komponentus į naują lauką.
6. Pašalinkite seną lauką tik tada, kai jo niekas nebenaudoja.

Tikslus metodas priklauso nuo duomenų bazės ir rašymo būdų. Dvigubas rašymas gali sukelti nesuderinamumą, jei vienas įrašymas nepavyksta. Gali reikėti duomenų bazės transakcijos ar kito aiškaus sinchronizavimo būdo. Netaikykite šio pavyzdžio nepatikrinę sistemos garantijų.

Martin Fowler tokį bendrą perėjimą aprašo kaip lygiagretų pakeitimą, dar vadinamą expand-and-contract. Esmė yra suderinamas perėjimas prieš pašalinimą.

Atkūrimą planuokite atskirai nuo grįžimo į ankstesnę versiją

Kodo grąžinimas atkuria ankstesnę programos versiją. Jis automatiškai neatšaukia duomenų migracijos. Sena versija gali nesuprasti naujų duomenų. Naikinanti migracija gali pašalinti informaciją, kurios kodo grąžinimas neatkurs.

Kiekvienam žingsniui nustatykite atkūrimo veiksmą. Duomenų papildymą, kurį galima paleisti iš naujo, gali būti saugu tęsti. Klaidingai transformacijai gali reikėti pataisos iš išsaugotų pradinių duomenų. Naikinančiai operacijai gali reikėti patikrintos atkūrimo procedūros.

Paklauskite, kas atsako už atkūrimo sprendimą ir kiek jis gali trukti. Nelaikykite teiginio „turime atsargines kopijas“ įrodymu, kad atkūrimas atitinka paslaugos reikalavimą.

Išlaikykite pakeitimą tinkamą peržiūrai

Nesusijusį tvarkymą atskirkite nuo funkcinio pakeitimo. Pull request pateikite suderinamumo planą, patikrinimo rezultatus ir pašalinimo sąlygas. Pažymėkite momentą, po kurio grįžimui į ankstesnę versiją reikia papildomo darbo.

Agentas gali padėti ištirti naudojančius komponentus ir parengti migravimo kodą. Atsakingas asmuo vis tiek turi priimti perėjimo ir atkūrimo planą. Galutinis sprendimas yra tik viena saugaus pakeitimo dalis.