Tinklaraštis
PTE diegimas keliasi į administravimo centrą: ką pakeisti iki 2027 m. balandžio
Kiek gyvuoja „Business Central” online, per-tenant plėtinys (PTE) į produkciją keliaudavo vienu keliu: žmogus su tinkamu teisių rinkiniu atsidarydavo puslapį Extension Management pačioje aplinkoje, įkeldavo .app failą ir spausdavo Deploy. Šį mėnesį diegiamas atnaujinimas 28.4 keičia adresą. PTE dabar galima įkelti, įdiegti, suplanuoti ir pašalinti iš „Business Central” administravimo centro ir jo API, o Microsoft paskelbė, kad įkėlimas iš aplinkos vidaus bus pašalintas 2027 leidimo 1 bangoje, versijoje 30, kuri ateina 2027 m. balandį. Puslapis Extension Management lieka, bet tik peržiūrėti, kas įdiegta.
Tai nedidelė funkcija su griežta data, o būtent tokie pakeitimai ignoruojami tol, kol sulaužo diegimą. Mūsų klientai, turintys vieną PTE ir partnerį, kuris jį diegia, vargu ar ką pastebės. Tie, kas turi automatizaciją, daugiau nei vieną diegiantį žmogų arba įprotį „tiesiog užkelti pataisą”, tegul skaito toliau.
Ką daro naujoji sąsaja
Administravimo centre aplinkos puslapis Manage Apps dabar turi veiksmą Install Extension. Pasirenkate .app failą, Sync Mode ir Deployment schedule: diegti iš karto, per artimiausią aplinkos atnaujinimo langą arba su kitu mažuoju ar didžiuoju atnaujinimu. Vieną ribą verta žinoti: PTE, kuris toje aplinkoje dar niekada nebuvo įdiegtas, gali keliauti tik iš karto arba su artimiausiu atnaujinimo langu; bandymas jį atidėti iki kito didžiojo atnaujinimo atmetamas su klaida „no existing deployed version to upgrade from”. Tas pats puslapis rodo būsimas plėtinių versijas, leidžia atšaukti suplanuotą diegimą ir pašalinti PTE, ko senasis Automation API niekada nesiūlė.
Pašalinimas tvarkomas taip pat. Skiltis Requirements for App Uninstall išvardija priklausomus app’sus ir aiškiai klausia, ar kartu su plėtiniu trinti ir jo duomenis; jungiklis pagal nutylėjimą stovi ties „ne”.
Administravimo centro API versija 2.29 atveria visa tai. Diegimo kvietimas yra multipart įkėlimas į endpointą /admin/{apiVersion}/applications/{applicationFamily}/environments/{environmentName}/apps/pteInstall, tad CI/CD pipeline’as gali stumti .app failą tiesiai, be Automation API konfigūravimo naštos. Tie patys endpointai atverti ir kaip įrankiai administravimo centro MCP serveryje, tad nurodymą „įdiek 1.4.2 versiją į UAT aplinką per artimiausią atnaujinimo langą” gali duoti ir skriptas, ir DI asistentas VS Code.
Du dalykai, ant kurių žmonės užklius
Dvi sąsajos kol kas viena kitos nemato. Iš Extension Management suplanuotas PTE diegimas administravimo centre nematomas, kol nesibaigia, ir atvirkščiai. Pati Microsoft pataria pereinamuoju laikotarpiu jų nemaišyti toje pačioje aplinkoje. Jei partneris diegia iš aplinkos vidaus, o jūsų IT žiūri į administravimo centrą, vienas iš jų matys pasenusį vaizdą. Išsirinkite po vieną sąsają kiekvienai aplinkai dabar ir užsirašykite.
Kam leidžiama diegti. Įkėlimui per Extension Management reikėjo teisių rinkinio EXTEND. MGT. - ADMIN, tai yra „Business Central” teisių. Administravimo centrui reikia administravimo centro rolės: Dynamics 365 Business Central Administrator, Dynamics 365 Administrator arba deleguoto administratoriaus ryšio partneriui. Daugumoje organizacijų tai skirtingi žmonės. Programuotojas, kuris vakar galėjo pats įdiegti savo hotfix’ą, 2027 m. balandį gali to nebegalėti, ir tai turbūt yra esmė: produkcijos diegimas tampa tenanto administravimo veiksmu su audito pėdsaku, o ne puslapio veiksmu programos viduje.
Kodėl manome, kad kryptis teisinga
Esame matę per daug produkcijos aplinkų, kuriose niekas negalėjo užtikrintai pasakyti, kuri PTE versija veikia, kas ją įdiegė ir kada. Diegimo sutelkimas administravimo centre kiekvienam įdiegimui duoda vietą Operations žurnale, suplanuotą laiką, pririštą prie atnaujinimų kalendoriaus, ir API, kurį pipeline’as gali kviesti be apėjimų. Taip pat PTE sulyginami su tuo, kaip AppSource app’sai valdomi jau metų metus, tad lieka vienas app’sų sąrašas aplinkai, o ne du. Kaina yra šiek tiek ceremonijos, o būtent patogumas ir leido atsirasti niekur neužfiksuotiems diegimams.
Ką darytume pirmiausia
- Surašykite, kas diegia šiandien. Išvardykite kiekvieną žmogų ir kiekvieną skriptą, kuris per pastaruosius metus įkėlė PTE. Administravimo centro app’sų sąrašas ir aplinkos puslapis Extension Management kartu parodo dabartinę būklę.
- Nuspręskite sąsają kiekvienai aplinkai. Produkcija ir UAT nuo šiol tik per administravimo centrą. Programuotojų sandbox’ai iki balandžio tegul lieka ten, kur programuotojui patogiau.
- Roles dalinkite apgalvotai. Kas diegs į produkciją, tam reikia administravimo centro rolės arba deleguoto administratoriaus ryšio. Nedalinkite Dynamics 365 Administrator programuotojui vien tam, kad išliktų įprotis; ten, kur diegia partneris, naudokite deleguoto administratoriaus kelią.
- Perkelkite CI/CD procesą anksčiau, nei būsite priversti. Jei build skriptas plėtinius diegia per Automation API, perrašykite jį prieš administravimo centro API 2.29 šį rudenį, kol veikia abu keliai. Teisių ir planavimo klausimus rasite turėdami laiko atsargą.
- Naudokite planavimą. „Diegti per artimiausią atnaujinimo langą” produkcijai yra geresnė numatytoji reikšmė nei „iš karto”, nes pakeitimas atsiduria ten, kur naudotojai ir taip laukia prastovos.
Nieko iš to nereikia daryti rytoj. Skubu kitu požiūriu: iki 2027 m. balandžio liko du didieji atnaujinimai, o diegimo procesas yra pats blogiausias dalykas, kurį galima aptikti nustojus veikti tą dieną, kai reikia išleisti pataisą.
Nesate tikri, kas ir kaip gali diegti į jūsų produkcijos aplinką? Papasakokite savo istoriją ir kartu tai susidėliosime.