Sûret:
Silav hemû! Em endezyarên otomasyonê ji pargîdaniyê ne û em ji bo pêşkeftina hilberên pargîdaniyê piştgirî peyda dikin: em hemî lûleya meclîsê ji pêkanîna rêzek kodê ji hêla pêşdebiran ve heya weşandina hilberên qedandî û destûrnameyên li ser serverên nûvekirinê piştgirî dikin. Bi nefermî, ji me re endezyarên DevOps tê gotin. Di vê gotarê de em dixwazin behsa qonaxên teknolojîk ên pêvajoya hilberîna nermalavê bikin, em wan çawa dibînin û em wan çawa dabeş dikin.
Ji materyalê hûn ê li ser tevliheviya hevrêziya pêşkeftina pir-hilberan fêr bibin, nexşeyek teknolojîk çi ye û ew çawa ji bo organîzekirin û dubarekirina çareseriyan dibe alîkar, pêvajoya pêşkeftinê ji kîjan qonax û gavên sereke pêk tê, deverên berpirsiyar çawa têne veqetandin. di navbera DevOps û tîmên di pargîdaniya me de.
Di derbarê Chaos û DevOps de
Ka em bi kurtî destnîşan bikin ku têgeha DevOps amûr û karûbarên pêşkeftinê, û her weha metodolojî û pratîkên çêtirîn ji bo karanîna wan vedihewîne. Ka em gerdûnî ronî bikin цель ji pêkanîna ramanên DevOps di pargîdaniya me de: ev kêmkirina domdar a lêçûna hilberandin û domandina hilberan e di warê mîqdar de (saet-man an makîne-saet, CPU, RAM, Dîsk hwd.). Awayê herî hêsan û eşkere ji bo kêmkirina lêçûna giştî ya pêşkeftinê di asta pargîdanî de ev e kêmkirina lêçûna pêkanîna karên rêzikên tîpîk di hemû qonaxên hilberînê de. Lê ev qonax çi ne, çawa dikarin ji pêvajoya giştî cuda bibin, ji çi gavan pêk tên?
Dema ku pargîdaniyek yek hilberek pêşve dike, her tişt kêm-zêde zelal e: bi gelemperî nexşeyek rê û nexşeyek pêşkeftinê ya gelemperî heye. Lê gava ku rêza hilberan berfireh bibe û hilber bêtir hebin meriv çi bike? Di nihêrîna pêşîn de, wan pêvajo û xetên civandinê yên mîna hev hene û lîstika "cudahiyên X bibînin" di têketin û nivîsan de dest pê dike. Ger jixwe 5+ proje di pêşkeftina çalak de hebin û ji bo çend guhertoyên ku di çend salan de hatine pêşve xistin de piştgirî hewce ye? Ma em dixwazin di lûleyên hilberan de bi qasî ku pêkan çareseriyan ji nû ve bikar bînin an em amade ne ku ji bo her yekê ji bo pêşkeftina bêhempa drav xerc bikin?
Meriv çawa hevsengiyek di navbera bêhempabûn û rêzebûna çareseriyan de peyda dike?
Van pirsan ji sala 2015-an pê ve her ku diçe bêtir û bêtir derdikevin pêşberî me. Hejmara hilberan zêde bû, û me hewl da ku beşa xweya otomasyonê (DevOps), ku xetên kombûnê yên van hilberan piştgirî dike, bi kêmanî berfirehtir bikin. Di heman demê de, min dixwest ku di navbera hilberan de bi qasî ku pêkan çareseriyan dubare bikim. Jixwe, çima heman tiştî di deh hilberan de bi awayên cûda dikin?
Rêveberê Pêşveçûnê: "Gelîno, em dikarin bi rengekî binirxînin ku DevOps ji bo hilberan çi dike?"
Em in: "Em nizanin, me ev pirs nekiriye, lê divê kîjan nîşanan bêne hesibandin?"
Rêveberê Pêşveçûnê: "Kî dizane! Ponijîn..."
Wek di wî fîlmê navdar de: “Ez diçim otêlê!..” - “Ew... Tu dikarî rê nîşanî min bidî?” Piştî ku fikirîn, em gihîştin wê encamê ku pêşî hewce ye ku em li ser rewşa dawî ya hilberan biryar bidin; ev bû armanca me ya yekem.
Ji ber vê yekê, hûn çawa dikarin bi dehan hilberan bi tîmên pir mezin ên ji 10 û 200 kesan re analîz bikin û dema ku çareseriyan dubare dikin metrîkên pîvandî diyar bikin?
1: 0 ji bo Chaos, an DevOps li ser blades
Me bi hewldana sepandina diagramên IDEF0 û diagramên cihêreng ên pêvajoya karsaziyê ji rêzikên BPwin dest pê kir. Tevlihevî piştî çargoşeya pêncemîn a qonaxa din a projeya din dest pê kir, û ev çargoşe ji bo her projeyekê dikare di 50+ gavan de di dûvika pythonek dirêj de were kişandin. Min xwe xemgîn kir û xwest ez li heyvê biqîrim - ew qet li hev nedihat.
Karên hilberîna tîpîk
Modelkirina pêvajoyên hilberînê karek pir tevlihev û bi êş e: hûn hewce ne ku gelek daneyan ji dezgeh û zincîreyên hilberînê yên cihêreng berhev bikin, pêvajo bikin û analîz bikin. Hûn dikarin li ser vê gotarê bêtir bixwînin "".
Dema ku me dest bi modela pêvajoya hilberîna xwe kir, me armancek taybetî hebû - ku em ji her karmendê ku di pêşvebirina hilberên pargîdaniya xwe de beşdar e û ji rêvebirên projeyê re ragihînin:
- çawa hilber û pêkhateyên wan, ji pêkanîna rêzek kodê dest pê dikin, di forma sazker û nûvekirinê de digihîjin xerîdar,
- çi çavkanî di her qonaxa hilberîna hilberê de têne peyda kirin,
- di her qonaxê de çi xizmet hene,
- ji bo her qonaxê qadên berpirsiyariyê çawa têne diyar kirin,
- çi girêbestên di ketin û derketina her qonaxê de hene.
Li ser wêneyê bikirtînin da ku di mezinahiya tevahî de vekin
Karê me di pargîdaniyê de li çend deverên fonksiyonel têne dabeş kirin. Beşa binesaziyê bi xweşbînkirina xebata hemî çavkaniyên hardware yên beşê, û her weha otomatîzekirina makîneyên virtual û jîngehê li ser wan mijûl e. Rêvebiriya çavdêriyê kontrola li ser performansa karûbaran 24/7 peyda dike; Em çavdêriyê jî wekî karûbarek ji bo pêşdebiran peyda dikin. Rêvebiriya xebatê ji bo birêvebirina pêvajoyên pêşkeftin û ceribandinê, analîzkirina rewşa kodê, û bidestxistina analîtîkên li ser projeyan amûran peyda dike. Û di dawiyê de, rêberiya webdev weşana weşanên li ser serverên nûvekirina GUS û FLUS, û hem jî lîsansa hilberan bi karanîna karûbarê LicenseLab piştrast dike. Ji bo piştgirîkirina xeta hilberînê, em ji bo pêşdebiran gelek karûbarên piştgirî yên cihêreng saz dikin û diparêzin (hûn dikarin di civînên kevn de li çîrokên hin ji wan guhdarî bikin: и). Em di heman demê de amûrên otomasyona navxweyî jî pêşdixin .
Di van pênc salên borî de, xebata me gelek operasyonên mîna û rûtîn berhev kirin, û bi navê karên tîpîk, çareseriya ku bi tevahî an jî qismî otomatîk e, ji bo lîstikvanan zehmetiyan dernaxe û xebatek girîng hewce nake. Li gel qadên pêşeng, me karên weha analîz kirin û karîbûn kategoriyên kesane yên xebatê, an jî nas bikin qonaxên hilberînê, qonax li gavên nayên dabeş kirin têne dabeş kirin, û çend qonax lê zêde dibin zincîra pêvajoya hilberînê.
Mînaka herî hêsan a zincîreyek teknolojî qonaxên kombûn, bicihkirin û ceribandina her yek ji hilberên me di hundurê pargîdaniyê de ye. Mînakî, qonaxa avakirinê ji gelek gavên standard ên cihêreng pêk tê: dakêşana çavkaniyan ji GitLab, amadekirina pêwendiyan û pirtûkxaneyên sêyemîn, ceribandina yekîneyê û analîza koda statîk, li ser GitLab CI-ya skrîptek çêkirinê, weşandina huneran li depoyek li ser Bi navgîniya amûra meya ChangelogBuilder-ê ya navxweyî ve notên serbestberdanê çêdikin û çêdikin.
Hûn dikarin di gotarên me yên din ên li ser Habré de li ser karên DevOps-ê yên tîpîk bixwînin:"And"".
Gelek zincîrên hilberîna tîpîk çêdibin pêvajoya çêkirinê. Nêzîkatiya standard ji bo danasîna pêvajoyan ev e ku modelên IDEF0 yên fonksiyonel bikar bînin.
Mînakek modelkirina pêvajoyek CI ya hilberînê
Me girîngiyek taybetî da pêşxistina projeyên standard ji bo pergalek entegrasyonê ya berdewam. Vê yekê îmkan da ku yekbûna projeyan bi dest bixe, bi navê ronî bike diagrama berdana avahîyan bi promosyonên.
Li vir çawa dixebite. Hemî proje tîpîk xuya dikin: ew veavakirina meclîsên ku diçin depoya wêneya wêneyê ya li ser Artifactory vedigirin, pişt re ew li ser maseyên ceribandinê têne bicîh kirin û ceribandin, û dûv re berbi depoya berdanê têne pêşve xistin. Karûbarê Artifactory xalek yekane ye ji bo belavkirina hemî berhemên çêkirinê di navbera tîm û karûbarên din de.
Ger em nexşeya berdana xwe pir hêsan bikin û giştî bikin, ew qonaxên jêrîn vedigire:
- avakirina hilberê cross-platform,
- şandina li ser maseyên ceribandinê,
- destpêkirina ceribandinên fonksiyonel û yên din,
- teşwîqkirina meclîsên ceribandin ji bo berdana depoyên li ser Artifactory,
- belavkirina weşanên ku ji bo nûvekirina serveran ava dike,
- radestkirina avahî û nûvekirina hilberînê,
- destpêkirina sazkirinê û nûvekirinên hilberê.
Werin em, wekî mînak, modela teknolojîk a vê pilana serbestberdana tîpîk (li vir bi tenê wekî Model tê binav kirin) di forma modelek IDEF0 ya fonksiyonel de bihesibînin. Ew qonaxên sereke yên pêvajoya meya CI nîşan dide. Modelên IDEF0 yên ku tê gotin bikar tînin Nîşana ICOM (Kêtin-Kontrol-Derketin-Mekanîzma) ku di her qonaxê de çi çavkaniyan têne bikar anîn, li gorî kîjan rêgez û pêdiviyan kar tê kirin, encam çi ye û kîjan mekanîzma, xizmet an jî mirov qonaxek taybetî pêk tînin diyar bike.
Li ser wêneyê bikirtînin da ku di mezinahiya tevahî de vekin
Wekî qaîdeyek, di modelên fonksiyonel de ew hêsantir e ku meriv ravekirina pêvajoyan hilweşîne û hûrgul bike. Lê her ku jimara hêmanan zêde dibe, famkirina tiştekî li ser wan her ku diçe dijwartir dibe. Lê di pêşkeftina rastîn de qonaxên alîkar jî hene: çavdêrîkirin, pejirandina hilberê, otomatîkkirina pêvajoyên xebatê û yên din. Tam ji ber pirsgirêka pîvandinê ye ku me dev ji vê şirovekirinê berda.
Jidayikbûna Hêvî
Di pirtûkekê de em rastî nexşeyên Sovyetê yên kevin ên ku pêvajoyên teknolojîk vedibêjin (ku, bi awayê, îro jî di gelek pargîdanî û zanîngehan yên dewletê de têne bikar anîn) hatin. Bisekine, bisekine, pêvajoyek me ya teknolojiyê jî heye!.. Qonax, encam, metris, hewcedarî, nîşanker û hwd., hwd hene... Çima hewl nadin ku nexşeyên teknolojîk li ser veguhezên hilberên xwe bicîh bikin? Hestek hebû: "Ev e! Me mijara rast dît, wextê wê ye ku em lêkdanek baş bidin!
Di tabloyek hêsan de, me biryar da ku hilberan li gorî stûnan, û qonaxên teknolojîk û gavên hilbera hilberê bi rêzan tomar bikin. Qonax tiştekî mezin e, wek qonaxa komkirina hilberekê. Û gav tiştek piçûktir û berfirehtir in, mînakî, gava dakêşana koda çavkaniyê ji servera avakirinê re an gavê berhevkirina kodê.
Li xaçerêyên rêz û stûnên nexşeyê, em ji bo qonax û hilberek taybetî statûyan danîne. Gelek dewlet ji bo statuyan hatine diyarkirin:
- Daneyên tune - an ne pratîkî. Pêdivî ye ku meriv daxwaziya qonaxek di hilberê de analîz bike. An analîz jixwe hatiye kirin, lê qonax niha ne hewce ye an jî ji hêla aborî ve ne rastdar e.
- Taloq kirin - an naha ne têkildar. Ev qonax di boriyê de pêwîst e, lê enerjî ji bo cîbicîkirina wê îsal nîne.
- Plankirin. Qonax ji bo pêkanîna îsal tê plankirin.
- Pêk anîn. Qonaxa di boriyê de bi qasî ku tê xwestin tê meşandin.
Bi dagirtina tabloyê proje bi proje dest pê kir. Pêşî, me qonax û gavên projeyekê dabeş kir û statûyên wan tomar kir. Paşê wan projeya din hildan, statûyên tê de tomar kirin û qonax û gavên ku di projeyên berê de tunebûn lê zêde kirin. Di encamê de, me qonax û gavên tevahiya lûleya hilberîna xwe û statûyên wan di projeyek taybetî de wergirtin. Encam tiştek mîna matrixek jêhatîbûnê ya ji bo veguhezkarek xwarinê ye. Me ji matrixek weha re got nexşeyek teknolojîk.
Bi alîkariya nexşeya teknolojîk, em ji hêla metrolojîkî ve bi tîmê re li ser plansaziyên xebatê yên salê û armancên ku em dixwazin bi hev re bi dest bixin re li hev dikin: kîjan qonaxên ku em îsal li projeyê zêde dikin, û yên ku em ji bo paşê dihêlin. Di heman demê de, dema ku em dixebitin, dibe ku em pêşveçûnên gavên ku me ji bo tenê yek hilberek qedandine bibînin. Dûv re em nexşeya xwe berfireh dikin û vê pêşkeftinê wekî qonaxek an gavek nû destnîşan dikin, dûv re em ji bo her hilberek analîzek çêdikin û gengaziya dubarekirina çêtirbûnê fêr dibin.
Dibe ku ew ji me re îtiraz bikin: “Ev hemû baş e, helbet, lê bi demê re dê hejmara gav û qonaxan pir zêde bibe. Derewînê bedew û biçûk?
Me ji bo her qonax û gavê ravekirinên standard û bi tevahî bêkêmasî yên hewcedariyê destnîşan kir da ku di hundurê pargîdaniyê de ew ji hêla her kesî ve bi heman rengî werin fam kirin. Bi demê re, her ku çêtirkirin têne bicîh kirin, dibe ku gavek di qonaxek an gavek din de were kişandin - wê hingê ew ê hilweşin. Di heman demê de, hemî hewcedarî û hûrgelên teknolojîk di nav hewcedariyên qonax an gavê gelemperî de cih digirin.
Meriv çawa bandora çareseriyên dubarekirinê dinirxîne? Em nêzîkatiyek pir hêsan bikar tînin: em lêçûnên sermayeya destpêkê ji bo pêkanîna qonaxek nû bi lêçûnên hilberên giştî yên salane ve girê didin, û dûv re di dema dubarekirinê de wan di nav her kesî de dabeş dikin.
Beşên pêşveçûnê jixwe wekî qonax û gavên li ser nexşeyê têne xuyang kirin. Em dikarin bi danasîna otomasyonê ji bo qonaxên tîpîk bandorê li kêmkirina lêçûnên hilberê bikin. Piştî vê yekê, em guheztinên di taybetmendiyên kalîteyê, metrîkên mîqdar û qezenca ku ji hêla tîmê ve hatî wergirtin (di demjimêrên mirov an makîne-saetên xilaskirî de) hesab dikin.
Nexşeya teknolojî ya pêvajoya hilberînê
Ger em hemî qonax û gavên xwe bavêjin, wan bi etîketan şîfre bikin û wan di yek zincîrê de berfireh bikin, wê hingê ew ê pir dirêj û nefêm bibe (bi rastî heman "duvika python" ya ku me di destpêka gotarê de behs kir) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Ev qonaxên komkirina hilberan in [Avakirin], şandina wan ji bo ceribandina serveran [Damezrandin], ceribandina [Test], pêşvebirina meclîsan ji bo berdana depoyan li ser bingeha encamên ceribandinê [Promote], hilberîn û weşandina lîsansan [Lîsans], weşandin [Weşandin] li ser servera nûvekirina GUS-ê û gihandina nûvekirinên FLUS ji pêşkêşkeran re, sazkirin û nûvekirina pêkhateyên hilberê li ser binesaziya xerîdar bi karanîna Rêvebiriya Vesazkirina Hilberê [Sazkirin], û her weha berhevkirina telemetry [Telemetry] ji hilberên sazkirî.
Ji bilî wan, em dikarin qonaxên cihêreng jî ji hev cuda bikin: şopandina rewşa binesaziyê [InfMonitoring], birêvebirina guhertoyên koda çavkaniyê [SourceCodeControl], amadekirina jîngeha kombûnê [Amadekirin], rêveberiya projeyê [Rêveçûna xebatê], peydakirina tîmê bi amûrên ragihandinê [ Ragihandin], pejirandina hilberê [Sertîfîkasyon] û misogerkirina xweseriya pêvajoyên CI [CISelfSufficiency] (mînak, serxwebûna meclîsan ji Înternetê). Em ê di pêvajoyên xwe de bi dehan gavan jî nehesibînin, ji ber ku ew pir taybetî ne.
Ger hûn wê di formê de xeyal bikin dê pir hêsantir were fam kirin û li tevahiya pêvajoya hilberînê binêre nexşeya teknolojîk; Ev tabloyek e ku tê de qonaxên hilberîna takekesî û gavên jihevketî yên Modelê di rêzan de têne tomar kirin, û di stûnan de ravekirina tiştên ku di her qonax an gavekê de têne kirin têne tomar kirin. Girîngiya sereke li ser çavkaniyên ku her qonaxê peyda dikin û veqetandina deverên berpirsiyariyê ye.
Ji bo me nexşeyek celebek dabeşker e. Ew beşên teknolojîk ên mezin ên hilberîna hilberê nîşan dide. Bi saya wê, ji bo tîmê meya otomasyonê hêsantir bûye ku bi pêşdebiran re têkilî daynin û bi hev re pêkanîna qonaxên otomasyonê plansaz bikin, û her weha fêm bikin ka dê ji bo vê çi lêçûn û çavkaniyên kedê (mirov û hardware) hewce bike.
Di hundurê pargîdaniya me de, nexşe bixweber ji şablonek jinja wekî pelek HTML-ya birêkûpêk tê çêkirin, û dûv re li servera Rûpelên GitLab tê barkirin. Dîmenek bi mînakek nexşeyek bi tevahî hatî çêkirin dikare were dîtin .
Li ser wêneyê bikirtînin da ku di mezinahiya tevahî de vekin
Bi kurtasî, nexşeyek teknolojîk wêneyek giştî ya pêvajoya hilberînê ye, ku bi fonksiyonên standard blokên bi zelalî veqetandî nîşan dide.
Struktura nexşeya me ya teknolojîk
Nexşe ji çend beşan pêk tê:
- Qada serî - li vir ravekek giştî ya nexşeyê ye, têgehên bingehîn têne destnîşan kirin, û çavkaniyên sereke û encamên pêvajoya hilberînê têne destnîşan kirin.
- Panela agahdarî - li vir hûn dikarin nîşana daneyan ji bo hilberên kesane kontrol bikin; kurteyek qonaxên pêkanîn û gavên bi gelemperî ji bo hemî hilberan têne peyda kirin.
- Nexşeya teknolojîk - danasîna tabloyî ya pêvajoya teknolojîk. Li ser nexşeyê:
- hemî qonax, gav û kodên wan têne dayîn;
- raveyên kurt û temam ên qonaxan têne dayîn;
- çavkaniyên têketinê û karûbarên ku di her qonaxê de têne bikar anîn têne destnîşan kirin;
- encamên her qonax û gavê kesane têne destnîşan kirin;
- qada berpirsiyariyê ji bo her qonax û gavê tê destnîşan kirin;
- çavkaniyên teknîkî hatine destnîşankirin, mînakî HDD (SSD), RAM, vCPU, û demjimêrên mirovî yên ku ji bo piştgirîkirina xebata di vê qonaxê de hewce ne, hem niha - rastî, hem jî di pêşerojê de - plan;
- ji bo her hilberek tê destnîşan kirin ka kîjan qonax an gavên teknolojîk ên ji bo wê hatine bicîh kirin, ji bo bicîhkirinê hatine plansaz kirin, ne girîng in an nehatine bicîh kirin.
Li ser bingeha nexşeya teknolojîk biryar girtin
Piştî xwendina nexşeyê, hûn dikarin li gorî rola karmendê di pargîdaniyê de (rêveberê pêşkeftinê, rêveberê hilberê, pêşdebir an ceribandinê) hin çalakiyan bikin:
- fêm bikin ka kîjan qonax di hilberek an projeyek rastîn de winda ne û hewcedariya pêkanîna wan binirxînin;
- deverên berpirsiyariyê di navbera çend beşan de bisînor bikin ger ew li ser qonaxên cûda dixebitin;
- peymanên danûstandinê ji bo têketin û encamên qonaxan;
- qonaxa xwe ya xebatê di pêvajoya pêşkeftina giştî de entegre bikin;
- rasttir hewcedariya çavkaniyan ji bo piştgirîkirina her qonaxê binirxînin.
Bi kurtî hemî yên jorîn
Nexşeya teknolojiyê pirreng e, berfereh û hêsan e ku were parastin. Ji modela IDEF0 ya akademîk ya hişk pêşvebirin û domandina danasînên pêvajoyê bi vî rengî pir hêsantir e. Wekî din, danasîna tabloyê ji modelek fonksiyonel hêsantir, nastir û çêtir avakirî ye.
Amûrek navxweyî ya taybetî, CrossBuilder, berpirsiyar e ji bo pêkanîna teknîkî ya gavan - amûrek qatkirina di navbera pergalên CI, karûbar û binesaziyê de. Pêşvebir ne hewce ye ku bisiklêta xwe bibire: di pergala meya CI de bes e ku meriv yek ji skrîptan (bi navê peywirê) amûra CrossBuilder-ê bixebite, ku dê wê bi rêkûpêk bicîh bîne, li gorî taybetmendiyên binesaziya me.
Encam
Gotar pir dirêj derket holê, lê dema ku modela pêvajoyên tevlihev tê ravekirin ev neçar e. Di dawiyê de, ez dixwazim bi kurtî fikrên me yên sereke bînim ziman:
- Armanca danasîna ramanên DevOps di pargîdaniya me de ev e ku em bi domdarî lêçûnên hilberandin û domandina hilberên pargîdaniyê di warê mîqdar de kêm bikin (saet-man an makîne-saet, vCPU, RAM, Disk).
- Rêbazek ji bo kêmkirina lêçûna giştî ya pêşkeftinê ev e ku meriv lêçûna pêkanîna karên rêzikên standard kêm bike: qonax û gavên pêvajoya teknolojîk.
- Karûbarek tîpîk karek e ku çareseriya wê bi tevahî an jî qismî otomatîk e, ji performeran re dibe sedema zehmetiyan û hewcedariya lêçûnên kedê yên girîng nake.
- Pêvajoya hilberînê ji qonaxan pêk tê, qonax li gavên nayên dabeş kirin têne dabeş kirin, ku peywirên tîpîk ên pîvan û cildên cihêreng temsîl dikin.
- Ji peywirên standard ên veqetandî em gihîştin zincîreyên teknolojîk ên tevlihev û modelên pir-astî yên pêvajoya hilberînê, ku dikarin ji hêla modelek IDEF0-ya fonksiyonel an nexşeyek teknolojîk a hêsan ve werin vegotin.
- Nexşeya herikînê temsîla tabloyî ya qonax û gavên pêvajoyek hilberînê ye. Tiştê herî girîng: nexşe dihêle hûn tevahiya pêvajoyê bi tevahî, di perçeyên mezin de bi îhtîmala hûrgulkirina wan bibînin.
- Li ser bingeha nexşeya teknolojîk, hûn dikarin hewcedariya bicîhkirina qonaxên di hilberek taybetî de binirxînin, deverên berpirsiyariyê veqetînin, li ser peymanên ji bo têketin û derketinên qonaxan li hev bikin, û bêtir rasttir hewcedariya çavkaniyan binirxînin.
Di gotarên jêrîn de em ê bi hûrgulî biaxivin ka kîjan amûrên teknîkî têne bikar anîn da ku hin qonaxên teknolojîk li ser nexşeya xwe bicîh bikin.
Nivîskarên gotarê:
- - Serokê Daîreya Otomasyonê (DevOps) li Teknolojiyên Positive
- - cîgir Serokê Beşa Otomasyonê (DevOps) li Teknolojiyên Positive
Source: www.habr.com