Czy źle jest opracowywać w oparciu o dane produkcyjne?

Zawsze słyszałem, że opracowywanie w oparciu o dane produkcyjne jest złą praktyką i obecnie przechodzę na model deweloperski> Etap> Produkcja , głównie dlatego, że mam nowego pracownika z minimalnymi umiejętnościami i wolałbym go nie mieć pracować bezpośrednio z danymi produkcyjnymi.

Ale przez długi czas pracowałem bezpośrednio z danymi produkcyjnymi przy minimalnych problemach głowy, z wyjątkiem może kilku błędów pełzających tu i tam, takich jak problemy z pisownią, zły tekst alternatywny, linki wskazujące niewłaściwą lokalizację. Wydaje się, że jest to spowodowane brakiem wzajemnej oceny z mojej strony, a nie pracą z danymi na żywo.

Dlaczego więc rozwijanie strony na żywo jest tak złe?

Jeśli podczas programowania korzystasz z poleceń SQL zawierających tabele bazy danych INSERTlub UPDATEna nich, narażasz się na ryzyko w zakresie, w jakim te tabele bazy danych mają kluczowe znaczenie.

Niektóre miejsca synchronizują dane produkcyjne w bazie danych programistów w określonych odstępach czasu, powiedzmy, raz w tygodniu lub na żądanie programisty, dzięki czemu masz świeże dane do opracowania.

Ale jeśli dane produkcyjne nie są zagrożone z powodu tego, co robisz, na przykład, jeśli po prostu opracowujesz widok niektórych danych, zwykle nie jest to wielka sprawa. Teraz, jeśli uruchamiasz raporty, które wykonują skanowanie tabeli, możesz potencjalnie zablokować tabelę, a to wpłynie na Twoich obecnych użytkowników.

W takich przypadkach odłożyłbym się na administratora bazy danych, jeśli nie byłoby „oficjalnego” DBA, popełniłem błąd po stronie ostrożności. Stworzenie bazy danych programistycznych jest proste, nawet dla mnie. W zespole jest to niezbędne. W przeciwnym razie, jeśli nalegasz na posiadanie tylko jednej bazy danych, możesz poprzedzić tabele programowania baz danych DEV_i poczuć się nieco lepiej. Tak, to wymaga pewnych zmian w kodzie, ale przy programowaniu dodawanie zmiennych podczas programowania $debug = trueitp. Jest zwykle warte wysiłku.

Wiele sposobów na zbliżenie się do tego. To bardzo zależy od twojej sytuacji.

NIE chcesz opracowywać w oparciu o dane produkcyjne na serwerze produkcyjnym. Istnieje kilka ogromnych powodów.

1. Rozwój spowalnia produkcję i stwarza luki w zabezpieczeniach. Co się stanie, jeśli nie otworzysz komputera i odejdziesz?
2. Jeśli popełnisz błąd, osoby odwiedzające Twoją witrynę mogą to zobaczyć.
3. Jeśli dokonasz jakiejkolwiek aktualizacji danych w ramach Transakcji w bazie danych i nie dokonasz jej natychmiast lub transakcja zajmie trochę czasu, zablokujesz wszystkie zaangażowane tabele i możesz spowodować przekroczenie limitu czasu .
4. Niektóre systemy baz danych, w szczególności SQL Server, wykonują blokady tabel tylko na instrukcjach SELECT! Co oznacza, że ​​możesz przypadkowo dać użytkownikom limity czasu lub strony błędów w swojej witrynie.

Jeśli to możliwe, nigdy nie będę pracował nad programowaniem na żywo. Najlepszym rozwiązaniem jest wykonanie kopii zapasowej bazy danych i stron oraz praca z kopią, a następnie przekazywanie aktualizacji. Jednym z narzędzi, które pomogło mi tonę, jest SyncToy firmy Msft.

Naprawdę możesz zepsuć dane. Wyobraź sobie pozostawienie klauzuli where. Nawet jeśli masz cogodzinne kopie zapasowe, byłoby to trudne do naprawienia.

Jeśli nie jeździsz bez pasa bezpieczeństwa, nie rozwijaj danych produkcyjnych. Tylko kwestia bezpieczeństwa.

Jeśli masz dostępne dane produkcyjne, uzasadnione jest wykorzystanie ich do testowania, ale użyj osobnej testowej bazy danych z kopią tych danych. W przeciwnym razie wiele rzeczy będzie działać w przypadku kilku rekordów testowych „blabla”, ale nie w prawdziwym scenariuszu.

A jeśli chodzi o opracowywanie danych na żywo - pamiętaj o prawach Murphy'ego: „Wszystko, co może pójść źle, pójdzie nie tak”, i tak łatwo jest popełnić niewielki błąd o dużych złych konsekwencjach.