Työkuorman kehittämisen toimitusketjun suunnittelusuositukset
Koskee tätä Power Platform hyvin suunnitellun operatiivisen huippuosaamisen tarkistuslistan suositusta:
| OE:06 | Ehdotettuja muutoksia ennakoitavissa, automatisoiduissa putkissa siirtävän työkuorman toimitusketjun muodostaminen. Jaksot testaavat ja edistävät näitä muutoksia eri ympäristöissä. Optimoi toimitusketju, jotta työmääräsi olisi luotettava, turvallinen, kustannustehokas ja suorituskykyinen. |
|---|
Tässä oppaassa käsitellään suosituksia, jotka koskevat CI/CD (jatkuva integrointi ja jatkuva toimitus) -putkiin perustuvan työkuorman kehityksen toimitusketjun suunnittelua. Pilvityönkuluissa toimitusketju on standardoitu työkalu- ja prosessipaketti, jolla voidaan vaikuttaa määritysten ja työkuorman muutoksiin koko ympäristöissä. Toimitusketjun kehittäminen varmistaa, että työkuorman ylläpitämiseen on käytettävissä ennakoitava, standardoitu menetelmä. CI/CD-putket ovat toimitusketjun ilmentymä; toimitusketjuja saa kuitenkin olla vain yksi. Sinulla voi olla useita putkia, jotka noudattavat samoja prosesseja ja käyttävät samoja työkaluja.
Toimitusketjun sisällyttämisellä voidaan suojata työkuormaan vaurioilta, joita voi esiintyä, jos työkuorman muutoksia ei hallita oikein. Ole aina tietoinen työmääräsi tilasta, jotta et ole vaarassa kokea arvaamatonta käyttäytymistä. Tämä riski kasvaa, jos joudut käyttämään kriittistä aikaa huomioimattomien muutosten jäljittämiseen ongelmien ilmetessä. Nämä riskit voidaan minimoida standardoimalla toimitusketjun määrittävät prosessit ja työkalut sekä varmistamalla, että työkuormatiimi on täysin sitoutunut niiden käyttämiseen.
Tärkeimmät suunnittelustrategiat
Seuraavat suositukset voivat auttaa määrittämään toimitusketjun perusperiaatteet.
Ehdotetut työkuorman muutokset tehdään toimitusketjun prosessien ja työkalujen kautta. Automaattisten mallipohjaisten käyttöönottojen käytön noudattavista valvotaan tiukasti. Tämä menetelmä auttaa varmistamaan, että työkuorman määritykset on standardoitu, hyvin määritettyjä ja tiukasti hallittuja kaikissa ympäristöissä. Koodin edistämisketjun ympäristöissä päivityksiä ei saa suorittaa manuaalisina prosesseina tai ihmisen tekemin toimin. Kaikki muutokset sisällytetään ympäristöön putken kautta määritettyjen käyttöönottokäytäntöjen mukaisesti. Tämän käytännön käytön valvontaa helpottamiseksi kannattaa harkita käyttöoikeuden rajoittamista oletusarvoisesti vain luku -muotoiseksi ja kirjoitusoikeuden sallimista käyttöoikeuksien valtuutusportin avulla.
Tämän periaatteen tärkeä seikka on se, että kaikki muutokset ovat ehdotettuja muutoksia siihen saakka, että ne otetaan tuotannossa käyttöön. Automaattisen testauksen, kuten integrointi- ja kuntotestauksen, kautta toimitusketjussa mahdollistetaan muutosten automaattinen hylkäys.
Kaikissa ympäristöissä ja putkissa käytetään yhtä koodiresurssi- ja artefaktijoukkoa. Yleinen organisaatioiden kipupiste on ei-tuotantoympäristöjen ja tuotantoympäristöjen mahdollinen erilaisuus. Tuotanto- ja ei-tuotantoympäristöjen manuaalinen muodostaminen aiheuttaa sen, että ympäristöissä on erilaiset määritykset: Tämä ristiriita hidastaa testausta ja sen vuoksi on myös todennäköisempää, että muutokset vahingoittavat tuotantojärjestelmää.
Toimitusketjun ja putken rakenteiden on vastattava organisaation rakennetta. Organisaatio voi olla siiloina tiimien kesken. Kukin tiimi hallitsee ehkä jotain toimitusketjun osaa. Monissa organisaatiossa on esimerkiksi tiimejä, jotka hallitsevat suojaus- ja vaatimustenmukaisuusasetuksia tai ympäristömäärityksiä. Nämä tiimit ovat erillään kehitystiimeistä, jotka hallitsevat sovelluksen kehitystä, testausta ja käyttöönottoja. Toimitusketjuun sisältyvien tiimien järjestämiseen on monenlaisia tapoja. Toimitusketju toiminnan edellytyksenä on kuitenkin se, että kaikki tiimit toimivat sujuvasti yhdessä. Niinpä onkin varmistettava, että kaikki tiimit noudattavat vakioprosesseja ja käyttävät vakiotyökaluja, sillä näin toimitusketju toimii mahdollisimman tehokkaasti.
Toimitusketju saattaa luottaa kolmannen osapuolen toimittajiin, jos ulkoistat osan työmäärän elinkaaresta. Nämä toimittajat ovat yhtä kriittisiä toimitusketju menestykselle kuin sisäiset resurssit. Varmista, että kaikki tiimit ovat keskenään yhtä mieltä käyttämistäsi prosesseista ja työkaluista.
Käyttöönottomenetelmän standardointi. Tuotteen omistajan kanssa on keskusteltava siitä, minkälaiset tuotantoympäristön käyttökatkokset ovat työkuorman osalta hyväksyttäviä. Mahdollisten käyttökatkosten määrän mukaan voidaan valita vaatimuksia parhaiten vastaava käyttöönottomenetelmä. Parhaassa tapauksessa käyttöönotot suoritetaan ylläpitoikkunan aikana, mikä vähentää monimutkaisuutta ja riskiä.
Kokonaisvaltaisen testausstrategian suunnittelu. Järjestelmän luotettavuuden ydinperiaate on "siirry vasemmalle" -periaate. Sovelluksen kehittäminen ja käyttöönottaminen on prosessi, joka kuvataan vasemmalta oikealle siirtyvinä vaiheina. Testausta ei kannata rajoittaa prosessin loppuvaiheeseen. Testaus kannattaa sen sijaan siirtää mahdollisuuksien mukaan varhaiseen vaiheeseen eli vasemmalle. Varhain havaittujen virheiden korjaaminen tulee halvemmaksi. Ne voivat olla kalliita tai mahdottomia korjata myöhemmin sovelluksen elinkaaren aikana.
Yhdenmukaisuuden varmistamiseksi kannattaa käyttää automaattista testausta aina, kun se on mahdollista. Toimitusketjun suunnitteluun kannattaa sisällyttää seuraavat testaustyypit:
Yksikkötestaus: Yksikkötestit suoritetaan yleensä osana jatkuvaa integrointirutiinia. Yksikkötestien on oltava laajoja ja nopeita. Parhaassa tapauksessa ne kattavat 100 prosenttia koodista. Yksikkötestejä käytetään kaikissa koodiresursseissa, mukaan lukien malleissa ja komentosarjoissa.
Savutestaus: Savutestit varmistavat, että työmäärä kestää testiympäristössä ja toimii odotetulla tavalla. Kuntotesteillä ei tarkisteta komponenttien välistä toimintaa. Kuntotestit tarkistavat, että infrastruktuurin ja sovelluksen käyttöönottomenetelmä toimii ja että järjestelmää reagoi odotetusti prosessin päättymisen jälkeen.
Integrointitestaus: Integrointitestit varmistavat, että sovelluskomponentit toimivat erikseen, ja määrittävät sitten, voivatko komponentit olla vuorovaikutuksessa keskenään niin kuin niiden pitäisi. Suuren integraatiotestipaketin suorittaminen voi kestää kauan. Siksi on parasta sisällyttää shift-left-periaate ja suorittaa testaus ohjelmistokehityksen elinkaaren varhaisessa vaiheessa. Integraatiotesti kannattaa varata skenaarioihin, joita ei voi testata kunto- tai yksikkötestillä. Pitkäkestoiset testiprosessit voidaan suorittaa tarvittaessa säännöllisin väliajoin. Säännölliset testausvälit ovat hyvä kompromissi, ja niiden avulla havaitaan sovelluksen komponenttien väliset toiminto-ongelmat enintään päivä sen jälkeen, kun ongelma aiheutettiin. Joissakin testausskenaarioissa on hyötyä manuaalisesta testauksesta. Manuaalista testausta voi käyttää silloin, kun testattavat elementit edellyttävät ihmisten vuorovaikutusta.
Hyväksyntätestaus: Asiayhteydestä riippuen voit suorittaa hyväksyntätestauksen manuaalisesti. Se voi olla osittain tai kokonaan automatisoitu. Hyväksyntätestaus määrittää, vastaako ohjelmistojärjestelmä vaatimusten määrityksiä. Tämän testin päätarkoituksena on arvioida, täyttääkö järjestelmä liiketoiminnan vaatimukset ja määrittää, täyttääkö järjestelmä käyttäjille toimittamiseen vaadittavat kriteerit.
Ota laatuportit käyttöön koko koodin edistämisprosessin ajan testaamalla. Koodi otetaan käyttöön alatason ympäristöissä, kuten laadunvalvonnassa ja testauksessa, ylätason ympäristöissä, kuten valmistelu- ja tuotantoympäristöissä. Käyttöönoton siirtyessä laatuporttien läpi laatutavoitteiden toteutuminen varmistetaan, ennen kuin muutokset siirtyvät tuotantoon. Liiketoimintatarpeet määrittävät, mihin laatuportit keskittyvät. Ota huomioon myös hyvin suunnitellut perusperiaatteet Power Platform : turvallisuus, luotettavuus ja suorituskyvyn tehokkuus.
Myös hyväksyntätyönkulut kannatta integroida laatuportteihin. Automaattiset hyväksyntätyönkulut on määritettävä tarvittaessa selkeästi. Määritä automaatioosi laadun hyväksymiskriteerit, jotta voit liikkua porttien läpi tehokkaasti ja turvallisesti.
Power Platform – avustaminen
Pipelinesin Power Platform tavoitteena on demokratisoida sovellusten elinkaaren hallinta (ALM) Power Platform asiakkaille ja Dynamics 365 tuomalla palveluun ALM-automaatio sekä jatkuvan integraation ja jatkuvan toimituksen (CI/CD) ominaisuudet.
Microsoft Power Platform Koontityökalujen Azure DevOps avulla voidaan automatisoida yleisiä koonti- ja käyttöönottotehtäviä, jotka liittyvät rakennettuihin Power Platform sovelluksiin.
GitHub-toiminnot, joiden Power Platform avulla kehittäjät voivat rakentaa automatisoituja ohjelmistokehityksen elinkaaren työnkulkuja. Microsoft Power Platformin GitHub-toimintojen avulla voit luoda säilöön työnkulkuja sovellusten luomiseen, testaamiseen, paketoimiseen, julkaisuun ja käyttöönottoon, automatisoinnin suorittamiseen sekä bottien ja muiden Power Platformissa luotujen komponenttien hallintaan.
ALM Accelerator on avoimen lähdekoodin työkalu, joka koostuu joukosta sovelluksia, skriptejä ja putkia, jotka on suunniteltu automatisoimaan jatkuva integraatio / jatkuva toimitusprosessi.
Automatisoi testit Azure Pipelinesin avulla.
Power Apps tarkistusverkko-ohjelmointirajapinta tarjoaa mekanismin, jolla voidaan suorittaa staattisia analyysitarkistuksia ympäristön mukautuksia ja laajennuksia Microsoft Dataverse vastaan.
Microsoft Power Platform CLI( PAC CLI) on komentorivityökalu, joka tukee ratkaisujen tuontia ja vientiä Power Platform sekä pakkaamista ratkaisujen lähdetiedostoihin Power Platform ja purkamista niistä. PAC CLI on saatavana erillisenä komentorivityökaluna tai koodin laajennuksena Visual Studio .
Terraformia, Bicepia ja Azure Resource Manageria voidaan käyttää muuttumattomana infrastruktuuri koodina (IaC) -käyttöönotoissa. Vaatimusten ja tiimin työkalujen tuntemuksen mukaan näitä työkaluja voidaan käyttää resurssien käyttöönottoihin ja hallintaan.
Organisaation kohdistus
Cloud Adoption Framework opastaa keskustiimejä tuottamaan työkuorman saapumisalueita. Kuormituksen laskeutumisalueet ovat paikkoja, joihin kuormituksen mukautettu toimitusketju ottaa sovellukset käyttöön.
Lue lisää artikkelista Mikä on Azuren laskeutumisalue? ja Azuren laskeutumisalueen suunnitteluperiaatteet.