Coffee break #120. Mga operator ng Java &, && (AT) || (O). Panimula sa GitOps at DevOps para sa Mga Developer

Mga operator ng Java &, && (AT) || (O)

Source: freeCodeCamp Sa Java programming language, gumagamit kami ng mga operator para magsagawa ng mga operasyon sa mga variable. Ang mga operator ay nahahati sa iba't ibang kategorya: mga operator ng aritmetika, mga operator ng pagtatalaga, mga operator ng paghahambing, mga lohikal na operator, at iba pa. Sa artikulong ito, pag-uusapan natin ang tungkol sa bitwise AND operator ( & ), pati na rin ang logical operators AND ( && ) at OR ( || ).

Paano gamitin ang bitwise AND operator

Ang simbolo & nagsasaad ng bitwise AT operator. Sinusuri nito ang binary na halaga ng mga ibinigay na numero. Ang binary na resulta ng mga numerong ito ay ibabalik sa amin sa base 10. Kapag nagsimula ang & operator sa trabaho nito, susuriin nito ang halaga ng mga character sa parehong numero, simula sa kaliwa. Tingnan natin ang isang halimbawa para mas maunawaan ito:

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

Paano ito ipaliwanag? Ang binary value ng 10 ay 1010. Ang binary value ng 12 ay 1100. Narito ang kailangan nating isaalang-alang bago natin simulan ang operasyon: 1 at 0 => 0 0 at 1 => 0 1 at 1 => 1 0 at 0 = > 0 Kaya't gawin natin ang operasyon. Ang unang simbolo para sa 10 ay 1, ang unang simbolo para sa 12 ay 1 din, samakatuwid: 1 at 1 = 1. Paglipat sa pangalawang simbolo - 0 para sa 10 at 1 para sa 12: 1 at 0 = 0. Para sa ikatlong simbolo - 1 para sa 10 at 0 para sa 12: 1 at 0 = 0. Para sa ikaapat na character - 0 para sa 10 at 0 para sa 12: 0 at 0 = 0. Ngayon, pagsamahin natin ang lahat ng ibinalik na character. Nagbibigay ito sa amin ng 1000. Ang binary na halaga ng 1000 sa base 10 ay 8, kaya ang aming operasyon ay bumalik sa 8.

Paano Gamitin ang Lohikal AT Operator

Tandaan na gumagamit kami ng mga Boolean operator upang suriin ang mga kundisyon. Nagbabalik sila ng totoo o mali depende sa mga ibinigay na kundisyon. Ang && simbolo ay kumakatawan sa AND operator. Sinusuri nito ang dalawang pahayag/kondisyon at nagbabalik lamang ng totoo kung ang parehong mga pahayag/kondisyon ay totoo. Ito ang hitsura ng syntax nito:

statment1/condition1 && statemnt2/condition2

Tulad ng makikita mo sa itaas, mayroong dalawang pahayag/kondisyon na pinaghihiwalay ng isang pahayag. Sinusuri ng operator ang halaga ng parehong mga pahayag/kondisyon at binibigyan kami ng resulta - true o false . Narito ang isang halimbawa:

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

Magbabalik ng true ang operasyon dahil ang parehong mga kundisyon ay totoo: 10 ay mas malaki kaysa sa 2 at 8 ay mas malaki kaysa sa 4. Kung alinman sa kundisyon ay may maling logic, kami ay makakatanggap ng false . Upang mas maunawaan ang && operator , dapat mong malaman na ang parehong mga kundisyon ay dapat totoo upang masuri sa true . Narito ang isa pang halimbawa na nagbabalik ng false :

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

Dito ang 2 ay hindi hihigit sa 10, at ang 8 ay mas malaki sa 4 - kaya't nakukuha natin ang false . Ito ay dahil ang isa sa mga kundisyon ay hindi tama.

• Kung ang parehong kundisyon ay totoo => totoo

• Kung mali ang isa sa dalawang kundisyon => false

• Kung ang parehong kundisyon ay false => false

Paano gamitin ang Boolean OR operator

Upang tukuyin ang OR operator ginagamit namin ang simbolo || . Ang operator na ito ay nagbabalik lamang ng false kung ang parehong mga kundisyon ay mali. Iyon ay, kung ang parehong mga kondisyon ay totoo, makakakuha tayo ng totoo , at kung ang isa sa parehong mga kundisyon ay totoo, pagkatapos ay makakakuha din tayo ng totoo . Narito ang syntax:

statment1/condition1 || statemnt2/condition2

Tingnan natin ang ilang halimbawa.

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

Ang totoo ay ibinalik sa atin dahil ang isa sa mga kondisyon ay totoo.

• Kung ang parehong kundisyon ay totoo => totoo

• Kung totoo ang isa sa mga kundisyon => totoo

• Kung ang parehong kundisyon ay false => false

Konklusyon

Sa artikulong ito, natutunan namin kung paano gamitin ang bitwise & operator at ang logical operator na && at || sa Java. . Nalaman din namin kung anong halaga ang ibinabalik ng bawat operasyon depende sa mga kondisyon nito.

Panimula sa GitOps at DevOps para sa Mga Developer

Source: Hackernoon Isa sa mga pangunahing layunin ng DevOps ay tulungan ang mga developer na mag-deploy ng feature sa produksyon nang mabilis at secure hangga't maaari. Nangangahulugan ito ng paglikha ng mga tool at proseso na ginagawa ang lahat mula sa pagbibigay ng mga pribadong development environment hanggang sa pag-deploy at pag-secure ng mga workload sa produksyon. Kasabay nito, ang pagmamadali ay hindi dapat humantong sa mga kritikal na kabiguan. Ang GitOps ay isang paraan upang i-automate ang DevOps. Higit na partikular, ito ay isang automation na taktika gamit ang Git development tool. Dahil nag-commit na ng code ang mga developer sa isang sentralisadong Git repository (gamit ang isang bagay tulad ng GitHub, GitLab, o BitBucket), maaaring isaksak ng mga developer ng DevOps ang alinman sa kanilang mga script sa trabaho upang bumuo, subukan, o mag-deploy ng mga application na tatakbo pagkatapos gawin ang bawat pagbabago ng code. Nangangahulugan ito na ang mga developer ay maaaring gumana nang eksklusibo sa Git, at lahat ng makakatulong sa kanila na makuha ang kanilang code sa produksyon ay magiging awtomatiko.

Bakit GitOps?

Dati, ang mga paraan ng DevOps at CI/CD ay isang hanay ng mga pagmamay-ari na script at tool na gumaganap ng mga pang-araw-araw na gawain: pagpapatakbo ng mga pagsubok, pagbibigay ng imprastraktura, o pag-deploy ng isang application. Gayunpaman, ang pagkakaroon ng mga bagong tool sa imprastraktura gaya ng Kubernetes, kasama ng pagtaas ng mga arkitektura ng microservice, ay nangangailangan ng mga developer na maging mas kasangkot sa mga proseso ng CI/CD. Ang pagbabagong ito ay lumikha ng mga problemang nauugnay sa mga sitwasyon ng user, na nagresulta sa nakakalito at hindi pare-parehong mga daloy ng trabaho, pagdoble ng pagsisikap, at isang matinding pagbaba sa bilis ng pag-develop. Para samantalahin ang mga tool at arkitektura ng cloud, kailangan ng mga team ng pare-pareho, automated na diskarte sa CI/CD. Papayagan nito ang mga developer na:

• Itigil ang paggawa at pagpapanatili ng mga pagmamay-ari na script at sa halip ay gumamit ng isang pangkalahatang proseso.

• Bumuo ng mga app at serbisyo nang mas mabilis gamit ang isang tinukoy at pangkalahatang proseso ng pag-deploy.

• I-deploy nang mas mabilis pagkatapos gumawa ng mga pagbabago sa code.

• I-enable ang automated deployment para sa mas mabilis, mas madalas, at mas maaasahang release.

• Magsagawa ng mga rollback at pag-audit para sa pagsunod sa mga pattern ng deklaratibong disenyo.

Gustung-gusto ng mga developer ang GitOps

Para sa lahat ng mga kadahilanang nakasaad sa itaas (at marami pa), ang mga kumpanya ay nangangailangan ng pinamamahalaan at automated na mga diskarte sa CI/CD at DevOps upang magtagumpay sa pagbuo at pagpapanatili ng mga cloud application. Ngunit kung wala lang ang automation, bakit mas mahusay ang GitOps kaysa sa iba pang mga diskarte (tulad ng SlackOps, naka-iskedyul na pag-deploy, o mga simpleng script)? Ang sagot ay simple: mahal ng mga developer ang GitOps.

Git - isang tool upang pamahalaan ang lahat ng ito

Sa mga nakalipas na taon, naging malinaw na ang GitOps ay isa sa mga may pinakamataas na rating na mga diskarte sa automation ng DevOps sa mga developer, at hindi mahirap makita kung bakit. Nakatira ang mga developer sa Git. Nag-iimbak sila ng mga pansamantalang pagbabago sa git, nakikipagtulungan gamit ang git, nagre-review ng code gamit ang git, at nagpapanatili ng kasaysayan at audit trail ng bawat pagbabagong nagawa ng sinuman, pati na rin sa git. Dahil ang mga developer ay lubos na umasa sa git, may mga espesyal na tool na magagamit upang gumana dito. Sa modernong tuluy-tuloy na integration system na kadalasang ginagamit upang suportahan ang GitOps, gaya ng CircleCI , Github Actions , Gitlab CI at iba pa, ang mga configuration na sumusuporta sa mga pipeline ay direktang matatagpuan sa Git repository. Tulad ng source code ng application, ang mga pagsasaayos na ito ay kinokontrol ng bersyon at nakikita ng bawat developer na nagtatrabaho sa proyekto. Hindi lamang nila makikita kung ano ang proseso ng pipeline, ngunit maaari rin silang mabilis at madaling gumawa ng mga pagbabago dito kung kinakailangan. Ang kadalian ng pag-access para sa mga developer ay kritikal habang nagsusulat sila ng mga pagsubok para sa kanilang mga application at tinitiyak ang kanilang seguridad at katatagan.

Buong paglilingkod sa sarili

Ang mga bagong feature o pag-aayos ng bug ay hindi itinuturing na kumpleto hanggang sa mailabas ang mga ito sa produksyon. Nangangahulugan ito na anumang bagay na pumipigil sa mga pagbabago sa code na gawin sa produksyon ay nag-aaksaya ng oras at enerhiya ng developer. Ipagpalagay na ang isang developer ay kailangang maghintay ng ilang oras para sa isa pang koponan o tao upang makumpleto ang ilang gawain bago niya maisara ang kanyang hakbang sa trabaho. Maaari itong lumikha ng alitan at salungatan sa organisasyon. Ang pagpapadali sa pakikipagtulungan sa pagitan ng mga koponan ay isa sa mga pangunahing benepisyo ng GitOps. Hindi lamang nagkakaroon ng pagkakataon ang mga developer na magtrabaho sa isang pamilyar na tool, ngunit maaari rin nilang ilabas ang kanilang code sa produksyon nang walang manu-manong interbensyon. Nangangahulugan ito na hindi sila naghihintay para sa ibang tao upang makumpleto ang kanilang mga gawain.

Patuloy na trabaho sa lahat ng bagay

Ang isa pang malaking benepisyo ng GitOps ay ang lahat ng mga proseso ay palaging tumatakbo! Ang bawat pagbabagong ginagawa namin ay nagti-trigger ng mga pagsubok na build at deployment nang walang anumang manu-manong hakbang. Dahil ang mga developer ay gagamit ng git na mayroon o walang GitOps, ang pagkonekta sa kanilang kasalukuyang daloy ng trabaho upang patakbuhin ang mga proseso ng DevOps ay isang mainam na opsyon para sa automation.

GitOps sa pagsasanay

Naturally, ang paglahok ng mga developer sa proseso ay humantong sa mga koponan sa malawakang paggamit ng mga tool na madaling gamitin tulad ng Git. Lumilikha din ito ng natural na pagkakapare-pareho para sa mga yugto ng integration/deployment ng CI/CD. Kung tutuusin, napakaraming bagay lang ang available sa isang Git repository (hal. commits, open/close pull requests, merges, atbp.), kaya ang hitsura at pakiramdam ng karamihan sa mga pagpapatupad ng GitOps ay may kasamang set ng mga tipikal na hakbang:

1. Hilahin ang mga kahilingan, pagsubok, at preview na kapaligiran

Matapos gumugol ng oras ang mga developer sa pagsusulat ng code para sa kanilang bagong feature, karaniwan nilang ibibigay ang code na iyon sa isang bagong sangay ng Git at magsumite ng kahilingang Pull o Pagsamahin pabalik sa pangunahing sangay ng repositoryo. Ginagawa ito ng mga developer araw-araw. Ang prompt ay nangangailangan ng mga teknikal na tagapamahala na suriin ang mga pagbabago sa code at aprubahan ang mga ito upang maisama sa pangunahing code ng aplikasyon. Isa itong magandang pagkakataon para sa DevOps na magdagdag ng mga karagdagang gawain. Sa pamamagitan ng pagkonekta sa mga open/close na kaganapan na nabuo ng proseso ng pull request na ito gamit ang isang tuloy-tuloy na integration (CI) na tool, ang mga DevOps team ay maaaring mag-trigger ng pagsasagawa ng mga unit test, paglikha ng mga preview environment, at execution ng integration tests laban sa mga environment na iyon. Ang tooling na ito ay nagbibigay-daan sa mga inhinyero na mabilis na magtiwala sa mga pagbabago sa code at nagbibigay-daan sa mga tagapamahala ng produkto na makita ang mga pagbabago sa code sa pamamagitan ng pre-merge na preview na kapaligiran. Ang mas malapit na tiwala ay nangangahulugan ng mas mabilis na pagsasanib. Kung mas kaunti at mas madalas ang data ay ipinasok, mas kaunting kumplikado at nakakalito na mga rollback. Ang diskarteng ito ng GitOps ay susi sa mas mabilis, malusog na development at production team.

2. Pagsamahin sa master at i-deploy sa pagtatanghal ng dula

Kapag nasuri na ng lahat ng partido ang mga pagbabago, maaaring isama ang code sa master branch ng repositoryo kasama ang mga pagbabagong ginawa ng iba pang development team. Ang master branch na ito ay kadalasang ginagamit bilang isang staging area para sa code na halos handa na para sa produksyon. May oras pa para kumpletuhin ang ilang operational na gawain tulad ng mga pagsubok at deployment. Bagama't karaniwan naming sinusubok ang code para sa bawat kahilingan sa paghila bago ito pagsamahin, magandang ideya na muling patakbuhin ang mga pagsubok upang matiyak na gumagana ang code sa iba pang mga pagbabagong ginawa ng natitirang bahagi ng koponan. Sulit ding i-deploy ang lahat ng mga pagbabagong ito sa isang karaniwang kapaligiran (tinatawag na “staging”) na magagamit ng buong team para suriin at subukan ang mga pinakabagong pagbabago bago ilabas ang mga ito sa mga customer.

3. Bawasan ang mga release at i-deploy sa produksyon

Sa wakas, pagkatapos magkaroon ng panahon ang mga manager at engineer na suriin at subukan ang mga pinakabagong pagbabago sa upstream na sangay, handa na ang mga team na ilabas ang release at i-deploy ito sa produksyon! Ang gawaing ito ay kadalasang ginagawa ng isang release manager, isang dedikadong (o umiikot) na miyembro ng team na naatasang magsagawa ng mga script ng deployment at subaybayan ang release. Nang hindi gumagamit ng GitOps, dapat suriin ng miyembro ng team na ito kung nasaan ang mga tamang script, kung anong pagkakasunud-sunod para patakbuhin ang mga ito, at kung ang lahat ng tamang library at package na kailangan para patakbuhin ang mga script ay naka-install sa kanilang makina. Sa GitOps, maaari naming i-link ang deployment na ito sa isa pang event na nakabatay sa Git—ang paggawa ng release o tag. Ang kailangan lang gawin ng release manager ay gumawa ng bagong "release," kadalasang gumagamit ng semver para sa pangalan. Awtomatikong tatakbo ang mga gawain upang bumuo at mag-deploy ng mga pagbabago sa code. Tulad ng karamihan sa mga gawaing ginagampanan ng isang tool ng CI, iko-configure ang mga ito kasama ang lokasyon ng mga script at ang pagkakasunud-sunod ng mga aklatan at mga pakete na kailangan upang patakbuhin ang mga ito.

Mga Tool ng GitOps

Ang isang matatag at madaling maunawaan na patuloy na tool sa pagsasama ay hindi lamang ang kailangan upang magamit ang mga proseso ng GitOps tulad ng mga inilarawan sa artikulong ito. Ang isang CI system ay maaaring mag-trigger ng mga script batay sa mga git na kaganapan, ngunit kailangan mo pa rin ng makapangyarihang mga tool upang patakbuhin ang mga script na iyon at gawin itong madali at ligtas na tumakbo at mapanatili. Ang pag-deploy ng mga pagbabago sa code (kilala rin bilang tuluy-tuloy na paghahatid, CD) ay isa sa pinakamahirap na hakbang upang i-automate. Kaya naman pumili kami ng ilang kategorya ng mga tool na makakatulong sa iyo sa iyong paglalakbay sa GitOps:

Containerization sa Docker

Dinala ng Docker ang cloud development sa isang ganap na bagong distributed na kapaligiran at tinulungan ang mga developer na magsimulang makatotohanang isaalang-alang ang mga arkitektura ng microservice bilang isang praktikal na opsyon. Isa sa mga bagay na nagpapalakas sa Docker ay kung gaano ito kaginhawaan para sa mga developer kumpara sa mga nakaraang henerasyong solusyon sa virtualization. Tulad ng mga declarative na configuration ng CI na makikita sa aming mga repository, kailangan lang ng mga developer na magsulat at magpanatili ng Dockerfile sa kanilang repository upang paganahin ang mga automated na build ng mga naka-deploy na virtual machine sa mga container. Ang Containerization ay isang napakalakas na taktika para sa mga cloud team at dapat ay isang pangunahing tool sa iyong repertoire.

Imprastraktura bilang Code (IaC)

Marami ang napupunta sa paghahanda ng imprastraktura at pag-deploy ng mga application na hindi nakaimbak sa isang Dockerfile. Para sa lahat ng iba pa, mayroong mga solusyon sa infrastructure-as-code (IaC) gaya ng Terraform , Cloudformation at iba pa. Ang mga solusyong ito ay nagbibigay-daan sa mga developer na ilarawan ang iba pang bahagi ng application, tulad ng mga mapagkukunan ng Kubernetes, mga balanse ng pag-load, networking, seguridad, at higit pa, sa paraang deklaratibo. Tulad ng mga CI configuration at Dockerfiles na inilarawan kanina, ang mga template ng IaC ay maaaring kontrolado ng bersyon at ibahagi sa lahat ng developer sa iyong team.