Jak mogę zautomatyzować wdrożenia produkcyjne, nie odczuwając skrajnego niepokoju?

W naszym sklepie używamy SVN do kontroli źródła i CruiseControl dla CI do obsługi automatycznych kompilacji i wdrożeń w naszych środowiskach programowania, testowania i integracji.

Wszystko to działa płynnie, jednak ze względu na ograniczenia sprzętowe i zasobowe nasze środowisko integracyjne nie jest środowiskiem równoważącym obciążenie 2 serwerów, podobnie jak nasze środowisko produkcyjne. Podczas gdy wszystko inne jest równe, byłaby to jedyna różnica między naszymi środowiskami integracji i produkcji (chociaż duże!)

Teoretycznie różnicą jest nieco inna konfiguracja naszych serwerów aplikacji, a skrypt wdrażania musiałby po prostu upuścić artefakty kompilacji na dwa serwery zamiast tylko jednego, ale dlaczego tak denerwuję się zautomatyzowaniem naszych wdrożeń produkcyjnych ?!

Generalnie nie jestem maniakiem kontroli, ale zawsze czuję nienasyconą potrzebę ręcznego wdrażania produkcji na produkcję. Słyszałem od kolegów, że jest to na ogół naprawdę BAD Thing ™, ale nie udało się tego uzasadnić.

Wiem, że kiedy robię to ręcznie, WIDZĘ, że fizycznie kopiuję prawidłowe pliki, fizycznie zamykam serwery aplikacji i upewniam się, że zostały pomyślnie zamknięte, fizycznie uruchamiam ponownie serwery, a następnie fizycznie sprawdzam dzienniki, aby utworzyć na pewno zaczęło się dobrze, a wdrożenie zakończyło się powodzeniem. To daje mi spokój.

Jakie są argumenty przeciwko tym argumentom OR dla automatycznego wdrażania produkcji skryptowej?

Istnieje kilka oczywistych argumentów przeciwko temu.

1. Co się stanie, jeśli odejdziesz. Czy wszystkie te informacje są dokładnie udokumentowane, czy też przeważnie są w twojej głowie? Zautomatyzowane skrypty są znacznie lepszym miejscem do przejęcia przez kogoś innego.

2. Wszyscy popełniają błędy. Nadejdzie czas, kiedy osoba przeprowadzająca rozlokowanie będzie zmęczona, nie zwracając uwagi na nic. Tak, idealnie, wdrożenia są przeprowadzane tylko w szczęśliwym spokojnym miejscu z dużą ilością czasu. W praktyce można się spieszyć i zestresować podczas próby wprowadzenia pilnych poprawek. Jest to najbardziej prawdopodobny czas na popełnienie błędu, a także najbardziej kosztowny. Jeśli wdrożenie jest pojedynczym skryptem, wówczas prawdopodobieństwo pomyłek jest ograniczone.

3. Czas. W miarę jak wdrożenia stają się coraz bardziej skomplikowane, ilość potrzebnych działań rośnie. Skrypty wymagają jedynie rozpoczęcia, ręcznego sprawdzenia, a następnie ręcznego przełączenia (można to również zautomatyzować, ale podzielam część paranoi :).

Możesz uzyskać to, co najlepsze z najlepszych światów: spokój ducha dzięki weryfikacji procesu i niezawodności automatyzacji.

Skryptuj wdrożenie. Następnie przejrzyj i ręcznie sprawdź, czy procesy zostały uruchomione, pliki usunięte itp. Innymi słowy, napisz własny skrypt kontroli jakości, aby sprawdzić, czy zautomatyzowane kroki 1 - X rzeczywiście miały miejsce.

Myślę, że kluczem jest tutaj: dlaczego uważasz, że nie możesz napisać skryptu procesu weryfikacji?

Moje skrypty wdrażania nie tylko wypychają archiwów i ponownie uruchamiają usługi. Drukują wiele kolorowych informacji na każdym etapie wdrażania i na końcu dostarczają mi podsumowania wydarzeń. Daje mi to do zrozumienia, że ​​procesy są uruchomione i że strona główna podaje kod statusu 200 oraz że wszystkie maszyny i usługi widzą się dobrze. Następnie mam osobną usługę, która nie jest częścią skryptu, który monitoruje pliki dziennika, błędy na poziomie 4xx i 5xx oraz kluczowe parametry witryny. Następnie zaczyna krzyczeć na mnie za pośrednictwem każdego możliwego medium (e-mail, wiadomość tekstowa i alarmy), jeśli występują drastyczne skoki negatywnych efektów.

Pomiędzy tym a serwerami CI uruchamiającymi testy, dosłownie wdrażam i zapominam na tym poziomie automatyzacji. Nawet nie przeglądam ani jednej strony w witrynie po wypchnięciu ze względu na to, jak niezawodny jest teraz ten proces, co nie tylko pozwala mi wdrażać tak często, jak chcę, ale pozwala nowemu deweloperowi projektu dokonać aktualizacji na żywo strona w ciągu kilku minut od wejścia na pokład. W przeszłości powodowałem nawet automatyczne wdrażanie serwerów CI do produkcji po zatwierdzeniu w gałęzi master / trunk, która przechodzi wszystko. Tak jestem pewien swoich narzędzi.

Ty też powinieneś być.

Czy uruchamiasz również swoje maszyny produkcyjne ze zdalnym debugowaniem i ręcznie je przechodzisz? Zbudowanie odpowiedniego skryptu jest identyczne jak napisanie programu. Wszystkie problemy, które masz, wskazują na rzeczy, na które trzeba będzie uważać i sprawdzać.

Jeśli coś pójdzie nie tak, należy przejść przez odpowiednie procedury wycofania i wysłać wiadomość. Wszystko, co się dzieje, można zapisać na później. Możesz kontrolować wersje skryptów i konfigurować przypadki testowe.

Ale jeśli ręcznie uruchamiasz polecenia, nie masz żadnej z tych zalet. Zamiast tego masz listę wad.

• Nie masz dobrego dziennika, historia powłoki się nie liczy
• Nikt inny nie wie jak to zrobić
• Kroki gubią się
• Kontrole są tylko czasami wykonywane
• Niektóre elementy do wdrożenia mogą zostać pominięte, robiłem to już wcześniej
• To trwa znacznie dłużej
• Możesz zostać przerwany podczas procesu

Właściwy skrypt powinien być prawie identyczny, jak jeśli wszystko wpisałeś w powłoce. Jest to jeden z powodów, dla których mamy skrypty bash. Jeśli ufasz tym, co robisz, dlaczego nie możesz nagrać wszystkiego i dokręcić? Lepsze sprawdzanie, szybsze sprawdzanie, więcej kontroli może się zdarzyć, ponieważ komputer to robi.

Rozumiem, że trochę się denerwuję, próbując czegoś nowego w środowisku produkcyjnym. Uważanie na potencjalną katastrofę to Good Thing ^TM .

Zautomatyzowane skrypty są również dobrą rzeczą ^TM i pod warunkiem, że podchodzisz do nich ostrożnie, powinieneś być w stanie zminimalizować niebezpieczeństwo i zmniejszyć swój strach. Tak więc moja rada jest następująca;

• Przygotuj (i poćwicz na env integracji) listę kontrolną / zestaw testów, abyś mógł szybko dowiedzieć się, czy zadziałało i co się stanie, jeśli coś pójdzie nie tak. Pełne rejestrowanie może w tym pomóc.
• Utwórz kopię zapasową wszystkiego. Przygotuj i przećwicz ręczne cofanie, aby móc odzyskać, jeśli pójdzie źle.
• Przetestuj jak najwięcej, zanim zrobisz to naprawdę na prod. Wygląda na to, że jesteś dobrym rozwiązaniem dzięki env integracji.
• Po raz pierwszy spróbuj, zrób to przy niskim profilu, niskiej zmianie wpływu. Coś w rodzaju drobnej aktualizacji lub poprawki. Chodzi o to, aby zminimalizować opad, jeśli pójdzie nie tak. Nie wybieraj głównego profilu o wysokim profilu (gdzie obserwują go prezes i wszyscy twoi konkurenci) podczas pierwszego uruchomienia.

Gdy zdobędziesz kilka udanych przebiegów, Twoje zaufanie wzrośnie, a wkrótce będziesz się zastanawiać, jak kiedykolwiek udało Ci się ręcznie wdrożyć.

Oto największy argument przeciwko ręcznym wdrożeniom do produkcji: jesteś człowiekiem i popełnisz błędy. Niewątpliwie będą chwile, kiedy zapomnisz zrobić coś, co spowoduje u ciebie smutek. Dobrze napisane automatyczne wdrażanie nie ma tej samej tendencji. To prawda, że ​​nadal możesz mieć pomieszane wdrożenia produkcyjne, ale dzieje się tak, ponieważ Twoje automatyczne wdrożenie zawiera błędy, które należy rozwiązać.

Z mojego doświadczenia wynika, że ​​zalety automatycznych wdrożeń w produkcji są ogromne. Najważniejsze jest to, że można bawić się w weekendy zamiast próbować przejść przez ręczny proces wdrażania, który nie będzie współpracował.

To powiedziawszy, oto kilka kluczowych wskazówek do automatyzacji wdrożeń produkcyjnych:

• Nie rób tego wszystkiego naraz! Zacznij powoli pisać automatyczne wdrożenia. Najpierw skonfiguruj osobne środowisko nieprodukcyjne i spróbuj zautomatyzować tam wdrożenia. Po zbudowaniu zaufania do zautomatyzowanych wdrożeń możesz zacząć myśleć o przeprowadzaniu wdrożeń produkcyjnych
• Zacznij wypuszczać i wdrażać bardzo często! Znacznie łatwiej jest wykonywać zautomatyzowane wdrożenia, gdy nie masz 4 miesięcy kodu czekającego na wydanie. Wydawaj małe funkcje i poprawki błędów wiele razy w tygodniu. Korzyści z tego stylu wydania nie można lekceważyć!
• Polegaj na automatycznych testach, aby mieć pewność, że Twoje środowisko produkcyjne będzie działać. Znowu wymaga to czasu, ale jest bardzo ważne. Zautomatyzowane testy są zawsze lepsze niż ręczne testy akceptacyjne. Oczywiście, ręczne testy akceptacyjne są w porządku, ale testy automatyczne mogą pomóc ci wiedzieć, czy powinieneś wdrożyć w produkcji, czy nie. Są kluczem, który umożliwia cały proces automatycznej, ciągłej dostawy. Jeśli testy nie przejdą pomyślnie, wiesz, że nie możesz wdrożyć do produkcji.

Uruchom skrypty na serwerze na żywo. Będzie działać, a gdy zobaczysz, że działa dobrze kilka razy, będziesz w pełni pewny.

Poważnie, częściej popełniasz błędy niż skrypt wdrażania.

Ludzie nie popełniają błędów, ludzie.

Napisz swój skrypt raz i dokładnie go sprawdź, przejdź przez linię po linii. Od tego momentu możesz być pewien, że za każdym razem będzie działać.

Zrób to ręcznie, a na pewno popełnisz błędy. Może napisałeś, wszystko, co musisz zrobić, w dół, ale tak łatwo popełnić błąd. Musisz skopiować wszystkie pliki oprócz pliku web.config? Możesz się założyć, że kiedyś go zastąpisz. Skrypt nigdy nie popełni tego błędu.

Jak mogę zautomatyzować wdrożenia produkcyjne, nie odczuwając skrajnego niepokoju?

Ogromny niepokój, jakiego można doświadczyć podczas automatyzacji wdrożeń produkcyjnych, najprawdopodobniej opiera się na dwóch przekonaniach:

1. Któregoś dnia jeden z etapów wdrażania zakończy się niepowodzeniem i ty lub inny człowiek jesteś w stanie szybko zregenerować się po awarii, podczas gdy skrypt automatyczny może to przeoczyć.

2. Pomijane niepowodzenie w produkcji ma dramatyczne konsekwencje.

Niewiele można zrobić z 2., oprócz unikania awarii, więc skupmy się na 1.

Tanim rozwiązaniem nieznacznie ulepszającym istniejące byłoby zastosowanie półautomatycznej procedury wdrażania, czekającej na sprawdzenie poprawności na końcu każdego etapu instalacji. Dzięki półautomatycznemu rozwiązaniu będziesz cieszyć się korzyściami z pełnego automatycznego rozwiązania, takimi jak spójność i odtwarzalność, a jednocześnie będziesz mieć szansę monitorowania postępów i odzyskiwania po błędach, tak jak obecnie.

Półautomatyczny skrypt i jego biotop (testy regresji itp.) Mogą również służyć jako nośnik wiedzy, którą gromadzisz na temat awarii, które zdarzają się w procedurze instalacyjnej i sposobów na ich odzyskanie.

Podoba mi się to, że możesz przetestować wdrożenie na etapie testowania lub kontroli jakości i wiedzieć, że kiedy uruchomisz go na prod, będą miały miejsce dokładnie te same kroki.

Gdy robisz to ręcznie, łatwiej jest zapomnieć o kroku lub zrobić to w niewłaściwej kolejności.

... ze względu na ograniczenia sprzętowe i związane z zasobami nasze środowisko integracyjne nie jest środowiskiem równoważącym obciążenie 2 serwerów, jak nasze środowisko produkcyjne. Podczas gdy wszystko inne jest równe, byłaby to jedyna różnica między naszymi środowiskami integracji i produkcji (chociaż duże!)

Biorąc pod uwagę powyższe, prawdopodobnie byłbym tak niespokojny jak ty.

Kiedyś sprawdziłem i przetestowałem zautomatyzowany skrypt, który wdraża się do SLB i mam wrażenie, że bez wstępnych testów przy konfiguracji z równoważeniem obciążenia wolę ręcznie robić rzeczy.

Oprócz konfiguracji testowania podobnej do prod, kolejną rzeczą, która miała znaczący wpływ na mój spokój ducha, jest fakt, że wdrożenie prod zostało wykonane przez inny zespół programistów - przez facetów, których jedynym zadaniem było utrzymanie środowiska produkcyjnego.

• W jednym z projektów pomagałem im we wdrożeniu jako przedstawiciel zespołu programistów. Przed wdrożeniem zapoznali się z moimi instrukcjami, a podczas wdrażania siedziałem online gotowy, by skonsultować się, jeśli coś pójdzie nie tak. Wtedy nauczyłem się doceniać to oddzielenie .
   
  Nie żeby były szybsze (dlaczego mieliby? Testowałem wdrożenia 5x-10x częściej niż one). Duża różnica była w centrum uwagi. Mam na myśli, że moja głowa jest zawsze obciążona „głównymi” rzeczami - kodowaniem, debugowaniem, nowymi funkcjami - jest po prostu zbyt wiele zakłóceń, aby właściwie skoncentrować się na wdrożeniu. W przeciwieństwie do tego, ich głównymi sprawami były tylko utrzymanie produkcji i byli na tym skupieni.
   
  To niesamowite, o ile lepiej działa mózg, gdy jest skupiony. Ci goście byli o wiele bardziej uważni, popełniali o wiele mniej błędów niż ja. Po prostu wiedzieli te rzeczy lepiej ode mnie. Nauczyli mnie nawet jednego lub dwóch rzeczy, które ułatwiły moje własne wdrożenia testowe.

Zbuduj skrypt wdrażania, którego używasz do przenoszenia kodu w dowolnym środowisku. Korzystamy z tego samego procesu wdrażania, aby przenieść kod na dev, qa, inscenizację i wreszcie produkcję. Ponieważ wdrażamy wiele razy dziennie dla programistów i codziennie w ramach kontroli jakości, zyskaliśmy pewność, że skrypty wdrażania są prawidłowe. Zasadniczo przetestuj to do diabła, używając go często.

1. Uproszczać. Twoim procesem zmian powinny być pliki rsync, skrypt SQL, nic więcej.
2. Automatyzacja.
3. Test.

Powodem zautomatyzowania jest uzyskanie czegoś, co jest testowalne, powtarzalne i które możesz zaufać, że będzie działać poprawnie w każdej oczekiwanej sytuacji.

Nadal musisz mieć plan wycofania się, jak w przypadku każdej zmiany w dowolnym kontekście, i powinien on również zostać zautomatyzowany.

Nadal będziesz chciał obserwować przebieg procesu, jeśli środowisko jest naprawdę wrażliwe, ale nigdy nie rób tego ręcznie, ponieważ nie można go odtworzyć.

Całkowicie możliwe jest użycie skryptów automatyzacji do wdrożenia w środowiskach produkcyjnych. Jednak, aby robić to niezawodnie, musisz być w stanie zrobić kilka rzeczy.

1. Niezawodnie przywróć poprzednią wersję.
2. Uzyskaj pozytywne potwierdzenie, że wdrożenie zostało pomyślnie zastosowane i odpowiada na prawidłowy ruch.
3. Mają porównywalne środowiska programowania i kontroli jakości, które również używają tych samych skryptów.

Skrypty mają pewne zalety, takie jak: nigdy nie umkną komendzie, ponieważ jest druga i zmęczona.

Jednak skrypty mogą i nadal będą zawieść. Czasami awaria polega na zaprojektowaniu skryptu, ale może być również spowodowana awarią sieci lub zasilania, uszkodzonym systemem plików, brakiem pamięci .....

Dlatego ważne jest, aby po uruchomieniu skryptu była również przestrzegana zdefiniowana faza testowa, która sprawdza, czy nowe wdrożenie jest uruchomione, działa i obsługuje żądania, zanim zostanie włączony ruch na żywo.

1. po raz pierwszy weź większe okno do wdrożenia, jeśli coś pójdzie nie tak

2. Podziel proces wdrażania na dwie części. za. Kopia zapasowa (ręczna) - powinno to zapewnić pewność, że podczas wdrażania coś pójdzie nie tak

   b. Wdrażanie (automatyczne)

gdy będziesz w stanie wdrożyć z pewnością po raz pierwszy. możesz także zautomatyzować proces tworzenia kopii zapasowej.