Meglévő rendszer biztonságos módosítása
ElvégezveŐrizze meg a meglévő működési szerződéseket a módosítás során. Vegye figyelembe a régi klienseket, az adatokat és a telepítési sorrendet.
Kiadó TaigaHogyan írunk
Ellenőrizze, mit értett megEgy adatbázisoszlopot átnevez, és ugyanabban a kiadásban frissíti az alkalmazást. Mi hibásodhat meg ettől még?Végezze el a gyakorlatot
Amit megtanulhat
- Azonosítani a helyi kódmódosítás által érintett működési szerződéseket.
- Elmagyarázni a bővítésből és kivezetésből álló, szakaszos módosítást.
- Megkülönböztetni a kód visszaállítását az adatok helyreállításától.
Azonosítsa a módosítás körüli működési szerződéseket
A meglévő szoftvert más komponensek hívják meg. Tárolt adatok, ütemezett feladatok és üzemeltetési eljárások tartoznak hozzá. Egyes függőségek nem láthatók a szerkeszteni kívánt fájlban. Az agent készíthet helyileg helyes módosítást, amely közben megsért egy ilyen működési szerződést.
A megvalósítás előtt azonosítsa az érintett adatok olvasóit és íróit. Vizsgálja meg az útvonalakat, a háttérfeladatokat, a riportokat és a külső integrációkat. Ellenőrizze, hogy más csapatok vagy régebbi kliensverziók támaszkodnak-e a jelenlegi működésre.
Kérje meg az agentet, hogy mutassa meg, milyen bizonyítékokra építette a függőségi térképet. Egy keresési találat hasznos kiindulópont. A dinamikus hívások és a külső felhasználó komponensek függőségeit azonban szükség lehet egy felelőssel megerősíttetni.
Tegye megfigyelhetővé a jelenlegi működést
Egy hiányosan dokumentált modulnál készítsen célzott ellenőrzéseket a változatlanul megőrzendő működéshez. Ezek az ellenőrzések a jelenlegi működési szerződést írják le. Nem bizonyítják, hogy minden meglévő viselkedés kívánatos.
Ha a jelenlegi működés ellentmond egy követelménynek, rögzítse az eltérést. Ne őrizzen meg egy biztonsági hibát pusztán azért, mert egy teszt ezt a viselkedést rögzítette. Kérje az elvárt működés és a hiba megkülönböztetéséhez szükséges döntést.
Használjon valószerű, érzékeny adatot nem tartalmazó tesztadatokat. Vegyen fel régi adatszerkezeteket és hiányos rekordokat is, ha ilyenek előfordulhatnak. Ha egy új sémát csak frissen létrehozott adatokkal tesztel, a migrációs problémák rejtve maradhatnak.
Vizsgálja meg a verziók közötti átmenetet
Vegyünk egy fiktív átnevezést: a customer_name mezőből display_name lesz. Az azonnali átnevezés telepítés közben működésképtelenné tehet egy régi alkalmazáspéldányt. Attól, hogy mindkét fájlt ugyanabban a pull requestben módosítja, a telepítés még nem válik atomi műveletté.
A szakaszos megközelítés megőrizheti a kompatibilitást:
- Adja hozzá az új mezőt a régi eltávolítása nélkül.
- Határozza meg, hogyan tartják az új írások összhangban a szükséges értékeket.
- Töltse fel a meglévő rekordok új mezőjét újraindítható folyamattal.
- Ellenőrizze a feltöltés teljességét és az olvasó komponensek működését.
- Állítsa át az olvasó komponenseket az új mezőre.
- Csak akkor távolítsa el a régi mezőt, amikor már semmi nem használja.
A pontos módszer az adatbázistól és az írási mintáktól függ. A kettős írás inkonzisztenciát okozhat, ha az egyik írás meghiúsul. Szükség lehet adatbázis-tranzakcióra vagy más, kifejezetten meghatározott szinkronizálási módszerre. Ne alkalmazza ezt a példát a rendszer garanciáinak ellenőrzése nélkül.
Martin Fowler ezt az általános átmenetet parallel change néven írja le; az expand-and-contract elnevezés is használatos. A lényeg: a kivezetést kompatibilis átmenet előzze meg.
Tervezze meg külön az adatok helyreállítását és a kód visszaállítását
A kód visszaállítása az alkalmazás egy korábbi verzióját állítja helyre. Nem vonja vissza automatikusan az adatmigrációt. A régi verzió nem feltétlenül tudja értelmezni az új adatokat. Egy destruktív migráció olyan információkat törölhet, amelyeket a kód visszaállítása nem tud visszahozni.
Minden lépéshez azonosítsa a helyreállítási műveletet. Az újraindítható adatfeltöltést biztonságos lehet folytatni. Egy hibás átalakítás javításához megőrzött forrásadatokra lehet szükség. Egy destruktív művelet ellenőrzött visszaállítási eljárást igényelhet.
Tisztázza, ki felel a helyreállítási döntésért, és mennyi idő áll rendelkezésre. A „van biztonsági mentésünk” kijelentés nem bizonyítja, hogy a helyreállítás teljesíti a szolgáltatás követelményeit.
Tartsa áttekinthetően ellenőrizhető állapotban a módosítást
Válassza külön a funkcionális módosítástól a hozzá nem kapcsolódó kódtisztítást. A pull requestben adja meg a kompatibilitási tervet, az ellenőrzések eredményeit és a kivezetés feltételeit. Jelölje meg azt a pontot, amely után a visszaállítás további munkát igényel.
Az agent segíthet a használó komponensek felderítésében és a migrációs kód elkészítésében. Az átmenet és a helyreállítás tervét továbbra is az illetékes felelősnek kell elfogadnia. A végleges terv csak egy része a biztonságos módosításnak.
Végezze el a gyakorlatot
Válasszon egy kisebb mező- vagy API-módosítást. Sorolja fel az összes olvasó és író komponenst, a háttérfeladatokat is. Írja le az első, bővítő lépést, az átmenet ellenőrzését és a kivezetés feltételét. Jelölje meg, melyik lépés akadályozhatja meg a visszaállítást.
Munkalap letöltése (Markdown)A kijelölés megszüntetése törli az ebben a böngészőben mentett összes haladást.
A haladás ebben a böngészőben marad. Nincs fiók, nincs követés.