Tinklaraštis
Vis dar „Business Central" 27 versijoje? Priverstinis atnaujinimas prasideda spalį
Kiekviena „Business Central” online aplinka per metus gauna du didžiuosius atnaujinimus, o kiekvienas administratorius gauna penkis mėnesius pasirinkti kiekvieno iš jų datą. 28 versijai tas langas užsidarė rugpjūčio 31 d. Rugsėjis yra lengvatinis laikotarpis (grace period), o spalio 1 d. prasideda priverstinio atnaujinimo laikotarpis: jei aplinka vis dar neperėjo į 28, Microsoft ją atnaujina vis tiek, o bet kuris kelyje stovintis plėtinys gali būti pašalintas, kad atnaujinimas praeitų.
Dauguma mūsų prižiūrimų aplinkų jau yra 28 versijoje, ir jei jūsų taip pat, šis įrašas tėra priminimas apie mechanizmą, kurį vėl sutiksite kovą. Jei vis dar esate 27 versijoje arba nesate tikri, skaitykite toliau. Taisyklės tikslios, visos paskelbtos Microsoft Learn, ir beveik niekas jų neskaito, kol atnaujinimas jau nėra įvykęs.
Trys laikotarpiai su datomis
Microsoft atnaujinimų ciklas didžiajai versijai turi tris etapus, ir kiekvienas iš jų siaurina, ką administratorius gali daryti.
- Atnaujinimo laikotarpis, balandis–rugpjūčio 31 d. 28 versija tapo visuotinai prieinama balandžio pradžioje, o esamoms aplinkoms buvo pasiūlyta maždaug po savaitės. Administratoriai galėjo suplanuoti atnaujinimą bet kuriai dienai per penkis mėnesius, o nepavykęs bandymas tiesiog būdavo kartojamas po septynių dienų.
- Lengvatinis laikotarpis, rugsėjis. Atnaujinimo nebegalima nukelti vėliau ir nebegalima nukreipti į kitą 27.x versiją. Nepavykusius bandymus Microsoft kartoja kas septynias dienas. Administratorius gali bandymą paankstinti arba pasirinkti kitą 28.x build’ą, ir tai visas meniu. Administravimo centre rodomi įspėjimai, o Microsoft gali rodyti įspėjimus ir visiems tenanto naudotojams pačioje programoje.
- Priverstinio atnaujinimo laikotarpis, nuo spalio. Microsoft toliau bando atnaujinti. Bet kuris plėtinys, dėl kurio atnaujinimas nepavyksta, paprastai dėl suderinamumo problemos, gali būti pašalintas automatiškai, kad atnaujinimas pavyktų.
Dvi pasekmes lengva praleisti. Vykstančio atnaujinimo nebegalima atšaukti, kai aplinka yra priverstiniame laikotarpyje. O kai atnaujinimas į 28 pavyksta, aplinkos nebegalima atkurti iš 27 versijos backupo, nes atkurti į versiją, kuri yra lengvatiniame ar priverstiniame laikotarpyje, neleidžiama.
Ką „priverstinis” reiškia ir ko nereiškia
Žodis skamba kaip duomenų praradimas. Taip nėra, ir šis skirtumas keičia, kiek visa tai skubu.
Kai plėtinys pašalinamas priverstiniu laikotarpiu, jo lentelės ir duomenys lieka duomenų bazėje. Po atnaujinimo įdiegus suderinamą to paties plėtinio versiją, viskas grįžta. Prarandate plėtinio funkciją, nuo atnaujinimo momento iki tol, kol kas nors įdiegia pataisytą versiją. Jei tas plėtinys registruoja jūsų tarpįmonines sąskaitas ar maitina sandėlio skenerius, „neištrinta” mažai guodžia tomis dienomis, kai jo nėra.
Antroji pusė svarbi ne mažiau: kai suderinama versija atsiranda, Microsoft jos už jus neįdiegia. AppSource app’sas, pašalintas, kad atnaujinimas praeitų, pats neįsidiegs, kai jo leidėjas išleis pataisą. Kažkas turi pastebėti ir kažkas turi įdiegti.
Taigi priverstinis atnaujinimas nėra grėsmė jūsų duomenims. Tai garantija, kad atnaujinimas įvyks Microsoft parinktą dieną, o kiekviena atsilikusi priklausomybė po jo bus dingusi tol, kol tai pastebėsite. Visa veikimo rugsėjį prasmė yra pačiam pasirinkti datą ir trūkstamas dalis turėti paruoštas prieš atnaujinimą, o ne po jo.
Antras atnaujinimas eilėje už pirmojo
Čia kalendorius tampa nepatogus visiems, kas laukė. 29 versija tampa visuotinai prieinama pirmąją spalio savaitę, tą patį mėnesį, kai prasideda 28 versijos priverstinis laikotarpis.
Kai atnaujinimas pavyksta, administravimo centras automatiškai suplanuoja kitą, nukreiptą į naujausią prieinamą versiją ir ne anksčiau kaip po septynių dienų. Aplinka, priverstinai perkelta į 28 spalio pradžioje, atnaujinimą į 29 turės suplanuotą per savaitę ar dvi, kol visi dar aiškinasi, kuriuos plėtinius pašalino pirmasis. Atnaujinimą į 29 galima perkelti į bet kurią dieną jo paties penkių mėnesių laikotarpyje, kuris tęsiasi iki 2027 m. kovo pradžios, tad tai suvaldoma. Suvaldoma tik tada, jei kas nors stebi administravimo centrą ir perkelia datą. Aplinka, kurios niekas nestebi, per kelias savaites gauna abi didžiąsias versijas datomis, kurių niekas nepasirinko.
Kodėl aplinkos užstringa
Aplinka praleidžia atnaujinimo langą dėl trijų priežasčių, ir visos trys susiveda į plėtinius.
- Per-tenant plėtinys, kurio niekas neperkompiliavo. Prieš trejus metus jums sukurta modifikacija vis dar kompiliuojasi su 27 ir lūžta su 28, dažniausiai ties lauku ar procedūra, kurią Microsoft pažymėjo kaip nebepalaikomą ir galiausiai pašalino. Microsoft apie pašalinimą įspėjo bent metais anksčiau nebepalaikomų funkcijų sąraše, o kompiliatorius įspėjo kiekvieną developerį, kuris nuo tada tą plėtinį kompiliavo. Įspėjimas nepasiekė nė vieno, kas už jį vis dar atsakingas.
- AppSource app’sas, kurio leidėjas neišleido naujos versijos. Šito patys nepataisysite; kodas priklauso tiekėjui. Pačios Microsoft priemonė čia grubi: su dabartine didžiąja versija nesuderinamas app’sas gali būti pašalintas iš AppSource praėjus 30 dienų nuo tos versijos išleidimo, o leidėjas, ignoruojantis lengvatinį laikotarpį, rizikuoja, kad bus išbraukti visi jo app’sai. Tuo tarpu aplinka, kurioje jis įdiegtas, lieka užstrigusi.
- Produkcijoje paliktas developerio plėtinys. Kažkas, ką kažkas skubiai publikavo tiesiai iš Visual Studio Code problemai užlopyti, kas niekada nepraėjo CI/CD proceso ir niekada nebuvo testuota su kita didžiąja versija.
Modifikacijas iškelti iš Base App į plėtinius buvo teisingas sprendimas, ir mes už jį išsamiai pasisakėme. Bet jis nepašalino atnaujinimo rizikos. Jis perkėlė ją nuo kodo, kuris priklauso jums, prie leidimų kalendorių, kurie jums nepriklauso, o priverstinis atnaujinimas yra vieta, kur šie du susitinka. Čia Microsoft kalba tiesiai: priverstiniu laikotarpiu klientas ir jo partneris yra visiškai atsakingi už tai, kaip judėti toliau.
Dešimties minučių patikra
Niekam iš to developerio nereikia. Atsidarykite „Business Central” administravimo centrą ir pažiūrėkite keturis dalykus.
- Aplinkos versija ir kitas atnaujinimas. Kiekviena aplinka rodo dabartinę versiją, naujausią prieinamą versiją ir kito atnaujinimo tikslą bei datą. Jei dabartinė versija prasideda 27, likusi įrašo dalis jums galioja jau šiandien.
- Notification recipients. Kiekvienas Microsoft siunčiamas įspėjimas apie atnaujinimą, įskaitant išankstinę suderinamumo patikrą, kuri įvardija nesuderinamą plėtinį ir ką jame keisti, keliauja į el. pašto adresus skirtuke Notification recipients ir niekur kitur. Jei tas skirtukas tuščias, įspėjimas nebuvo išsiųstas niekam. Jei jame įrašytas žmogus, kuris išėjo, tas pats. Laiškai ateina iš no-reply-dynamics365@microsoft.com, tad patikrinkite ir tai, ar jie nekeliauja į spam’ą.
- Operations žurnalas. Nepavykęs atnaujinimo bandymas ten įrašytas su savo klaida. Ta klaida paprastai įvardija plėtinį, ir tai greičiausias būdas sužinoti, kodėl rugsėjo bandymai vis nepavyksta.
- Atnaujinimo langas. Pagal nutylėjimą aplinką galima atnaujinti nuo 20:00 iki 06:00 vietos laiku, o langas turi būti bent šešių valandų. Atnaujinimas, kuris nesibaigia lange, atšaukiamas, aplinka atkuriama, o bandymas nukeliamas septyniomis dienomis. Didelė duomenų bazė su siauru langu gali nepavykti vien dėl laiko, o iš išorės tai atrodo lygiai taip pat kaip suderinamumo klaida.
Jei aplinka siunčia telemetriją į Application Insights, ta pati istorija yra aplinkos gyvavimo ciklo signaluose: LC0100, kai atnaujinimas tampa prieinamas, LC0107, kai jis nepavyksta.
Ką darytume šią savaitę
- Išbandykite atnaujinimą ant kopijos. Nukopijuokite produkciją į sandbox’ą, suplanuokite sandbox’o atnaujinimą šiandienai ir nustatykite Allow the update to run outside the update window į „taip”. Per kelias valandas turėsite arba veikiantį 28 sandbox’ą, arba tikslią klaidą, su kuria dirbti. Tai vienintelis testas, kurio preview aplinka duoti negali, nes preview aplinkos negalima sukurti iš jūsų produkcijos duomenų.
- Pataisykite PTE ir paruoškite jį. Perkompiliuokite su 28, ištestuokite tame sandbox’e ir įkelkite naują versiją su Deployment Schedule reikšme Next major. Nuo atnaujinimo 28.4 tai daroma administravimo centre; kaip tai pasikeitė, rašėme prieš dvi savaites. Suderinama versija tada įsidiegia kaip paties atnaujinimo dalis.
- Raginkite tiekėją raštu. Dėl AppSource app’so, kuris blokuoja atnaujinimą, paprašykite leidėjo su 28 suderinamos versijos ir datos. Jei atsakymas yra tyla, nuspręskite dabar, ar galite kurį laiką dirbti be to app’so, nes spalį šis sprendimas bus priimtas už jus.
- Pašalinkite tai, ko niekas nenaudoja. Aplinkose kaupiasi išbandyti ir pamiršti plėtiniai. Kiekvienas iš jų yra potencialus blokatorius. Šalinant duomenys lieka, nebent aiškiai pasirinktumėte kitaip, tad rizika maža.
- Pasirinkite savo datą. Kai sandbox’o atnaujinimas pavyksta, suplanuokite produkciją tai šio mėnesio nakčiai, kuri tinka jūsų verslui, o ne spalio nakčiai, kuri tinka algoritmui.
- Tada pažiūrėkite į 29. Jos preview jau prieinama, o pakeitimai, kuriuos verta testuoti, žinomi. Aplinka, kuri šį mėnesį atsiduria 28 versijoje, 29 gali paimti pasirinktą dieną bet kada iki kovo.
Didysis atnaujinimas „Business Central” online niekada nebuvo pasirenkamas. Priverstinis laikotarpis keičia tik tai, kas renkasi dieną, o rugsėjis yra paskutinis mėnuo, kai tai vis dar esate jūs.
Nežinote, kas blokuoja jūsų aplinką arba kas turėtų stebėti administravimo centrą? Papasakokite savo istoriją ir išsiaiškinsime kartu.