Piezīme
Lai piekļūtu šai lapai, ir nepieciešama autorizācija. Varat mēģināt pierakstīties vai mainīt direktorijus.
Lai piekļūtu šai lapai, ir nepieciešama autorizācija. Varat mēģināt mainīt direktorijus.
Attiecas uz šo Power Platform labi arhitektūras operatīvās izcilības kontrolsaraksta ieteikumu:
| OE:06 | Izveidojiet darba slodzes piegādes ķēdi, kas virza ierosinātās izmaiņas, izmantojot paredzamus, automatizētus cauruļvadus. Cauruļvadi pārbauda un veicina šīs izmaiņas dažādās vidēs. Optimizējiet piegādes ķēdi, lai padarītu savu darba slodzi uzticamu, drošu, rentablu un veiktspēju. |
|---|
Šajā rokasgrāmatā ir aprakstīti ieteikumi darba slodzes izstrādes piegādes ķēdes izstrādei, kuras pamatā ir nepārtraukta integrācija un nepārtraukta piegāde (CI/CD) cauruļvadi. Mākoņa darba slodzēs piegādes ķēde ir standartizēts rīku un procesu komplekts, ko izmantojat, lai ietekmētu konfigurāciju un darba slodzes izmaiņas dažādās vidēs. Izstrādājiet piegādes ķēdi, lai nodrošinātu, ka jums ir paredzama, standartizēta metode darba slodzes uzturēšanai. CI/CD cauruļvadi ir piegādes ķēdes izpausme, bet jums vajadzētu būt vienai piegādes ķēdei. Iespējams, jums ir vairāki konveijers, kas izmanto vienus un tos pašus procesus un izmanto tos pašus rīkus.
Iekļaujiet piegādes ķēdi, lai aizsargātu savu darba slodzi no bojājumiem, kas var rasties, ja nepareizi pārvaldāt darba slodzes izmaiņas. Vienmēr apzinieties savas darba slodzes stāvokli, lai jums nebūtu risks piedzīvot neparedzamu uzvedību. Šis risks palielinās, ja jums ir nepieciešams pavadīt kritisku laiku, lai izsekotu neuzskaitītas izmaiņas, kad rodas problēmas. Lai samazinātu šos riskus, standartizējiet procesus un rīkus, kas definē jūsu piegādes ķēdi, un pārliecinieties, ka jūsu darba slodzes komanda pilnībā apņemas tos izmantot.
Galvenās dizaina stratēģijas
Tālāk sniegtie ieteikumi var palīdzēt definēt piegādes ķēdes pamatprincipus.
Veiciet ierosinātās darba slodzes izmaiņas, izmantojot piegādes ķes procesus un rīkus. Ieviest stingru automatizētu veidņu izvietošanas politiku. Šī metode palīdz nodrošināt, ka jūsu darba slodzes konfigurācija visās vidēs ir standartizēta, skaidri definēta un stingri kontrolēta. Koda veicināšanas ķēdes vidēs neveiciet atjauninājumus, izmantojot manuālus procesus vai cilvēka mijiedarbību. Iekļaujiet visas vides izmaiņas, izmantojot konveijeru, ievērojot definēto izvietošanas praksi. Lai palīdzētu īstenot šo politiku, apsveriet iespēju ierobežot piekļuvi tikai lasīšanai kā noklusējumu un izmantot piekļuves autorizācijas vārtus, lai atļautu rakstīšanas piekļuvi.
Svarīgs šī principa aspekts ir tas, ka visas izmaiņas tiek piedāvātas izmaiņas , līdz tās tiek ieviestas ražošanā. Izmantojot automatizētu testēšanu, piemēram, integrāciju un dūmu testēšanu, jūs ļaujat savai piegādes ķēdei automātiski noraidīt izmaiņas.
Izmantojiet vienu koda līdzekļu un artefaktu kopu visās vidēs un cauruļvados. Izplatīts sāpju punkts organizācijām ir tad, kad ar ražošanu nesaistītās vides atšķiras no ražošanas vides. Manuāla ražošanas un neražošanas vides veidošana var izraisīt neatbilstošas konfigurācijas starp vidēm. Šī neatbilstība palēnina testēšanu un palielina iespējamību, ka izmaiņas var kaitēt ražošanas sistēmai.
Atspoguļojiet savu organizatorisko struktūru piegādes ķēdes un cauruļvadu dizainā. Jūsu organizācija var būt izolēta starp komandām. Katra komanda var pārvaldīt piegādes ķēdes daļu. Piemēram, daudzām organizācijām ir darba grupas, kas pārvalda drošības un atbilstības iestatījumus vai vides konfigurācijas. Šīs komandas ir atdalītas no izstrādes komandām, kas pārvalda lietojumprogrammu izstrādi, testēšanu un izvietošanu. Ir daudz veidu, kā organizēt piegādes ķēdē iesaistītās komandas. Jūsu piegādes ķēde ir atkarīga no visu komandu nevainojamā sadarbības. Pārliecinieties, ka visas komandas ievēro standarta procesus un izmanto standarta rīkus, lai padarītu piegādes ķēdi pēc iespējas efektīvāku.
Jūsu piegādes ķēde var būt atkarīga no trešo pušu piegādātājiem, ja jūs nododat ārpakalpojumus daļu no darba slodzes dzīves cikla. Šie piegādātāji ir tikpat kritiski svarīgi jūsu piegādes ķēdes panākumiem kā iekšējie resursi. Pārliecinieties, ka visās komandās ir savstarpēja vienošanās par izmantotajiem procesiem un rīkiem.
Standartizējiet izvietošanas metodi. Runājiet ar produkta īpašnieku par pieņemamo ražošanas dīkstāvi jūsu darba slodzei. Atkarībā no tā, cik daudz dīkstāves ir pieņemamas, varat izvēlēties jūsu prasībām piemērotāko izvietošanas metodi. Ideālā gadījumā jums vajadzētu veikt izvietošanu uzturēšanas loga laikā, lai samazinātu sarežģītību un risku.
Plānojiet holistisku testēšanas stratēģiju. Sistēmas uzticamības pamatprincips ir "nobīdes pa kreisi" princips. Lietojumprogrammas izstrāde un izvietošana ir process, kas tiek attēlots kā virkne soļu, kas iet no kreisās uz labo pusi. Jums nevajadzētu ierobežot testēšanu līdz procesa beigām. Cik vien iespējams, pārvietojiet testēšanu uz sākumu vai pa kreisi. Kļūdas ir lētāk labot, kad tās noķerat agri. Tos var būt dārgi vai neiespējami noteikt vēlāk lietojumprogrammas dzīves ciklā.
Ja iespējams, izmantojiet automatizētu testēšanu, lai nodrošinātu konsekvenci. Iekļaujiet piegādes ķēdes dizainā šādus testēšanas veidus:
Vienības testēšana: vienības testi parasti tiek veikti kā daļa no nepārtrauktas integrācijas rutīnas. Vienības testiem jābūt plašiem un ātriem. Ideālā gadījumā tiem vajadzētu aptvert 100 procentus koda. Lietojiet vienības testus visiem koda līdzekļiem, tostarp veidnēm un skriptiem.
Dūmu testēšana: Dūmu testi pārbauda, vai darba slodzi var izturēt testa vidē, un darbojas kā paredzēts. Dūmu testi nepārbauda komponentu savietojamību. Dūmu testi pārbauda, vai infrastruktūras un lietojumprogrammas izvietošanas metodika darbojas un ka sistēma reaģē kā paredzēts pēc procesa pabeigšanas.
Integrācijas testēšana: integrācijas testi nodrošina, ka lietojumprogrammas komponenti darbojas atsevišķi, un pēc tam nosaka, vai komponenti var mijiedarboties savā starpā, kā vajadzētu. Liela integrācijas testa komplekta palaišana var aizņemt ievērojamu laiku. Tāpēc vislabāk ir iekļaut nobīdes principu pa kreisi un veikt testēšanu programmatūras izstrādes dzīves cikla sākumā. Rezervējiet integrācijas testus scenārijiem, kurus nevar pārbaudīt ar dūmu testu vai vienības testu. Ja nepieciešams, varat regulāri izpildīt ilgstošas pārbaudes procesus. Regulārs intervāls piedāvā labu kompromisu un ne vēlāk kā vienu dienu pēc to ieviešanas atklāj sadarbspējas problēmas starp lietojumprogrammas komponentiem. Daži testēšanas scenāriji gūst labumu no manuālas palaišanas. Izmantojiet manuālo testēšanu, ja testos ir jāievieš cilvēka interaktivitātes elementi.
Pieņemšanas testēšana: atkarībā no konteksta varat manuāli veikt pieņemšanas testēšanu. Tas var būt daļēji vai pilnībā automatizēts. Pieņemšanas testēšana nosaka, vai programmatūras sistēma atbilst prasību specifikācijām. Šī testa galvenais mērķis ir novērtēt sistēmas atbilstību biznesa prasībām un noteikt, vai sistēma atbilst nepieciešamajiem kritērijiem piegādei lietotājiem.
Ieviesiet kvalitātes vārtus visā koda reklamēšanas procesā, veicot testēšanu. Izvietojiet kodu zemākās vidēs, piemēram, kvalitātes nodrošināšanā un testēšanā, kā arī augstākās vidēs, piemēram, iestāšanā un ražošanā. Kad izvietojums iet cauri kvalitātes vārtiem, pārliecinieties, ka tas atbilst kvalitātes mērķiem, pirms izmaiņas tiek nodotas ražošanai. Jūsu biznesa prasības nosaka, kāds ir jūsu kvalitātes vārtu fokuss. Apsveriet arī labi izstrādātos pamatprincipus Power Platform : drošība, uzticamība un veiktspējas efektivitāte.
Integrējiet arī apstiprināšanas darbplūsmas kvalitātes vārtos. Skaidri definējiet un automatizējiet apstiprināšanas darbplūsmas, ja nepieciešams. Definējiet kvalitātes pieņemšanas kritērijus savā automatizācijā, lai jūs varētu efektīvi un droši pārvietoties pa vārtiem.
Power Platform Atvieglošana
Konveijeru Power Platform mērķis ir demokratizēt lietojumprogrammu dzīves cikla pārvaldību (ALM) Power Platform un Dynamics 365 klientiem, pakalpojumā ieviešot ALM automatizācijas un nepārtrauktas integrācijas un nepārtrauktas piegādes (CI/CD) iespējas.
Microsoft Power Platform Veidošanas rīkus Azure DevOps var izmantot, lai automatizētu bieži sastopamus veidošanas un izvietošanas uzdevumus, kas saistīti ar lietotnēm, uz kurām veidotas lietotnes Power Platform.
GitHub darbības ļauj izstrādātājiem veidot automatizētas programmatūras izstrādes dzīves cikla darbplūsmas. Power Platform Izmantojot GitHub Actions for Microsoft Power Platform, varat savā repozitorijā izveidot darbplūsmas, lai veidotu, testētu, iepakotu, izlaistu un izvietotu lietotnes; veiktu automatizāciju; un pārvaldītu robotprogrammatūras un citus komponentus, uz kuriem balstās to izveide Power Platform.
ALM Accelerator ir atvērtā pirmkoda rīks, kas sastāv no lietojumprogrammu, skriptu un cauruļvadu kopas, kas paredzētas nepārtrauktas integrācijas/nepārtrauktas piegādes procesa automatizēšanai.
Automatizējiet testus, izmantojot Azure Pipelines.
Power Apps Pārbaudītāja tīmekļa API nodrošina mehānismu statiskās analīzes pārbaužu veikšanai, salīdzinot Microsoft Dataverse platformas pielāgojumus un paplašinājumus.
Microsoft Power Platform CLI (PAC CLI) ir komandrindas rīks, kas atbalsta risinājumu Power Platform importēšanu un eksportēšanu, kā arī iepakošanu risinājumu avota failos un izpakošanu no tiem. Power Platform PAC CLI ir pieejams kā atsevišķs komandrindas rīks vai kā paplašinājums Visual Studio Code.
Nemaināmas infrastruktūras kā koda (IaC) izvietošanai varat izmantot Terraform, Bicep un Azure Resource Manager. Atkarībā no jūsu prasībām un komandas pieredzes ar rīkiem, resursu izvietošanai un pārvaldībai varat izmantot vienu vai vairākus no šiem rīkiem.
Organizatoriskā saskaņošana
Mākoņpakalpojumu ieviešanas ietvars sniedz norādījumus centrālajām komandām darba slodzes nosēšanās zonu nodrošināšanai. Darba slodzes nosēšanās zonas ir vietas, kur darba slodzes pielāgotā piegādes ķēde izvieto lietojumprogrammas.
Uzziniet vairāk sadaļā Kas ir Azure nosēšanās zona? un Azure nosēšanās zonas izstrādes principi.