Przerwa kawowa #120. Operatory Java &, && (AND) || (LUB). Wprowadzenie do GitOps i DevOps dla programistów

Operatory Java &, && (AND) || (LUB)

Źródło: freeCodeCamp W języku programowania Java używamy operatorów do wykonywania operacji na zmiennych. Operatory dzielą się na różne kategorie: operatory arytmetyczne, operatory przypisania, operatory porównania, operatory logiczne i tak dalej. W tym artykule omówimy bitowy operator AND ( & ), a także operatory logiczne AND ( && ) i OR ( || ).

Jak używać bitowego operatora AND

Symbol & oznacza bitowy operator AND. Ocenia wartość binarną podanych liczb. Binarny wynik tych liczb zostanie nam zwrócony w bazie 10. Gdy operator & rozpocznie swoją pracę, oceni wartość znaków w obu liczbach, zaczynając od lewej. Spójrzmy na przykład, który pomoże lepiej to zrozumieć:

System.out.println(10 & 12);
// returns 8

Jak to wyjaśnić? Wartość binarna liczby 10 to 1010. Wartość binarna liczby 12 to 1100. Oto, co musimy wziąć pod uwagę przed rozpoczęciem operacji: 1 i 0 => 0 0 i 1 => 0 1 i 1 => 1 0 i 0 = > 0 Zatem wykonajmy operację. Pierwszym symbolem dla 10 jest 1, pierwszym symbolem dla 12 jest także 1, zatem: 1 i 1 = 1. Przejdźmy do drugich symboli - 0 dla 10 i 1 dla 12: 1 i 0 = 0. Dla trzeciego symbolu - 1 dla 10 i 0 dla 12: 1 i 0 = 0. Dla czwartego znaku - 0 dla 10 i 0 dla 12: 0 i 0 = 0. Teraz połączmy wszystkie zwrócone znaki. To daje nam 1000. Wartość binarna 1000 w bazie 10 wynosi 8, więc nasza operacja zwróciła 8.

Jak korzystać z operatora logicznego AND

Należy pamiętać, że do oceny warunków używamy operatorów logicznych. Zwracają wartość true lub false w zależności od podanych warunków. Symbol && reprezentuje operator AND. Ocenia dwie instrukcje/warunki i zwraca wartość true tylko wtedy, gdy oba instrukcje/warunki są prawdziwe. Tak wygląda jego składnia:

statment1/condition1 && statemnt2/condition2

Jak widać powyżej, istnieją dwie instrukcje/warunki oddzielone instrukcją. Operator ocenia wartość obu instrukcji/warunków i podaje nam wynik – prawda lub fałsz . Oto przykład:

System.out.println((10 > 2) && (8 > 4));
//true

Operacja zwróci wartość true, ponieważ oba warunki są prawdziwe: 10 jest większe niż 2, a 8 jest większe niż 4. Jeśli którykolwiek z warunków miałby niepoprawną logikę, otrzymalibyśmy false . Aby lepiej zrozumieć operator && , powinieneś wiedzieć, że oba warunki muszą być spełnione, aby wartość była prawdziwa . Oto kolejny przykład, który zwraca wartość false :

System.out.println((2 > 10) && (8 > 4));
// false

Tutaj 2 nie jest większe niż 10, a 8 jest większe niż 4 - więc otrzymujemy false . Dzieje się tak, ponieważ jeden z warunków jest nieprawidłowy.

• Jeśli oba warunki są prawdziwe => prawdziwe

• Jeśli jeden z dwóch warunków jest fałszywy => fałszywy

• Jeśli oba warunki są fałszywe => fałszywe

Jak używać operatora logicznego OR

Aby oznaczyć operator OR, używamy symbolu || . Operator ten zwraca wartość false tylko wtedy, gdy oba warunki są fałszywe. Oznacza to, że jeśli oba warunki są prawdziwe, otrzymamy true , a jeśli jeden z obu warunków jest prawdziwy, to również otrzymamy true . Oto składnia:

statment1/condition1 || statemnt2/condition2

Spójrzmy na kilka przykładów.

System.out.println((6 < 1) || (4 > 2));
// true

Wartość True jest nam zwracana, ponieważ jeden z warunków jest prawdziwy.

• Jeśli oba warunki są prawdziwe => prawdziwe

• Jeśli jeden z warunków jest prawdziwy => prawdziwy

• Jeśli oba warunki są fałszywe => fałszywe

Wniosek

W tym artykule dowiedzieliśmy się, jak używać operatora bitowego & oraz operatorów logicznych && i || w Javie. . Dowiedzieliśmy się także, jaką wartość zwraca każda operacja w zależności od jej warunków.

Wprowadzenie do GitOps i DevOps dla programistów

Źródło: Hackernoon Jednym z głównych celów DevOps jest pomoc programistom we wdrażaniu funkcji w środowisku produkcyjnym tak szybko i bezpiecznie, jak to możliwe. Oznacza to tworzenie narzędzi i procesów, które wykonują wszystko, od zapewniania prywatnych środowisk programistycznych po wdrażanie i zabezpieczanie obciążeń produkcyjnych. Jednocześnie pośpiech nie powinien prowadzić do krytycznych niepowodzeń. GitOps to sposób na automatyzację DevOps. Mówiąc dokładniej, jest to taktyka automatyzacji wykorzystująca narzędzie programistyczne Git. Ponieważ programiści już przekazują kod do scentralizowanego repozytorium Git (używając czegoś takiego jak GitHub, GitLab lub BitBucket), programiści DevOps mogą podłączyć dowolny ze swoich skryptów roboczych, aby budować, testować lub wdrażać aplikacje, które będą uruchamiane po każdej zmianie kodu. Oznacza to, że programiści mogą pracować wyłącznie z Gitem, a wszystko, co pomoże im we wprowadzeniu kodu do produkcji, zostanie zautomatyzowane.

Dlaczego GitOps?

Wcześniej metody DevOps i CI/CD były zbiorem autorskich skryptów i narzędzi, które wykonywały codzienne zadania: uruchamianie testów, udostępnianie infrastruktury czy wdrażanie aplikacji. Jednak dostępność nowych narzędzi infrastrukturalnych, takich jak Kubernetes, w połączeniu z rozwojem architektur mikrousług, wymaga od programistów większego zaangażowania w procesy CI/CD. Ta zmiana spowodowała problemy związane ze scenariuszami użytkownika, co skutkowało zagmatwanymi i niespójnymi przepływami pracy, powielaniem wysiłków i gwałtownym spadkiem szybkości programowania. Aby móc korzystać z narzędzi i architektur chmurowych, zespoły potrzebują spójnego, zautomatyzowanego podejścia do CI/CD. Umożliwi to programistom:

• Przestań tworzyć i utrzymywać zastrzeżone skrypty i zamiast tego użyj uniwersalnego procesu.

• Szybciej twórz aplikacje i usługi dzięki określonemu, uniwersalnemu procesowi wdrażania.

• Wdrażaj szybciej po wprowadzeniu zmian w kodzie.

• Włącz automatyczne wdrażanie, aby uzyskać szybsze, częstsze i bardziej niezawodne wydania.

• Wykonuj wycofywania zmian i audyty pod kątem zgodności z deklaratywnymi wzorcami projektowymi.

Programiści uwielbiają GitOps

Ze wszystkich powodów podanych powyżej (i wielu innych) firmy potrzebują zarządzanego i zautomatyzowanego podejścia do CI/CD i DevOps, aby odnieść sukces w budowaniu i utrzymywaniu aplikacji w chmurze. Ale jeśli wystarczy automatyzacja, to dlaczego GitOps jest lepszy od innych strategii (takich jak SlackOps, zaplanowane wdrożenia lub proste skrypty)? Odpowiedź jest prosta: programiści uwielbiają GitOps.

Git – jedno narzędzie do zarządzania tym wszystkim

W ostatnich latach stało się jasne, że GitOps jest jedną z najwyżej ocenianych strategii automatyzacji DevOps wśród programistów i nietrudno zrozumieć, dlaczego. Programiści żyją w Git. Przechowują tymczasowe zmiany w git, współpracują przy użyciu gita, przeglądają kod przy użyciu gita oraz prowadzą historię i ścieżkę audytu każdej zmiany, którą ktokolwiek kiedykolwiek wprowadził, także w git. Ponieważ programiści tak bardzo polegają na gicie, dostępne są specjalne narzędzia do pracy z nim. W nowoczesnych systemach ciągłej integracji, które są najczęściej wykorzystywane do obsługi GitOps, takich jak CircleCI , Github Actions , Gitlab CI i inne, konfiguracje obsługujące potoki znajdują się bezpośrednio w repozytorium Git. Podobnie jak kod źródłowy aplikacji, konfiguracje te podlegają kontroli wersji i są widoczne dla każdego programisty pracującego nad projektem. Mogą nie tylko zobaczyć, jak wygląda proces potokowy, ale także mogą szybko i łatwo wprowadzić w nim zmiany, jeśli zajdzie taka potrzeba. Ta łatwość dostępu dla programistów jest krytyczna, ponieważ piszą testy dla swoich aplikacji i zapewniają ich bezpieczeństwo i stabilność.

Pełna samoobsługa

Nowe funkcje lub poprawki błędów nie są uważane za kompletne, dopóki nie zostaną wprowadzone do wersji produkcyjnej. Oznacza to, że wszystko, co uniemożliwia wprowadzenie zmian w kodzie w środowisku produkcyjnym, marnuje czas i energię programistów. Załóżmy, że programista musi chwilę poczekać, aż inny zespół lub osoba wykona jakieś zadanie, zanim będzie mógł zakończyć swój etap pracy. Może to powodować tarcia i konflikty w organizacji. Ułatwianie współpracy między zespołami to jedna z głównych korzyści GitOps. Programiści nie tylko mają możliwość pracy w znanym narzędziu, ale mogą także udostępnić swój kod do produkcji bez ręcznej interwencji. Oznacza to, że nie czekają, aż ktoś inny wykona ich zadania.

Ciągła praca we wszystkim

Kolejną dużą zaletą GitOps jest to, że wszystkie procesy są zawsze uruchomione! Każda wprowadzana przez nas zmiana uruchamia kompilacje i wdrożenia testowe bez konieczności wykonywania ręcznych czynności. Ponieważ programiści będą używać Git z GitOps lub bez niego, połączenie z istniejącym przepływem pracy w celu uruchomienia procesów DevOps jest idealną opcją do automatyzacji.

GitOps w praktyce

Naturalnie zaangażowanie programistów w ten proces doprowadziło do tego, że zespoły szeroko korzystają z przyjaznych dla użytkownika narzędzi, takich jak Git. Tworzy to również naturalną spójność na etapach integracji/wdrożenia CI/CD. W końcu w repozytorium Git dostępnych jest tylko określona liczba rzeczy (np. zatwierdzenia, żądania otwarcia/zamknięcia ściągnięcia, scalanie itp.), więc wygląd i działanie większości implementacji GitOps obejmuje zestaw typowych kroków:

1. Ściągnij żądania, testy i środowiska podglądu

Po tym, jak programiści spędzą czas na pisaniu kodu dla swojej nowej funkcji, zazwyczaj przesyłają ten kod do nowej gałęzi Git i przesyłają żądanie ściągnięcia lub żądanie łączenia z powrotem do głównej gałęzi repozytorium. Deweloperzy robią to codziennie. Monit wymaga od menedżerów technicznych przejrzenia zmian w kodzie i zatwierdzenia ich w celu połączenia z głównym kodem aplikacji. Jest to świetna okazja dla DevOps na dodanie dodatkowych zadań. Łącząc się ze zdarzeniami otwierania/zamykania generowanymi przez ten proces żądania ściągnięcia za pomocą narzędzia ciągłej integracji (CI), zespoły DevOps mogą inicjować wykonywanie testów jednostkowych, tworzenie środowisk podglądu i wykonywanie testów integracyjnych w odniesieniu do tych środowisk. To narzędzie pozwala inżynierom szybko zyskać zaufanie do zmian w kodzie i pozwala menedżerom produktu zobaczyć zmiany w kodzie za pośrednictwem środowiska podglądu przed połączeniem. Bliższe zaufanie oznacza szybszą fuzję. Im rzadziej i częściej wprowadzane są dane, tym mniej skomplikowanych i mylących operacji wycofywania danych. Ta technika GitOps jest kluczem do szybszych i zdrowszych zespołów programistycznych i produkcyjnych.

2. Połącz się z systemem głównym i wdroż go w fazie testowej

Gdy wszystkie strony przejrzą zmiany, kod może zostać scalony z główną gałęzią repozytorium wraz ze zmianami wprowadzonymi przez resztę zespołu programistów. Ta gałąź główna jest często używana jako obszar przejściowy dla kodu, który jest prawie gotowy do produkcji. Jest jeszcze czas na dokończenie niektórych zadań operacyjnych, takich jak testy i wdrożenie. Chociaż zazwyczaj testujemy kod każdego żądania ściągnięcia przed jego połączeniem, dobrym pomysłem jest ponowne uruchomienie testów, aby upewnić się, że kod działa z innymi zmianami wprowadzonymi przez resztę zespołu. Warto także wdrożyć wszystkie te zmiany we wspólnym środowisku (zwanym „stagingiem”), którego cały zespół może używać do przeglądania i testowania najnowszych zmian przed udostępnieniem ich klientom.

3. Ogranicz liczbę wydań i wdrażaj w środowisku produkcyjnym

Wreszcie, gdy menedżerowie i inżynierowie mają czas na przejrzenie i przetestowanie najnowszych zmian w gałęzi wyższego szczebla, zespoły są gotowe do wydania nowej wersji i wdrożenia jej w środowisku produkcyjnym! To zadanie jest często wykonywane przez menedżera wersji, dedykowanego (lub rotacyjnego) członka zespołu, którego zadaniem jest wykonywanie skryptów wdrażania i monitorowanie wydania. Nie korzystając z GitOps, ten członek zespołu musi sprawdzić, gdzie znajdują się właściwe skrypty, w jakiej kolejności je uruchamiać i czy na jego komputerze są zainstalowane wszystkie poprawne biblioteki i pakiety potrzebne do uruchomienia skryptów. Dzięki GitOps możemy połączyć to wdrożenie z innym wydarzeniem opartym na Git — utworzeniem wydania lub tagu. Wszystko, co musi zrobić menedżer wersji, to utworzyć nowe „wydanie”, często używając nazwy semver. Zadania tworzenia i wdrażania zmian w kodzie będą uruchamiane automatycznie. Podobnie jak większość zadań wykonywanych przez narzędzie CI, zostaną one skonfigurowane z lokalizacją skryptów oraz kolejnością bibliotek i pakietów potrzebnych do ich uruchomienia.

Narzędzia GitOps

Solidne i intuicyjne narzędzie do ciągłej integracji nie jest jedyną rzeczą potrzebną do instrumentowania procesów GitOps, takich jak te opisane w tym artykule. System CI może uruchamiać skrypty w oparciu o zdarzenia Git, ale nadal potrzebujesz potężnych narzędzi, aby uruchamiać te skrypty i sprawić, że będą łatwe i bezpieczne w uruchamianiu i utrzymaniu. Wdrażanie zmian w kodzie (znane również jako ciągłe dostarczanie, CD) to jeden z najtrudniejszych etapów automatyzacji. Dlatego wybraliśmy kilka kategorii narzędzi, które mogą pomóc Ci w Twojej podróży do GitOps:

Konteneryzacja za pomocą Dockera

Docker wprowadził rozwój chmury do zupełnie nowego środowiska rozproszonego i pomógł programistom zacząć realistycznie rozważać architektury mikrousług jako realną opcję. Jedną z rzeczy, która sprawia, że ​​Docker jest tak potężny, jest jego wygoda dla programistów w porównaniu z rozwiązaniami wirtualizacyjnymi poprzedniej generacji. Podobnie jak w przypadku deklaratywnych konfiguracji CI znajdujących się w naszych repozytoriach, programiści muszą po prostu napisać i utrzymać plik Dockerfile w swoim repozytorium, aby umożliwić automatyczne budowanie wdrożonych maszyn wirtualnych w kontenerach. Konteneryzacja to niezwykle skuteczna taktyka dla zespołów zajmujących się chmurą i powinna stanowić podstawowe narzędzie w Twoim repertuarze.

Infrastruktura jako kod (IaC)

Wiele zależy od przygotowania infrastruktury i wdrożenia aplikacji, które nie są przechowywane w pliku Dockerfile. Do wszystkiego innego dostępne są rozwiązania typu infrastruktura jako kod (IaC), takie jak Terraform , Cloudformation i inne. Rozwiązania te umożliwiają programistom opisywanie innych części aplikacji, takich jak zasoby Kubernetes, moduły równoważenia obciążenia, sieć, bezpieczeństwo i inne, w sposób deklaratywny. Podobnie jak opisane wcześniej konfiguracje CI i pliki Dockerfile, szablony IaC mogą być kontrolowane pod względem wersji i udostępniane wszystkim programistom w Twoim zespole.