Je špatné vyvíjet se proti výrobním datům?
Vždy jsem slyšel, že je špatnou praxí vyvíjet se proti výrobním datům a v současné době se stěhuji do modelu Dev> Stage> Production , hlavně proto, že mám nového zaměstnance s minimálními dovednostmi a Raději bych ho nechal pracovat přímo s výrobními daty.
Ale dlouho jsem pracoval přímo s produkčními daty s minimálními bolestmi hlavy, až na to, že sem nebo tam došlo k několika chybám, jako jsou problémy s hlášením, špatný alt text, odkazy směřující na nesprávné místo. Zdá se, že to je způsobeno nedostatkem peer review z mé strany, ne kvůli práci s živými daty.
Proč se tedy na živém webu vyvíjí takový špatný postup?
Pokud během vývoje spouštíte příkazy SQL, které obsahují INSERT nebo UPDATE ve stávajících databázových tabulkách, riskujete, že tyto databázové tabulky jsou kriticky důležité.
Některá místa synchronizují výrobní data do vývojové databáze v určitém intervalu, řekněme jednou týdně nebo na žádost vývojáře, takže máte k dispozici nová data.
Ale pokud vaše výrobní data nejsou ohrožena tím, co děláte, například, pokud jste prostě vyvíjeli pohled na některá data, obvykle to není velký problém. Pokud nyní spustíte přehledy, které provádějí skenování tabulek, máte potenciál uzamknout tabulku a ovlivnit tak stávající uživatele.
V takových případech bych se odložil svému administrátorovi databáze, pokud neexistuje žádná „oficiální“ DBA, mýlím se na straně opatrnosti. Vytvoření vývojové databáze je dost jednoduché i pro mě. V týmu je to zásadní. Pokud by to nebylo naléhavé, kdybyste museli mít pouze jednu databázi, mohli byste své tabulky vývojové předpony předponou DEV_ a cítit se trochu lépe. Ano, to vyžaduje určité změny kódu, ale ve vývoji přidávání některých proměnných během vývoje $debug = true, atd., Obvykle stojí za námahu.
Spousta způsobů, jak k tomu přistupovat. Je to velmi závislé na vaší situaci.
Nechcete se vyvíjet proti výrobním datům na produkčním serveru. Existuje několik obrovských důvodů.
- Vývoj zpomaluje vaše výrobní pole a vytváří zranitelnosti. Co se stane, pokud necháte počítač odemčený a odejdete?
- Pokud uděláte chybu, lidé, kteří navštíví váš web, to uvidí.
- Pokud provedete jakoukoli aktualizaci dat uvnitř transakce v databázi a nezavazujete ji okamžitě nebo transakce chvíli trvá, zablokujete všechny zúčastněné tabulky a můžete způsobit vypršení časového limitu .
- Některé databázové systémy, konkrétně SQL Server, budou někdy provádět zámky tabulek pouze na příkazech SELECT! Což znamená, že na svém webu můžete nechtěně dát lidem časový limit nebo chybové stránky.
Kdyby to bylo možné, nikdy bych nevyvíjel vývojové práce na live boxu. Nejlepším řešením je vytvořit zálohu databáze a stránek a pracovat s kopií a poté posílat aktualizace. Jedním z nástrojů, který mi pomohl tunu, je SyncToy společnosti Msft.
Můžete si to opravdu dát do dat. Představte si opuštění klauzule where. I když máte hodinové zálohy, byla by to bolest.
Pokud máte k dispozici produkční data, je rozumné je použít pro testování, ale použijte samostatnou testovací databázi s kopií těchto dat. V opačném případě bude pro vaše několik testovacích záznamů „blabla“ fungovat mnoho věcí, nikoli však pro skutečný scénář.
A pro vývoj na živých produkčních datech - pamatujte na Murphyho zákony „Všechno, co se může pokazit, se pokazí.“, A je tak snadné udělat malou chybu s velkými špatnými důsledky.
Pokud nejedete bez bezpečnostního pásu, nevyvíjejte údaje o produkci. Jen bezpečnostní problém.