Raport będzie mówił o niektórych praktykach DevOps, ale z punktu widzenia programisty. Zazwyczaj wszyscy inżynierowie dołączający do DevOps mają już na swoim koncie kilkuletnie doświadczenie administracyjne. Nie oznacza to jednak, że nie ma tu miejsca dla dewelopera. Najczęściej programiści są zajęci naprawianiem „kolejnego pilnie krytycznego błędu dnia” i nie mają czasu nawet rzucić okiem na pole DevOps. W rozumieniu autora DevOps to przede wszystkim zdrowy rozsądek. Po drugie, jest to szansa na większą skuteczność. Jeśli jesteś programistą, kierujesz się zdrowym rozsądkiem i chcesz być bardziej skutecznym graczem zespołowym, ten raport jest dla Ciebie.
Pozwólcie, że się przedstawię, w pełni przyznaję, że są na sali osoby, które mnie nie znają. Nazywam się Anton Bojko i jestem Microsoft Azure MVP. Co to jest MVP? To jest prezenter widoku modelu. Model-View-Prezenter to dokładnie ja.
Ponadto obecnie zajmuję stanowisko architekta rozwiązań w Ciklum. A niedawno kupiłem sobie taką piękną domenę i zaktualizowałem swój e-mail, który zwykle pokazuję na prezentacjach. Możesz do mnie napisać na adres: me [dog] byokoant.pro. Możesz wysłać mi e-mail z pytaniami. Zwykle im odpowiadam. Tyle, że nie chciałbym otrzymywać drogą mailową pytań dotyczących dwóch tematów: polityki i religii. O wszystkim innym możesz pisać do mnie e-mailem. Minie trochę czasu, odpowiem.
Kilka słów o mnie:
- Zajmuję się tą dziedziną już od 10 lat.
- Pracowałem w Microsoft.
- Jestem założycielem ukraińskiej społeczności Azure, którą założyliśmy gdzieś w 2014 roku. Nadal go mamy i rozwijamy.
- Jestem także ojcem założyciela konferencji Azure, którą gościmy na Ukrainie.
- Pomagam także w organizacji Global Azure Bootcamp w Kijowie.
- Jak mówiłem, jestem Microsoft Azure MVP.
- Często przemawiam na konferencjach. Bardzo lubię przemawiać na konferencjach. W ciągu ostatniego roku udało mi się wystąpić około 40 razy. Jeśli mijasz Ukrainę, Białoruś, Polskę, Bułgarię, Szwecję, Danię, Holandię, Hiszpanię lub dajesz lub wybierasz inny kraj w Europie, jest całkiem możliwe, że udając się na konferencję, której strumień jest poświęcony tematyce chmury, być może zobaczysz mnie na liście prelegentów.
- Jestem także fanem Star Treka.
Porozmawiajmy trochę o Agendzie. Nasz program jest bardzo prosty:
- Porozmawiamy o tym, czym jest DevOps. Porozmawiajmy, dlaczego to jest ważne. Wcześniej DevOps było słowem kluczowym, które wpisywałeś w swoim CV i od razu otrzymywałeś +500 dolarów wynagrodzenia. Teraz musisz w CV wpisać np. blockchain, żeby otrzymać +500 dolarów do swojej pensji.
- A potem, kiedy już trochę zrozumiemy, o co chodzi, porozmawiamy o praktykach DevOps. Ale nie tyle w kontekście DevOps w ogóle, ale o tych praktykach DevOps, które mogą zainteresować programistów. Powiem Ci, dlaczego mogą Cię zainteresować. Powiem Ci, dlaczego w ogóle powinieneś to robić i jak może pomóc Ci odczuwać mniejszy ból.
Tradycyjny obraz, który pokazuje wiele osób. Tak się dzieje w wielu projektach. To wtedy mamy działy rozwoju i operacji, które wspierają nasze oprogramowanie. A te działy nie komunikują się ze sobą.
Być może, jeśli nie czuliście tego tak wyraźnie w działach DevOps i operacyjnych, można wyciągnąć analogię z działami Dev i QA. Są ludzie, którzy tworzą oprogramowanie i są ludzie zajmujący się kontrolą jakości, którzy są źli z punktu widzenia programistów. Na przykład umieszczam mój wspaniały kod w repozytorium, a tam siedzi jakiś łajdak, który zwraca mi ten kod i mówi, że twój kod jest zły.
Wszystko to dzieje się dlatego, że ludzie nie komunikują się ze sobą. I rzucają sobie jakieś pakiety, jakieś aplikacje przez jakąś ścianę nieporozumień i próbują coś z nimi zrobić.
To właśnie ten mur ma zniszczyć kultura DevOps, tj. zmusić ludzi do wzajemnej komunikacji i przynajmniej zrozumienia, czym zajmują się różni ludzie w projekcie i dlaczego ich praca jest ważna.
A kiedy mówimy o DevOps, ktoś powie Ci, że DevOps ma miejsce wtedy, gdy projekt ma ciągłą integrację; ktoś powie, że DevOps jest wtedy, gdy w projekcie wdrażana jest praktyka „infrastruktura jako kod”; ktoś powie, że pierwszym krokiem do DevOps jest rozgałęzianie funkcji i flagi funkcji.
Zasadniczo wszystko to jest prawdą na swój sposób. Ale to tylko ostateczne praktyki, jakie mamy. Zanim przejdę do tych praktyk, sugeruję obejrzenie tego slajdu, który pokazuje 3 etapy wdrażania metodologii Dev-Ops w Twoim projekcie, w Twojej firmie.
Slajd ten ma również drugą nieoficjalną nazwę. Możesz wyszukiwać w Internecie, aby dowiedzieć się, kim są 3 muszkieterowie DevOps. Możliwe, że znajdziesz ten artykuł. Dlaczego 3 muszkieterów? Poniżej jest napisane: ludzie, procesy i produkty, czyli tzw. PPP – Portos, Portos i Portos. Oto 3 muszkieterów DevOps. W tym artykule opisano bardziej szczegółowo, dlaczego jest to ważne i z czym się wiąże.
Kiedy zaczynasz wdrażać kulturę DevOps, bardzo ważne jest, aby wdrażać ją w następującej kolejności.
Na początku trzeba rozmawiać z ludźmi. Trzeba też wyjaśnić ludziom, co to jest i jakie korzyści mogą z tego odnieść.
Nasza konferencja nazywa się DotNet Fest. I jak mi powiedzieli organizatorzy, zaprosiliśmy tu głównie publiczność deweloperów, więc mam nadzieję, że większość osób na sali jest zaangażowana w rozwój.
Porozmawiamy o ludziach, porozmawiamy o tym, co deweloperzy chcą robić na co dzień. Czego chcą najbardziej? Chcą napisać nowy kod, skorzystać z nowatorskich frameworków, stworzyć nowe funkcje. Czego deweloperzy chcą najmniej? Napraw stare błędy. Mam nadzieję, że się ze mną zgodzisz. Tego chcą deweloperzy. Chcą pisać nowe funkcje, nie chcą naprawiać błędów.
Liczba błędów wytwarzanych przez konkretnego programistę zależy od tego, jak proste są jego ramiona i jak bardzo wyrastają z ramion, a nie z kieszeni na tyłku. Niemniej jednak, gdy mamy duży projekt, czasami zdarza się, że nie da się wszystkiego ogarnąć, dlatego dobrze byłoby zastosować pewne podejścia, które pomogą nam napisać bardziej stabilny i wyższej jakości kod.
Czego QA chcą najbardziej? Nie wiem, czy są na korytarzu. Trudno mi powiedzieć, że chcę kontrolera jakości, ponieważ nigdy nim nie byłem. I bez urazy do chłopaków, powiedzą, że mam nadzieję, że nigdy tego nie zrobię. Ale nie dlatego, że uważam ich pracę za bezsensowną i bezużyteczną, ale dlatego, że nie uważam się za osobę, która mogłaby wykonać tę pracę sprawnie, więc nawet nie będę próbował tego robić. Ale z tego, co rozumiem, to, czego QA nie lubi najbardziej, to będzie działać rano, ciągle przeprowadzając jakieś testy regresyjne, wchodząc na te same błędy, które zgłosili programistom 3 sprinty temu i pytając: „Kiedy będziesz , Monsieur D. „Artagnan, napraw ten błąd”. A pan d’Artagnan odpowiada mu: „Tak, tak, tak, już to naprawiłem”. I jak to się dzieje, że naprawiłem jeden błąd, a po drodze zrobiłem 5.
Ludzie, którzy wspierają to rozwiązanie na produkcji, chcą, aby to rozwiązanie działało bez błędów, aby nie musieli restartować serwera w każdy piątek, kiedy wszyscy normalni ludzie idą do baru. Programiści wdrożyli wersję w piątek, administratorzy siedzą do soboty, próbując przygotować i naprawić to wdrożenie.
A kiedy wyjaśnisz ludziom, że ich celem jest rozwiązanie tych samych problemów, możesz przejść do sformalizowania procesów. To jest bardzo ważne. Dlaczego? Ponieważ kiedy mówimy „formalizacja”, ważne jest, abyś przynajmniej gdzieś na serwetce opisał, jak przebiegają Twoje procesy. Musisz zrozumieć, że jeśli wdrażasz na przykład środowisko QA lub środowisko produkcyjne, to zawsze dzieje się to w tej kolejności; na tych etapach przeprowadzamy np. automatyczne testy jednostkowe i testy interfejsu użytkownika. Po wdrożeniu sprawdzamy, czy wdrożenie przebiegło dobrze, czy źle. Ale masz już przejrzystą listę działań, które należy wielokrotnie powtarzać podczas wdrażania do środowiska produkcyjnego.
I dopiero wtedy, gdy Twoje procesy zostaną sformalizowane, zaczniesz wybierać produkty, które pomogą Ci zautomatyzować te procesy.
Niestety bardzo często spotykam się z sytuacją odwrotną. Gdy tylko ktoś usłyszy słowo „DevOps”, od razu sugeruje instalację Jenkinsa, ponieważ wierzy, że gdy tylko zainstaluje Jenkinsa, będzie miał DevOps. Zainstalowali Jenkinsa, przeczytali artykuły „Jak to zrobić” na stronie internetowej Jenkins, próbowali wrzucić procesy do tych artykułów, a potem podeszli do ludzi i nakłonili ich, mówiąc, że w książce jest napisane, że trzeba to zrobić w ten sposób, więc robimy to w ten sposób.
To nie tak, że Jenkins jest złym narzędziem. Nie chcę tego w żaden sposób powiedzieć. Ale to tylko jeden z produktów. Decyzja o tym, jakiego produktu użyjesz, powinna być Twoją ostatnią, a w żadnym wypadku nie pierwszą. Twój produkt nie powinien być napędzany wdrażaniem kultury i podejść. Zrozumienie tego jest bardzo ważne, dlatego poświęcam tyle czasu temu slajdowi i tak długo to wszystko wyjaśniam.
Porozmawiajmy ogólnie o praktykach DevOps. Czym oni są? Jaka jest różnica? Jak je przymierzyć? Dlaczego są ważne?
Pierwsza praktyka, o której mogłeś słyszeć, nazywa się ciągłą integracją. Być może ktoś w projekcie ma ciągłą integrację (CI).
Największym problemem jest to, że najczęściej, gdy pytam osobę: „Czy masz CI w projekcie?” i odpowiada: „Tak”, po czym pytając, czym się zajmuje, opisuje mi absolutnie cały proces automatyzacji. Nie jest to do końca prawdą.
W rzeczywistości praktyka CI ma na celu po prostu integrację kodu napisanego przez różnych ludzi w jakąś pojedynczą bazę kodu. To wszystko.
Oprócz CI zwykle istnieją inne praktyki – takie jak ciągłe wdrażanie, zarządzanie wydaniami, ale o tym porozmawiamy później.
Sam CI mówi nam, że różne osoby piszą kod i kod ten musi być stale integrowany w jedną bazę kodu.
Co nam to daje i dlaczego jest to ważne? Jeśli mamy DotNet, to dobrze, jest to język skompilowany, możemy skompilować naszą aplikację. Jeśli się skompiluje, jest to już dobry znak. To jeszcze nic nie znaczy, ale to pierwszy dobry znak, który możemy przynajmniej skompilować.
Wtedy możemy przeprowadzić jakieś testy, co też jest odrębną praktyką. Wszystkie testy są zielone – to drugi dobry znak. Ale to znowu nic nie znaczy.
Ale dlaczego miałbyś to zrobić? Wszystkie praktyki, o których dzisiaj będę mówił, niosą ze sobą w przybliżeniu tę samą wartość, czyli w przybliżeniu te same korzyści i są też mniej więcej w ten sam sposób mierzone.
Po pierwsze, pozwala przyspieszyć dostawę. W jaki sposób pozwala to przyspieszyć dostawę? Kiedy wprowadzimy jakieś nowe zmiany w naszej bazie kodu, możemy natychmiast spróbować coś zrobić z tym kodem. Nie czekamy, aż nadejdzie czwartek, ponieważ w czwartek wypuszczamy to do QA Environment, robimy to tutaj i tutaj.
Opowiem Wam jedną smutną historię z mojego życia. To było dawno temu, kiedy byłem jeszcze młody i przystojny. Teraz jestem już młoda, piękna, mądra i skromna. Jakiś czas temu brałem udział w projekcie. Mieliśmy duży zespół około 30 programistów. Mieliśmy duży, duży projekt Enterprise, który rozwijał się przez około 10 lat. I mieliśmy różne gałęzie. W repozytorium mieliśmy gałąź, po której chodzili programiści. Była też gałąź, która wyświetlała wersję kodu, która jest w fazie produkcyjnej.
Gałąź produkcyjna była 3 miesiące za gałęzią dostępną dla deweloperów. Co to znaczy? Oznacza to, że gdy tylko pojawi się gdzieś błąd, który trafia do produkcji z winy programistów, ponieważ na to pozwolili, i z winy kontroli jakości, ponieważ go sprawdzili, oznacza to, że jeśli otrzymam zadanie dotyczące poprawki dla środowiska produkcyjnego, to muszę wycofać zmiany w kodzie wprowadzone 3 miesiące temu. Muszę przypomnieć sobie, co miałem 3 miesiące temu i spróbować to naprawić.
Jeśli jeszcze tego nie doświadczyłeś, możesz wypróbować to w swoim domowym projekcie. Najważniejsze jest to, aby nie próbować tego na komercyjnym. Napisz kilka linii kodu, zapomnij o nich na sześć miesięcy, a następnie wróć i spróbuj szybko wyjaśnić, o co chodzi w tych liniach kodu i jak możesz je naprawić lub zoptymalizować. To bardzo, bardzo ekscytujące doświadczenie.
Jeśli mamy praktykę ciągłej integracji, to pozwala nam to sprawdzić za pomocą szeregu zautomatyzowanych narzędzi tu i teraz, gdy tylko napiszę kod. Może to nie da mi pełnego obrazu, ale mimo to usunie przynajmniej część zagrożeń. A jeśli pojawi się jakiś potencjalny błąd, dowiem się o tym już teraz, czyli dosłownie za kilka minut. Nie będę musiał cofać 3 miesięcy. Będę musiał cofnąć się tylko o 2 minuty. Dobry ekspres do kawy nie zdąży nawet zaparzyć kawy w 2 minuty, więc jest całkiem spoko.
Ma to tę wartość, że można je powtarzać wielokrotnie przy każdym projekcie, tj. nie tylko ten, na którym to skonfigurowałeś. Możesz powtórzyć zarówno samą praktykę, jak i sam CI będzie powtarzany przy każdej nowej zmianie wprowadzonej w projekcie. Pozwala to zoptymalizować zasoby, ponieważ Twój zespół pracuje wydajniej. Nie będziesz już mieć sytuacji, w której pojawi się błąd w kodzie, z którym pracowałeś 3 miesiące temu. Nie będziesz już musiał przełączać kontekstu, kiedy będziesz siedzieć i spędzać pierwsze dwie godziny, próbując zrozumieć, co się wtedy wydarzyło i zagłębić się w istotę kontekstu, zanim zaczniesz coś poprawiać.
Jak możemy zmierzyć sukces lub porażkę tej praktyki? Jeśli zgłosisz dużemu szefowi, co wdrożyliśmy w projekcie CI, usłyszy bla bla bla. Wdrożyliśmy, OK, ale dlaczego, co nam to dało, jak to mierzymy, jak poprawnie lub nieprawidłowo to wdrażamy?
Po pierwsze, dzięki CI możemy wdrażać coraz częściej i częściej właśnie dlatego, że nasz kod jest potencjalnie bardziej stabilny. W ten sam sposób skraca się nasz czas na znalezienie błędu i czas na jego poprawienie właśnie dlatego, że tu i teraz otrzymujemy odpowiedź z systemu, co jest nie tak z naszym kodem.
Inną praktyką, którą mamy, jest praktyka testowania automatycznego, która najczęściej towarzyszy praktyce CI. Idą ramię w ramię.
Co tu warto zrozumieć? Ważne jest, aby zrozumieć, że nasze testy są inne. Każdy zautomatyzowany test ma na celu rozwiązanie własnych problemów. Mamy np. testy jednostkowe, które pozwalają nam przetestować moduł osobno, tj. Jak to działa w próżni? To jest dobre.
Posiadamy również testy integracyjne, które pozwalają nam zrozumieć, w jaki sposób różne moduły integrują się ze sobą. To też jest dobre.
Możemy posiadać testy automatyzacji UI, które pozwalają sprawdzić, jak dobrze praca z UI spełnia określone wymagania stawiane przez klienta itp.
Konkretne testy, które uruchamiasz, mogą mieć wpływ na częstotliwość ich przeprowadzania. Testy jednostkowe są zwykle pisane krótko i zwięźle. I można je uruchamiać regularnie.
Jeśli mówimy o testach automatyzacji interfejsu użytkownika, to dobrze, jeśli Twój projekt jest niewielki. Testy automatyzacji interfejsu użytkownika mogą zająć trochę czasu. Jednak zazwyczaj test automatyzacji interfejsu użytkownika w przypadku dużego projektu zajmuje kilka godzin. I dobrze, jeśli jest to kilka godzin. Jedyną rzeczą jest to, że nie ma sensu uruchamiać ich dla każdej kompilacji. Rozsądne jest uruchamianie ich w nocy. A kiedy rano wszyscy przyszli do pracy: zarówno testerzy, jak i programiści, otrzymali coś w rodzaju raportu, że w nocy przeprowadziliśmy autotest interfejsu użytkownika i otrzymaliśmy takie wyniki. I tutaj godzina pracy serwera, który sprawdzi, czy Twój produkt spełnia jakieś wymagania, będzie znacznie tańsza niż godzina pracy tego samego inżyniera QA, nawet jeśli jest to Junior QA Engineer, który pracuje za jedzenie i podziękowania. Niemniej jednak godzina pracy maszyny będzie tańsza. Dlatego warto w to inwestować.
Mam kolejny projekt, nad którym pracuję. Nad tym projektem mieliśmy dwutygodniowe sprinty. Projekt był duży, ważny dla sektora finansowego i nie można było popełnić błędu. Po dwutygodniowym sprincie po cyklu rozwoju nastąpił proces testowania, który trwał kolejne 4 tygodnie. Spróbuj wyobrazić sobie skalę tragedii. Przez dwa tygodnie piszemy kod, potem robimy to niczym CodeFreeze, pakujemy do nowej wersji aplikacji i udostępniamy testerom. Testerzy testują go przez kolejne 4 tygodnie, tj. Podczas gdy oni go testują, my mamy czas przygotować dla nich jeszcze dwie wersje. To naprawdę smutny przypadek.
Powiedzieliśmy im, że jeśli chcesz być bardziej produktywny, warto wdrożyć praktyki testowania automatycznego, ponieważ to właśnie cię boli tu i teraz.
Ćwicz ciągłe wdrażanie. Świetnie, skończyłeś budować. To już jest dobre. Twój kod został skompilowany. Teraz byłoby miło wdrożyć tę kompilację w jakimś środowisku. Powiedzmy w środowisku dla programistów.
Dlaczego to jest ważne? Po pierwsze, możesz sprawdzić, jak udany jest sam proces wdrażania. Spotkałem się z takimi projektami, gdy pytam: „Jak wdrożyć nową wersję aplikacji?”, chłopaki odpowiadają: „Asemblujemy to i pakujemy do archiwum zip. Wysyłamy go do administratora pocztą. Administrator pobiera i rozwija to archiwum. I całe biuro zaczyna się modlić, żeby serwer pobrał nową wersję.”
Zacznijmy od czegoś prostego. Na przykład zapomnieli umieścić CSS w archiwum lub zapomnieli zmienić hashtag w nazwie pliku JavaScript. A kiedy wysyłamy żądanie do serwera, przeglądarka myśli, że ma już ten plik JavaScript i postanawia go nie pobierać. A była stara wersja, czegoś brakowało. Ogólnie rzecz biorąc, może być wiele problemów. Dlatego praktyka ciągłego wdrażania pozwala przynajmniej przetestować, co by się stało, gdybyś zrobił czysty obraz referencyjny i przesłał go do zupełnie nowego, czystego środowiska. Możesz zobaczyć, dokąd to prowadzi.
Również wtedy, gdy integrujesz kod między sobą, tj. pomiędzy poleceniami, pozwala to również zobaczyć, jak to wygląda w interfejsie użytkownika.
Jednym z problemów pojawiających się w przypadku użycia dużej ilości zwykłego skryptu Java jest to, że dwóch programistów pochopnie zadeklarowało zmienną o tej samej nazwie w obiekcie okna. A potem, w zależności od szczęścia. Czyj plik skryptu Java zostanie wyciągnięty jako drugi, nadpisze zmiany w drugim. To także bardzo ekscytujące. Wchodzisz: jedna rzecz działa dla jednej osoby, inna nie działa dla innej. I jest „cudownie”, kiedy wszystko wychodzi na rynek.
Następną praktyką, którą mamy, jest praktyka Automatycznego Przywracania, czyli przywracania poprzedniej wersji aplikacji.
Dlaczego jest to ważne dla programistów? Są jeszcze tacy, którzy pamiętają odległe, odległe lata 90., kiedy komputery były duże, a programy małe. Jedynym sposobem na tworzenie stron internetowych było PHP. Nie chodzi o to, że PHP jest złym językiem, chociaż jest.
Ale problem był inny. Kiedy wdrożyliśmy nową wersję naszej witryny PHP, w jaki sposób ją wdrożyliśmy? Najczęściej otwieraliśmy Far Managera lub coś innego. I przesłałem te pliki na FTP. I nagle zdaliśmy sobie sprawę, że mamy jakiś mały, mały błąd, na przykład zapomnieliśmy postawić średnik lub zapomnieliśmy zmienić hasło do bazy danych, a hasło do bazy danych jest na lokalnym hoście. Decydujemy się szybko połączyć z FTP i tam edytować pliki. To jest po prostu ogień! To właśnie było popularne w latach 90-tych.
Ale jeśli nie spojrzałeś w kalendarz, lata 90. minęły prawie 30 lat. Teraz wszystko dzieje się trochę inaczej. I spróbuj sobie wyobrazić skalę tragedii, gdy powiedzą Ci: „Wdrożyliśmy produkcję, ale coś poszło nie tak. Oto Twój login i hasło FTP, połącz się z produkcją i szybko to napraw. Jeśli jesteś Chuckiem Norrisem, to zadziała. Jeśli nie, ryzykujesz, że jeśli naprawisz jeden błąd, popełnisz kolejnych 10. Właśnie dlatego ta praktyka wycofywania się do poprzedniej wersji pozwala wiele osiągnąć.
Nawet jeśli coś złego w jakiś sposób dostało się gdzieś do środka, to jest złe, ale nie śmiertelne. Możesz przywrócić poprzednią wersję, którą posiadasz. Nazwij to kopią zapasową, jeśli łatwiej to zrozumieć w tej terminologii. Możesz przywrócić poprzednią wersję, a użytkownicy nadal będą mogli pracować z Twoim produktem, a Ty będziesz mieć odpowiedni czas buforowania. Możesz spokojnie, bez pośpiechu to wszystko wziąć i przetestować lokalnie, naprawić, a potem wgrać nową wersję. Naprawdę warto to zrobić.
Spróbujmy teraz jakoś połączyć w jedną całość dwie poprzednie praktyki. Otrzymamy trzecią funkcję o nazwie Zarządzanie wydaniami.
Kiedy mówimy o ciągłym wdrażaniu w jego klasycznej formie, mówimy, że musimy pobrać kod z jakiejś gałęzi z repozytorium, skompilować go i wdrożyć. Dobrze, jeśli mamy to samo środowisko. Jeśli mamy kilka środowisk, oznacza to, że za każdym razem musimy ściągać kod, nawet z tego samego zatwierdzenia. Będziemy go wyciągać za każdym razem, będziemy go budować za każdym razem i wdrażamy w nowym środowisku. Po pierwsze jest to czas, bo zbudowanie projektu, jeśli masz duży i pochodzisz z lat 90-tych, może zająć kilka godzin.
Poza tym jest jeszcze jeden smutek. Kiedy budujesz, nawet na tej samej maszynie, będziesz budować te same źródła, nadal nie masz gwarancji, że ta maszyna będzie w tym samym stanie, w jakim była podczas ostatniej kompilacji.
Załóżmy, że ktoś przyszedł i zaktualizował dla Ciebie DotNet lub odwrotnie, ktoś zdecydował się coś usunąć. A potem pojawia się dysonans poznawczy, że dwa tygodnie temu z tego zatwierdzenia budowaliśmy kompilację i wszystko było w porządku, ale teraz wydaje się, że to ta sama maszyna, to samo zatwierdzenie, ten sam kod, który próbujemy zbudować, ale to nie działa . Będziesz się z tym borykał przez długi czas i nie jest faktem, że się z tym uporasz. Przynajmniej bardzo zepsujesz sobie nerwy.
Dlatego praktyka zarządzania wydaniami sugeruje wprowadzenie dodatkowej abstrakcji zwanej repozytorium artefaktów, galerią lub biblioteką. Możesz to nazwać jak chcesz.
Główną ideą jest to, że gdy tylko mamy tam jakiś rodzaj zatwierdzenia, powiedzmy w gałęzi, którą jesteśmy gotowi wdrożyć w różnych środowiskach, zbieramy aplikacje z tego zatwierdzenia i wszystko, czego potrzebujemy do tej aplikacji, pakujemy to do archiwum zip i zapisz je w pewnym niezawodnym miejscu. Z tego magazynu możemy w dowolnym momencie pobrać to archiwum zip.
Następnie bierzemy go i automatycznie wdrażamy w środowisku deweloperskim. Ścigamy się tam i jeśli wszystko będzie dobrze, wkraczamy na etap. Jeśli wszystko jest w porządku, to wdrażamy na produkcję to samo archiwum, te same pliki binarne, skompilowane dokładnie raz.
Ponadto posiadanie takiej galerii pomaga nam również zaradzić zagrożeniom, o których mówiliśmy na ostatnim slajdzie, gdy mówiliśmy o przywróceniu poprzedniej wersji. Jeśli przypadkowo wdrożyłeś coś nie tak, zawsze możesz pobrać dowolną inną poprzednią wersję z tej galerii i cofnąć jej wdrożenie w tych środowiskach w ten sam sposób. Dzięki temu można łatwo wrócić do poprzedniej wersji, jeśli coś pójdzie nie tak.
Jest jeszcze jedna świetna praktyka. Oboje rozumiemy, że kiedy przywrócimy nasze aplikacje do poprzedniej wersji, może to oznaczać, że będziemy potrzebować także infrastruktury z poprzedniej wersji.
Kiedy mówimy o infrastrukturze wirtualnej, wiele osób uważa, że jest to coś, co skonfigurowali administratorzy. A jeśli potrzebujesz, powiedzmy, zdobyć nowy serwer, na którym chcesz przetestować nową wersję swojej aplikacji, to musisz napisać zgłoszenie do adminów lub devopsów. Devops zajmie to 3 tygodnie. A po 3 tygodniach powiedzą Ci, że zainstalowaliśmy dla Ciebie maszynę wirtualną, z jednym rdzeniem, dwoma gigabajtami RAM i serwerem Windows bez DotNet. Mówisz: „Ale ja chciałem DotNet”. Oni: „OK, wróć za 3 tygodnie”.
Pomysł jest taki, że stosując praktyki Infrastructure as Code, możesz traktować swoją wirtualną infrastrukturę jak kolejny zasób.
Być może, jeśli ktoś z Was tworzy aplikacje w DotNet, być może słyszał o bibliotece o nazwie Entity Framework. Być może nawet słyszałeś, że Entity Framework to jedno z podejść, które Microsoft aktywnie promuje. W przypadku pracy z bazą danych jest to podejście zwane Code First. Dzieje się tak, gdy opisujesz w kodzie, jak ma wyglądać Twoja baza danych. Następnie wdrażasz aplikację. Łączy się z bazą danych, sam określa, które tabele są, a których nie, i tworzy wszystko, czego potrzebujesz.
To samo możesz zrobić ze swoją infrastrukturą. Nie ma różnicy pomiędzy tym, czy potrzebujesz bazy danych do projektu, czy potrzebujesz serwera Windows do projektu. To tylko źródło. Możesz zautomatyzować tworzenie tego zasobu, możesz zautomatyzować konfigurację tego zasobu. W związku z tym za każdym razem, gdy będziesz chciał przetestować jakąś nową koncepcję, jakieś nowe podejście, nie będziesz musiał pisać biletu do devops, możesz po prostu wdrożyć dla siebie izolowaną infrastrukturę z gotowych szablonów, z gotowych skryptów i wdrożyć ją tam wszystkie twoje eksperymenty. Możesz to usunąć, uzyskać wyniki i zgłosić więcej na ten temat.
Następną praktyką, która również istnieje i jest również ważna, ale z której korzysta niewiele osób, jest Monitorowanie Wydajności Aplikacji.
Chciałem powiedzieć tylko jedną rzecz na temat monitorowania wydajności aplikacji. Co jest najważniejsze w tej praktyce? To właśnie Monitorowanie wydajności aplikacji jest mniej więcej tym samym, co naprawa mieszkania. To nie jest stan ostateczny, to jest proces. Musisz to robić regularnie.
W dobrym tego słowa znaczeniu dobrze byłoby przeprowadzić Monitoring Wydajności Aplikacji na niemal każdej kompilacji, chociaż, jak rozumiesz, nie zawsze jest to możliwe. Należy to jednak przeprowadzić przynajmniej w przypadku każdego wydania.
Dlaczego to jest ważne? Ponieważ jeśli nagle odczujesz spadek wydajności, musisz jasno zrozumieć, dlaczego. Jeśli Twój zespół ma, powiedzmy, dwutygodniowe sprinty, to przynajmniej raz na dwa tygodnie powinieneś wdrożyć swoją aplikację na osobnym serwerze, na którym masz wyraźnie ustalony procesor, RAM, dyski itp. I przeprowadzić te same testy wydajnościowe . Otrzymujesz wynik. Zobacz jak to się zmieniło od poprzedniego sprintu.
A jeśli okaże się, że wypłata gdzieś gwałtownie spadła, będzie to oznaczać, że stało się tak po prostu ze względu na zmiany, które zaszły w ciągu ostatnich dwóch tygodni. Dzięki temu znacznie szybciej zidentyfikujesz i naprawisz problem. I znowu, są to mniej więcej te same wskaźniki, dzięki którym możesz zmierzyć, jak skutecznie Ci się to udało.
Następną praktyką, którą mamy, jest praktyka zarządzania konfiguracją. Niewielu jest takich, którzy traktują to poważnie. Ale uwierz mi, to naprawdę bardzo poważna sprawa.
Niedawno wydarzyła się zabawna historia. Chłopaki podeszli do mnie i powiedzieli: „Pomóż nam przeprowadzić audyt bezpieczeństwa naszej aplikacji”. Długo wspólnie przyglądaliśmy się kodowi, opowiadali mi o aplikacji, rysowali diagramy. I plus minus wszystko było logiczne, zrozumiałe, bezpieczne, ale było jedno ALE! Mieli w kontroli źródła pliki konfiguracyjne, w tym te z produkcji z bazą danych IP, z loginami i hasłami do łączenia się z tymi bazami itp.
A ja mówię: „Chłopaki, ok, zamknęliście środowisko produkcyjne zaporą ogniową, ale fakt, że macie login i hasło do produkcyjnej bazy danych bezpośrednio w kontroli źródła i każdy programista może je odczytać, już stanowi ogromne zagrożenie bezpieczeństwa . I niezależnie od tego, jak bardzo bezpieczna jest Twoja aplikacja z punktu widzenia kodu, jeśli pozostawisz ją pod kontrolą źródła, nigdy nigdzie nie przejdziesz żadnego audytu. O tym właśnie mówię.
Zarządzanie konfiguracją. W różnych środowiskach możemy mieć różne konfiguracje. Na przykład możemy mieć różne loginy i hasła do baz danych na potrzeby kontroli jakości, wersji demonstracyjnych, środowiska produkcyjnego itp.
Konfigurację tę można również zautomatyzować. Powinien być zawsze oddzielony od samej aplikacji. Dlaczego? Ponieważ aplikację zbudowałeś raz, a potem aplikacji jest już wszystko jedno, czy łączysz się z serwerem SQL po takim a takim IP, czy takim a takim IP, powinno działać tak samo. Dlatego jeśli nagle ktoś z Was nadal będzie kodował ciąg połączenia w kodzie, pamiętajcie, że znajdę was i ukarzę, jeśli znajdziecie się ze mną w tym samym projekcie. Jest to zawsze umieszczane w osobnej konfiguracji, na przykład w pliku web.config.
I ta konfiguracja jest już zarządzana osobno, czyli jest to dokładnie ten moment, w którym programista i administrator mogą przyjść i usiąść w tym samym pokoju. A programista może powiedzieć: „Spójrz, oto pliki binarne mojej aplikacji. Oni pracują. Aplikacja do działania potrzebuje bazy danych. Tutaj obok plików binarnych znajduje się plik. W tym pliku to pole odpowiada za login, to za hasło, to za IP. Wdróż go w dowolnym miejscu.” Jest to proste i jasne dla administratora. Może go wdrożyć naprawdę wszędzie, zarządzając tą konfiguracją.
Ostatnią praktyką, o której chciałbym porozmawiać, jest praktyka bardzo, bardzo związana z chmurami. A maksymalny efekt przynosi praca w chmurze. Jest to automatyczne usuwanie Twojego środowiska.
Wiem, że na tę konferencję uczęszcza kilka osób z zespołów, z którymi współpracuję. We wszystkich zespołach, z którymi pracuję, stosujemy tę praktykę.
Dlaczego? Oczywiście byłoby wspaniale, gdyby każdy programista posiadał maszynę wirtualną, która działałaby 24 godziny na dobę, 7 dni w tygodniu. Ale być może to dla ciebie wiadomość, być może nie zwróciłeś uwagi, ale sam programista nie pracuje 24 godziny na dobę, 7 dni w tygodniu. Programista pracuje zazwyczaj 8 godzin dziennie. Nawet jeśli przychodzi do pracy wcześniej, zjada obfity lunch, podczas którego idzie na siłownię. Niech będzie 12 godzin dziennie, kiedy programista faktycznie korzysta z tych zasobów. Zgodnie z naszym ustawodawstwem za dni robocze uważa się 5 z 7 dni w tygodniu.
W związku z tym w dni powszednie maszyna ta nie powinna pracować 24 godziny, ale tylko 12, a w weekendy maszyna ta nie powinna w ogóle działać. Wydawałoby się, że wszystko jest bardzo proste, ale co tu ważnego powiedzieć? Wdrażając tę prostą praktykę na tym podstawowym harmonogramie, pozwala obniżyć koszty utrzymania tych środowisk o 70%, czyli wziąłeś cenę swojego dewelopera, kontroli jakości, wersji demonstracyjnej, środowiska i podzieliłeś ją przez 3.
Pytanie brzmi, co zrobić z resztą pieniędzy? Na przykład programiści powinni kupić ReSharper, jeśli jeszcze tego nie zrobili. Lub zorganizuj przyjęcie koktajlowe. Jeśli wcześniej miałeś jedno środowisko, w którym pasowali się zarówno programiści, jak i kontrola jakości, i to wszystko, teraz możesz stworzyć 3 różne, które będą odizolowane, a ludzie nie będą sobie przeszkadzać.
Odnosząc się do slajdu z ciągłym pomiarem wydajności, jak mamy porównywać wydajność, jeśli w projekcie mieliśmy w bazie danych 1 rekordów, a dwa miesiące później jest ich już milion? Jak zrozumieć dlaczego i jaki jest sens pomiaru wydajności?
To dobre pytanie, ponieważ zawsze należy mierzyć wydajność tych samych zasobów. Oznacza to, że wdrażasz nowy kod i mierzysz wydajność nowego kodu. Na przykład musisz przetestować różne scenariusze wydajności, załóżmy, że chcesz przetestować działanie aplikacji przy niewielkim obciążeniu, gdy jest 1 użytkowników, a rozmiar bazy danych wynosi 000 gigabajtów. Zmierzyłeś to i masz liczby. Następnie przyjmujemy inny scenariusz. Na przykład 5 użytkowników, rozmiar bazy danych 5 terabajt. Otrzymaliśmy wyniki i zapamiętaliśmy je.
Co jest tu ważne? Ważne jest to, że w zależności od scenariusza, ilości danych, liczby jednoczesnych użytkowników itp., możesz napotkać pewne ograniczenia. Na przykład do granic karty sieciowej, do granic dysku twardego lub do granic możliwości procesora. To jest ważne, abyś to zrozumiał. W różnych scenariuszach napotykasz pewne ograniczenia. I musisz zrozumieć liczby, kiedy je trafisz.
Czy mówimy o mierzeniu wydajności w specjalnym środowisku testowym? To znaczy, że to nie jest produkcja?
Tak, to nie jest produkcja, to jest środowisko testowe, które jest zawsze takie samo, aby można było je porównać z poprzednimi pomiarami.
Zrozumiałem, dzięki!
Jeśli nie ma pytań, myślę, że możemy zakończyć. Dziękuję!
Źródło: www.habr.com