Dobre, proste powody posiadania wielu środowisk

Przez całą moją karierę pracowałem w firmach, które miały zbiór różnych środowisk do różnych celów. Zawsze mieliśmy mniej więcej nasze środowisko pulpitu, środowisko testowe, środowisko kontroli jakości, środowisko pomostowe i środowisko produkcyjne. Dotyczyło to zarówno serwerów / aplikacji, jak i wszelkich używanych przez nas źródeł danych.

Kiedy zaczynałem w mojej obecnej firmie, zauważyłem, że 90% aplikacji zostało opracowanych w środowisku stacjonarnym w oparciu o źródła danych produkcyjnych lub bezpośrednio na serwerze produkcyjnym, w zależności od platformy. Nie było to szczególnie zaskakujące, ponieważ zostałem zatrudniony częściowo do wprowadzenia zmian w celu usprawnienia funkcjonowania zespołu programistów, co wyraźnie wynika z mojego wywiadu. Powoli zaczęliśmy zmieniać filozofię i już wkrótce większość aplikacji można uruchomić w środowisku stacjonarnym, testowym lub produkcyjnym. Niedługo potem pojawiła się także ta inscenizacja.

Teraz większość naszych programistów dostrzega zalety tej metodologii i broni jej czujnie. Mamy jednak wiele starszych aplikacji, które nigdy nie zostały migrowane. Mamy również wielu starszych programistów, którzy uważają to za stratę czasu. Niestety dostaliśmy usługę warg, ale nigdy nie otrzymaliśmy pełnego wpisowego od zarządu. Dostaliśmy coś, co uważaliśmy za zobowiązanie do znacznego zainwestowania w to około rok temu, ale nic się nie urzeczywistniło pomimo znacznego planowania, które w to włożyliśmy. Teraz odkrywamy, że potrzebujemy coraz więcej środowisk. Potrzebujemy pomocy ze strony zespołów administrujących serwerami / siecią do konfiguracji i potrzebujemy udziału interesariuszy biznesowych w celu wsparcia cyklu wydania. Jesteśmy teraz w miejscu, w którym projekt może funkcjonować, co rozsądni programiści uważają za „normalnie”

Chciałbym przedstawić pełny argument, ale kierownictwo naprawdę nie ma czasu i zainteresowania wysłuchaniem mnie, dopóki nie pojawi się krytyczny problem. Nie jestem w stanie wyrazić korzyści po prostu, ponieważ zawsze wydawało mi się to drugą naturą. Zastanawiałem się, czy istnieją jakieś dobre, proste, niezaprzeczalne powody oddzielenia środowisk, które sprawiłyby, że menedżerowie nie mieliby doświadczenia w programowaniu, aby wesprzeć ten pomysł? . Czy są jakieś dobre zasoby / literatura na ten temat?

Odpowiedź: pieniądze

Nie obchodzi mnie, jaki jest prawdziwy powód. Pieniądze MUSZĄ znajdować się u podstaw całego rozumowania, szczególnie w kontaktach z zarządem.

Gdybyśmy oboje siedzieli w pokoju przez 2 godziny, moglibyśmy wymyślić dziesiątki powodów, dla których lepiej jest mieć wiele środowisk.

Oto problem: jeśli przyczyny nie są oparte na pieniądzach, żadne z nich nie ma znaczenia .

Programiści nie są zatrudniani, by być inteligentnymi. Nie są zatrudniani do kreatywności. Zatrudniani są w celu zwiększenia przychodów - albo przez zarabianie pieniędzy, albo przez oszczędzanie pieniędzy. Jeśli nie robisz żadnego z nich, lepiej zbierz swoje CV.

Patrząc na to z tego punktu widzenia, odpowiedź jest prosta:

Posiadanie tylko jednego środowiska zwiększa nasze przestoje i powoduje utratę dochodów. Wiele środowisk pozwala nam chronić nasze zyski, dając naszym użytkownikom interfejs, który jest równie niezawodny i niezawodny jak nasza firma.

Powtarzaj to codziennie.

Poniżej kilka świetnych komentarzy, które dodają prawdziwej wartości tej odpowiedzi, więc wspomnę o nich:

• Karl Bielefeldt miał świetny punkt, kiedy wspomniał, że analiza kosztów / korzyści jest ważnym czynnikiem. Ekonomista może nazywać to kosztem alternatywnym prowadzenia wielu środowisk. Choć może to być zaskakujące, istnieją scenariusze, w których wiele środowisk może nie być odpowiedzią! Jeśli witryna Twojej firmy jest bardzo niewielkim dodatkiem, nieoczekiwane przestoje mogą być bardziej opłacalnym sposobem prowadzenia działalności. To nie brzmi jak pozycja, w której się znajdujesz, ale warto o tym wspomnieć.

• BlairHippo miał dobrą rację, ponieważ powinieneś czuć się swobodnie, aby wyglądało to jak katastrofa (a jeśli stracisz swoje dane, to prawda!). Odpowiedzialność jest doskonałym narzędziem do przekonania menedżerów, ale wciąż z tego samego powodu - procesy sądowe są drogie. Unikanie ich oszczędza pieniądze.

Jako dodatek uznałem ten artykuł za całkiem dobry. Nie odpowiada bezpośrednio na twoje pytanie, ale pozwala rozpoznać, jak programiści postrzegani są do zarządzania, co z kolei prowadzi do tej odpowiedzi. Dobra lektura.

Pojedynczy punkt awarii

Nie mając środowiska programistycznego ani testowego, masz jeden punkt awarii dla starszych aplikacji. Kierownictwo usłyszy cię, jeśli opisasz starsze aplikacje w tych kategoriach.

Musisz umieć podzielić wiadomość na bajty dźwiękowe, które mają dla nich sens. Wyjmij „ Dyskusję programisty ” z dyskusji i zamień go na „ Menedżer mowy ”. Udawaj, że masz 30-sekundową przejażdżkę windą, aby zdobyć punkt.

Miałem sytuację, w której mój szef był piechotą piechoty morskiej. Powtarzałem mu, że potrzebuję narzędzi programowych i szkolenia komputerowego dla moich Marines, aby być bardziej produktywnym. Nie zrozumiał. W końcu pewnego dnia poszedłem do jego biura i powiedziałem mu, że wszystko poszło nie tak.

Powiedziałem coś do skutku ... „Gdybym toczył wojnę, używałbym patyków, skał i gałęzi drzew. Potrzebuję granatów, bazooki i karabinów maszynowych”. Dostał wiadomość.

Czy to naprawdę krytyczne?

Rozumiem chęć korzystania z oddzielnych środowisk. Niejasne pytanie brzmi:

Czy migracja starszego systemu jest naprawdę ważna ?

Myślę, że większość technicznie nastawionych ludzi koncentruje się na akademickim pytaniu, która droga jest lepsza, co jest dobre w środowisku akademickim. W biznesie jednak najlepsze nie zawsze wygrywają. Nie twierdzę, że jest to negatywne, ani nie rozpętam wojny z płomieniami. Mam rzeczy oczywiste, czy to, co powinno być oczywiste dla tych z nas, którzy byli w oprogramowaniu branży od kilku lat.

Wszystkie decyzje biznesowe są zazwyczaj podejmowane na podstawie postrzeganego kosztu / korzyści. Pytanie, które prawdopodobnie zadaje firma, brzmi:

Czy koszt dodatkowej inwestycji systemowej i rozwojowej w starszą aplikację jest warty korzyści w porównaniu z umieszczeniem tej samej inwestycji w innym projekcie / produkcie?

Mam i nadal przeprowadzam regularne analizy kosztów i korzyści, aby dokonywać ustaleń nie tylko w migracji / przepisywaniu oprogramowania, ale w codziennych decyzjach, w które zwykle angażuje się potencjalny klient. Przekazałem przepisywanie / migrację starego oprogramowania, ponieważ miało ono ograniczoną żywotność i dlatego wartość.

Rozdzielanie środowisk

Do biznesowych powodów, aby oddzielić środowisk.

• Mniejsze ryzyko w wydaniach i naprawach błędów. Udowodnij to za pomocą liczb. Ile razy produkt zawiódł i kosztował przychody klientów z powodu złego wydania / błędu.
• Mniejsze ryzyko w rozwoju. Przypadkowe zdmuchnięcie dev db różni się od przypadkowego zdmuchnięcia db db produkcji
• Zdolność do wyraźnego oddzielenia ról i dostępu, tj. lepsze bezpieczeństwo. dobrze jest ograniczyć liczbę palców w cieście produkcyjnym
• Zdolność do oddzielania środowisk oraz praktyki i procedury towarzyszące temu stylowi programowania umożliwiają przyszłe wdrożenie w Cloud Systems.
• Oddzielenie środowiska powinno wymusić zwiększenie wydajności w środowiskach replikacji, które mogą być przydatne w skalowaniu zaplanowanym, a także dynamicznym.

Wygląda na to, że masz już wszystkie „właściwe” argumenty. Zamiast tego doświadczasz „czerwonego śledzia”, jeśli chcesz. Lub „gonić marchewkę”

kierownictwo naprawdę nie ma czasu i zainteresowania wysłuchaniem mnie, dopóki nie pojawi się problem krytyczny

To właśnie uważam za prawdziwy problem. Z mojego doświadczenia wynika, że ​​jeśli firma ma słabe praktyki rozwojowe tak słabe, jak to opisujesz. To nie jest po prostu kwestia „nie wiedzieliśmy nic lepszego”. Jest to raczej kompilacja długu technicznego spowodowanego przez zespół zarządzający wyższego szczebla, który nie wie (obchodzi?) O problemach, które przedstawia.

W takich przypadkach dobra rozmowa nie zmieni nagle twojego kierunku. Być może poważna trauma (awaria produktu widoczna dla klienta i bezpośrednio związana ze złymi praktykami), ale jestem pewien, że rozsądne, bystre technologie przed wypróbowaniem rozmowy.

Moją sugestią jest albo ssać i brać rzeczy takimi, jakie są, lub szukać nowej pozycji.

Ile grup osób planuje jednocześnie pracować nad aplikacją? Zwykle widziałem jedno środowisko dla każdej grupy ludzi. Są to programiści (dostają środowisko DEV i środowisko integracji DEV - niektórzy twierdzą, że nie jest to w 100% konieczne, powiedziałbym, że różni się w zależności od projektu), dwa środowiska testowe (jedna grupa testerów wykonuje bardzo szczegółowe testy, druga dla testerzy QA wysokiego poziomu - zwykle są to użytkownicy biznesowi, a nie przeszkoleni testerzy). Zwykle istnieje również izolowane środowisko testowania wydajności (dzięki czemu można testować ogromne ilości danych, symulować ogromne ilości użytkowników itp. G).

Dlaczego wszystkie te środowiska? Różne grupy mogą więc testować różne funkcje bez stawiania sobie czoła. Jeśli programiści i testerzy pracują w tym samym środowisku, to koszmar: tester może otworzyć defekt funkcji, która jest aktywnie zmieniana co minutę przez programistę. Jeśli istnieją dwa poziomy testowania, mogą skupić się na różnych czynnościach i nie martwić się wzajemnym zepsuciem danych. Posiadanie izolowanego środowiska wydajności pozwala na uruchamianie testów, które mogą zawiesić maszynę, ale jeśli jest izolowane, nie będzie to miało wpływu na innych testerów.

Gdy zbyt wiele osób próbuje robić zbyt wiele różnych rzeczy w tym samym środowisku, kończy się to marnowaniem czasu, gdy jedna grupa czeka na zakończenie testu innej grupy, aby mogli uruchomić swój. A to marnuje czas, a zmarnowany czas może prowadzić do zmarnowanych pieniędzy, co, jak zauważył Stargazer712, może stanowić najsilniejszą argumentację.

Innym powodem (nie tak powszechnym) są dane: jeśli aplikacja ma wrażliwe dane osobowe lub dane karty kredytowej, zwykle nie można tego umieścić w środowiskach testowych, a wymagania dotyczące maskowania są zwykle inne niż środowiska jakości i produkcji.

Wygląda na to, że włożyłeś wiele wysiłku w zmianę kulturową w miejscu pracy. Jest to wielkie osiągnięcie, ponieważ zmiana jest trudna w najlepszym momencie, ale zmiana kulturowa nie polega tylko na zmianie umysłu ludzi, ale na zmianie nawyków, łamaniu uprzedzeń, a ostatecznie na otwieraniu potencjalnie zamkniętych umysłów na większe możliwości. Pytanie, które zadajesz sobie w tym momencie, brzmi: „Co przegapiłem?”. Prostą odpowiedzią jest to, że możesz nie być w pełni zaangażowany w zarządzanie.

Uzyskanie wpisowego od zarządzania jest łatwe, ale jeszcze trudniejsze jest uzyskanie akceptacji. Niezależnie od argumentów dotyczących pieniędzy itp., Rzeczywistość jest taka, że ​​musisz mieć wpływ na pogląd kierownictwa na priorytet. Twój menedżer będzie miał budżet i będzie chciał wykazać, że budżet został wykorzystany rozsądnie i zgodnie z wartościami i priorytetami firmy. Niektóre z tych priorytetów będą miały charakter fiskalny, ale inne będą dotyczyły innych potrzeb. W niektórych przypadkach może to oznaczać smarowanie dłoni innych menedżerów, aby uzyskać awans, którego zawsze chciał szef. Jednak w większości przypadków prawdopodobnie chodzi o znalezienie sposobów na zdobycie większej liczby firm lub poprawę relacji z partnerami i klientami. Jeśli nie możesz przedstawić swojego argumentu na tych warunkach, będziesz mógł posunąć się tak daleko, zanim znajdziesz się w impasie.

Sugeruję, aby spróbować uzasadnić produktywność i jej wpływ na budżet, jak sugerowali inni, ale także uzasadnić priorytety firmy i jej bezpośredni wpływ na relacje firmy z innymi firmami.

Oto jeden: testowalność.

Posiadanie środowiska testowego daje swobodę wykonywania testów w bazie danych, których nie zaleca się przeprowadzać w środowisku produkcyjnym.

Chcesz zmienić sposób, w jaki twoja organizacja rozwija swoje oprogramowanie? Zapomnij o martwieniu się o „powody” dla „robienia rzeczy inaczej”. Ludzie nie zmieniają zachowania z powodu racjonalnych argumentów. Zmieniają się z powodu psychologicznego wpływu na ich nawyki.

Więc gdzie ja z tym idę?

Chociaż czasami można z powodzeniem zmienić zachowanie organizacji poprzez argumentację, istnieją inne taktyki, które działają lepiej. Obejmują one:

• Wsparcie oddolne: znajdź JEDNEGO innego „starszego” programistę, który zechce dać ci szansę. Współpracuj z nim i zmieniaj sposób działania. Nie ogłaszaj zmiany. Po prostu dokonaj zmiany. Jeśli ktoś cię o to zapyta, po prostu powiedz „O tak, właśnie tak to robimy”.

• Przejmij odpowiedzialność. Zgłaszaj się na ochotnika, aby zająć się wdrożeniami starszych osób. Zachowuj się, jakbyś to uwielbiał. Z przyjemnością zrzekną się tej odpowiedzialności. Następnie uruchom go tak, jak chcesz.

• Obwiniaj właściwych ludzi za ich błędy. Następnym razem, gdy do produkcji zostanie wprowadzony starszy błąd aplikacji z powodu mechanizmu wdrażania z epoki kamienia, zwróć na to uwagę. Zrób to subtelnie ... Nie w wiadomości e-mail. Następnym razem, gdy będziesz na spotkaniu z menedżerem, podaj od niechcenia przykład przyczyny, dla której wdrożenie było problematyczne. „Tak, pamiętasz, jak wspinaliśmy się w zeszły piątek z powodu błędu Foo, który Bob wprowadził do produkcji? Tak, to był dużo zmarnowanego wysiłku!”

• Ułatw to, aby zrobić to lepiej. Spójrz na przykład na iPhone'a. Jest na nim JEDEN przycisk. (Cóż, dwa). Jest bardzo łatwy do włączenia. Spraw, by wdrożenie w wielu środowiskach było głupie łatwe. Uprość to wszystkim menedżerom!

Jest to bardziej problem, gdy zaczynasz zajmować się połączonymi lub starszymi systemami, systemami, od których firma musi działać i być dokładna. Jest to ważne, ponieważ musi istnieć segregacja między etapami, jest to powód, dla którego nie DEV na PROD, ponieważ może potencjalnie spowodować straty warte miliony dolarów w straconym czasie .

Zawsze wykonujemy DEV -> QA -> PROD (czasami te kroki są podzielone na mniejsze części) z identycznym sprzętem za nimi. Bieżące dane produkcyjne są zawsze przekazywane z PROD do QA do DEV.

DEV: ma być piaskownicą programistyczną, w której rzeczy są wypróbowywane, iterowane i pobijane na dowolnych danych w tym środowisku, nigdy nie należy im ufać, i są regularnie niszczone przez programistów po prostu szukających sposobów rozwiązania problemu.

QA: Gdy Twoi programiści będą zadowoleni z testów jednostkowych, nadszedł czas, aby grupa testowa zajęła się tym. Uruchamiają przypadki testowe, testy wydajności i znajdują błędy. Te błędy / ulepszenia są przekazywane do DEV, a cykl trwa, dopóki wszyscy nie będą zadowoleni.

PROD: Po przejściu do tego etapu należy upewnić się, że kod działa w połączeniu z bieżącymi danymi, a grupa QA / użytkownicy biznesowi są zadowoleni z wdrożenia. Jeśli wszystko zrobiłeś poprawnie, powinieneś po prostu móc zaktualizować kod i skończyć z nim.

W ten sam sposób nigdy nie wypuszczasz nieprzetestowanego produktu klientom, nigdy nie powinieneś wypuszczać nieprzetestowanego kodu do środowiska produkcyjnego.

Jeśli firma nie będzie skłonna zainwestować czasu, aby zrobić to właściwie, zwróci 10-krotny koszt konserwacji awaryjnej i błędów.

Jako mały przykład: mieliśmy jedną firmę, która postanowiła samodzielnie wprowadzić zmiany w raporcie produkcyjnym. Nikt nie wiedział, że to się zmieniło, dopóki nie pojawiliśmy się w celu rozwiązania różnych problemów w ciągu roku lub dwóch.

Kiedy wskazaliśmy na nieprawidłowość w raporcie, twarz dyrektora finansowego zrobiła się biała, okazało się, że tracili około 250 000 $ na kwartał z powodu szybkiej zmiany.

Zdarza się częściej niż myślisz, jeśli nie możesz sobie pozwolić na prawidłowe wykonanie tej czynności, nie rób tego.

Zarządzanie ma duży wpływ na sukces firm produkujących oprogramowanie i produktów programowych, które były wymagane do wygenerowania tych środowisk. Weźmy przykład twojego projektu. Jeśli twoje oprogramowanie jest rozwijane na dużą skalę, to jeśli nie zarządzasz wymaganiami projektu, kontrolą procesu, wersjami testowymi itp., Istnieje ryzyko niepowodzenia. aby istniało zarządzanie projektami.

W pewnym stopniu zgadzam się z @ Stargazer712, że twoje oświadczenie wskazuje na znaczenie pieniędzy, ale sprawdź następujące oświadczenie, które otrzymałem z książki Marca Hamiltona na temat rozwoju oprogramowania: Building Reliable Systems (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Po przeanalizowaniu wszystkich tych czynników; moja opinia na temat twojego pytania jest taka, że ​​Single Environment nie da ci oszczędności, będzie to proces długoterminowy do ukończenia projektu / oprogramowania. Środowiska rozproszone pozwolą zaoszczędzić czas i przychody, ponieważ dowiedziałem się i zobaczyłem z własnego doświadczenia, że ​​stało się to z firmami tworzącymi oprogramowanie, od których zacząłem swoją działalność.

Istnieje wiele artykułów wykazujących, że bez względu na sukces, sprawdź ten Organizowanie udanego rozwoju oprogramowania

Każda osoba w organizacji ma określone umiejętności, które są zazwyczaj mierzone w oparciu o formalne lub nieformalne wskaźniki wydajności prowadzące do nagród (wynagrodzeń) jako zachęt do przyszłych wyników. Ludzie w organizacji ustalają swoją kulturę - wzorce zachowań i wartości, które są ogólnie uznawane za przyjęte.

Ogromny zestaw programistów będzie walczył, a ostatecznie nie osiągnie swoich celów, jeśli będzie musiał spędzić cały swój czas na walce z niewłaściwą strukturą organizacyjną.

Wiele startupów programowych zaczyna życie od kilku programistów pracujących w garażu. Na tym etapie historii firmy nie jest wymagana żadna struktura organizacyjna, ale struktura organizacyjna nadal istnieje. Na przykład w 1977 r., Kiedy Bill Gates i Paul Allen utworzyli spółkę i oficjalnie nazwali ją Microsoft, firma miała minimalną strukturę organizacyjną. Mniej niż tuzin pracowników pracowało w pierwszym biurze Microsoftu w Albuquerque w Nowym Meksyku i wszyscy wiedzieli, kto jest odpowiedzialny. Żadne skomplikowane schematy organizacyjne nie były potrzebne do ustalenia struktury raportowania wszystkich. Jednocześnie wszyscy pracownicy znali swoją rolę w firmie i to, co starali się osiągnąć. Stało się tak, ponieważ każda potrzebna struktura organizacyjna mogła być nieformalnie komunikowana między każdym pracownikiem.

Zapomnij o czasie, pieniądzach, testowalności, jakości ... a może reputacji .

dobre, proste, niezaprzeczalne powody oddzielenia środowisk, które sprawiłyby, że menedżerowie nie mieliby doświadczenia w programowaniu, aby wesprzeć ten pomysł.

Uber niedawno wysłał do github kod zawierający hasła do ich środowiska na żywo , umożliwiając hakerom pobranie wszystkich danych klientów. Uber mówi, że było to naruszenie, wszyscy inni mówią: „nie udostępniaj kluczy do swoich zamków w widoku publicznym. Jeśli ich programiści pracowaliby całkowicie w środowisku deweloperskim, mogliby wydać klucze do swojego środowiska programistycznego na githubie, ale to całkowicie nieszkodliwe To, że te produkcyjne zostały wydane, pokazuje, jak kiepska jest ta idea działania dewelopera w środowisku produkcyjnym.

Po prostu przypomnij swojemu menedżerowi, że błędy się zdarzają, więc sposobem, aby uniknąć ciągnięcia go przed dyrektora generalnego, który ma dostać grilla przed dziennikarzami i wyśmiewanego przez publiczność techniczną, jest podjęcie prostych, oczywistych kroków, aby zapobiec tym katastrofalnym błędom. te.

Wygląda na to, że musisz pracować w wielu różnych środowiskach, a konfiguracja „środowiska” kosztuje dużo czasu.

Powinieneś mieć jak najmniejszą liczbę różnych „środowisk” , z których możesz uciec, ale być w stanie klonować wiele kopii z tylu powodów, ile chcesz i ty (i „firma” oznacza konfigurację systemu)!

Optymalnie jedynymi różnicami powinny być:

1. Rozmiar (minimalny, zalecany, największy obsługiwany / testowany);
2. Inscenizacja i produkcja nie mają narzędzi programistycznych
3. Produkcja jest chroniona przed przypadkowym zastąpieniem danych
4. Możesz bardzo łatwo ładować dane demo, testować lub [anoymizowane] dane klientów do serwerów programistycznych lub testowych

NASTĘPNIE pytanie o to, ile i jakie testy należy przeprowadzić, to ocena ryzyka / kosztów i decyzja podjęta na poziomie przedsiębiorstwa, ponieważ to cała firma ucierpi, jeśli znaczące usterki dostaną się do szeregu klientów .

Późniejsza edycja: To skłoniło mnie do zracjonalizowania moich konwencji nazewnictwa za pomocą moich produktów internetowych (dzięki za pytanie). Zdecydowałem się na cztery „środowiska”, w których testowanie jest podzielone między qa (minimalna pojedyncza warstwa tylko do testowania funkcjonalności) i testowanie (ta sama architektura co produkcja, do testowania obciążenia / wydajności / wolumenu).

Jedyną prawdziwą różnicą w zaopatrzeniu jest to, że produkcja / przemieszczanie instaluje DB w oddzielnym systemie, którym kontroluję, w których grupach znajdują się różne serwery. Qa / dev mają role serwera WWW i db. Równoważenie obciążenia odbywa się przez chmurę.

Mam również zmienną ENV_NO, która jest przekazywana do systemów, dzięki czemu mogę wybrać tyle przykładów „qa” lub „staging”, ile zechcę.

Tak więc, aby skonfigurować drugie środowisko qa, w tym moją ostatnią kopię zapasową z live, komendy będą następujące:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Wreszcie mam jeden dodatkowy (opcjonalny) serwer o nazwie „tylko do odczytu” jako ostatnia siatka bezpieczeństwa przed uderzeniem w ziemię. Jest obsługiwany jak system qa, ale z wyłączonymi funkcjami tworzenia kopii zapasowych i aktualizacji w nocy (oprogramowanie jest również aktualizowane do ostatniej nocy).

Wykorzystuje podejście „Wszystkie jajka w innym koszyku”: Jest wyposażony w inną rejestrację lokalizacji / DNS, hosta DNS, dostawców usług hosta systemowego. Jest to ostateczna / ostatnia siatka bezpieczeństwa, więc jeśli wszystko wybuchnie w płomieniach, możesz przynajmniej dostać się do danych do ostatniej nocy. Skrypty udostępniania izolują różnicę między różnymi dostawcami, więc 99% jest takie samo, tylko flaga tylko do odczytu. Moduł równoważenia obciążenia Cloudflare przekieruje ruch do witryny tylko do odczytu, jeśli wszystkie działające serwery ulegną awarii.

Jeśli chodzi o wprowadzanie zmian, będziesz mieć szczęście, że będziesz mieć kogoś, kto tylko wysłucha Twojej profesjonalnej opinii i wprowadzi sugerowane zmiany.

Z mojego doświadczenia wynika, że ​​za każdym razem, gdy musiałem dokonać poważnej zmiany, musiałem ją uzasadnić pod względem oszczędności, jakie przyniesie firma. Na przykład wprowadzenie ReSharper do potoku programowania było dość łatwe, ponieważ mogłem powiedzieć coś na marginesie:

ReSharper kosztuje około 50 £ na programistę. Średni koszt programisty rocznie wynosi 40 tys. Funtów. ReSharper powinien zwiększyć produktywność programistów o co najmniej 20%, biorąc pod uwagę jego pełny potencjał. Powiedzmy, że programista spędza 75% swojego czasu na pisaniu kodu w IDE. 75% z 40 tys. To 30 tys. 30 tys. Funtów to obecnie koszt produktywności programisty. Dodatkowy procent wydajności (1%) rocznie kosztuje 300 GBP. Aby uzyskać dodatkowe 20% wydajności, firma musiałaby wydać 6 tys. Funtów.

Jeśli spojrzysz na to z innej perspektywy, możesz powiedzieć, że możesz zatrudnić kogoś innego i uzyskać dodatkowe 20% wydajności za 6 tys. Funtów, lub możesz uzyskać ten sam wynik, wydając 50 funtów na licencję ReSharper. Gdy liczby znajdą się przed firmą, decyzja będzie łatwa do podjęcia.

Teraz, jeśli chodzi o pytania dotyczące posiadania wielu środowisk, wystarczy znaleźć sposób obliczenia, ile kosztuje firma każdego roku, aby mieć takie środowiska.

Możesz poprosić innych programistów o śledzenie godzin spędzonych co tydzień na konfigurowaniu aplikacji do programowania, wdrażania itp. Na przykład dziesięć godzin czasu starszego programisty może kosztować biznes 500 funtów. To 10 godzin, które można przeznaczyć na rozwój lub coś znacznie ważniejszego. Zbierasz dane przez pewien czas i zapewniasz biznesowi roczny koszt.

Osobiście nienawidzę tego rodzaju polityki, ale jest to powszechne i musimy z tym żyć.