Rruga 02Mësim 5 / 6

Ndryshoni në mënyrë të sigurt një sistem ekzistues

Ruani kontratat teknike aktuale ndërsa futni një ndryshim. Merrni parasysh klientët e vjetër, të dhënat dhe rendin e vendosjes.

I avancuar11 minShqyrtuar

Publikuar nga Si shkruajmë

Kontrolloni çfarë keni kuptuarRiemërtoni një kolonë të bazës së të dhënave dhe përditësoni aplikacionin në të njëjtin publikim. Çfarë mund të dështojë ende?Bëni ushtrimin
Riemërtoni një kolonë të bazës së të dhënave dhe përditësoni aplikacionin në të njëjtin publikim. Çfarë mund të dështojë ende?

Çfarë do të mësoni

  • Identifikoni kontratat teknike që mund të prekë një ndryshim lokal kodi.
  • Shpjegoni një ndryshim me faza zgjerimi dhe heqjeje.
  • Dalloni rikthimin e kodit nga rikuperimi i të dhënave.

Identifikoni kontratat teknike rreth ndryshimit

Softueri ekzistues ka thirrës, të dhëna të ruajtura, punë të planifikuara dhe procedura operative. Disa varësi nuk duken në skedarin që dëshironi të redaktoni. Një agjent mund të prodhojë një ndryshim lokalisht të saktë që shkel një nga këto kontrata teknike.

Para implementimit, identifikoni komponentët që lexojnë dhe shkruajnë të dhënat e prekura. Shqyrtoni route-et, punët në sfond, raportet dhe integrimet e jashtme. Kontrolloni nëse ekipe të tjera ose versione më të vjetra klientësh varen nga sjellja aktuale.

Kërkojini agjentit të tregojë evidencën për këtë hartë. Një rezultat kërkimi është pikënisje e dobishme, por thirrjet dinamike dhe komponentët e jashtëm që e përdorin sistemin mund të kërkojnë konfirmim të varësisë nga një përgjegjës.

Bëjeni sjelljen aktuale të vëzhgueshme

Për një modul të dokumentuar dobët, shtoni kontrolle të përqendruara rreth sjelljes që duhet të mbetet e qëndrueshme. Këto kontrolle përshkruajnë kontratën teknike aktuale. Nuk vërtetojnë se çdo sjellje ekzistuese është e dëshirueshme.

Nëse sjellja aktuale bie ndesh me një kërkesë, regjistroni konfliktin. Mos ruani një defekt sigurie vetëm sepse një test e ka regjistruar atë sjellje. Merrni vendimin e nevojshëm për të dalluar sjelljen e synuar nga defekti.

Përdorni fixtures realiste dhe pa të dhëna sensitive. Përfshini forma të vjetra të të dhënave dhe rekorde të paplota aty ku mund të shfaqen. Një skemë e re e testuar vetëm me të dhëna të sapokrijuara mund të fshehë probleme migrimi.

Shqyrtoni kalimin mes versioneve

Merrni një riemërtim të sajuar nga customer_name në display_name. Një riemërtim i menjëhershëm mund të prishë një instancë të vjetër të aplikacionit gjatë vendosjes. Përditësimi i të dy skedarëve në një pull request nuk e bën vendosjen atomike.

Një qasje me faza mund ta ruajë përputhshmërinë:

  1. Shtoni fushën e re pa hequr të vjetrën.
  2. Përcaktoni si i mbajnë shkrimet e reja të qëndrueshme vlerat e kërkuara.
  3. Plotësoni rekordet ekzistuese me një proces që mund të rifillojë.
  4. Verifikoni plotësinë dhe sjelljen e komponentëve që lexojnë.
  5. Kalojini komponentët lexues te fusha e re.
  6. Hiqeni fushën e vjetër vetëm pasi të mos ketë më komponentë që e përdorin.

Metoda e saktë varet nga baza e të dhënave dhe modelet e shkrimit. Shkrimet në të dyja fushat mund të sjellin mospërputhje nëse një shkrim dështon. Mund të nevojitet një transaksion i bazës së të dhënave ose një metodë tjetër e qartë sinkronizimi. Mos e zbatoni këtë shembull pa kontrolluar garancitë e sistemit.

Martin Fowler e përshkruan këtë kalim të përgjithshëm si ndryshim paralel, i quajtur edhe expand-and-contract. Ideja kryesore është një kalim i përputhshëm para heqjes.

Planifikoni rikuperimin veçmas nga rikthimi i versionit

Rikthimi i kodit rikthen një version të mëparshëm të aplikacionit. Nuk anulon automatikisht një migrim të dhënash. Versioni i vjetër mund të mos i kuptojë të dhënat e reja. Një migrim shkatërrues mund të heqë informacion që rikthimi i kodit nuk mund ta rikuperojë.

Identifikoni veprimin e rikuperimit për çdo hap. Një proces plotësimi që mund të rifillojë mund të jetë i sigurt për t’u vazhduar. Një transformim i gabuar mund të kërkojë korrigjim nga të dhënat burimore të ruajtura. Një veprim shkatërrues mund të kërkojë një procedurë të verifikuar restaurimi.

Pyesni kush është përgjegjës për vendimin e rikuperimit dhe sa kohë mund të marrë rikuperimi. Mos e trajtoni ‘kemi kopje rezervë’ si evidencë se rikuperimi plotëson kërkesën e shërbimit.

Mbajeni ndryshimin të shqyrtueshëm

Ndani pastrimin e palidhur nga ndryshimi funksional. Jepni në pull request planin e përputhshmërisë, rezultatet e verifikimit dhe kushtet e heqjes. Shënoni pikën pas së cilës rikthimi i versionit kërkon punë shtesë.

Një agjent mund të ndihmojë të shqyrtohen komponentët që e përdorin sistemin dhe të përgatitet kodi i migrimit. Një person përgjegjës ende duhet ta pranojë planin e kalimit dhe rikuperimit. Projektimi final është vetëm një pjesë e një ndryshimi të sigurt.

Bëni ushtrimin

Zgjidhni një ndryshim të vogël fushe ose API-je. Renditni çdo komponent që lexon ose shkruan të dhënat, përfshirë punët në sfond. Përshkruani një hap të parë shtues, një kontroll kalimi dhe një kusht heqjeje. Identifikoni cili hap mund të pengojë rikthimin e versionit.

Shkarkoni fletën e punës (Markdown)
Kontrolloni çfarë keni kuptuar ↑

Vazhdoni të mësoni

Burime dhe lexime të mëtejshme

Lexime përkatëse nga Taiga

Mësimi i mëparshëm: Shqyrtoni kodin e gjeneruar me AI