Rozwijanie na serwerze produkcyjnym

Dzisiaj zostałem wykrzyczany za opracowanie aplikacji na serwerze produkcyjnym. Cytat: „ rozwój na serwerze produkcyjnym jest niedopuszczalny - nigdy! ”

Oto sytuacja.

1. Skonfigurowałem wystąpienie programistyczne: http://example.com:3000
2. Instancja produkcyjna to: http://example.com
3. Kończę wszystkie prace programistyczne http://example.com:3000i kiedy klient jest zadowolony ze zmian, przenoszę je do http://example.com.

Aplikacja, z którą pracuję, jest starą aplikacją Ruby on Rails i muszę powiedzieć, że początkowo próbowałem skonfigurować środowisko programistyczne lokalnie, ale nigdy nie udało mi się go uruchomić. Po krótkiej próbie poddałem się i postanowiłem rozwijać się na serwerze produkcyjnym.

Znowu jestem idiotą? Prawdopodobnie tak, ale zajmuję się tworzeniem stron internetowych od kilku lat i nigdy nie spotkałem się z taką sytuacją. Kto ma rację i dlaczego?

Zwykłem programować na serwerze produkcyjnym. Może działać dobrze, ale jest niewskazany z co najmniej dwóch powodów:

1. Kod programistyczny może powodować nieskończone pętle, wycieki pamięci lub inne problemy, które blokują procesor, pochłaniają całą pamięć lub w inny sposób wpływają na serwer w sposób, który wpłynie na kod produkcyjny.
2. Jeśli musisz wprowadzić zmiany w komponentach środowiska serwerowego w ramach prac programistycznych, takich jak wersja Ruby lub MySQL lub cokolwiek innego, będziesz w stanie powiązać.

Jak powiedzieli inni, kodowanie w środowisku PROD naraża użytkowników na błędy. Nawet jeśli uruchomiłeś inną instancję, nadal masz udostępnione zasoby sprzętowe i nadal masz dostęp do plików produkcyjnych i baz danych. I jak niektóre komentarze podkreślić, jeśli instancja Dev zostanie posiekany (na przykład z powodu pominięcia go wytrzeć, a następnie ktoś odkrywa ogromny bezpieczeństwo wykorzystać w Rails), już teraz ma publicznie dostępną maszynę ze swojej aplikacji działającej jako brama do środka. Co byłoby ... niefortunne.

Różne firmy mają różne odpowiedzi na to pytanie, ale ogólnie można je podzielić w następujący sposób:

• Czy wystąpił błąd?
• Ile czasu zajęłoby przywrócenie zmiany (pracuję głównie w C ++, więc wycofanie pliku binarnego może potrwać znacznie dłużej niż w Rubim, szczególnie gdy „straciłeś” stary plik binarny i trzeba go ponownie skompilować)
• Jaki jest efekt zmiany (przybliżony przewodnik: zepsucie przechowywanych danych jest o wiele gorsze niż brak przechowywania lub wyświetlania danych, co z kolei jest gorsze niż brak wyświetlania strony)
• Gdybyś spieprzył, a potem wyszedł przez drzwi, czy ktoś wiedziałby, co zrobiłeś?
• Czy istniała inna opcja wdrożenia, która zapobiegałaby / zminimalizowała / wykryła zakręcenie przed uderzeniem?

To daje ostateczne obliczenia:

• Ile kosztowałoby to całkowicie niemożliwe do zepsucia przedsięwzięcie?

Teraz o tyle mniej warta jest cała struktura zarządzania dla faceta podejmującego decyzje budżetowe. Stąd shouty.

Jeśli pracujesz na wewnętrznej stronie firmy „O nas” i wpiszesz swoje własne imię na L. „God-like” Thomas, kłopotliwy problem z pseudonimem; jeśli pracujesz nad aplikacją zakupową o kluczowym znaczeniu dla biznesu, która przypadkowo wypisuje dane karty kredytowej ze strony głównej ... problem z pozwem sądowym. Pomiędzy tymi skrajnościami kryje się wszystko, od przeładowywania, paraliżującej produktywności i wszystkich innych rzeczy, które mogą odstraszyć klientów.

Powodem, dla którego nie pozwala się na to nawet na stronie „O nas”, jest to, że kodowanie bezpośrednio w produkcji jest uzależniające . Zaczynasz od robienia tego tylko dla nieletnich, ale z biegiem czasu jest o wiele szybsze, aby nie zmuszać DEV do działania.

Poza tym wielkość firmy może mieć duży wpływ. W dwuosobowym zespole, gdy coś zaczyna się psuć, pochylasz się przez ramię i mówisz „Oi, jackass, odłóż to”. W 300-osobowej firmie musisz zacząć się martwić, czy to niekompetencja, czy złośliwość, menedżerowie mogą ponosić odpowiedzialność za rzeczy, nad którymi nie mieli kontroli itp.

Na koniec dnia, jeśli wykonasz procedurę i spieprzysz, sprawdzą, co jest nie tak z tą procedurą. Jeśli ominiesz procedurę i spieprzysz, to teraz twoja odpowiedzialność spoczywa na sobie, nawet jeśli wina się trochę rozłoży. To, czy chcesz rzucić kostką, zależy od ciebie.

Próbowałem skonfigurować środowisko programistyczne lokalnie, ale nigdy nie udało mi się go uruchomić. Po krótkiej próbie poddałem się i postanowiłem rozwijać się na serwerze produkcyjnym.

Wspieram instrukcje AVOID na serwerze produkcyjnym. Możesz być uzasadniony, aby to zrobić w GUN, jeśli jest to poprawka literówki w pliku konfiguracyjnym i nalegana przez twojego kierownika.

WHY NOT?- Ponieważ bardzo ryzykowne i zaimkowe stanie się później nawykiem , bardzo cię to złapie. Ponieważ krytyczne błędy / awarie produkcyjne mogą cię kosztować zwolnienie z pracy.

Pozwól, że powtórzę to jeszcze raz, nawet jeśli poprosiłeś o korektę literówki na productionserwerze, najpierw zrób to Staging. lub innymi słowy przetestuj swoje zmiany, przetestuj je i ponownie przetestuj przed wprowadzeniem do produkcji.

Dzieje się tak często w miejscach, w których kultura „rób to szybko i brudno ” wydaje się normą.

Edycja: Programowanie na serwerze produkcyjnym, jako osobne środowisko, również NIE jest akceptowane . Wszelkie problemy spowodowane w pracy mogą po prostu doprowadzić do awarii serwera produkcyjnego i wpłynąć na wydajność aplikacji produkcyjnej . Jako przykład pamiętam przypadek, gdy istniała luka w zabezpieczeniach, gdy mój poprzedni współpracownik próbował użyć serwera produkcyjnego WinServer 2003 do celów programistycznych.

To naprawdę problem z protokołem. Zasadniczo nie jest to coś, co chciałbyś robić. Chcesz zostawić maszyny produkcyjne w spokoju. Mogą zawierać poufne dane i nie chcesz narażać wydajności lub stabilności witryn produkcyjnych za pomocą kodu nieprodukcyjnego.

To powiedziawszy, są chwile, w których jest to powszechnie wykonywane. Jeśli jesteś w sytuacji, gdy wypompowujesz oprogramowanie o niskim natężeniu ruchu lub proste witryny CMS, prawdopodobnie nie będzie to stanowić problemu. Ale jeśli pracujesz nad czymś z wrażliwymi danymi lub procesami „krytycznymi dla biznesu”, naprawdę nie powinieneś ryzykować posiadania kodu programistycznego na tym samym komputerze.

Innym ważnym powodem, aby nie rozwijać się bezpośrednio w produkcji, jest to, że instancja programistyczna zwykle generuje i wyświetla pełne błędy i ślady stosu. Nigdy nie chcesz ujawniać tego użytkownikowi.

Tak, możesz je zalogować zamiast pokazywać je klientowi, ale to sprawia, że ​​debugowanie jest o wiele mniej zabawne niż jest już.

Dodano Rozwiązanie problemu ubocznego związanego z problemami z instancją programistyczną: Odniosłem wielki sukces we wdrożeniu maszyny wirtualnej opartej na VirtualBox , która powiela nasze środowisko produkcyjne (oczywiście nie tylko sprzętowe) z Ubuntu Server .

Dziwi mnie, że nikt nie wspomniał o najważniejszym z powodów, dlaczego absolutnie zabrania się tworzenia na serwerach produkcyjnych:

Nie zadzieraj z danymi produkcyjnymi, co może się zdarzyć tak łatwo!

Mały błąd w jednym miejscu prowadzi do gigantycznych problemów w innych obliczeniach, a następnego dnia wszystkie dane są śmieciami, a klient jest wkurzony. Jest to o wiele, znacznie gorzej niż błąd w interfejsie użytkownika lub mała awaria tu i tam.

W przypadku większości aplikacji wartość leży w danych, a nie w procedurach.

Zawsze staram się zapytać innych programistów, jakie są procedury dla konkretnej firmy. Ogólnie tak, zawsze powinieneś:

1. Buduj lokalnie.
2. Popchnij go do jakiegoś pudełka, które naśladuje produkcję tak bardzo, jak to możliwe, aby sprawdzić, czy gra tam ładnie.
3. Ewentualnie przekaż go do instancji kontroli jakości lub certyfikacji, aby przekazać go klientowi / zespołowi kontroli jakości w celu przejrzenia zmian.
4. Popchnij do produkcji.

Możesz użyć receptur Capistrano w połączeniu z GitHub, aby obsłużyć wszystkie te rzeczy za Ciebie. Jeśli musisz to robić ręcznie za każdym razem, może szybko się zestarzeć.

Innym problemem związanym z tworzeniem na prod jest to, że czasami te rzeczy są pomijane w kontroli źródła i przyszłe wydanie może cofnąć twoją szybką poprawkę.

Jeśli jesteś w spółce publicznej w Stanach Zjednoczonych, nie powinieneś mieć nawet dostępu do produ z powodów prawnych. Zasadniczo w żadnej firmie programista nie powinien mieć dostępu do produktu (z powodów podanych we wszystkich odpowiedziach, a także z możliwych przyczyn prawnych), więc twój menedżer również nie ma racji, przyznając ci prawa do tego serwera.

Reguły, które używają „zawsze” lub „nigdy” są zwykle źle zdefiniowane. Będą wyjątkowe przypadki, w których złamanie najlepszej praktyki będzie uzasadnione. Znacznie lepsza rada brzmi: „Nie dotykaj serwerów produkcyjnych, chyba że masz bardzo dobre powody”

W mojej karierze znalazłem tylko dwa powody do zmiany kodu na serwerach produkcyjnych:

1. Błędy lub zachowania, które występują tylko tam i nie są powtarzalne w środowisku programistycznym. Są to rzadkie, ale mogą być bardzo denerwujące i trudne do znalezienia.

2. Bezpośrednie naprawianie błędu krytycznego, na który nie można czekać, aby przejść przez normalny proces wdrażania, jeśli zajmuje to więcej niż kilka minut. Następnie zostanie to wyjaśnione przez kierownictwo. Jeśli masz szczęście, powinieneś mieć tylko kilka z nich przez całą karierę.

Oba najlepiej pozostawić starszym programistom, którzy dokładnie znają systemy.