वर्शन मैनेज करना

Magdalena Skarbińska

Demián Renzulli

आइसोलेटेड वेब ऐप्लिकेशन (आईडब्ल्यूए), वेब प्लैटफ़ॉर्म पर एक भरोसेमंद, सुरक्षित, और अलग-अलग वर्शन वाला रनटाइम एनवायरमेंट उपलब्ध कराते हैं. प्रोडक्शन एनवायरमेंट में, खास तौर पर मैनेज किए जा रहे एंटरप्राइज़ में, एडमिन और डेवलपर को सॉफ़्टवेयर डिप्लॉयमेंट पर बारीकी से कंट्रोल की ज़रूरत होती है.

इन ज़रूरी शर्तों को पूरा करने के लिए, Chrome में आईडब्ल्यूए के लिए वर्शन मैनेज करने की कई सुविधाएं उपलब्ध हैं. इनमें अपडेट चैनल, वर्शन पिन करना, और वर्शन डाउनग्रेड करना शामिल है. इन सुविधाओं की मदद से, डिप्लॉयमेंट के बारे में अनुमान लगाया जा सकता है. साथ ही, उपयोगकर्ताओं के ग्रुप के लिए, तेज़ी से रिकवरी करने वाले कंट्रोल चालू किए जा सकते हैं.

उपलब्धता

वर्शन मैनेजमेंट का तरीका इस बात पर निर्भर करता है कि आईडब्ल्यूए को कोई एडमिन मैनेज कर रहा है या उसे किसी उपयोगकर्ता ने सीधे इंस्टॉल किया है:

• मैनेज किए जा रहे आईडब्ल्यूए: एडमिन के लिए उपलब्ध सुविधाएं, Chrome 133 से उपलब्ध हैं. इनमें नीति के तहत पिन करने और डाउनग्रेड करने की सुविधाएं शामिल हैं.
• मैनेज नहीं किए जा रहे (उपयोगकर्ता ने इंस्टॉल किए हैं) आईडब्ल्यूए: इस्तेमाल करने वाले लोगों के लिए उपलब्ध सुविधाएं (जैसे, मैन्युअल तरीके से चैनल चुनना), Chrome 150 से उपलब्ध हैं.

सेशन टाइप के साथ काम करने की सुविधा

वर्शन मैनेज करने की सभी सुविधाएं, ChromeOS के सभी सेशन टाइप के साथ काम करती हैं. इनमें अपडेट चैनल और वर्शन पिन करने की सुविधा भी शामिल है. इसमें इस तरह का कॉन्टेंट शामिल है:

• मैनेज किए जा रहे स्टैंडर्ड उपयोगकर्ता सेशन
• मैनेज किए जा रहे गेस्ट सेशन (एमजीएस)
• खास तौर पर कीऑस्क मोड के लिए बनाए गए एनवायरमेंट

ध्यान दें: यह पक्का करने के लिए कि अपडेट की पहचान सही तरीके से हो, वर्शन स्ट्रिंग को मान्य आईडब्ल्यूए फ़ॉर्मैट का पालन करना चाहिए. यह प्लैटफ़ॉर्म, सिर्फ़ अंकों वाले वर्शन के साथ काम करता है. इनमें ज़्यादा से ज़्यादा चार कॉम्पोनेंट हो सकते हैं. उदाहरण के लिए: 1, 1.2, 1.2.4 या 111.22.3.4.

ध्यान दें: पिन करने और चैनल को टारगेट करने की सुविधा, सभी तरह के सेशन के साथ काम करती है. हालांकि, वर्शन को डाउनग्रेड करने की सुविधा, शुरुआत में सिर्फ़ भरोसेमंद टेस्टर के लिए उपलब्ध हो सकती है. यह इस बात पर निर्भर करता है कि प्लैटफ़ॉर्म को डिप्लॉय करने की टाइमलाइन क्या है.

चैनल अपडेट करें

अपडेट चैनलों का इस्तेमाल करके, डेवलपर अलग-अलग ऐप्लिकेशन बिल्ड को सेगमेंट में बांट सकते हैं. इससे, उन्हें अलग-अलग ऑडियंस के लिए, ऐप्लिकेशन को डिप्लॉय करने और टेस्ट करने में मदद मिलती है. चैनल कॉन्फ़िगर करने के लिए, ऐप्लिकेशन अपडेट मेनिफ़ेस्ट में हर वर्शन एंट्री में, वैकल्पिक चैनल कलेक्शन फ़ील्ड जोड़ें. चैनल के ये नाम, प्लैटफ़ॉर्म के तय कीवर्ड (जैसे, canary या stable) तक सीमित नहीं होते. इसके बजाय, ये डेवलपर के तय किए गए आइडेंटिफ़ायर होते हैं. इन्हें लोअरकेस ASCII अक्षरों और अंकों वाली स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाना चाहिए. इनमें हाइफ़न या अंडरस्कोर शामिल हो सकते हैं, लेकिन स्पेस नहीं. अगर किसी वर्शन एंट्री में चैनल फ़ील्ड को पूरी तरह से छोड़ दिया जाता है, तो Chrome डिफ़ॉल्ट रूप से इसकी उपलब्धता को "डिफ़ॉल्ट" चैनल पर सेट कर देता है. आखिर में, एडमिन से जुड़ी नीति में तय किया गया चैनल का नाम, मेनिफ़ेस्ट में तय की गई स्ट्रिंग से पूरी तरह मैच होना चाहिए. टाइपिंग से जुड़ी कोई भी गड़बड़ी या गलत कॉन्फ़िगरेशन होने पर, ज़रूरी शर्तें पूरी करने वाले किसी भी वर्शन की पहचान नहीं की जा सकेगी. इससे उन क्लाइंट के लिए अपडेट नहीं मिल पाएंगे.

मेनिफ़ेस्ट कॉन्फ़िगरेशन

चैनल कॉन्फ़िगर करने के लिए, अपने वेब ऐप्लिकेशन मेनिफ़ेस्ट में हर वर्शन एंट्री में एक वैकल्पिक channels कलेक्शन जोड़ें. इन बातों का ध्यान रखें:

• चैनल मैपिंग: अगर किसी वर्शन एंट्री में channels कलेक्शन तय किया गया है, तो उस वर्शन को सिर्फ़ तय किए गए चैनलों पर इंस्टॉल किया जा सकता है.
• डिफ़ॉल्ट फ़ॉलबैक: अगर किसी वर्शन एंट्री में channels फ़ील्ड को पूरी तरह से छोड़ दिया जाता है, तो Chrome यह मान लेता है कि वह वर्शन सिर्फ़ default चैनल के लिए है.
• एग्ज़ैक्ट मैच: क्लाइंट-साइड नीति कॉन्फ़िगरेशन में बताए गए चैनल के नाम, अपडेट मेनिफ़ेस्ट में तय की गई स्ट्रिंग से पूरी तरह मैच होने चाहिए. यह केस-सेंसिटिव होता है. अगर टारगेट किए गए चैनल के नाम से कोई वर्शन मैच नहीं होता है, तो ऐप्लिकेशन को ज़रूरी अपडेट नहीं मिलेंगे.

अपडेट मेनिफ़ेस्ट का उदाहरण

यहां दिए गए उदाहरण में, एक से ज़्यादा रिलीज़ चैनलों के साथ काम करने वाला अपडेट मेनिफ़ेस्ट दिखाया गया है:

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

इस मेनिफ़ेस्ट के आधार पर, टारगेट किए गए हर चैनल के लिए ये वर्शन उपलब्ध हैं:

• default: 0.2.0,0.4.0 (जिसमें कोई चैनल नहीं होता और डिफ़ॉल्ट रूप से, डिफ़ॉल्ट चैनल पर सेट होता है)
• डेल्टा: 0.1.0, 0.2.0, 0.3.0
• बीटा: 0.3.0

आईडब्ल्यूए अपडेट इंजन, ऐप्लिकेशन के अपडेट मेनिफ़ेस्ट में चैनल फ़ील्ड को देखकर, चुनिंदा रिलीज़ चैनलों को टारगेट करने की सुविधा देता है.

वर्शन पिन करना

नियमों का सख्ती से पालन करने वाले या बेहद स्थिर एंटरप्राइज़ एनवायरमेंट में, एडमिन को यह पक्का करना चाहिए कि डिवाइसों पर कारोबार के लिए ज़रूरी सॉफ़्टवेयर के सटीक वर्शन चल रहे हों. वर्शन पिन करने की सुविधा की मदद से, एडमिन किसी आईडब्ल्यूए को किसी खास वर्शन पर लॉक कर सकते हैं. इससे, बैकग्राउंड में होने वाले सभी अपडेट रुक जाते हैं. इससे एंटरप्राइज़ को कॉन्फ़िगरेशन को स्थिर बनाए रखने और सख्त आंतरिक या इंडस्ट्री के नियमों का पालन करने का एक भरोसेमंद तरीका मिलता है.

किसी आइसोलेटेड वेब ऐप्लिकेशन (आईडब्ल्यूए) को रिलीज़ के लिए तैयार किसी खास बिल्ड पर फ़्रीज़ करने के लिए, एंटरप्राइज़ एडमिन IsolatedWebAppInstallForceList नीति में जाकर, pinned_version प्रॉपर्टी को कॉन्फ़िगर कर सकते हैं. इस सुविधा को मुख्य रूप से, Google Admin console में ऐप्लिकेशन के जानकारी पैनल में मौजूद इंटरैक्टिव यूज़र इंटरफ़ेस (यूआई) कंट्रोल की मदद से मैनेज किया जाता है. इसके लिए, आईडब्ल्यूए इंस्टॉल करने के स्टैंडर्ड वर्कफ़्लो का इस्तेमाल किया जाता है. हालांकि, एडमिन के पास रॉ JSON कॉन्फ़िगरेशन का इस्तेमाल करके, इन नीति वैल्यू को सीधे तौर पर डिप्लॉय करने का विकल्प भी होता है. जब एडमिन किसी मान्य वर्शन स्ट्रिंग को टारगेट कर लेता है, तो Chrome उस पैकेज को डाउनलोड कर लेता है. साथ ही, इसके बाद अपने-आप होने वाले सभी अपडेट को ब्लॉक कर देता है.

खास व्यवहार और पाबंदियां

• अपडेट फिर से शुरू करना (अनपिन करना): अपने-आप अपडेट होने की सुविधा को फिर से चालू करने के लिए, pinned_version प्रॉपर्टी को हटाएं या इसकी वैल्यू को नए टारगेट वर्शन में बदलें.
• डिफ़ॉल्ट रूप से डाउनग्रेड नहीं किया जाता: pinned_version को इंस्टॉल किए गए मौजूदा वर्शन से पहले के वर्शन पर सेट करने से, रोलबैक ट्रिगर नहीं होगा. ऐसा तब तक नहीं होगा, जब तक allow_downgrades को साफ़ तौर पर चालू न किया गया हो.
• पिन किए गए वर्शन उपलब्ध नहीं हैं: अगर कॉन्फ़िगर किया गया pinned_version, तय किए गए अपडेट चैनल में मौजूद नहीं है या इंस्टॉल किए गए वर्शन से पुराना है (डाउनग्रेड करने की सुविधा बंद होने पर), तो Chrome इंस्टॉल किए गए मौजूदा वर्शन को बनाए रखेगा और आगे के सभी अपडेट ब्लॉक कर देगा.
• नए डिप्लॉयमेंट: अगर मैनेज किए जा रहे किसी डिवाइस पर अब तक कोई आईडब्ल्यूए इंस्टॉल नहीं किया गया है और अपडेट मेनिफ़ेस्ट से, तय किया गया pinned_version नहीं मिल रहा है या मौजूद नहीं है, तो आईडब्ल्यूए इंस्टॉल नहीं हो पाएगा.

वर्शन डाउनग्रेड करना

अगर हाल ही में डिप्लॉय किए गए किसी अपडेट में कोई गंभीर गड़बड़ी या जोखिम है, तो एडमिन को डिवाइसों को पिछली स्थिर स्थिति में वापस लाना पड़ सकता है. Chrome, पहले से इंस्टॉल किए गए मैनेज किए जा रहे आईडब्ल्यूए को डाउनग्रेड करने की सुविधा देता है. पहले, इस प्लैटफ़ॉर्म पर सिर्फ़ अपग्रेड करने की सुविधा उपलब्ध थी.

डाउनग्रेड सिर्फ़ तब किया जा सकता है, जब नीति की ये दोनों शर्तें पूरी हों:

1. pinned_version को किसी मान्य और पुराने वर्शन पर सेट किया गया है.
2. allow_downgrades को साफ़ तौर पर 'सही' पर सेट किया गया हो.

डाउनग्रेड करने की प्रोसेस कैसे काम करती है

• ट्रिगर करने का तरीका: रोलबैक की प्रोसेस, अपडेट की जांच करने के सामान्य साइकल के दौरान पूरी की जाती है. यह साइकल हर चार से छह घंटे में चलता है.
• बैकग्राउंड में होने वाली प्रोसेस: Chrome, आईडब्ल्यूए को फिर से इंस्टॉल करता है. इसके लिए, वह अपडेट मेनिफ़ेस्ट में बताए गए पुराने वेब बंडल (.swbn) का इस्तेमाल करता है.

चेतावनी: उपयोगकर्ता का डेटा हमेशा के लिए मिट जाएगा: आईडब्ल्यूए को डाउनग्रेड करने पर, उससे जुड़े स्टोरेज पार्टिशन पूरी तरह से मिट जाएंगे. इनमें IndexedDB, LocalStorage, कैश मेमोरी, और कुकी शामिल हैं. उपयोगकर्ता के डेटा को सुरक्षित रखने के लिए, डाउनग्रेड करने की सुविधा को आपातकालीन स्थितियों के लिए रिज़र्व रखें. जैसे, सुरक्षा से जुड़ी गंभीर समस्याओं को ठीक करना. ऐसी गड़बड़ियां जो ज़्यादा गंभीर नहीं हैं उन्हें ठीक करने के लिए, हमारा सुझाव है कि आप रोल बैक करने के बजाय, एक नया और पैच किया गया माइनर वर्शन अपडेट बनाएं और उसे पब्लिश करें.

अहम जानकारी: अपडेट को तुरंत फ़्रीज़ करना: allow_downgrades को true पर टॉगल करने से, सभी स्टैंडर्ड फ़ॉरवर्ड अपडेट तुरंत फ़्रीज़ हो जाते हैं. भले ही, आपने pinned_version तय न किया हो. इस सुविधा के चालू होने पर, ब्राउज़र स्टैंडर्ड अपडेट को तब तक ब्लॉक करता है, जब तक कि आप साफ़ तौर पर कोई नया pinned_version असाइन न करें या allow_downgrades को वापस false पर टॉगल न करें.

चैनल ट्रांज़िशन लॉजिक

किसी नीति की मदद से, ऐप्लिकेशन के टारगेट किए गए चैनल को स्विच करने पर, अपडेट इंजन कुछ खास व्यवहारों का पालन करता है:

पहली स्थिति: पिछले वर्शन वाले चैनल पर स्विच करना

• अगर डाउनग्रेड करने की अनुमति है: अगर pinned_version, टारगेट चैनल पर मौजूद किसी पुराने वर्शन से मैच करता है और allow_downgrades की वैल्यू 'सही है' पर सेट है, तो रोलबैक होता है. साथ ही, उपयोगकर्ता का लोकल डेटा मिटा दिया जाता है.
• अगर डाउनग्रेड करने की अनुमति नहीं है: कोई डाउनग्रेड नहीं होगा. डिवाइस, इंस्टॉल किए गए मौजूदा नए वर्शन पर ही रहेगा. यह सिर्फ़ तब अपडेट होगा, जब नए चुने गए चैनल पर कोई नया वर्शन उपलब्ध होगा.

स्थिति B: किसी चैनल को उसके मिलते-जुलते वर्शन पर स्विच करना

• कोई बदलाव नहीं: अगर नया चुना गया चैनल, इंस्टॉल किए गए मौजूदा वर्शन नंबर पर ले जाता है, तो Chrome, इंस्टॉल किए गए बंडल में कोई बदलाव नहीं करेगा.
• बाइट-दर-बाइट आइडेंटिटी का सिद्धांत: डेवलपर को यह गारंटी देनी होगी कि अलग-अलग चैनलों पर मौजूद एक जैसे वर्शन नंबर में, एक जैसे बाइट-मैचिंग कोड सिग्नेचर शामिल हों. सभी चैनलों पर एक ही वर्शन स्ट्रिंग के तहत अलग-अलग कोड बेस डिप्लॉय करने से, ऐप्लिकेशन की स्थिति में अनचाहे और अनियमित बदलाव हो सकते हैं.

एडमिन नीति का कॉन्फ़िगरेशन

एंटरप्राइज़ वर्शन कंट्रोल, Google Admin console के प्लैटफ़ॉर्म की मदद से लागू किए जाते हैं. इसके लिए, IsolatedWebAppInstallForceList नीति स्कीमा का इस्तेमाल किया जाता है. इन सेटिंग को Admin console में यूज़र इंटरफ़ेस (यूआई) कंट्रोल की मदद से सीधे तौर पर मैनेज किया जा सकता है. इसके अलावा, इन्हें रॉ JSON नीति कॉन्फ़िगरेशन का इस्तेमाल करके भी डिप्लॉय किया जा सकता है.
एडमिन के लिए नीति कॉन्फ़िगरेशन के इस उदाहरण में, अपडेट चैनल, वर्शन पिन करने, और डाउनग्रेड करने के बारे में बताया गया है:

नीति की वैल्यू को दिखाने का तरीका

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

स्कीमा पैरामीटर के बारे में जानकारी

• channel (स्ट्रिंग, ज़रूरी नहीं): इससे Chrome को अपडेट मेनिफ़ेस्ट में, इस चैनल को असाइन किए गए वर्शन का ही आकलन करने का निर्देश मिलता है. अगर इसे शामिल नहीं किया जाता है, तो Chrome "डिफ़ॉल्ट" चैनल का आकलन करता है.
• pinned_version (स्ट्रिंग, ज़रूरी नहीं): यह डिवाइस को साफ़ तौर पर, स्ट्रिंग के तौर पर दिए गए वर्शन पर लॉक कर देता है. बैकग्राउंड में अपने-आप होने वाले अपडेट ब्लॉक कर दिए जाते हैं.
• allow_downgrades (बूलियन, ज़रूरी नहीं): इससे रोलबैक की सुविधा चालू होती है. अगर इस नीति को 'सही है' पर सेट किया जाता है और इसे किसी मान्य, पुराने pinned_version के साथ जोड़ा जाता है, तो Chrome डाउनग्रेड करके फिर से इंस्टॉल करने की प्रोसेस को ट्रिगर करेगा. चेतावनी: इस पैरामीटर को true पर सेट करने से, सभी स्टैंडर्ड फ़ॉरवर्ड अपडेट ब्लॉक हो जाएंगे. भले ही, pinned_version फ़ील्ड को शामिल न किया गया हो.

मैनेज नहीं किए जा रहे (उपयोगकर्ता ने इंस्टॉल किए हैं) आईडब्ल्यूए (150 से)

मैनेज नहीं किए जा रहे और उपयोगकर्ता की ओर से इंस्टॉल किए गए आइसोलेटेड वेब ऐप्लिकेशन के लिए, वर्शन को मैन्युअल तरीके से मैनेज किया जाता है:

इंस्टॉलेशन बंडल ──► उपयोगकर्ता चैनल चुनता है ──► चुने गए चैनल पर अपने-आप जांच होती है

अपने-आप अपडेट होने की सुविधा के लिए, मेनिफ़ेस्ट से जुड़ी ज़रूरी शर्तें

उपयोगकर्ता के इंस्टॉल किए गए आईडब्ल्यूए, बैकग्राउंड में समय-समय पर अपने-आप होने वाले अपडेट की जांच कर सकें और उन्हें पा सकें, इसके लिए ऐप्लिकेशन के लोकल वेब ऐप्लिकेशन मेनिफ़ेस्ट (/.well-known/manifest.webmanifest पर बंडल के अंदर पैकेज किया गया मेटाडेटा) में एक मान्य update_manifest_url फ़ील्ड होना ज़रूरी है.

अगर इस यूआरएल को ऐप्लिकेशन की लोकल मेनिफ़ेस्ट फ़ाइल से हटा दिया जाता है, तो मैनेज नहीं किया जाने वाला अपडेट इंजन, बैकग्राउंड में कभी भी जांच नहीं करेगा. साथ ही, ऐप्लिकेशन हमेशा के लिए अपने शुरुआती इंस्टॉलेशन वर्शन पर फ़्रीज़ रहेगा.

मैन्युअल तरीके से चैनल चुनने की सुविधा

मैनेज नहीं किए जा रहे आईडब्ल्यूए को पहली बार इंस्टॉल करने के दौरान, ब्राउज़र अपडेट मेनिफ़ेस्ट की जांच करता है. साथ ही, अगर डेवलपर ने कई चैनल कॉन्फ़िगर किए हैं, तो वह उपयोगकर्ता को सीधे तौर पर उपलब्ध चैनल के विकल्प दिखाता है. जैसे, "स्टेबल", "बीटा".

कुंजी के लाइफ़साइकल से जुड़े नियम

1. पहली बार इंस्टॉल करने का सोर्स: इंस्टॉल करते समय उपयोगकर्ता ने चाहे जो भी चैनल चुना हो, पहली बार इंस्टॉल करने पर हमेशा वही फ़ाइलें डिप्लॉय होती हैं जो इंस्टॉल करने के लिए उपलब्ध कराए गए बंडल में मौजूद होती हैं.
2. इसके बाद के अपडेट: इंस्टॉल होने के बाद, आने वाले समय में मिलने वाले अपडेट के लिए, सिर्फ़ चुने गए चैनल से क्वेरी की जाती है. ऐप्लिकेशन सिर्फ़ तब अपडेट होगा, जब टारगेट किए गए चैनल पर इंस्टॉल किए गए वर्शन से ज़्यादा वर्शन पब्लिश किया जाएगा.
3. चैनल बदलना: इंस्टॉल करने के बाद, किसी दूसरे अपडेट चैनल पर स्विच करने के लिए, उपयोगकर्ता को आईडब्ल्यूए को अनइंस्टॉल करके फिर से इंस्टॉल करना होगा. साथ ही, इंस्टॉल करने के दौरान चुने गए चैनल को चुनना होगा.

मैनेज किए जा रहे डिप्लॉयमेंट को टेस्ट करने का तरीका

Chrome Enterprise Admin console की मदद से डिवाइसों को मैनेज करने वाले एडमिन या सीधे तौर पर नीतियां कॉन्फ़िगर करने वाले एडमिन के लिए:

1. संगठन की सेटिंग में जाकर, ऐप्लिकेशन के बारे में जानकारी पैनल पर जाएं.
2. पिन करने और चैनल टारगेट की जांच करने के लिए, कॉन्फ़िगरेशन प्रॉपर्टी लागू करें. ये कंट्रोल, स्टैंडर्ड उपयोगकर्ता सेशन, मैनेज किए जा रहे गेस्ट सेशन (एमजीएस), और किऑस्क के साथ पूरी तरह से काम करते हैं. इसलिए, टारगेट किए गए सभी डिप्लॉयमेंट एनवायरमेंट में, इनके काम करने के तरीके की पुष्टि की जा सकती है.
3. अपडेट की जांच को स्थानीय तौर पर देखने के लिए, टेस्ट क्लाइंट पर chrome://web-app-internals पर जाएं. इससे, अपडेट की जांच को मैन्युअल तरीके से लागू किया जा सकता है और आने वाले मेनिफ़ेस्ट पैकेट का विश्लेषण किया जा सकता है.

नतीजा

आइसोलेटेड वेब ऐप्लिकेशन का सुरक्षा आर्किटेक्चर, डेवलपर को सशक्त बनाने के लिए डिज़ाइन किया गया है. साथ ही, ऐप्लिकेशन के लाइफ़साइकल के व्यवहार पर सख्त अनुमान और कंट्रोल बनाए रखा गया है. Chrome के वर्शन मैनेजमेंट की सुविधाओं का फ़ायदा उठाकर, डेवलपर और आईटी एडमिन, दोनों ही डिप्लॉयमेंट की ऐसी मज़बूत पाइपलाइन बना सकते हैं जो अनुपालन के सख्त मानकों और ऑपरेशनल लक्ष्यों के मुताबिक हों.

अपने ऐप्लिकेशन के अपडेट की रणनीति को डिज़ाइन और मैनेज करते समय, इन मुख्य बातों को ध्यान में रखें:

• प्रोग्रेसिव चैनलों का इस्तेमाल करें: अपडेट चैनलों (जैसे, beta, dev या कस्टम रिंग) की मदद से, टेलीमेट्री और सुझाव/राय धीरे-धीरे इकट्ठा की जा सकती है. इससे यह पक्का होता है कि डिफ़ॉल्ट चैनल पर आम लोगों के लिए उपलब्ध होने से पहले, खास अपडेट की अच्छी तरह से पुष्टि की जाए.
• स्थिरता के लिए पिन करना: बहुत ज़्यादा स्ट्रक्चर्ड या नियमों का पालन करने वाले एंटरप्राइज़ एनवायरमेंट में, ज़रूरी एंडपॉइंट को पुष्टि किए गए, सटीक pinned_version पर लॉक करें. इससे, अचानक होने वाली गड़बड़ियों या वर्कफ़्लो में आने वाली रुकावटों से, कार्रवाइयों को सुरक्षित रखा जा सकता है.
• आपातकालीन स्थितियों के लिए, डाउनग्रेड करने की सुविधा को रिज़र्व रखें: यह समझें कि वर्शन को डाउनग्रेड करना, सुरक्षा के लिए एक असरदार और सही तरीका है. पहले ऐसा करना मुमकिन नहीं था. हालांकि, रोलबैक करने पर, ऐप्लिकेशन को पूरी तरह से फिर से इंस्टॉल किया जाता है. साथ ही, क्लाइंट के सभी लोकल स्टोरेज (IndexedDB, LocalStorage, कुकी) को मिटा दिया जाता है. इसलिए, इसका इस्तेमाल सिर्फ़ सुरक्षा से जुड़ी गंभीर समस्याओं को ठीक करने के लिए किया जाना चाहिए. सामान्य पैच के लिए, भविष्य को ध्यान में रखकर छोटा अपडेट डिप्लॉय करना हमेशा सबसे सही रणनीति होती है.
• नीति के फ़्लैग को समझें: एडमिन के स्विच का ध्यान रखें. allow_downgrades को चालू करने से, आगे के सभी अपडेट रुक जाएंगे. भले ही, पिन को ऐक्टिव तौर पर तय न किया गया हो.
• बाइट-दर-बाइट इंटिग्रिटी सेट अप करना: पक्का करें कि अलग-अलग चैनलों पर डिप्लॉय किए गए एक जैसे वर्शन नंबर, एक जैसे बाइट-मैचिंग बंडल से मैप हों. इससे, क्लाइंट के एक चैनल से दूसरे चैनल पर स्विच करने पर, ऐप्लिकेशन की स्थिति में होने वाली गड़बड़ियों से बचा जा सकता है.

इन सुविधाओं को सीधे अपने अपडेट मेनिफ़ेस्ट और एंटरप्राइज़ नीति स्कीमा में इंटिग्रेट करके, अपडेट के भरोसेमंद, ऑडिट किए जा सकने वाले, और सुरक्षित फ़्लो को पक्का किया जा सकता है. इससे, Isolated Web App नेटवर्क की भरोसेमंद सुविधाओं को सुरक्षित रखा जा सकता है.