بهروزرسانیهای مکرر سیستم عامل برای تضمین امنیت و دسترسی به جدیدترین ویژگیها حیاتی هستند. بهطور پیشفرض، ChromeOS تقریباً هر ۴ هفته یکبار یک بهروزرسانی کامل سیستم عامل را برای کانال پایدار (Stable) منتشر میکند . بهروزرسانیهای جزئی، مانند رفع مشکلات امنیتی و بهروزرسانیهای نرمافزاری، هر ۲ تا ۳ هفته یکبار انجام میشوند. توسعهدهندگان میتوانند برنامههای خود را قبل از انتشار هر نسخه پایدار جدید، در کانالهای توسعهدهندگان (Dev) یا بتا (Beta) آزمایش کنند تا مطمئن شوند که برنامههایشان بهخوبی کار میکنند. نسخه توسعهدهندگان هفتهای یک یا دو بار بهروزرسانی میشود و نشان میدهد که تیم کروم در حال حاضر روی چه چیزی کار میکند. این نسخه هنوز در معرض اشکالات است، اما پیشنمایشی ۹ تا ۱۲ هفتهای از آنچه که به نسخه پایدار میآید، ارائه میدهد. نسخه بتا پیشنمایشی ۴ تا ۶ هفتهای از ویژگیهایی که به نسخه پایدار میآیند، ارائه میدهد.
اما، آزمایش ماهانه با این کانالهای موجود میتواند برای مدیران سیستم و توسعهدهندگان چالشبرانگیز باشد. برای ارائه پشتیبانی بهتر و دادن زمان بیشتر به همه برای آزمایش، ما یک طرح پشتیبانی بلندمدت جدید، با کانالهای پشتیبانی بلندمدت، برای ChromeOS ایجاد کردهایم.
نسخههای پشتیبانی بلندمدت
نسخههای پشتیبانی بلندمدت ChromeOS ابزاری قدرتمند برای کاهش تلاش برای مدیریت دستگاهها در یک سازمان و تأیید عملکرد خوب برنامهها برای هر بهروزرسانی سیستمعامل هستند. هم مدیران و هم توسعهدهندگان باید با آنها آشنا شوند تا تجربهای عالی را برای سازمانهایی که آنها را اتخاذ میکنند، فراهم کنند.
ChromeOS دو نسخه با پشتیبانی بلندمدت ارائه میدهد: یک نسخه کاندیدای پشتیبانی بلندمدت (LTC) و یک نسخه پایدار بلندمدت (LTS) .
- کاندیدای پشتیبانی بلندمدت (LTC) - به عنوان پایهای برای نسخه بعدی LTS استفاده میشود و سه ماه قبل از LTS از نسخه پایدار حذف میشود و به مدیران سیستم یک پیشنمایش برای آمادهسازی میدهد.
- کانال پشتیبانی بلندمدت (LTS) - این کانال که هر ۶ ماه بهروزرسانی میشود، کندترین آهنگ انتشار را دارد و به عنوان جایگزینی برای کانال پایدار معمولی در نظر گرفته شده است. به جز تعداد کمی از کاربران که باید برای اهداف آزمایشی در LTC باقی بمانند، اکثر کاربران هنگام پذیرش نسخههای پشتیبانی بلندمدت در سراسر سازمان باید در LTS باشند.
جدول زمانی انتشار نسخههای پایدار، LTC و LTS
چرخه عمر LTC/LTS به شرح زیر است:
- نسخه LTC (108 LTC در نمودار) از نسخه پایدار (108 Stable) جدا شده است، بنابراین در طول ماه اول هر دو یکسان هستند.
- LTC شروع به دریافت اصلاحات امنیتی هر دو هفته یکبار به مدت ۳ ماه آینده تا انتشار LTS بعدی (۱۰۸ LTS در نمودار) میکند. این بدان معناست که ۳ ماه پس از انتشار اولیه LTC، LTC از LTS پیروی خواهد کرد.
- پس از انتشار LTS، هر دو هفته یکبار اصلاحات امنیتی دریافت خواهد کرد.
- دستگاههایی که پس از انتشار LTS همچنان روی LTC باقی میمانند، همچنان هر دو هفته یکبار اصلاحات امنیتی را دریافت میکنند و پس از انتشار نسخه بعدی LTC، به طور خودکار به آن بهروزرسانی میشوند.
علاوه بر ویژگیهای سیستم عامل و رفع اشکالات، بهروزرسانیهای میانافزار نیز در نسخههای LTS تا زمان انقضای بهروزرسانی خودکار دستگاه (AUE) ارائه میشوند.
برای فعال کردن هر یک از کانالها، باید یک دامنه گوگل و یک دستگاه مدیریتشده داشته باشید. میتوانید در نسخه آزمایشی Chrome Enterprise Upgrade ثبتنام کنید تا به کنسول مدیریت گوگل دسترسی پیدا کنید و بتوانید کرومبوکهای مدیریتشده را راهاندازی و مستقر کنید . در نهایت، دستگاههای مدیریتشده خود را از کنسول مدیریت به کانال LTS یا LTC تغییر دهید . توصیه میکنیم اکثر دستگاههای خود را در کانال LTS نگه دارید و از LTC برای آزمایش نسخه LTS آینده استفاده کنید.
گردش کار تست برای LTC / LTS
LTC و LTS به گونهای طراحی شدهاند که تلاشهای تست را برای مدیران به میزان قابل توجهی کاهش دهند، در حالی که یک تجربه سیستم عامل امن را تضمین میکنند. برای اینکه مدیران سیستم و توسعهدهندگان با چرخه عمر پشتیبانی بلندمدت هماهنگ باشند، باید:
- قبل از انتشار نسخه پایدار که با انتشار کانال LTC آینده مطابقت دارد، روی نسخههای توسعهدهندگان و بتا آزمایش کنید.
- پس از انتشار LTC، آن را آزمایش کنید تا مطمئن شوید که هرگونه اصلاح امنیتی اعمال شده تا زمان قطع LTS، بر کار شما تأثیر نمیگذارد.
- به محض اینکه LTC به LTS ارتقا یابد، LTS هر دو هفته یکبار اصلاحات امنیتی را دریافت خواهد کرد. شما هم باید آنها را آزمایش کنید.
با در نظر گرفتن نمودار چرخه عمر به عنوان مرجع:
- آزمایش روی نسخه توسعهدهندگان ۱۰۸ و بتای ۱۰۸ را شروع کنید تا مطمئن شوید که همه چیز قبل از انتشار نسخه پایدار ۱۰۸ که از آن LTC ۱۰۸ حذف خواهد شد، به خوبی کار میکند.
- هر دو هفته یکبار روی 108 LTC آزمایش کنید تا 108 LTS سه ماه پس از تاریخ اولیه کاهش قیمت منتشر شود.
- به طور منظم به آزمایش LTS ادامه دهید تا مطمئن شوید که رفع مشکلات امنیتی چیزی را خراب نمیکند.
مدیریت تغییرات بین نسخههای LTC/LTS
چه بخواهید یک نسخه پشتیبانی بلندمدت از ChromeOS را اتخاذ کنید و چه با سازمانی که آن را دارد کار کنید، مدیریت صحیح تغییرات بین نسخهها بسیار مهم است. ممکن است یک ویژگی را بر اساس قابلیتهای جدید پلتفرم اضافه کنید یا به ویژگیای که در نسخههای بعدی منسوخ شده است تکیه کنید. یا ممکن است به ویژگیهای خاص یک نسخه خاص از یک برنامه تکیه کنید، یا بخواهید به کاربران این امکان را بدهید که نسخهای را که اجرا میکنند انتخاب کنند. برای اطمینان از دسترسی یکپارچه به برنامه، باید مطمئن شوید که برنامه شما با نسخههای قبلی سازگار است، نمونههای جداگانهای برای هر نسخه ارائه دهید، یا هر دو کار را انجام دهید.
اطمینان از سازگاری با نسخههای قبلی
سازگاری به عقب به نسخههای جدیدتر برنامه شما اجازه میدهد تا روی نسخههای قدیمیتر پلتفرم خود اجرا شوند. میتوانید این کار را با تکنیکی به نام تشخیص ویژگی انجام دهید، که در آن قبل از تلاش برای استفاده از یک ویژگی جدید، در دسترس بودن آن را بررسی میکنید. اگر وجود داشته باشد، از آن استفاده میکنید؛ در غیر این صورت، به صورت اختیاری یک جایگزین ارائه میدهید. نسخه عمومی این تکنیک، پرچمهای ویژگی نامیده میشود، که در آن یک مسیر کد بسته به اینکه آیا یک ویژگی فعال است یا خیر، یا از طریق در دسترس بودن قابلیت یا پیکربندی سطح برنامه یا کاربر، بارگذاری میشود. برنامههای اندروید، افزونههای کروم و برنامههای وب همگی از این تکنیک بهرهمند میشوند. با اطمینان از اینکه نسخههای جدیدتر برنامه شما با نسخههای قدیمی سازگار هستند، میتوانید یک برنامه واحد را برای همه کاربران خود مدیریت کنید.
یک برنامه وب که به دنبال ارائه انیمیشنهای محاسباتی است، ممکن است بخواهد WebGPU را برای مرورگرهایی که از آن پشتیبانی میکنند پیادهسازی کند و در صورت عدم دسترسی به انیمیشنهای سادهتر مبتنی بر جاوا اسکریپت، به آنها بازگردد. برای انجام این کار، آنها ممکن است موارد زیر را انجام دهند:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
ارائه نمونههای جداگانه
گاهی اوقات تفاوتهای بین نسخهها آنقدر زیاد است که نمیتوان با تکنیکهای سازگاری معکوس آنها را مدیریت کرد. تفاوت ویژگیها ممکن است خیلی زیاد باشد یا ممکن است نیازهای تجاری شما ایجاب کند که یک نسخه پشتیبانی بلندمدت جداگانه از برنامه اصلی خود داشته باشید. در این صورت، ممکن است بخواهید برای هر نسخه نمونههای جداگانهای ارائه دهید. اگرچه این تضمین میکند که کاربران از نسخه خاصی از برنامه شما استفاده میکنند، اما ممکن است هزینههای عملیاتی شما را افزایش دهد، بنابراین هنگام انتخاب این راه حل این نکته را در نظر داشته باشید.
برای برنامههای وب، ارائه یک نمونه جداگانه معمولاً به معنای میزبانی نسخههای مختلف برنامه شما در URL های مختلف است که به طور بالقوه به سرورها، پایگاههای داده یا سایر زیرساختهای وبسایت جداگانه نیاز دارد. برای برنامههای اندروید، این به معنای داشتن لیستهای جداگانه در فروشگاه Play برای هر نسخه است. این ممکن است منجر به سردرگمی کاربران شما شود زیرا چندین برنامه مشابه در دسترس خواهد بود و آنها ممکن است ندانند کدام یک را انتخاب کنند. افزونههای Chrome نیز میتوانند چندین لیست داشته باشند، یا میتوانید با ارجاع به این مستندات که جزئیات نحوه پین کردن افزونهها و برخی از نکات مرتبط با پین کردن را شرح میدهد، به مشتریان خود توصیه کنید نسخه افزونه Chrome مورد نیاز خود را از طریق کنسول مدیریت Chrome پین کنند.
یک برنامه اندروید که میخواهد فقط نسخه پشتیبانی بلندمدت را به کاربران ChromeOS ارائه دهد، میتواند یک فهرست جداگانه با موارد زیر در فایل AndroidManifest.xml خود ایجاد کند تا مشخص کند که فقط باید به دستگاههای ChromeOS ارائه شود:
<uses-feature android:name="org.chromium.arc" android:required="true" />