Pracuję w małym zespole programistycznym wspierającym większą organizację. W tym roku nasz menedżer zdecydował, że wykorzystamy technologie Oracle Apex do obsługi większości danych w naszej firmie.

To byłoby w porządku, z wyjątkiem tego, że mamy tylko jeden serwer Apex. Nasz kierownik stwierdził, że wszystko dzieje się w tym jednym przypadku. Nasz zespół tworzy aplikacje, a demo naszego menedżera - i używają ich nasi wewnętrzni klienci, co z oczywistych powodów już powoduje problemy!

Mogę się tylko spodziewać, że sytuacja się pogorszy, gdy będziemy bardziej inwestować w Apex, aplikacje stają się bardziej złożone, a liczba użytkowników rośnie. Słyszałem, że najlepszą praktyką jest oddzielne środowisko programistyczne, testowe i produkcyjne, ale dlaczego tak jest?

Pytanie: Dlaczego powinniśmy mieć osobne środowiska programistyczne, testowe i produkcyjne?

Dlaczego powinniśmy mieć osobne środowiska programistyczne, testujące i produkcyjne?

Równolegle odbywa się kilka działań:

• programowanie - gdzie programiści popełniają kod, popełniają błędy, eksperymentują itp.
• testowanie - gdzie testy są uruchamiane ręcznie lub automatycznie, a ze względu na złożoność mogą zużywać wiele zasobów.
• produkcja - gdzie tworzona jest wartość dla klientów i / lub firmy

Czy chcesz, aby wszystko to działo się w tym samym środowisku? Czy chcesz, aby firma się zatrzymała, ponieważ nowy test zmusił twoje serwery do wymiany dysków twardych i zużywa każdy rdzeń procesora? Czy chcesz, aby Twoje testy się zatrzymały, ponieważ programista wykonał zawiłą bombę widełkową na podstawie eksperymentu skalowania? Czy chcesz, aby kod, który Twoim zdaniem działał w testach ze względu na sznurek i taśmę programistyczną, działał podczas produkcji? Czy chcesz, aby programiści pracowali z potencjalnie wrażliwymi danymi produkcyjnymi (wiem, że nie dotyczy to wszystkich firm, ale w wielu z nich)?

Co zapobiega występowaniu tych problemów?

Oddzielne środowiska.

Czego więc potrzebujesz?

Potrzebujesz osobnych środowisk.

Ujmując to formalnie

Potrzebujesz osobnych środowisk z następujących powodów:

• w celu zmniejszenia ryzyka blokowania rozwoju biznesu i oprogramowania.
• w celu zmniejszenia ryzyka wprowadzenia kodu do produkcji, który przeszedł testy z powodu fałszowania oprogramowania ad hoc.
• w celu zmniejszenia ryzyka, że ​​dane produkcyjne dostaną się w niepowołane ręce (bardzo ważne, gdy organizacje mają do czynienia z danymi wrażliwymi, takimi jak numery identyfikacyjne i informacje finansowe i zdrowotne) lub zostaną zmieszane z danymi testowymi lub zniszczone.

W twoim kontekście nowa platforma technologiczna

Może to jeszcze nie jest tak naprawdę produkcja (ponieważ jest to stosunkowo nowa platforma), ale dostaniesz swoje oddzielne środowiska, gdy firma zacznie na nich polegać, i są albo wystarczająco mądrzy, aby przewidzieć ryzyko lub uświadomić sobie to, ucząc się trudnego sposób.

Słyszałem, że najlepszą praktyką jest oddzielne środowisko programistyczne, testowe i produkcyjne, ale dlaczego tak jest?

Obecnie nie jest to tak wyraźne.

Wiele miejsc nie wykonuje już ręcznych testów, więc nie mają samych danych testowych. Wiele innych miejsc ma taką skalę, że nie mogą odtworzyć środowiska produkcyjnego ze względu na koszty. Zwłaszcza w związku z gwałtownym rozwojem mikrousług, wyzwaniem staje się utrzymywanie synchronizacji szybko zmieniających się środowisk, aby zapewnić, że testowanie w środowisku kontroli jakości dokładnie odtwarza rzeczy w celu wykrycia błędów, które pojawiłyby się w produkcji.

Dlaczego powinniśmy mieć osobne środowiska programistyczne, testujące i produkcyjne?

• Gdyby dane testowe były widoczne dla użytkowników, byłoby bardzo źle.
• Gdyby twoje dane produktu były widziane przez programistów / testerów, byłoby bardzo źle.
• Jeśli nie możesz ufać programistom, że nie zepsują się źle i nie możesz szybko naprawić tej sytuacji.
• Jeśli masz zautomatyzowane CI, dzięki czemu promocja kodu jest szybka i łatwa.

Zasadniczo, jeśli koszt posiadania środowisk jest mniejszy niż koszt braku środowisk .

Głównym (i najbardziej widocznym) powodem jest to, że nigdy nie chcesz mieszać danych testowych i produkcyjnych. Może to być bardzo mylące bardzo szybko zarówno dla użytkowników systemu, jak i programistów. Podczas administrowania zapewnianiem jakości i testami jednostkowymi (które powinieneś robić), musisz upewnić się, że znajdują się one w całkowicie oddzielnym środowisku. Jeśli coś eksploduje w twoim środowisku programistycznym lub w QA, miałoby to negatywny wpływ na produkcję, a tym samym na żywych użytkowników i ich ważne dane! Absolutnie nie chcesz, żeby to wpłynęło na produkcję!

Dotyczy to normalnych usług, z których powinieneś korzystać w codziennej pracy, takich jak kontrola wersji. Nie można właściwie używać kontroli wersji, jeśli kontrolowany kod znajduje się w środowisku na żywo! Twoi użytkownicy oszaleją - co zrobić, jeśli musisz przywrócić lub przywrócić? Co jeśli popełnisz drastyczny błąd, piętnaście popełnia głębokie błędy? Jak poradzisz sobie z rozgałęzianiem?

W ostateczności powinieneś rozdzielić swoje środowisko na kilka wirtualnych instancji, ale naprawdę musisz zrobić dokładnie to, co powiedziałeś i mieć całkowicie odrębne instancje dla każdego środowiska; idealnie rozwój, kontrola jakości, inscenizacja i produkcja.

Wszystko to ostatecznie powoduje ogromną szkodę nie tylko dla twojej czołowej aplikacji (a tym samym dla twojej reputacji wśród użytkowników), ale także dla wydajności twojego zespołu.

Posiadanie tylko jednej instancji Oracle nie oznacza tego samego, co „brak oddzielenia między środowiskiem deweloperskim, testowym i produkcyjnym”!

Napisałeś w komentarzu

Obecnie używamy różnych schematów do różnych projektów

Ok, więc poświęcając tylko kilka projektów na rzecz rozwoju, a niektóre do testowania, to można oddzielić środowisk do pewnego stopnia, za pomocą różnych schematów. Wydaje mi się, że już to zrobiłeś, ponieważ jest to jedyne rozsądne podejście, jakie znam, gdy nie planuje się separacji instancji. Nie mogę sobie wyobrazić, aby Twój menedżer był tak szalony, że chce, abyś pomieszał dane programistów, dane testowe i dane klientów w jednym schemacie w dowolny sposób. Najprawdopodobniej chce po prostu zaoszczędzić pieniądze, nie kupując drugiego serwera ani nie inwestując pieniędzy w licencję na drugi przypadek.

Dlatego prawdziwe pytanie, które musisz zadać, to:

Czy musimy używać różnych instancji i / lub serwerów do oddzielania środowisk programistycznych, testowych i produkcyjnych, czy też separacja schematów jest wystarczająca?

To sprawia, że ​​odpowiedź nie jest tak jednoznaczna, jak w innych odpowiedziach tutaj. Różne schematy pozwalają na różne prawa dostępu, więc możesz przynajmniej uzyskać izolację do pewnego stopnia w jednej instancji Oracle. Twoi programiści najprawdopodobniej będą jednak potrzebowali pewnych uprawnień administracyjnych w „swoim” schemacie, więc trudniej będzie upewnić się, że nie będą mieli dostępu do danych produkcyjnych, jeśli użyjesz tylko jednej instancji.

Co więcej, jedna instancja / jeden serwer będzie również oznaczać wspólne zasoby między deweloperem, testem i produkcją - wspólne zarządzanie użytkownikami / schematami, wspólne miejsce na dysku, wspólne procesory, wspólna przepustowość sieci. Połącz to z „prawem nieszczelnych abstrakcji” , a będzie jasne, że użycie tylko jednego wystąpienia będzie wiązało się z pewnym ryzykiem wystąpienia niepożądanych efektów ubocznych między środowiskiem deweloperskim, testowym i produkcyjnym.

W końcu musisz sam zdecydować: czy możesz skutecznie pracować z wadami tego podejścia? Czy twoja aplikacja nie wymaga tak dużych zasobów, a twoje dane produkcyjne nie są tak „tajne”, że tolerowany jest niższy poziom separacji między programowaniem, testowaniem i produkcją niż poziom, który można uzyskać z „trzech instancji / trzech serwerów” podejście? Jeśli nie możesz skutecznie pracować w ten sposób lub nie masz wysokiego ryzyka zakłócenia produkcji w sposób, w jaki zaczynasz tracić klientów, masz wszystkie argumenty, których potrzebujesz, aby przekonać swojego menedżera do zakupu co najmniej drugiego serwera.

Potrzebujesz wielu typów środowisk, a może nawet wielu serwerów w każdym środowisku.

Programiści mogą aktualizować kod w trakcie programowania. Kod może nawet nie działać - być może aplikacja nawet się nie uruchomi.

Nie ma to wpływu na kontrolę jakości, która testuje najnowszą stabilną wersję we własnym środowisku.

Ponieważ zarówno środowisko programistyczne, jak i kontrola jakości aktualizują swoje środowiska, produkcja odbywa się w najnowszej wersji wydanej sześć miesięcy temu i zmiany w innych środowiskach nie mają na nią wpływu.

Zmiany wprowadzane w różnych środowiskach mogą być kodem lub danymi. Być może QA musi przetestować skrypt bazy danych zaprojektowany do naprawy niektórych złych danych w produkcji. Być może skrypt pogarsza problem - przywróć kopię zapasową bazy danych i spróbuj ponownie. Jeśli tak się stanie w produkcji, możesz mieć bardzo poważny problem finansowy.

Co się stanie, jeśli masz wiele wersji? Być może pracujesz nad wersją 2.0, ale nadal potrzebujesz poprawek w dziale konserwacji 1.0. Teraz potrzebujesz wielu środowisk programistycznych i kontroli jakości, aby mieć pewność, że zawsze możesz opracować i przetestować dowolną gałąź, gdy krytyczny błąd zostanie wykryty i trzeba go wczoraj naprawić.

Zauważyłeś już problemy, które nie powodują oddzielnych środowisk. Oto podstawowa przyczyna istnienia oddzielnych środowisk: wyeliminowanie problemów spowodowanych konfliktami, które nieuchronnie powstają, gdy próbujesz wykonywać operacje programowania, testowania i produkcji w jednym środowisku. To samo rozumowanie dotyczy przydzielania programistom indywidualnych piaskownic do pracy, pozwala to uniknąć błędów jednego dewelopera, a nawet po prostu niekompatybilnych zmian, uniemożliwiających cały zespół programistów.

Jest to również najlepszy argument, jaki możesz przedstawić kierownictwu, aby odejść od pojedynczego środowiska: wskazując problemy, które już wywołuje jedno środowisko, pokazując linię trendu i argumentując, że prędzej czy później, jeśli wszystko będzie tak jak jest, będzie problem, którego oczyszczenie będzie kosztować znacznie więcej (zarówno w przypadku bezpośredniego wysiłku, jak i utraty zaufania klienta do zdolności firmy do świadczenia usług), niż ponowna konfiguracja rzeczy dla oddzielnych środowisk.

Istnieje wiele przeciwstawnych sił i dynamiki. Koszt posiadania wielu serwerów i koszt posiadania tylko jednego. Myślę, że to pytanie może zawierać więcej niż tylko baza danych? Mogę być nieporozumieniem, ale wiąże się to z nieporozumieniem systemowym, które wiąże się z kosztami rzeczy materialnych vs.

Zazwyczaj oczywiste koszty są łatwe do zrozumienia.

Koszty abstrakcyjne są trudniejsze do oszacowania, a przez to trudniejsze do zrozumienia. TechnicalDebt, koszt błędów, koszt stresu, obciążenie programistów, skutki zmian, testy regresji, wpływ przestojów i tak dalej są trudniejsze do wyjaśnienia.

różne środowiska Środowiska są zwykle oddzielone dla danych i / lub celu. Każde środowisko ma inną funkcję. Szybkość zmian w systemie, tj. jak często będzie aktualizowany, jakie zmiany i skutki zmian są brane pod uwagę.

Używamy różnych środowisk, aby trywializować zmiany.

Używamy różnych środowisk, dlatego oferujemy solidność i pewność, że środowisko się nie zmieniło.

Używamy środowisk do rozważenia skutków zmiany.

Używamy środowisk, aby obniżyć koszty związane ze zmianami.

testowanie i stabilizacja systemu kosztuje dużo. Tworzysz środowiska w celu zabezpieczenia inwestycji poczynionych w stabilnym środowisku.

Nigdy nie jesteś zbyt małym zespołem, aby przestrzegać pragmatycznych, oszczędnych, rzetelnych i sprawdzonych wzorców procesów.

Używanie jednego środowiska do wszystkiego przypomina przechowywanie wszystkich zdjęć na jednym dysku twardym, możesz to zrobić, ale będziesz tego żałować.

niektóre osoby potrzebują dowodu , że w wielu sytuacjach miałem do czynienia z klientami lub innymi, którzy nie doceniają kosztów zapewnienia solidności i przestrzegania najlepszych praktyk. Sugeruję, abyś zebrał kilka przykładów prawdziwych przypadków, w których koszty są jasno określone.