Uprawiasz demagogię.
Nie uprawiam demagogi, opisuję swoją sytuację i podejście, które z powodzeniem sprawdza się w mojej pracy. Oczywiście można mi nie wierzyć, albo najlepiiej w ogóle stwierdzić, że jestem głupi. Nic nie poradzę.
U was zamówienia się nie zmieniają?
Generalnie po tym jak zamówienie zostało złożone, to potem może zostać potwierdzone, opłacone, skompletowane i wysłane. Może też zostać w jakiś sposób poprawione (np. przez zmianę jakichś parametrów albo produktów), może też zostać anulowane. Ale anulowane też przecież zostaje w bazie, po prostu zmienia się mu status. No i to też jest zdarzenie księgowe, bo klient niekoniecznie dostanie pieniądze z powrotem.
Użytkownikom nie zmieniają się prawa.
Nie, jest tylko jeden rodzaj uzytkowników - klienci, ich prawa to robienie zakupów i zarządzanie własnym profilem.
Batchy nocnych i żadnych procesów nie macie?
Mamy, ale to jest tylko odczyt danych. I nie na środowiskach zespołowych.
Pracujecie na danych w ROMie czy tez wyrytych na kamiennych tablicach?
Głównie na AWS, cholera wie co oni mają tam pod spodem.
Co by nie wciskać o jakiś problemach organizacyjnych, to jednak w normalnym świecie (poza sf somekinda),
Nie nazywałbym fikcją czegoś, co po prostu działa.
I nie twierdzę, że może działać wszędzie, i wszędzie ma sens. Pokazuję tylko inne możliwe podejście. Ktoś może potraktować to jako inspirację, ktoś inny jako ciekawostkę, ktoś jako okazję do kłótni i pokazywania wyższości, no cóż, co kto woli.
- ludzie zmieniają dane w systemach. Przez to pracowicie tropione heisenbugi szlag może trafić,
Owszem, jeśli są jakieś współdzielone dane, to jest takie ryzyko. U mnie takiego nie ma.
- ludzie wgrywają nowe wersje i (o zgrozo) robią bugi (przez to juz np. od 2 tygodni nie mogę przetestować e2e procesu w jednym banku, bo angażuje około 15 systemów i jeszcze nie było dnia żeby w jakimś bug się nie objawił, w jednym naprawią to w drugim zepsują, a to dlatego, że własnie mają tam takiego pielęgnowanego INTa),
No to jest straszne. Kiedyś pracowałem z takimi środowiskami integracyjnymi, na których wszystkie zespoły dłubały jednocześnie, to prawie nigdy nie działało w pełni. Bardzo się cieszę, że tego nie mam teraz.
- utrzymanie takich INT, DEV kosztuje, a zawsze się okazuje, że może przydać się kolejne (typowo np. na testy wydajnościowe... i co wtedy? w jednej firmie ładnie pisali, że dziś nie wolno korzystać z INT bo testy wydajnościowe :-) , cudo :-) )
U nas właściwie w testach wydajnościowych najlepiej sprawdza się produkcja. Nie dość, że ludzie testują obciążenie, to jeszcze za to płacą. :)
Jak do tej pory jedyni ludzie, którym nigdy te INT, DEVy itd nie przeszkadzały i nie widzieli problemu to byli niemieccy architekci. Nie musieli się w tym grzebać, a z wieży problemów nie widać.
Tak, że tego... tu pisze do somekinda. Jak uważasz, że jest fajnie to może spójrz w dół i zobacz, czy nie siedzisz za wysoko.
Ja jestem zwykłym programistą. Ale teraz mam wrażenie, że to Ty siedzisz za wysoko. Tak wysoko, że nie widzisz nawet literek w moich postach. Ja nic o żadnych INTach i DEVach nie pisałem. Niezależne środowiska dla zespołów są bardzo daleko od scentralizowanych na poziomie całego projektu DEV i INT.
@somekind no generalnie tak, jak nie widzisz potrzeby, to prawdopodobnie nie potrzebujesz. Jeśli ktoś jednak miałby dzisiaj wybierać, jak rozwiąże dane problemy, to użyłby raczej gotowego narzędzia, zamiast pisać własne. Tym bardziej, że docker jest darmowy, a chmura jednak raczej płatna.
Pełna zgoda, nie warto pisać własnych narzędzi, jeśli już istnieją. Mój pech, że trafiłem do zbyt bogatej firmy, dla której IT jest biznesem, a nie kosztem, a swoje problemy zaczęli rozwiązywać na długo przed powstaniem dockera. :)