Programmēšana

Izmanto paraugpraksi: 5 metodes, kas jums jāpieņem

Devops tagad ir svarīgs daudzās tehnoloģiju organizācijās divu šķietami pretēju misiju un kultūru dēļ, kurām jāapvienojas:

  • Izveicīgas izstrādes komandas ātri pārvietojas, lai atbilstu biznesa prasībām un ieviestu lietojumprogrammu izmaiņas.
  • Operatīvās komandas cītīgi strādā, lai nodrošinātu sistēmu darbību, nodrošinātu skaitļošanas vides drošību un pārvaldītu skaitļošanas resursus.

Veiklas komandas bieži vien operatīvās komandas uzskata par lēnām un stingrām, savukārt sistēmu inženieri veiklus izstrādātājus uzskata par darbības neatbalstošiem un neapdomīgiem, ja lietojumprogrammu izvietošana rada ražošanas problēmas.

Tie ir vispārinājumi, taču abām disciplīnām bieži ir atšķirīga motivācija, terminoloģija un rīki - un šī neatbilstība var radīt biznesa problēmas. Piemēram, kad jaunie uzņēmumi kļūst lielāki, viņiem ir jāizstrādā darbības procedūras, lai nodrošinātu stabilitāti, vienlaikus minimāli ietekmējot viņu attīstības ātrumu un veiklību. Lieliem uzņēmumiem viņiem jāatrod veidi, kā ātrāk piegādāt klientam piemērotas lietojumprogrammas un iekšējās darbplūsmas uzlabojumus, neapdraudot uzticamību un neizkļūstot no atbilstības.

Devops mērķis ir risināt šos konfliktus ar kultūru, darbības principu kopumu un jaunu paraugprakses kopumu, kas ļauj ātri ieviest lietojumprogrammas un nodrošināt stabilitāti, nodrošinot to mazāk konfliktu un kompromisu. Tas lielā mērā tiek darīts, nodrošinot praksi, kas automatizē darbības soļus un standartizē konfigurācijas:

  • Izstrādes komandām šī prakse standartizē un automatizē darbības, sākot no koda izstrādes līdz lietojumprogrammu testēšanai, drošībai un darbināšanai dažādās vidēs.
  • Darbībām prakse veicina automatizāciju, konfigurējot un izvietojot infrastruktūru, pārraugot vairākus domēnus un ļaujot ātrāk atrisināt ražošanas problēmas.

Devops prakse ietver:

  • Versiju kontrole un sazarošanas stratēģijas.
  • Nepārtrauktas integrācijas un nepārtrauktas piegādes (CI / CD) cauruļvadi.
  • Konteineri, kas standartizē un izolē lietojumprogrammu izpildlaika vides.
  • Infrastructure as code (IAC), kas ļauj skriptu izveidot infrastruktūras slāni.
  • Devops cauruļvadu un darbojas lietojumprogrammu stāvokļa uzraudzība.

Devops sāk ar praksi un rīkiem, kas tiek izmantoti programmatūras izlaišanai, lai aprēķinātu vidi ar pamatprocedūrām, kas pastāv jau gadu desmitiem. Tie ietver versiju kontroli, lai pārvaldītu koda izmaiņas izstrādātāju komandā, kodu bāzes sazarošanu, lai atbalstītu dažādas izstrādes darbības, un versiju marķēšanas programmatūras izlaidumus, pirms tie tiek pārvietoti dažādās vidēs.

Galvenās devops komandu atšķirības ir tādas, ka rīkus ir vieglāk izmantot un labāk integrēt citās tehnoloģijās, kas automatizē lietojumprogrammu izveidi un izvietošanu. Ir arī vairāk standartizētas sazarošanas un kodu apvienošanas stratēģijas, kuras ir vieglāk pārvaldīt ar modernām versiju kontroles sistēmām.

Piemēram, daudzas organizācijas izmanto Git (ieskaitot GitHub un BitBucket versijas) un citus versiju vadības rīkus, kas piedāvā vairāku klientu lietojumprogrammas, API integrēšanai un komandrindas rīkus, lai pārvaldītu biežākas vai sarežģītākas procedūras. Mūsdienās lielākā daļa izstrādātāju savos projektos ir izmantojuši vismaz vienu versiju vadības tehnoloģiju, tāpēc standartu ieviešana nav tik grūta kā agrāk.

Organizācijas, kas izmanto šos rīkus, var pieņemt atzarošanas stratēģijas, piemēram, Gitflow, kas standartizē ražošanas, testēšanas un izstrādes filiāles un izveido procedūras jaunu funkciju vai ražošanas ielāpu izstrādei. Šīs sazarošanas stratēģijas ļauj komandām sadarboties dažāda veida attīstības vajadzībām un ievieš tikai pārbaudītu un izvietojamu kodu ražošanas filiālēs. Pēc tam komandas izmanto versiju marķēšanu, lai iezīmētu visas avota koda un citu failu versijas, kas ir daļa no programmatūras laidiena.

Lielākā daļa organizāciju, kurām pēc ražošanas izlaišanas ir nepieciešams lietotāju atbalsts, un citas organizācijas, kas agri izstrādā savu devops praksi, bieži ievēro tradicionālo laidienu pārvaldības praksi, kas atbalsta tādas konstrukcijas kā lielākās un mazākās versijas. Sarežģītākas komandas, kas izstrādā lietojumprogrammas, kurām nepieciešams mazāks lietotāju atbalsts, var praktizēt nepārtrauktu izvietošanu, ja ir automatizācija, kas nepārtraukti integrē un nodrošina koda izmaiņas ražošanas vidēs.

Lai iespējotu biežākus izlaidumus, komandas vēlas automatizēt soļus no koda pārbaudes līdz pilnībā pārbaudītu lietojumprogrammu piegādei mērķa skaitļošanas vidē. Nepārtraukta integrācija (CI) ir automatizācija visu programmatūras komponentu izveidošanai un integrēšanai tā, lai tie būtu izvietojamā paketē. Nepārtrauktas izvietošanas (CD) rīki pārvalda videi raksturīgos mainīgos un automatizē lietojumprogrammu virzīšanu uz attīstību, testēšanu, ražošanu un citām skaitļošanas vidēm. Šie rīki kopā veido CI / CD cauruļvadu.

Lai CI / CD būtu efektīvs automatizācijas process, cauruļvadā jāievieš nepārtraukta testēšana, lai pārliecinātos, ka jaunais kods nerada defektus un citas problēmas. Vienības testi, kas ieviesti nepārtrauktas integrācijas cauruļvadā, nodrošina, ka piešķirtais kods nepārkāpj visus esošos vienību testus. Citus testus, kas meklē koda līmeņa drošības problēmas un koda struktūru, var ieviest arī integrācijas posmā. Automatizēta funkcionalitāte un veiktspēja, kurai nepieciešama izpildlaika vide, bieži tiek automatizēta kā daļa no nepārtrauktas piegādes cauruļvadiem.

Šī automatizācija veicina daudzas labvēlīgas uzvedības un prakses izmaiņas, kas komandām ļauj veikt izmaiņas biežāk un drošāk. Tas liek komandām biežāk reģistrēties un pārbaudīt kodu, kas ļauj ātrāk atrast un novērst defektus. Manuālās izvietošanas procedūras ir pakļautas kļūdām, kuras automatizācija lielā mērā novērš. Automatizācija arī aizņem lielāko daļu papildu izdevumu, virzot lietotājiem jaunas iespējas, ļaujot komandām biežāk izvietoties.

Ja CI / CD nodrošina automatizāciju lietotņu piegādei, konteineri ir lietojumprogrammas darbības vides iepakojums. Izstrādātāji var norādīt operētājsistēmu, lietojumprogrammu prasības un konfigurācijas prasības kā konteineru lietojumprogrammu darbināšanai izolētā slānī, kas koplieto sava resursdatora operētājsistēmu. Docker un Kubernetes ir konteineru tehnoloģijas, kas palīdz izstrādātājiem konsekventi definēt lietojumprogrammu vidi.

Ar CI / CD cauruļvadiem, lai integrētu un izvietotu kodu, un ar standartizētiem konteineriem, kas izolē katras lietojumprogrammas skaitļošanas vajadzības, izstrādātājiem ir rīki, lai ražotu lietojumprogrammu pakalpojumus bez daudzām papildu izmaksām. Izstrādes komandām ir lielākas iespējas pārveidot biznesa prasības mikropakalpojumos, kurus var izvietot, pielāgot un piesaistīt vairākām biznesa vajadzībām.

Tā kā kodu integrācijas un piegādes automatizēšana un lietojumprogrammu konteinerizēšana veicina lietojumprogrammu piegādi, nākamā izstrādes prakse palīdz automatizēt un standartizēt infrastruktūru un mākoņpakalpojumus.

Agrāk bija grūti automatizēt un pārvaldīt infrastruktūru. Kad tika izvēlēta arhitektūra, operatīvie inženieri devās uz dažādiem infrastruktūras komponentiem, lai tos izveidotu un konfigurētu atbilstoši prasībām. Konfigurācijas un aktīvu pārvaldības rīkiem, kas izmantoti šo arhitektūru iegūšanai, bija nepieciešami automatizēti un manuāli soļi, un tie bieži bija novecojuši vai trūka kritiskās informācijas. Arī skaitļošanas vide bija neelastīga, un, lai arī bija daži instrumenti, lai automatizētu mērogošanas vides, tie bieži tika izolēti no noteikta infrastruktūras veida, automatizācijas ieviešanai bija nepieciešamas dažādas prasmes, un tiem bija piekļuve tikai operatīvo datu apakškopai, lai noteiktu, vai un kā mērogot.

Mūsdienu mākoņu vide piedāvā lietotāju saskarnes, kas vienkāršo darbu inženieriem. Inženieri var izmantot šos rīkus, lai iestatītu virtuālos privātos tīklus, konfigurētu drošības grupas un pēc tam palaistu skaitļošanas, krātuves un citus nepieciešamos pakalpojumus.

Bet devops komandas sper šo soli tālāk. Tā vietā, lai izmantotu tīmekļa saskarnes un manuāli konfigurētu skaitļošanas resursus, viņi procesu automatizē ar kodu. Infrastructure as code (IaC) rīki ļauj operatīvajiem inženieriem izveidot skriptu un automatizēt infrastruktūras iestatīšanu un pārvaldību. Šajos skriptos var tikt iestrādātas arī konfigurācijas, kas ļauj palielināt un samazināt vidi. Chef, Puppet, Ansible un Salt ir četras konkurējošas tehnoloģijas, kas palīdz operatīvajām komandām ieviest IaC.

Ražošanas process ir tikpat labs kā spēja uzraudzīt, brīdināt un atgūties no problēmām. Tas pats attiecas uz devops uzraudzību un lietotāju pieredzi, lietojot lietojumprogrammas un pakalpojumus. Tā kā organizācijas iegulda automatizācijā, konteinerizēšanā, standartizācijā un lietojumprogrammu ieviešanā, paralēla investīcija uzraudzībā ir labākā prakse.

Padomājiet par monitoringu vairākos līmeņos. Zemākajā līmenī ir infrastruktūras pārraudzība, kas ļauj atpazīt un reaģēt, ja skaitļošanas resursi nav veselīgi vai slikti. Mākoņu vide šodien piedāvā iespējas uzraudzīt, brīdināt un izmantot elastīgas mākoņa iespējas, lai reaģētu uz infrastruktūras problēmām.

Nākamais slānis sastāv no rīkiem, lai uzraudzītu un uztvertu metriku ap devops automatizāciju. Šie rīki kļūst arvien kritiskāki, jo palielinās izstrādātāju un izvietojamo pakalpojumu skaits. Šie rīki sniedz brīdinājumus par būvēšanas kļūmi un revīzijas rīkus, lai palīdzētu diagnosticēt problēmas.

Visbeidzot, ir rīki, kas pārrauga lietojumprogrammas darbības laiku, veiktspēju un citus izpildlaika rādītājus. Šie uzraudzības rīki bieži pārbauda API un arī veic pilnīgus pārlūka testus vai nu ar atsevišķiem galapunktiem, vai ar daudzpakāpju darījumiem. Šie monitori ir priekšējā aizsardzība, lai brīdinātu devops komandas, kad API vai lietojumprogrammas darbojas ārpus pieņemamā servisa līmeņa.

Ir daudz devops prakses, un tām visām ir vajadzīgs laiks, lai nobriestu un integrētos. To ieviešanai nav noteikta kārtība vai stingri ieteikumi par to, cik daudz automatizācijas ieguldīt.

Tomēr organizācijām vispirms vajadzētu meklēt kultūru un domāšanas veidu atbilstību devops principiem un pēc tam atzīt, kāda prakse vislabāk atbilst uzņēmējdarbības vajadzībām. Piemēram, organizācijas, kurām jau ir slikta lietojumprogrammu veiktspēja, vispirms var izvēlēties ieviest uzraudzību, lai palīdzētu ātrāk atrisināt problēmas un vieglāk identificēt pamatcēloņus. Citas organizācijas, kas sāk mākoņa migrāciju, var izvēlēties infrastruktūru izvietot kā kodu, savukārt organizācijas, kas izveido standarta lietojumprogrammu izstrādes arhitektūru, var ieguldīt CI / CD cauruļvados.

Tehniķiem jāpatur prātā, ka automatizācijas ieviešana izmaksā dārgi un ka ne katrai organizācijai nepieciešama nepārtraukta izvietošana. Vislabākā prakse ir pārliecināties, ka vispirms tiek izpildītas uzņēmējdarbības vajadzības, un saskaņot automatizāciju ar tādām jomām, kur bieži atkārtojas, un manuāli centieni ir pakļauti kļūdām.

Saistītais video: Devops pieaugums uzņēmumā

$config[zx-auto] not found$config[zx-overlay] not found