Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Bydd yr adroddiad yn sôn am rai arferion DevOps, ond o safbwynt datblygwr. Yn nodweddiadol, mae gan bob peiriannydd sy'n ymuno â DevOps sawl blwyddyn o brofiad gweinyddol o dan eu gwregys eisoes. Ond nid yw hyn yn golygu nad oes lle i'r datblygwr yma. Yn amlach na pheidio, mae datblygwyr yn brysur yn trwsio “byg hollbwysig nesaf y dydd,” ac nid oes ganddyn nhw amser i hyd yn oed edrych yn gyflym ar faes DevOps. Yn nealltwriaeth yr awdur, DevOps, yn gyntaf, yw synnwyr cyffredin. Yn ail, mae’n gyfle i fod yn fwy effeithiol. Os ydych chi'n ddatblygwr, gyda synnwyr cyffredin ac eisiau bod yn fwy effeithiol fel chwaraewr tîm, mae'r adroddiad hwn ar eich cyfer chi.

Gadewch imi gyflwyno fy hun, rwy'n cyfaddef yn llwyr bod yna bobl yn yr ystafell nad ydyn nhw'n fy adnabod. Fy enw i yw Anton Boyko, rwy'n MVP Microsoft Azure. Beth yw MVP? Dyma Model-View-Cyflwynydd. Mae Model-View-Presenter yn union fi.

Yn ogystal, rwyf ar hyn o bryd yn dal swydd pensaer datrysiadau yn Ciklum. Ac yn ddiweddar, prynais barth mor brydferth i mi fy hun, a diweddarais fy e-bost, yr wyf fel arfer yn ei ddangos mewn cyflwyniadau. Gallwch ysgrifennu ataf yn: fi [ci] byokoant.pro. Gallwch anfon e-bost ataf gyda chwestiynau. Fel arfer byddaf yn eu hateb. Yr unig beth yw na hoffwn dderbyn cwestiynau trwy e-bost sy'n ymwneud â dau bwnc: gwleidyddiaeth a chrefydd. Gallwch ysgrifennu ataf am bopeth arall trwy e-bost. Bydd peth amser yn mynd heibio, atebaf.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Ychydig eiriau amdanaf fy hun:

  • Rwyf wedi bod yn y maes hwn ers 10 mlynedd bellach.
  • Roeddwn i'n gweithio yn Microsoft.
  • Fi yw tad sefydlu cymuned Azure Wcreineg, a sefydlwyd gennym yn rhywle yn 2014. Ac mae gennym ni o hyd ac rydym yn ei ddatblygu.
  • Rwyf hefyd yn dad i sylfaenydd cynhadledd Azure, yr ydym yn ei chynnal yn yr Wcrain.
  • Rwyf hefyd yn helpu i drefnu'r Bŵtcamp Byd-eang Azure yn Kyiv.
  • Fel y dywedais, rwy'n MVP Microsoft Azure.
  • Rwy'n siarad mewn cynadleddau yn eithaf aml. Rwyf wrth fy modd yn siarad mewn cynadleddau. Dros y flwyddyn ddiwethaf roeddwn i'n gallu perfformio tua 40 o weithiau. Os byddwch chi'n mynd heibio i'r Wcráin, Belarus, Gwlad Pwyl, Bwlgaria, Sweden, Denmarc, yr Iseldiroedd, Sbaen neu'n rhoi neu'n cymryd gwlad arall yn Ewrop, yna mae'n ddigon posibl pan ewch chi i gynhadledd sydd â thema cwmwl yn ei ffrwd, efallai y gwelwch fi ar y rhestr o siaradwyr.
  • Dwi hefyd yn gefnogwr Star Trek.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Gadewch i ni siarad ychydig am Agenda. Mae ein Hagenda yn syml iawn:

  • Byddwn yn siarad am beth yw DevOps. Gadewch i ni siarad pam mae hyn yn bwysig. Yn flaenorol, roedd DevOps yn allweddair y gwnaethoch chi ei ysgrifennu ar eich ailddechrau a chael + $ 500 mewn cyflog ar unwaith. Nawr mae angen i chi ysgrifennu, er enghraifft, blockchain yn eich ailddechrau er mwyn cael +500 o ddoleri i'ch cyflog.
  • Ac yna, pan fyddwn yn deall ychydig beth yw hyn, byddwn yn siarad am beth yw arferion DevOps. Ond nid cymaint yng nghyd-destun DevOps yn gyffredinol, ond am yr arferion DevOps hynny a allai fod o ddiddordeb i ddatblygwyr. Fe ddywedaf wrthych pam y gallent fod o ddiddordeb i chi. Byddaf yn dweud wrthych pam y dylech wneud hyn o gwbl a sut y gall eich helpu i brofi llai o boen.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Darlun traddodiadol y mae llawer o bobl yn ei ddangos. Dyma beth sy'n digwydd mewn llawer o brosiectau. Dyma pryd mae gennym adrannau datblygu a gweithredu sy'n cefnogi ein meddalwedd. Ac nid yw'r adrannau hyn yn cyfathrebu â'i gilydd.

Efallai, os nad oeddech chi'n gallu ei deimlo mor glir yn yr adrannau DevOps a gweithrediadau, gallwch chi lunio cyfatebiaeth â'r adrannau Dev a SA. Mae yna bobl sy'n datblygu meddalwedd ac mae yna bobl QA sy'n ddrwg o safbwynt y datblygwyr. Er enghraifft, rwy'n ymrwymo fy nghod gwych i'r ystorfa, ac mae rhywfaint o ddrwgdeimlad yn eistedd yno sy'n dychwelyd y cod hwn ataf ac yn dweud bod eich cod yn ddrwg.

Mae hyn i gyd yn digwydd oherwydd nad yw pobl yn cyfathrebu â'i gilydd. Ac maen nhw'n taflu rhai pecynnau, rhai cais i'w gilydd trwy ryw wal o gamddealltwriaeth ac yn ceisio gwneud rhywbeth gyda nhw.

Y wal hon yn union y mae diwylliant DevOps wedi'i gynllunio i'w ddinistrio, h.y. gorfodi pobl i gyfathrebu â’i gilydd ac o leiaf ddeall beth mae gwahanol bobl yn y prosiect yn ei wneud a pham mae eu gwaith yn bwysig.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

A phan fyddwn yn siarad am DevOps, bydd rhywun yn dweud wrthych mai DevOps yw pan fydd gan y prosiect integreiddio parhaus; bydd rhywun yn dweud bod DevOps os yw'r prosiect yn gweithredu'r arfer “isadeiledd fel cod”; bydd rhywun yn dweud mai'r cam cyntaf i DevOps yw canghennog nodwedd, baneri nodwedd.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Yn y bôn, mae hyn i gyd yn wir yn ei ffordd ei hun. Ond dyma'r arferion eithaf sydd gennym. Cyn symud ymlaen at yr arferion hyn, rwy'n awgrymu edrych ar y sleid hon, sy'n dangos y 3 cham o weithredu methodoleg Dev-Ops yn eich prosiect, yn eich cwmni.

Mae gan y sleid hon ail enw answyddogol hefyd. Gallwch chwilio ar-lein i ddarganfod beth yw 3 Mysgedwr DevOps. Mae'n bosibl y byddwch chi'n dod o hyd i'r erthygl hon. Pam 3 Mysgedwr? Isod mae'n dweud: pobl, prosesau a chynhyrchion, h.y. PPP – Porthos, Porthos a Porthos. Dyma 3 Mysgedwr DevOps. Mae'r erthygl hon yn disgrifio'n fanylach pam mae hyn yn bwysig a beth mae'n ei olygu.

Pan ddechreuwch weithredu diwylliant DevOps, mae'n bwysig iawn ei fod yn cael ei weithredu yn y drefn ganlynol.

I ddechrau mae angen i chi siarad â phobl. Ac mae angen i chi esbonio i bobl beth ydyw a sut y gallant gael rhai buddion ohono.

Enw ein cynhadledd yw DotNet Fest. Ac fel y dywedodd y trefnwyr wrthyf, fe wnaethom wahodd cynulleidfa o ddatblygwyr yn bennaf yma, felly rwy'n gobeithio bod y rhan fwyaf o'r bobl yn y neuadd yn ymwneud â datblygu.

Byddwn yn siarad am bobl, byddwn yn siarad am yr hyn y mae datblygwyr am ei wneud bob dydd. Beth maen nhw ei eisiau fwyaf? Maen nhw eisiau ysgrifennu cod newydd, defnyddio fframweithiau newfangled, creu nodweddion newydd. Beth mae datblygwyr ei eisiau leiaf? Trwsio hen chwilod. Rwy'n gobeithio y byddwch yn cytuno â mi. Dyma beth mae'r datblygwyr ei eisiau. Maen nhw eisiau ysgrifennu nodweddion newydd, nid ydyn nhw eisiau trwsio chwilod.

Mae nifer y chwilod y mae datblygwr penodol yn eu cynhyrchu yn dibynnu ar ba mor syth yw ei freichiau a faint maen nhw'n tyfu o'i ysgwyddau, ac nid o'i bocedi casgen. Ond serch hynny, pan fydd gennym brosiect mawr, weithiau mae'n digwydd ei bod yn amhosibl cadw golwg ar bopeth, felly byddai'n braf inni ddefnyddio rhai dulliau a fydd yn ein helpu i ysgrifennu cod mwy sefydlog ac o ansawdd uwch.

Beth mae Sicrwydd Ansawdd ei eisiau fwyaf? Wn i ddim os ydyn nhw yn y neuadd. Mae'n anodd i mi ddweud fy mod i eisiau QA, oherwydd dydw i erioed wedi bod yn un. A dim tramgwydd i'r bois, fe ddywedir fy mod yn gobeithio na fyddaf byth. Ond nid am y rheswm fy mod yn ystyried eu gwaith yn ddiystyr ac yn ddiwerth, ond oherwydd nad wyf yn ystyried fy hun yn berson a allai wneud y gwaith hwn yn effeithlon, felly ni fyddaf hyd yn oed yn ceisio ei wneud. Ond o'r hyn rwy'n ei ddeall, yr hyn nad yw QA yn ei hoffi fwyaf yw mynd i weithio yn y bore, gan redeg rhyw fath o brofion atchweliad yn gyson, camu ar yr un chwilod a adroddwyd ganddynt i'r datblygwyr 3 sbrint yn ôl a dweud: “Pryd fyddwch chi , Monsieur D 'Artagnan, trwsio byg hwn.' Ac mae Monsieur D'Artagnan yn ei ateb: “Ie, ie, ydw, rydw i eisoes wedi ei drwsio.” A sut mae'n digwydd i mi drwsio un byg a gwneud 5 ar hyd y ffordd.

Mae'r bobl sy'n cefnogi'r datrysiad hwn wrth gynhyrchu eisiau i'r ateb hwn weithio heb fygiau, fel nad oes rhaid iddynt ailgychwyn y gweinydd bob dydd Gwener, pan fydd yr holl bobl arferol yn mynd i'r bar. Mae'r datblygwyr a ddefnyddir ddydd Gwener, mae'r gweinyddwyr yn eistedd tan ddydd Sadwrn, yn ceisio sefydlu'r defnydd hwn a'i drwsio.

A phan fyddwch yn esbonio i bobl eu bod wedi'u hanelu at ddatrys yr un problemau, gallwch symud ymlaen i ffurfioli'r prosesau. Mae'n bwysig iawn. Pam? Oherwydd pan rydyn ni'n dweud “ffurfioli,” mae'n bwysig ichi ddisgrifio sut mae'ch prosesau'n digwydd o leiaf yn rhywle ar napcyn. Mae angen i chi ddeall, os ydych chi, er enghraifft, yn defnyddio i amgylchedd QA neu amgylchedd cynhyrchu, yna mae bob amser yn digwydd yn y drefn hon; ar y camau hyn rydym yn rhedeg, er enghraifft, profion uned awtomatig a phrofion UI. Ar ôl lleoli, byddwn yn gwirio a aeth y lleoliad yn dda neu'n wael. Ond mae gennych eisoes restr glir o gamau gweithredu y mae'n rhaid eu hailadrodd dro ar ôl tro pan fyddwch yn eu defnyddio i gynhyrchu.

A dim ond pan fydd eich prosesau wedi'u ffurfioli, y byddwch chi'n dechrau dewis cynhyrchion a fydd yn eich helpu i awtomeiddio'r prosesau hyn.

Yn anffodus, rwy'n aml iawn yn gweld hyn yn digwydd i'r gwrthwyneb. Cyn gynted ag y bydd rhywun yn clywed y gair “DevOps”, maent yn awgrymu gosod Jenkins ar unwaith, oherwydd eu bod yn credu, cyn gynted ag y byddant yn gosod Jenkins, y bydd ganddynt DevOps. Fe wnaethon nhw osod Jenkins, darllen yr erthyglau “Sut i” ar wefan Jenkins, ceisio stwffio prosesau i mewn i'r erthyglau Sut i hyn, ac yna dod at bobl a phlygu pobl drosodd, gan ddweud bod y llyfr yn dweud bod angen i chi ei wneud fel hyn, felly rydyn ni'n ei wneud fel hyn.

Nid arf drwg yw Jenkins. Nid wyf yn bwriadu dweud hynny mewn unrhyw ffordd. Ond dim ond un o'r cynhyrchion yw hwn. A pha gynnyrch a ddefnyddiwch ddylai fod eich penderfyniad olaf, ac nid y cyntaf o bell ffordd. Ni ddylai eich cynnyrch gael ei ysgogi gan ddiwylliant a dulliau gweithredu. Mae hyn yn bwysig iawn i'w ddeall, a dyna pam rydw i'n treulio cymaint o amser ar y sleid hon ac yn esbonio hyn i gyd cyhyd.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Gadewch i ni siarad am arferion DevOps yn gyffredinol. Beth ydyn nhw? Beth yw'r gwahaniaeth? Sut i roi cynnig arnyn nhw? Pam maen nhw'n bwysig?

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Yr enw ar yr arferiad cyntaf y gallech fod wedi clywed amdano yw Integreiddio Parhaus. Efallai bod gan rywun ar y prosiect Integreiddio Parhaus (CI).

Y broblem fwyaf yw hynny amlaf pan fyddaf yn gofyn i berson: “Oes gennych chi CI ar y prosiect?” ac mae'n dweud: “Ie,” yna pan ofynnaf beth mae'n ei wneud, mae'n disgrifio'r broses awtomeiddio gyfan i mi yn llwyr. Nid yw hyn yn hollol wir.

Mewn gwirionedd, mae arfer CI wedi'i anelu at integreiddio'r cod y mae gwahanol bobl yn ei ysgrifennu i ryw fath o sylfaen cod sengl. Dyna i gyd.

Ynghyd â CI, mae arferion eraill ar hyd y ffordd fel arfer - megis Defnydd Parhaus, Rheoli Rhyddhau, ond byddwn yn siarad am hynny yn nes ymlaen.

Mae CI ei hun yn dweud wrthym fod gwahanol bobl yn ysgrifennu cod a rhaid integreiddio'r cod hwn yn barhaus i un sylfaen cod.

Beth mae hyn yn ei roi i ni a pham ei fod yn bwysig? Os oes gennym DotNet, yna mae hynny'n dda, mae'n iaith gryno, gallwn ni lunio ein cais. Os yw'n llunio, yna mae hyn eisoes yn arwydd da. Nid yw hyn yn golygu dim eto, ond dyma'r arwydd da cyntaf y gallwn o leiaf ei lunio.

Yna gallwn redeg rhai profion, sydd hefyd yn arfer ar wahân. Mae'r profion i gyd yn wyrdd - dyma'r ail arwydd da. Ond eto, nid yw hyn yn golygu dim.

Ond pam fyddech chi'n gwneud hyn? Mae gan yr holl arferion y byddaf yn siarad amdanynt heddiw tua'r un gwerth, h.y. tua'r un buddion ac maent hefyd yn cael eu mesur tua'r un ffordd.

Yn gyntaf, mae'n eich galluogi i gyflymu cyflwyno. Sut mae hyn yn caniatáu ichi gyflymu'r broses ddosbarthu? Pan fyddwn yn gwneud rhai newidiadau newydd i'n sylfaen cod, gallwn geisio gwneud rhywbeth gyda'r cod hwn ar unwaith. Nid ydym yn aros nes daw dydd Iau oherwydd ar ddydd Iau rydym yn ei ryddhau i QA Environment, rydym yn ei wneud yn iawn yma ac yma.

Byddaf yn dweud wrthych un stori drist o fy mywyd. Roedd yn amser maith yn ôl, pan oeddwn yn dal yn ifanc a golygus. Nawr rydw i eisoes yn ifanc, yn hardd ac yn smart, ac yn gymedrol. Beth amser yn ôl roeddwn mewn prosiect. Roedd gennym dîm mawr o tua 30 o ddatblygwyr. Ac roedd gennym ni brosiect Menter mawr, mawr a ddatblygodd am tua 10 mlynedd. Ac roedd gennym ni ganghennau gwahanol. Yn yr ystorfa roedd gennym gangen lle roedd datblygwyr yn cerdded. Ac roedd cangen a oedd yn arddangos y fersiwn o'r cod sy'n cael ei gynhyrchu.

Roedd y gangen gynhyrchu 3 mis ar ôl y gangen a oedd ar gael i ddatblygwyr. Beth mae hyn yn ei olygu? Mae hyn yn golygu, cyn gynted ag y bydd gennyf fyg yn rhywle sy'n mynd i gynhyrchu oherwydd bai'r datblygwyr, oherwydd eu bod yn caniatáu hynny, ac oherwydd bai QA, oherwydd iddynt edrych arno, yna mae hyn yn golygu os byddaf yn derbyn dasg ar gyfer hotfix ar gyfer cynhyrchu, yna mae'n rhaid i mi rolio yn ôl fy newidiadau cod 3 mis yn ôl. Mae'n rhaid i mi gofio beth gefais 3 mis yn ôl a cheisio ei drwsio yno.

Os nad ydych wedi cael y profiad hwn eto, gallwch roi cynnig arno ar eich prosiect cartref. Y prif beth yw, peidiwch â rhoi cynnig arni ar un masnachol. Ysgrifennwch ychydig o linellau o god, anghofiwch amdanynt am chwe mis, ac yna dewch yn ôl a cheisiwch esbonio'n gyflym beth yw pwrpas y llinellau cod hynny a sut y gallwch chi eu trwsio neu eu optimeiddio. Mae'n brofiad cyffrous iawn, iawn.

Os oes gennym ni arfer Integreiddio Parhaus, yna mae hyn yn caniatáu inni ei wirio gyda nifer o offer awtomataidd yma ac ar hyn o bryd, cyn gynted ag y byddaf wedi ysgrifennu fy nghod. Efallai na fydd hyn yn rhoi’r darlun llawn i mi, ond serch hynny, bydd yn dileu o leiaf rhai o’r risgiau. Ac os oes unrhyw fyg posibl, byddaf yn gwybod amdano ar hyn o bryd, hynny yw, yn llythrennol mewn ychydig funudau. Ni fydd angen i mi rolio'n ôl 3 mis. Dim ond 2 funud fydd angen i mi rolio'n ôl. Ni fydd peiriant coffi da hyd yn oed yn cael amser i fragu coffi mewn 2 funud, felly mae hynny'n eithaf cŵl.

Mae i hyn y gwerth y gellir ei ailadrodd dro ar ôl tro ar bob prosiect, h.y. nid dim ond yr un y gwnaethoch ei sefydlu arno. Gallwch ailadrodd yr arfer ei hun a bydd CI ei hun yn cael ei ailadrodd ar gyfer pob newid newydd a wnewch i'r prosiect. Mae hyn yn caniatáu ichi optimeiddio adnoddau oherwydd bod eich tîm yn gweithio'n fwy effeithlon. Ni fydd gennych sefyllfa mwyach lle daw byg atoch o'r cod y buoch yn gweithio ag ef 3 mis yn ôl. Ni fyddwch yn cael newid cyd-destun mwyach pan fyddwch yn eistedd ac yn treulio'r ddwy awr gyntaf yn ceisio deall beth ddigwyddodd bryd hynny a mynd i mewn i hanfod y cyd-destun cyn i chi ddechrau cywiro rhywbeth.

Sut gallwn ni fesur llwyddiant neu fethiant yr arfer hwn? Os byddwch yn adrodd i'r bos mawr am yr hyn a weithredwyd gennym ar y prosiect CI, mae'n clywed blah blah blah. Fe wnaethom ei roi ar waith, iawn, ond pam, beth a ddaeth i'n rhan, sut rydym yn ei fesur, pa mor gywir neu anghywir yr ydym yn ei roi ar waith?

Y cyntaf yw y gallwn, diolch i CI, ddefnyddio'n amlach ac yn amlach, ac yn amlach yn union oherwydd bod ein cod yn fwy sefydlog o bosibl. Yn yr un modd, mae ein hamser i ddod o hyd i wall yn cael ei leihau ac mae'r amser i gywiro'r gwall hwn yn cael ei leihau'n union am y rheswm ein bod yn derbyn ateb gan y system yma ac ar hyn o bryd, beth sydd o'i le ar ein cod.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Arfer arall sydd gennym yw'r arfer Profi Awtomatiaeth, sy'n dod yn aml gyda'r arfer CI. Maen nhw'n mynd law yn llaw.

Beth sy'n bwysig i'w ddeall yma? Mae'n bwysig deall bod ein profion yn wahanol. Ac mae pob prawf awtomataidd wedi'i anelu at ddatrys ei broblemau ei hun. Mae gennym, er enghraifft, brofion uned sy’n caniatáu inni brofi modiwl ar wahân, h.y. Sut mae'n gweithio mewn gwactod? Mae hyn yn dda.

Mae gennym hefyd brofion integreiddio sy'n ein galluogi i ddeall sut mae gwahanol fodiwlau yn integreiddio â'i gilydd. Mae hefyd yn dda.

Efallai y bydd gennym ni brofion awtomeiddio UI sy'n ein galluogi i wirio pa mor dda mae'r gwaith gyda'r UI yn bodloni rhai gofynion a osodwyd gan y cwsmer, ac ati.

Gall y profion penodol rydych chi'n eu cynnal effeithio ar ba mor aml rydych chi'n eu rhedeg. Mae profion uned fel arfer yn cael eu hysgrifennu'n fyr ac yn fach. A gellir eu lansio'n rheolaidd.

Os ydym yn sôn am brofion awtomeiddio UI, yna mae'n dda os yw'ch prosiect yn fach. Gall eich profion awtomeiddio UI gymryd peth amser digonol. Ond fel arfer mae prawf awtomeiddio UI yn rhywbeth sy'n cymryd sawl awr ar brosiect mawr. Ac mae'n dda os yw'n ychydig oriau. Yr unig beth yw nad oes diben eu rhedeg ar gyfer pob adeilad. Mae'n gwneud synnwyr eu rhedeg yn y nos. A phan ddaeth pawb i'r gwaith yn y bore: profwyr a datblygwyr, cawsant ryw fath o adroddiad ein bod yn rhedeg yr autotest UI yn y nos a chael y canlyniadau hyn. Ac yma, bydd awr o waith gweinydd a fydd yn gwirio bod eich cynnyrch yn bodloni rhai gofynion yn llawer rhatach nag awr o waith yr un peiriannydd SA, hyd yn oed os yw'n beiriannydd Sicrwydd Ansawdd Iau sy'n gweithio i fwyd a diolch. Yr un peth, bydd awr o weithrediad peiriant yn rhatach. Dyna pam ei bod yn gwneud synnwyr i fuddsoddi ynddo.

Mae gen i brosiect arall rydw i wedi bod yn gweithio arno. Cawsom sbrintiau pythefnos ar y prosiect hwn. Roedd y prosiect yn fawr, yn bwysig i'r sector ariannol, ac ni ellid gwneud camgymeriad. Ac ar ôl sbrint o bythefnos, dilynwyd y cylch datblygu gan broses brofi, a gymerodd 4 wythnos arall. Ceisiwch ddychmygu maint y drasiedi. Rydyn ni'n ysgrifennu cod am bythefnos, yna rydyn ni'n ei wneud fel CodeFreeze, yn ei becynnu i fersiwn newydd o'r cais, ac yn ei gyflwyno i brofwyr. Mae profwyr yn ei brofi am 4 wythnos arall, h.y. Tra eu bod yn ei brofi, mae gennym amser i baratoi dwy fersiwn arall ar eu cyfer. Mae hwn yn achos trist iawn.

A dywedasom wrthynt, os ydych chi am fod yn fwy cynhyrchiol, ei bod yn gwneud synnwyr i chi weithredu arferion Profi Awtomataidd, oherwydd dyma sy'n eich brifo chi yma, ar hyn o bryd.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Ymarfer Defnydd Parhaus. Gwych, rydych chi wedi gwneud adeiladu. Mae hyn eisoes yn dda. Mae eich cod wedi'i lunio. Nawr byddai'n braf defnyddio'r adeilad hwn ar rai amgylchedd. Gadewch i ni ddweud mewn amgylchedd ar gyfer datblygwyr.

Pam ei fod yn bwysig? Yn gyntaf, gallwch edrych ar ba mor llwyddiannus ydych chi gyda'r broses leoli ei hun. Rwyf wedi cwrdd â phrosiectau fel hyn, pan ofynnaf: “Sut ydych chi'n defnyddio fersiwn newydd o'r cais?”, mae'r bechgyn yn dweud wrthyf: “Rydym yn ei gydosod a'i bacio i mewn i archif sip. Rydym yn ei anfon at y gweinyddwr trwy'r post. Mae'r gweinyddwr yn lawrlwytho ac yn ehangu'r archif hon. Ac mae'r swyddfa gyfan yn dechrau gweddïo y bydd y gweinydd yn codi'r fersiwn newydd. ”

Gadewch i ni ddechrau gyda rhywbeth syml. Er enghraifft, maent wedi anghofio rhoi CSS yn yr archif neu wedi anghofio newid yr hashnod yn enw ffeil java-script. A phan fyddwn yn gwneud cais i'r gweinydd, mae'r porwr yn meddwl bod ganddo'r ffeil java-script hon eisoes ac yn penderfynu peidio â'i lawrlwytho. Ac roedd yna hen fersiwn, roedd rhywbeth ar goll. Yn gyffredinol, gall fod llawer o broblemau. Felly, mae'r arfer o Ddefnydd Parhaus yn caniatáu ichi o leiaf brofi beth fyddai'n digwydd pe baech yn cymryd delwedd gyfeirio lân a'i huwchlwytho i amgylchedd newydd hollol lân. Gallwch weld i ble mae hyn yn arwain.

Hefyd, pan fyddwch yn integreiddio cod rhwng eich gilydd, h.y. rhwng y gorchymyn, mae hyn yn caniatáu ichi hefyd weld sut mae'n edrych ar yr UI.

Un o'r problemau sy'n digwydd lle mae llawer o java-script fanila yn cael ei ddefnyddio yw bod dau ddatblygwr wedi datgan yn fyrbwyll newidyn gyda'r un enw yn y gwrthrych ffenestr. Ac yna, yn dibynnu ar eich lwc. Bydd y ffeil java-script sy'n cael ei thynnu allan yn ail yn trosysgrifo newidiadau'r llall. Mae hefyd yn gyffrous iawn. Rydych chi'n dod i mewn: mae un peth yn gweithio i un person, nid yw peth arall yn gweithio i un arall. Ac mae'n “rhyfeddol” pan ddaw'r cyfan allan wrth gynhyrchu.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Yr arfer nesaf sydd gennym yw'r arfer o Adfer Awtomatig, sef dychwelyd i fersiwn flaenorol y cais.

Pam fod hyn yn bwysig i ddatblygwyr? Mae yna rai o hyd sy'n cofio'r 90au pell, pell, pan oedd cyfrifiaduron yn fawr a rhaglenni'n fach. A'r unig ffordd i ddatblygu gwe oedd trwy PHP. Nid yw PHP yn iaith ddrwg, er ei fod.

Ond roedd y broblem yn wahanol. Pan wnaethom ni ddefnyddio fersiwn newydd o'n gwefan php, sut wnaethon ni ei ddefnyddio? Yn fwyaf aml fe wnaethom agor Pell Manager neu rywbeth arall. Ac wedi llwytho'r ffeiliau hyn i FTP. Ac fe sylweddolon ni'n sydyn fod gennym ni fyg bach, bach, er enghraifft, fe wnaethon ni anghofio rhoi hanner colon neu anghofio newid y cyfrinair ar gyfer y gronfa ddata, ac mae cyfrinair ar gyfer y gronfa ddata, sydd ar y gwesteiwr lleol. Ac rydym yn penderfynu cysylltu'n gyflym â FTP a golygu'r ffeiliau yno. Dim ond tân yw hwn! Dyma beth oedd yn boblogaidd yn y 90au.

Ond, os nad ydych wedi edrych ar y calendr, roedd y 90au bron i 30 mlynedd yn ôl. Nawr mae popeth yn digwydd ychydig yn wahanol. A cheisiwch ddychmygu maint y drasiedi pan maen nhw'n dweud wrthych chi: “Fe wnaethon ni anfon at gynhyrchu, ond aeth rhywbeth o'i le yno. Dyma'ch mewngofnodi FTP a'ch cyfrinair, cysylltu â chynhyrchu a'i drwsio'n gyflym yno." Os mai chi yw Chuck Norris, bydd hyn yn gweithio. Os na, yna rydych mewn perygl o drwsio un byg, y byddwch yn gwneud 10 yn fwy. Dyna'n union pam mae'r arfer hwn o ddychwelyd i'r fersiwn flaenorol yn caniatáu ichi gyflawni llawer.

Hyd yn oed pe bai rhywbeth drwg rywsut yn dod i mewn i rywle, yna mae'n ddrwg, ond nid yn angheuol. Gallwch rolio yn ôl i'r fersiwn flaenorol sydd gennych. Galwch gopi wrth gefn, os yw'n haws ei ganfod yn y derminoleg honno. Gallwch rolio'n ôl i'r fersiwn flaenorol hon, a bydd defnyddwyr yn dal i allu gweithio gyda'ch cynnyrch, a bydd gennych amser clustogi digonol. Gallwch chi gymryd hyn i gyd yn bwyllog, heb frys, a'i brofi'n lleol, ei drwsio, ac yna uwchlwytho fersiwn newydd. Mae wir yn gwneud synnwyr i wneud hyn.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Nawr, gadewch i ni geisio cyfuno rhywsut y ddau arfer blaenorol gyda'i gilydd. Byddwn yn cael trydydd un o'r enw Rheoli Rhyddhau.

Pan fyddwn yn sôn am Ddefnydd Parhaus yn ei ffurf glasurol, dywedwn fod yn rhaid inni dynnu cod o ryw gangen o'r ystorfa, ei lunio a'i ddefnyddio. Mae'n dda os oes gennym yr un amgylchedd. Os oes gennym ni sawl amgylchedd, mae hyn yn golygu bod yn rhaid i ni dynnu'r cod bob tro, hyd yn oed o'r un ymrwymiad. Byddwn yn ei dynnu allan bob tro, byddwn yn ei adeiladu bob tro a byddwn yn ei ddefnyddio mewn amgylchedd newydd. Yn gyntaf, mae hwn yn amser, oherwydd i adeiladu prosiect, os oes gennych un mawr ac yn dod o'r 90au, yna gall gymryd sawl awr.

Eithr, mae tristwch arall. Pan fyddwch chi'n adeiladu, hyd yn oed ar yr un peiriant, byddwch chi'n adeiladu'r un ffynonellau, nid oes gennych chi unrhyw sicrwydd o hyd bod y peiriant hwn yn yr un cyflwr ag yr oedd yn ystod yr adeiladu diwethaf.

Gadewch i ni ddweud bod rhywun wedi dod i mewn a diweddaru DotNet i chi neu, i'r gwrthwyneb, penderfynodd rhywun ddileu rhywbeth. Ac yna mae gennych anghyseinedd gwybyddol ein bod, o'r ymrwymiad hwn bythefnos yn ôl, yn adeiladu adeilad a bod popeth yn iawn, ond yn awr mae'n ymddangos fel yr un peiriant, yr un ymrwymiad, yr un cod yr ydym yn ceisio ei adeiladu, ond nid yw'n gweithio. . Byddwch yn delio â hyn am amser hir ac nid yw'n ffaith y byddwch yn ei ddarganfod. O leiaf, byddwch chi'n difetha'ch nerfau'n fawr.

Felly, mae arfer Rheoli Rhyddhau yn awgrymu cyflwyno tyniad ychwanegol a elwir yn ystorfa arteffactau neu oriel neu lyfrgell. Gallwch ei alw beth bynnag y dymunwch.

Y prif syniad yw, cyn gynted ag y bydd gennym ryw fath o ymrwymiad yno, dyweder, mewn cangen yr ydym yn barod i'w defnyddio i'n gwahanol amgylcheddau, ein bod yn casglu ceisiadau gan yr ymrwymiad hwn a phopeth sydd ei angen arnom ar gyfer y cais hwn, rydym yn ei bacio. i mewn i archif zip a'i gadw mewn rhywfaint o storfa ddibynadwy. Ac o'r storfa hon gallwn gael yr archif zip hwn ar unrhyw adeg.

Yna rydyn ni'n ei gymryd ac yn ei ddefnyddio'n awtomatig i'r amgylchedd datblygu. Rydyn ni'n rasio yno, ac os yw popeth yn dda, yna rydyn ni'n anfon i'r llwyfan. Os yw popeth yn iawn, yna rydym yn defnyddio'r un archif i gynhyrchu, yr un deuaidd, a luniwyd yn union unwaith.

Yn ogystal, pan fydd gennym oriel fel hon, mae hefyd yn ein helpu i fynd i'r afael â'r risgiau y gwnaethom fynd i'r afael â hwy ar y sleid olaf pan wnaethom siarad am ddychwelyd i'r fersiwn flaenorol. Os gwnaethoch chi anfon rhywbeth o'i le ar ddamwain, gallwch chi bob amser gymryd unrhyw fersiwn flaenorol arall o'r oriel hon a'i ddad-leoli i'r amgylcheddau hyn yn yr un ffordd. Mae hyn yn caniatáu ichi ddychwelyd yn hawdd i'r fersiwn flaenorol os aiff rhywbeth o'i le.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Mae yna arfer gwych arall. Rydych chi a minnau i gyd yn deall, pan fyddwn yn rholio ein ceisiadau yn ôl i fersiwn flaenorol, y gallai hyn olygu bod angen seilwaith y fersiwn flaenorol arnom hefyd.

Pan fyddwn yn siarad am seilwaith rhithwir, mae llawer o bobl yn meddwl bod hyn yn rhywbeth y mae gweinyddwyr wedi'i sefydlu. Ac os oes angen, dyweder, i gael gweinydd newydd yr ydych am brofi fersiwn newydd o'ch cais, yna rhaid i chi ysgrifennu tocyn i'r gweinyddwyr neu devops. Bydd Devops yn cymryd 3 wythnos ar gyfer hyn. Ac ar ôl 3 wythnos byddant yn dweud wrthych ein bod wedi gosod peiriant rhithwir i chi, gydag un craidd, dau gigabeit o RAM a gweinydd Windows heb DotNet. Rydych chi'n dweud: “Ond roeddwn i eisiau DotNet.” Maen nhw: “Iawn, dewch yn ôl mewn 3 wythnos.”

Y syniad yw, trwy ddefnyddio Seilwaith fel arferion Cod, y gallwch drin eich seilwaith rhithwir fel adnodd arall yn unig.

Efallai, os oes unrhyw un ohonoch yn datblygu cymwysiadau ar DotNet, efallai eich bod wedi clywed am lyfrgell o'r enw Endity Framework. Ac efallai eich bod hyd yn oed wedi clywed bod Fframwaith Endid yn un o'r dulliau y mae Microsoft yn eu gwthio'n weithredol. Ar gyfer gweithio gyda chronfa ddata, mae hwn yn ddull a elwir yn Code First. Dyma pan fyddwch chi'n disgrifio mewn cod sut rydych chi am i'ch cronfa ddata edrych. Ac yna rydych chi'n defnyddio'r cais. Mae'n cysylltu â'r gronfa ddata, mae'n penderfynu pa dablau sydd yno a pha dablau nad ydynt, ac yn creu popeth sydd ei angen arnoch.

Gallwch chi wneud yr un peth gyda'ch seilwaith. Nid oes unrhyw wahaniaeth rhwng a oes angen cronfa ddata arnoch ar gyfer prosiect neu a oes angen gweinydd Windows arnoch ar gyfer prosiect. Dim ond adnodd ydyw. A gallwch chi awtomeiddio creu'r adnodd hwn, gallwch chi awtomeiddio cyfluniad yr adnodd hwn. Yn unol â hynny, bob tro y byddwch am brofi rhai cysyniad newydd, rhyw ddull newydd, ni fydd angen i chi ysgrifennu tocyn i devops, gallwch ddefnyddio seilwaith ynysig i chi'ch hun o dempledi parod, o sgriptiau parod a'i roi ar waith. yno eich holl arbrofion. Gallwch ddileu hwn, cael rhai canlyniadau ac adrodd ymhellach amdano.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Yr arfer nesaf, sydd hefyd yn bodoli ac sydd hefyd yn bwysig, ond y mae ychydig o bobl yn ei ddefnyddio, yw Monitro Perfformiad Cymwysiadau.

Roeddwn i eisiau dweud un peth yn unig am Fonitro Perfformiad Ceisiadau. Beth sydd bwysicaf am yr arfer hwn? Dyma beth yw Monitro Perfformiad Cymhwysiad tua'r un peth â thrwsio fflat. Nid yw hon yn gyflwr terfynol, mae'n broses. Mae angen i chi ei wneud yn rheolaidd.

Mewn ffordd dda, byddai'n dda cynnal Monitro Perfformiad Ceisiadau ar bron bob adeilad, er, fel y deallwch, nid yw hyn bob amser yn bosibl. Ond, o leiaf, mae angen ei wneud ar gyfer pob datganiad.

Pam ei fod yn bwysig? Oherwydd os byddwch chi'n profi gostyngiad mewn perfformiad yn sydyn, yna mae angen i chi ddeall yn glir pam. Os oes gan eich tîm, dyweder, sbrintiau pythefnos, yna o leiaf unwaith bob pythefnos dylech ddefnyddio'ch cais i ryw weinydd ar wahân, lle mae gennych brosesydd wedi'i osod yn glir, RAM, disgiau, ac ati. A rhedeg y rhai yr un profion perfformiad . Rydych chi'n cael y canlyniad. Gweld sut mae wedi newid ers y sbrint blaenorol.

Ac os byddwch chi'n darganfod bod y gostyngiad wedi gostwng yn sydyn yn rhywle, bydd yn golygu mai dim ond oherwydd y newidiadau a ddigwyddodd dros y pythefnos diwethaf y bu hynny. Bydd hyn yn eich galluogi i adnabod a thrwsio'r broblem yn llawer cyflymach. Ac eto, mae'r rhain yn fras yr un metrigau y gallwch chi eu defnyddio i fesur pa mor llwyddiannus y gwnaethoch chi hynny.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Yr arfer nesaf sydd gennym yw'r practis Rheoli Ffurfweddu. Ychydig iawn sy'n cymryd hyn o ddifrif. Ond credwch chi fi, mae hyn mewn gwirionedd yn beth difrifol iawn.

Cafwyd stori ddoniol yn ddiweddar. Daeth y dynion ataf a dweud: “Helpwch ni i gynnal archwiliad diogelwch o’n cais.” Rydym yn edrych ar y cod gyda'n gilydd am amser hir, maent yn dweud wrthyf am y cais, yn tynnu diagramau. A plws neu finws roedd popeth yn rhesymegol, yn ddealladwy, yn ddiogel, ond roedd un OND! Roedd ganddynt ffeiliau cyfluniad yn eu rheolaeth ffynhonnell, gan gynnwys y rhai o gynhyrchu gyda'r gronfa ddata IP, gyda mewngofnodi a chyfrineiriau ar gyfer cysylltu â'r cronfeydd data hyn, ac ati.

Ac rwy'n dweud: “Bois, iawn, rydych chi wedi cau'ch amgylchedd cynhyrchu gyda wal dân, ond mae'r ffaith bod gennych chi'r mewngofnodi a'r cyfrinair ar gyfer y gronfa ddata gynhyrchu yn union yn y rheolaeth ffynhonnell a gall unrhyw ddatblygwr ei ddarllen eisoes yn risg diogelwch enfawr . Ac ni waeth pa mor ddiogel iawn yw eich cais o safbwynt cod, os byddwch chi'n ei adael mewn rheolaeth ffynhonnell, yna ni fyddwch byth yn pasio unrhyw archwiliad yn unman." Dyna beth rwy'n siarad amdano.

Rheoli cyfluniad. Efallai bod gennym ni wahanol ffurfweddiadau mewn gwahanol amgylcheddau. Er enghraifft, efallai y bydd gennym wahanol fewngofnodi a chyfrineiriau ar gyfer cronfeydd data ar gyfer QA, demo, amgylchedd cynhyrchu, ac ati.

Gall y cyfluniad hwn fod yn awtomataidd hefyd. Dylai bob amser fod ar wahân i'r cais ei hun. Pam? Oherwydd ichi adeiladu'r cais unwaith, ac yna nid yw'r rhaglen yn poeni a ydych chi'n cysylltu â'r gweinydd SQL trwy'r fath ac IP o'r fath neu IP o'r fath, dylai weithio yr un peth. Felly, os yn sydyn mae un ohonoch chi'n dal i godio'r llinyn cysylltu yn y cod caled, yna cofiwch y byddaf yn dod o hyd i chi ac yn eich cosbi os byddwch chi'n cael eich hun ar yr un prosiect â mi. Mae hyn bob amser yn cael ei roi mewn ffurfweddiad ar wahân, er enghraifft, yn web.config.

Ac mae'r cyfluniad hwn eisoes yn cael ei reoli ar wahân, h.y. dyma'r union foment y gall datblygwr a gweinyddwr ddod i eistedd yn yr un ystafell. A gall y datblygwr ddweud: “Edrychwch, dyma deuaidd fy nghais. Maen nhw'n gweithio. Mae angen cronfa ddata ar y rhaglen i weithio. Yma wrth ymyl y binaries mae ffeil. Yn y ffeil hon, mae'r maes hwn yn gyfrifol am y mewngofnodi, mae hyn ar gyfer y cyfrinair, mae hyn ar gyfer yr IP. Ei ddefnyddio yn unrhyw le." Ac mae'n syml ac yn glir i'r gweinyddwr. Gall ei ddefnyddio yn unrhyw le mewn gwirionedd trwy reoli'r cyfluniad hwn.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

Ac mae'r arfer olaf yr hoffwn siarad amdano yn arfer sy'n gysylltiedig iawn, iawn â chymylau. Ac mae'n dod â'r effaith fwyaf os ydych chi'n gweithio yn y cwmwl. Mae hyn yn cael gwared awtomatig o'ch amgylchedd.

Rwy'n gwybod bod nifer o bobl yn y gynhadledd hon o'r timau rwy'n gweithio gyda nhw. A chyda'r holl dimau rwy'n gweithio gyda nhw, rydyn ni'n defnyddio'r arfer hwn.

Pam? Wrth gwrs, byddai'n wych pe bai gan bob datblygwr beiriant rhithwir a fyddai'n gweithio 24/7. Ond efallai bod hyn yn newyddion i chi, efallai na wnaethoch chi dalu sylw, ond nid yw'r datblygwr ei hun yn gweithio 24/7. Mae datblygwr fel arfer yn gweithio 8 awr y dydd. Hyd yn oed os yw'n dod i'r gwaith yn gynnar, mae'n cael cinio mawr ac yn mynd i'r gampfa. Gadewch iddo fod yn 12 awr y dydd pan fydd y datblygwr yn defnyddio'r adnoddau hyn mewn gwirionedd. Yn ôl ein deddfwriaeth, mae gennym ni 5 allan o 7 diwrnod yr wythnos sy’n cael eu hystyried yn ddyddiau gwaith.

Yn unol â hynny, yn ystod yr wythnos ni ddylai'r peiriant hwn weithio 24 awr, ond dim ond 12, ac ar benwythnosau ni ddylai'r peiriant hwn weithio o gwbl. Mae'n ymddangos bod popeth yn syml iawn, ond beth sy'n bwysig i'w ddweud yma? Trwy weithredu'r arfer syml hwn ar yr amserlen sylfaenol hon, mae'n caniatáu ichi leihau'r gost o gynnal a chadw'r amgylcheddau hyn 70%, h.y. cymeroch bris eich dev, QA, demo, amgylchedd a'i rannu â 3.

Y cwestiwn yw, beth i'w wneud gyda gweddill yr arian? Er enghraifft, dylai'r datblygwyr brynu ReSharper os nad ydyn nhw wedi gwneud hynny eisoes. Neu gael parti coctel. Os oedd gennych chi un amgylchedd yn flaenorol lle roedd dev a QA yn pori, a dyna ni, nawr gallwch chi wneud 3 o wahanol rai a fydd yn cael eu hynysu, ac ni fydd pobl yn ymyrryd â'i gilydd.

Arferion DevOps gorau ar gyfer datblygwyr. Anton Boyko (2017)

O ran y sleid gyda mesur perfformiad parhaus, sut y gallwn gymharu perfformiad os oedd gennym 1 o gofnodion yn y gronfa ddata yn y prosiect, dau fis yn ddiweddarach mae miliwn? Sut i ddeall pam a beth yw pwynt mesur perfformiad?

Mae hwn yn gwestiwn da, oherwydd dylech bob amser fesur perfformiad ar yr un adnoddau. Hynny yw, rydych chi'n cyflwyno cod newydd, rydych chi'n mesur perfformiad ar y cod newydd. Er enghraifft, mae angen i chi brofi gwahanol senarios perfformiad, gadewch i ni ddweud eich bod am brofi sut mae'r cais yn perfformio ar lwyth ysgafn, lle mae 1 o ddefnyddwyr a maint y gronfa ddata yw 000 gigabeit. Fe wnaethoch chi ei fesur a chael y niferoedd. Nesaf rydym yn cymryd senario arall. Er enghraifft, 5 o ddefnyddwyr, maint cronfa ddata 5 terabyte. Cawsom y canlyniadau a'u cofio.

Beth sy'n bwysig yma? Y peth pwysig yma yw, yn dibynnu ar y senario, maint y data, nifer y defnyddwyr ar yr un pryd, ac ati, efallai y byddwch chi'n rhedeg i derfynau penodol. Er enghraifft, i derfyn cerdyn rhwydwaith, neu i derfyn gyriant caled, neu i derfyn galluoedd prosesydd. Dyma beth sy'n bwysig i chi ei ddeall. Mewn gwahanol senarios rydych chi'n rhedeg i mewn i derfynau penodol. Ac mae angen i chi ddeall y niferoedd pan fyddwch chi'n eu taro.

A ydym yn sôn am fesur perfformiad mewn amgylchedd prawf arbennig? Hynny yw, nid yw hyn yn cynhyrchu?

Ydy, nid yw hyn yn gynhyrchiad, mae hwn yn amgylchedd prawf, sydd bob amser yr un peth fel y gallwch ei gymharu â mesuriadau blaenorol.

Wedi deall diolch!

Os nad oes cwestiynau, credaf y gallwn orffen. Diolch!

Ffynhonnell: hab.com

Ychwanegu sylw