👩🏿‍🏫 🤒 🙌 दो प्लेटफार्मों को एक में कैसे संयोजित करें और उपयोगकर्ताओं को अपमानित न करें। Yandex.Kew Developers अनुभव 🧕🏿 💡 🤾🏽

पिछले साल, TheQuestion सेवा Yandex में शामिल हो गई। उस समय, पहले से ही प्रश्नों और उत्तरों की एक समान सेवा थी - Yandex.Znatoki। पारखी लोगों के पास एक बड़े दर्शक वर्ग और कई दिलचस्प सवाल थे, लेकिन पर्याप्त विशेषज्ञ नहीं थे जो इन सवालों के उच्च-गुणवत्ता के उत्तर दे सकते थे। TheQuestion, इसके विपरीत, विशेषज्ञों का एक मजबूत समुदाय था, लेकिन इसमें दिलचस्प सवालों का अभाव था। उनमें से प्रत्येक से सर्वश्रेष्ठ लेने के लिए तार्किक कदम दो सेवाओं को जोड़ना था। लेकिन यह कैसे करें यदि प्रत्येक सेवा का अपना तकनीकी आधार, सामग्री और उपयोगकर्ता हैं?

आज मैं इस बारे में बात करूंगा कि हमारी टीम ने तकनीकी दृष्टि से इस समस्या को कैसे हल किया। आपको पता चल जाएगा कि हमने किन विकल्पों के संयोजन पर विचार किया है और जो अंत में चुना है। मैं आपको "स्वैप एपीआई", डेटाबेस माइग्रेशन, पूलिंग प्रोफाइल और बैकएंड टेस्टिंग के बारे में बताता हूँ। और फिर भी - गलती करने के अधिकार के बिना कदम की रात के बारे में। आप देखेंगे कि हमें ऊब नहीं होना था।

दो सेवाओं को एक में विलय करने का कार्य नया नहीं है, लेकिन इससे यह आसान नहीं होता है। इतिहास एकीकरण के कई सफल (और ऐसा नहीं) उदाहरणों को जानता है, लेकिन, दुर्भाग्य से, कोई "चांदी की गोली" नहीं है और एक स्पष्ट निर्देश "यह करो और सब कुछ बाहर काम करेगा"। सब कुछ बहुत सेवाओं की विशिष्टताओं और संयुक्त परिणाम पर निर्भर करता है।

हमारे मामले में, लक्ष्य यह था: कि प्रत्येक साइट पर लिखी गई सभी सामग्री एक एकीकृत सेवा पर उपलब्ध थी, और इसके लेखक इसे प्रबंधित कर सकते थे।

तो, आप दो क्यू एंड ए सेवाओं को कैसे संयोजित करते हैं, जो कि समान प्रतीत होते हैं, लेकिन सार में बहुत भिन्न हैं? सामग्री और उपयोगकर्ताओं को एक सेवा से दूसरी सेवा में स्थानांतरित करना पुराने अपार्टमेंट से एक नए स्थान पर जाने के समान है।

केवल हमारे मामले में, उपयोगकर्ता एक साथ दो अपार्टमेंट (कॉनॉन्सेर्स और थिंकशन) में रह सकते हैं, और आपको इसे सावधानी से तीसरे तक पहुंचाने की आवश्यकता है। आपको सभी फर्नीचर, पौधों, एक बिल्ली और यहां तक कि वॉलपेपर को एक नए अपार्टमेंट में स्थानांतरित करने की आवश्यकता है (अर्थात, प्रश्न, उत्तर, टिप्पणी, पसंद), और फिर उसे स्थानांतरित करने के लिए आमंत्रित करें।

यह कैसे करना है? कई विकल्प तुरंत दिमाग में आते हैं।

विकल्प 1. बहुत बुरा।
चलो बस सेवाओं में से एक ले लो, सभी सामग्री को दूसरे में स्थानांतरित करें (हालांकि यह भी अब आसान नहीं है) और मूल सेवा को बंद करें।

यह विकल्प पहली सेवा के उपयोगकर्ता के दृष्टिकोण से बहुत खराब है। हमने उसके पुराने घर को ध्वस्त कर दिया और उसे एक नए घर में जाने के लिए मजबूर किया। कोई भी व्यक्ति इस रवैये को पसंद नहीं करेगा, और आगे बढ़ने के बजाय, वह बस सूर्यास्त में जा सकता है। हमारे लिए, मुख्य मूल्य उपयोगकर्ता समुदाय है, इसलिए हमने किसी को अपमानित करने की योजना नहीं बनाई है। और साहसपूर्वक अन्य विकल्पों पर स्विच किया गया।

विकल्प 2. खराब
चलो सेवाओं में से किसी को भी नहीं बदलते हैं, इसके बजाय, एक नया, एकीकृत एक लॉन्च करें, और हम समय-समय पर अन्य दो से सामग्री जोड़ेंगे (उदाहरण के लिए, दिन में एक बार)।

इस मामले में, हम उपयोगकर्ता को बदतर नहीं बनाते हैं, लेकिन हम भी बेहतर नहीं करते हैं। उनका पुराना अपार्टमेंट अपरिवर्तित बना हुआ है, लेकिन नए में जाने का कोई मतलब नहीं है। सभी पड़ोसी भी एक पुराने घर में रहते हैं, बस खरीदे गए एक फूल को एक दिन बाद ही एक नए अपार्टमेंट में ले जाया जाएगा। ऐसी एकीकृत सेवा के पास नया घर बनने का कोई मौका नहीं है।

विकल्प 3. अच्छा, लेकिन मुश्किल।
चलो सेवाओं में से किसी को भी बंद न करें, हम तुरंत एकीकृत सेवा पर सामग्री और प्रोफाइल की नकल करेंगे, और लोग समय के साथ आगे बढ़ेंगे।

सभी उपयोगकर्ता के पड़ोसी (और यहां तक कि बिल्ली) पुराने और नए घर में एक साथ रहते हैं। एक फूल जिसे आपने अभी खरीदा था, एक नए अपार्टमेंट में दिखाई देता है। वास्तव में क्या जरूरत है! यह विकल्प उपयोगकर्ता के दृष्टिकोण से सबसे आरामदायक है। इसलिए, हमने इसे चुना।

हिलना शुरू करो

हमने आखिरकार जो किया वह कई वाक्यों में वर्णित किया जा सकता है। हमने पूरी तरह से पूरी TheQuestion API बैकएंड को Connoisseurs backend के आधार पर दोहराया, इस प्रकार एक सिंगल बैकेंड प्राप्त किया जो एक ही बार में दो (और यहां तक कि तीन) साइटों के साथ काम कर सकता है। उसी समय, TheQuestion का दृश्य लगभग अपरिवर्तित रहा, जिसका अर्थ है कि उपयोगकर्ताओं के दृष्टिकोण से, साइट स्वयं व्यावहारिक रूप से परिवर्तित नहीं हुई है। इस परियोजना को आंतरिक नाम "स्वैप एपीआई" प्राप्त हुआ है। लेकिन पहले बातें पहले।

प्रवेश द्वार पर हमारे पास क्या था: दो पूरी तरह से स्वतंत्र साइटें। Connoisseurs Yandex के आंतरिक बादलों में रहते हैं। Connoisseurs backend पायथन में लिखा गया है। TheQuestion Microsoft Azure के बादलों में रहता है, TheQuestion backend को Go में लिखा गया है। डेटाबेस में सेवाओं की पूरी तरह से अलग डेटा संग्रहण योजना है। इसके अलावा, TheQuestion में दो मोबाइल एप्लिकेशन (एंड्रॉइड और आईओएस के लिए) हैं, जिन्हें समर्थन करने की भी आवश्यकता है। सामान्य तौर पर, दुश्मन ऐसे चिड़ियाघर को एकजुट नहीं करना चाहता है।

स्टेज 0. यैंडेक्स क्लाउड में ड्राइव करें

कड़ाई से बोलते हुए, यह कदम "प्लगइन एपीआई" के लिए आवश्यक नहीं है, लेकिन यह अगले चरणों को काफी सरल करता है। इस स्तर पर, हमने बाहरी भंडारण और सुविधाओं को पूरी तरह से छोड़ दिया। TheQuestion ने Yandex DNS सर्वर का उपयोग शुरू किया। किराया सेवाओं को Yandex.Cloud में स्थानांतरित कर दिया गया था। डेटाबेस को Yandex प्रबंधित डेटाबेस में स्थानांतरित किया गया था। इस कदम के दौरान, हम TheQuestion में कई त्रुटियों को खोजने और ठीक करने में सक्षम थे, उदाहरण के लिए, 2015 कोड में रेडिस के लिए बिना कनेक्शन के। एक बोनस के रूप में, हमें TheQuestion के लिए अतिरिक्त शक्ति भी मिली।

स्टेज 1. डेटा माइग्रेशन

भले ही आप सेवाओं को संयोजित करना चाहते हों, लेकिन हमें किसी भी स्थिति में डेटा को संयोजित करना होगा। एकल डेटाबेस के लिए, उन्होंने PostgreSQL लेने का फैसला किया - यह DBMS पहले से ही विशेषज्ञों और TheQuestion दोनों में उपयोग किया गया है। परियोजना को फिर से जटिल नहीं करने के लिए, उन्होंने एकीकृत सेवा के लिए एक तीसरा आधार बनाना शुरू नहीं किया, लेकिन बस ज़न्नतकोव डेटाबेस लिया और इसे विस्तारित किया ताकि यह सभी TheQuestion डेटा को स्वीकार कर सके। यह पहली बड़ी तकनीकी चुनौती थी।

TheQuestion डेटाबेस से प्रत्येक तालिका में प्रत्येक प्रविष्टि को परिवर्तित किया जाना था और विशेषज्ञ डेटाबेस में डाल दिया गया था। फिर - प्रत्येक स्तंभ को एक और दूसरे आधार से सहसंबंधित करें। कई क्षेत्रों को एक प्रारूप से दूसरे में परिवर्तित किया जाना था। इसलिए, QML (TheQuestion) से मार्कडाउन (विशेषज्ञों) तक पाठ भंडारण प्रारूप (प्रश्न या उत्तर भंडारण का वास्तविक प्रारूप) का एक अलग बड़ा उपवाक्य रूपांतरण था।

हमने एक डेटाबेस से दूसरे में नए डेटा को स्थानांतरित करने की एक नियमित (दिन में कई बार) प्रक्रिया की स्थापना की, लेकिन साथ ही यह भी सुनिश्चित किया कि अगले चरण के पूरा होने तक TheQuestion के डेटा को कहीं भी प्रदर्शित नहीं किया गया था। क्योंकि "दिन में कई बार" का वादा "तुरन्त" होने से दूर है, और डेटा TheQuestion पर समान डेटा के साथ असंगत स्थिति में हो सकता है, जो उपयोगकर्ताओं को भ्रमित करेगा। तो क्यों हम डेटा माइग्रेशन से शुरू करते हैं अगर बैकएंड अभी तक तैयार नहीं था?

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

स्टेज 2. "स्वैपिंग एपीआई"

इसलिए, हमने पहले समस्याओं को हल किया - हमने TheQuestion डेटाबेस से सामग्री लेना सीखा और यदि आप चाहें तो इसे प्रदर्शित भी कर सकते हैं। अब इस सामग्री को तुरंत एकीकृत डेटाबेस में लाने के लिए आवश्यक था, और दिन में कई बार नहीं।

ऐसा करने के लिए, सभी आवश्यक तर्क के साथ संपूर्ण TheQuestion बैकएंड को फिर से लिखना आवश्यक था। परियोजना का नाम, "स्वैप एपीआई," सख्ती से बोलना, सार को पूरी तरह से प्रतिबिंबित नहीं करता है। इसे "स्वैप बैकेंड" कहना अधिक सही होगा। तथ्य यह है कि, TheQuestion फ्रंट-एंड के कामकाज के लिए आवश्यक सभी "पेन" के प्रत्यक्ष कार्यान्वयन के अलावा, अन्य संभावनाओं को महसूस किया जाना था। हमने कई प्रमुख कार्यों का सामना किया।

प्राधिकरणYandex में एक केंद्रीकृत उपयोगकर्ता प्राधिकरण प्रणाली है - Yandex.Passport। और Connoisseurs, निश्चित रूप से, पासपोर्ट का उपयोग करते थे। इसमें लॉग इन करने के लिए, आपके पास यैंडेक्स में एक खाता होना चाहिए। यही समस्या थी। सभी TheQuestion उपयोगकर्ता Yandex के माध्यम से साइट पर लॉग इन नहीं हुए (हालाँकि ऐसा अवसर था)। कई उपयोगकर्ताओं के पास Yandex लॉगिन बिल्कुल नहीं था और सोशल नेटवर्क (VKontakte, Facebook ...) के माध्यम से चला गया। स्वाभाविक रूप से, हमें चलते समय इस कार्यक्षमता को रखना था। इसलिए, हमने "गैर-पासपोर्ट" प्राधिकरण लागू किया।

जगह खोजना।TheQuestion ने प्रश्नों, उत्तरों, उपयोगकर्ताओं और विषयों पर एक खोज को लागू किया। खोज के लिए, एक तृतीय-पक्ष स्फिंक्स समाधान का उपयोग किया गया था। जाहिर है, अगर हम किसी एकल सेवा के बारे में बात कर रहे हैं, तो खोज समान होनी चाहिए, अर्थात यह एक साथ दो प्रणालियों पर काम नहीं कर सकता है। इस प्रकार, स्फिंक्स को आंतरिक खोज इंजन के पक्ष में छोड़ दिया गया था, जो सभी TheQuestion सामग्री की आवश्यक कार्यक्षमता और अनुक्रमण के समर्थन के साथ था।

ज़ेन और टर्बो में पृष्ठों का शिपमेंट । शामिल होने के समय, TheQuestion ने पहले से ही Yandex प्रौद्योगिकियों का उपयोग किया था। टर्बो पृष्ठों का समर्थन किया गया, दिलचस्प सामग्री ज़ेन फ़ीड में गिर गई। यह सब "प्रतिस्थापन एपीआई" में भी समर्थित होना था।

सेवा और अनुप्रयोगों में सूचनाएं, मेलिंग सूचियां।उपयोगकर्ताओं को सूचित करने से संबंधित सब कुछ: सदस्यताएँ, दिलचस्प सामग्री के साथ समाचार पत्र, पसंद और टिप्पणियों के बारे में धक्का, बहुत कुछ। यह सब सावधानीपूर्वक स्थानांतरित किया जाना था और भूल नहीं गया था।

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

एकीकृत उपयोगकर्ता रेटिंग प्रणाली।यह कार्य तकनीकी नहीं, बल्कि तार्किक था। औपचारिक रूप से, "स्वैप एपीआई" के लिए एकीकृत रेटिंग प्रणाली विकसित करना आवश्यक नहीं है, लेकिन भविष्य में एकीकृत सेवा के लिए इस प्रणाली की आवश्यकता है। दोनों साइटों पर, उपयोगकर्ताओं को बनाई गई सामग्री की मात्रा और गुणवत्ता के लिए मूल्यांकन किया गया था। रेटिंग के विवरण का खुलासा नहीं किया गया था, लेकिन जितना अधिक बार और बेहतर आप सवालों के जवाब देते हैं, आपकी रेटिंग उतनी ही अधिक होती है। रेटिंग सिद्धांत दोनों सेवाओं पर समान थे, लेकिन सूत्र और कारक बहुत अलग थे। यह न केवल सही ढंग से और ईमानदारी से Znatokov और TheQuestion के उपयोगकर्ताओं की आपस में तुलना करने के लिए आवश्यक था, बल्कि उन विशेषज्ञों के लिए एक ही रेटिंग पर विचार करने के लिए सीखना था जिन्होंने एक बार में दो सेवाओं पर लिखा था।

और सभी एपीआई को फिर से लिखना।यह पसंद है या नहीं, यह कार्य सबसे महत्वपूर्ण और कठिन था। सेवाओं पर कई प्रक्रियाएं समान थीं, इसलिए हमने उन्हें Connoisseurs से लिया और खरोंच से नहीं लिखा। लेकिन बहुत सी नई चीजें भी थीं, उदाहरण के लिए, उपयोगकर्ताओं की सीधी रेखा या ड्राफ्ट उत्तर। परिणामस्वरूप, हमने "स्वैप एपीआई" में 100 से अधिक "पेन" को फिर से लिखा और 50 से अधिक आरईएसटी संसाधनों को लागू किया।

हमने ऊपर वर्णित सभी कार्यक्षमता को लागू करने के बाद, चलना शुरू करना संभव था। लेकिन इससे पहले कि हम एक तरकीब करते।

यह स्पष्ट है कि उत्पादन में "स्वैप एपीआई" को बदलने और रोल आउट करने से पहले, इसे बहुत अच्छी तरह से जांचना होगा। सबसे पहले, इसे कार्यात्मक रूप से परीक्षण करना आवश्यक था, अर्थात सीधे नए एपीआई पर पूरी साइट के प्रदर्शन की जांच करें। दूसरे, यह तनावपूर्ण है। हम 100% सुनिश्चित होना चाहते थे कि हमारा डिजाइन लोड के तहत "झूठ" नहीं होगा। स्वाभाविक रूप से, हमने नियमित रूप से "लोड फायरिंग" किया, जिससे पता चला कि हमारे पास प्रदर्शन की अच्छी आपूर्ति है। लेकिन सेवा प्रदर्शन के मामलों में, इसे सुरक्षित रूप से खेलना हमेशा बेहतर होता है। कोई भी, यहां तक कि सबसे अच्छा, सिंथेटिक लोड परीक्षण उत्पादन भार से किसी भी तरह अलग हैं। इसलिए, हमने तय किया, एपीआई को बदलने से पहले, हमारे स्टैंड पर उत्पादन लोड को भरने के लिए।

ऐसा करने के लिए, TheQuestion के दृश्यपटल पर, हमने एक ही बार में दो API में GET के सभी अनुरोधों (मतलब डेटा रिक्वेस्ट, मॉडिफिकेशन नहीं) के दोहराव को लागू किया: "पुराना API" TheQuestion, जो उस समय मुख्य था, और द्वितीयक "स्वैप एपीआई"। उसी समय, फ्रंटएंड ने मामूली एपीआई प्रतिक्रिया की प्रतीक्षा नहीं की और त्रुटियों को संसाधित नहीं किया, लेकिन हम वास्तविक उपयोगकर्ताओं पर बैकएंड का परीक्षण करने में सक्षम थे।

स्टेज 3. और फिर हमें अनुप्रयोगों के बारे में याद आया

नहीं, निश्चित रूप से, हमने इस समय उनके बारे में याद किया, लेकिन एक समस्या का सामना किया। जिन लोगों ने मोबाइल एप्लिकेशन के साथ काम किया है, वे जानते हैं कि उनके साथ परेशानी साइट की तुलना में बहुत अधिक है। यह मुख्य रूप से नए संस्करणों के वितरण के कारण है।

सबसे पहले, आपको ऐप स्टोर और Google Play की बाहरी सेवाओं के साथ काम करना होगा और परीक्षण को पारित करने के लिए नए संस्करणों की प्रतीक्षा करनी होगी (और कभी-कभी सत्यापन में काफी समय लग सकता है)। दूसरे, भले ही आपका एप्लिकेशन पहले ही परीक्षण पास कर चुका हो और स्टोर में दिखाई दिया हो, लेकिन इसका मतलब यह नहीं है कि उपयोगकर्ता अपडेट करेंगे।

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

बैक-एंड की तुलना में फ्रंट-एंड पर कुछ बदलाव करना बहुत आसान था, इसलिए, "प्लग-इन एपीआई" विकसित करने की प्रक्रिया में, फ्रंट-एंड थोड़ा था, लेकिन बदल गया। विशेष रूप से, पुराने TheQuestion डेटाबेस ने संख्यात्मक 64-बिट आईडी का उपयोग किया था। Connoisseurs डेटाबेस और, तदनुसार, संयुक्त डेटाबेस और TheQuestion के लिए नए API ने स्ट्रिंग 128-बिट आईडी का उपयोग किया। सामान्य तौर पर, Node.js में लिखे गए एक दृश्य के लिए, यह अंतर महत्वपूर्ण नहीं है। लेकिन दृढ़ता से टाइप किए गए अनुप्रयोगों के लिए, यह घातक निकला। हमने पिछड़ी संगतता खो दी, और पुराने एप्लिकेशन "प्लगइन एपीआई" के साथ काम नहीं कर सके।

कुछ बिंदु पर, यहां तक कि "प्लगइन एपीआई के लिए प्लगइन एपीआई" नामक एक परियोजना भी थी, जिसका सार नए बैकएंड और अनुप्रयोगों के बीच एक छोटी परत लिखना था जो सभी डेटा को पुराने प्रारूप में बदल देगा। हालाँकि, हमने इस विचार को जल्दी छोड़ दिया। यह परत बहुत कठोर "बैसाखी" होगी, जो भविष्य में निश्चित रूप से हमें कई समस्याएं लाएगी। उदाहरण के लिए, आप केवल 128-बिट आईडी को 64-बिट में नहीं ले सकते हैं और उसका अनुवाद नहीं कर सकते हैं। मुझे जानकारी के नुकसान के साथ अनुवाद करना होगा और, परिणामस्वरूप, आईडी द्वारा संभावित टकराव, या पुरानी और नई आईडी (डेटाबेस के सभी तत्वों के लिए) के पत्राचार के साथ एक मध्यवर्ती तालिका बनाए रखना होगा। दोनों कि, और एक और - सबसे अच्छा वास्तुशिल्प समाधान नहीं।

आईडी के अलावा, कई अन्य परिवर्तन भी थे जो फ्रंट-एंड और एप्लिकेशन साइड पर समर्थन करना बहुत आसान थे। नतीजतन, हमने अनुप्रयोगों में परिवर्तन लागू करने का फैसला किया और अभी भी मजबूर अपडेट का उपयोग करते हैं। थोड़े समय में, हमने "स्वैप एपीआई" के साथ संगत अनुप्रयोगों के नए संस्करण विकसित किए, क्योंकि सामने के छोर से इतने बदलाव नहीं हुए थे और वे बहुत गंभीर नहीं थे। ऐप स्टोर और Google Play पर भेजा गया, सफलतापूर्वक मॉडरेट किया गया और प्रतीक्षा करने लगा।

स्टेज एक्स। चलो चलें!

तो सभी कोड लिखा है। "प्रतिस्थापन एपीआई" के साथ स्टैंड का परीक्षण और निकाल दिया गया है। एप्लिकेशन के नए संस्करणों को दुकानों में परीक्षण किया गया है और प्रकाशन के लिए तैयार हैं। अब इस सब को उत्पादन में बदलना पड़ा।

इस तथ्य के कारण कि पुराने डेटाबेस से नए डेटा की प्रतिलिपि नए के लिए असिंक्रोनस रूप से होती है और कुछ समय लगता है, आप किसी कार्य स्थल पर बैकेंड (और इसके तहत डेटाबेस) को स्विच नहीं कर सकते। इससे उपयोगकर्ता डेटा की हानि या असंगति हो सकती है। इसलिए, हमने एक तारीख चुनी, उपयोगकर्ताओं को चेतावनी दी और एक प्लेट तैयार की "प्रगति में तकनीकी कार्य"।

और फिर घंटे आ गए, या रात के बजाय एक्स। रोल-आउट योजना इस तरह दिखी:

वेबसाइट TheQuestion पर हमने एक स्टब लटका दिया "कार्य प्रगति पर है"।
हम एप्लिकेशन को Readonly मोड में ट्रांसफर करते हैं। उपयोगकर्ता पुराने डेटाबेस से सामग्री पढ़ सकते हैं, लेकिन एक नया नहीं बना सकते।
TheQuestion Readonly. : . , , .
. , .
.
, , API.
API . — , API .
, , .
« », API.
.

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

इसके अलावा, स्विचिंग की प्रक्रिया में, एक प्रमुख विशेषता थी जो कई बार सब कुछ जटिल करती थी और जिम्मेदारी बढ़ जाती थी। तथ्य यह है कि स्विचिंग प्रक्रिया को उलट नहीं किया जा सकता है।

यद्यपि पुराने TheQuestion डेटाबेस से डेटा को एक नए में कॉपी और परिवर्तित करने की प्रक्रिया, एक एकीकृत की स्थापना की गई थी और हमारे लिए डीबग की गई थी, लेकिन रिवर्स कॉपी करने की प्रक्रिया नहीं थी (नए डेटाबेस से पुराने एक तक)। इसका मतलब यह है कि जैसे ही हम साइट को "स्वैप एपीआई" पर खोलते हैं और उपयोगकर्ता यातायात शुरू करते हैं, सभी नए बनाए गए प्रश्न, उत्तर, टिप्पणियां और पसंद अब आसानी से पुराने TheQuestion डेटाबेस में नहीं मिल सकते हैं। यदि खोलने के बाद कुछ गलत हो जाता है, उदाहरण के लिए, एक एकल डेटाबेस लोड के साथ सामना नहीं कर सकता है, तो यह जल्दी से सब कुछ वापस करने के लिए संभव नहीं होगा।

वास्तव में, निश्चित रूप से, मैं अतिशयोक्ति करता हूं। किसी भी स्थिति में, हम उपयोगकर्ता डेटा नहीं खोएंगे। हमारे पास एक प्लान बी और एक नए डेटाबेस से डेटा को मैन्युअल रूप से बैक अप करने का एक तरीका है। लेकिन यह अभी भी कुछ समय लगेगा, और रोलबैक उपयोगकर्ताओं के लिए काफी दर्द रहित रूप से नहीं हुआ होगा।

सौभाग्य से, प्लान ए ने काम किया, और कुछ भी वापस नहीं करना पड़ा।

अंतिम चरण

तो, बैकएंड बदल दिया गया था, डेटाबेस को जोड़ दिया गया था, मोबाइल एप्लिकेशन को नहीं भुलाया गया था। उपयोगकर्ताओं के लिए, कुछ भी नहीं बदला है, क्योंकि Yandex.Ku साइट, जिसे दोनों साइटों से डेटा को संयोजित करना था, उस समय अभी तक लॉन्च नहीं किया गया था। और इसके लॉन्च के लिए हमें एक और समस्या का समाधान करना होगा।

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

ज़न्नतोकोव से केव में जाने पर, सब कुछ सरल है: दोनों मामलों में, एक ही यैंडेक्स खाते का उपयोग किया जाता है। लेकिन TheQuestion का अपना खाता है, जिसे Kew पर अधिकृत नहीं किया जा सकता है। सौभाग्य से, हमने इस बारे में पहले से सोचा था। ऊपर वर्णित क्रियाओं से बहुत पहले, हमने TheQuestion उपयोगकर्ताओं को अपने Yandex प्रोफाइल को लिंक करने में सक्षम किया। और सेवाओं के भौतिक समेकन के समय तक, 90% से अधिक सक्रिय उपयोगकर्ताओं ने इसे किया। इसने हमें सामग्री और उपयोगकर्ताओं के प्रवास को दर्द रहित तरीके से शुरू करने की अनुमति दी।

संपूर्ण

जब हम चले गए, हम प्रत्येक उपयोगकर्ता को बचाना चाहते थे, इसलिए हम जानबूझकर प्लेटफार्मों के संयोजन के सबसे अधिक समय लेने वाले और जोखिम भरे विकल्प में चले गए। हमने एक एकीकृत तकनीकी आधार बनाया, जो सामग्री और प्रोफाइल को तुरंत परिवहन करने का तरीका सीखा। अप्रत्याशित बंद होने और जबरन स्थानांतरण के बजाय, उन्होंने पुरानी सेवाओं की कार्यक्षमता बनाए रखी, एक नया लॉन्च किया और इसके फायदे बताए।

हमने पिछले साल Yandex.Kew लॉन्च किया था। अब TheQuestion और Znatokov के सक्रिय लेखकों में से 80% से अधिक स्वेच्छा से एक नए घर में चले गए।

दो प्लेटफार्मों को एक में कैसे संयोजित करें और उपयोगकर्ताओं को अपमानित न करें। Yandex.Kew Developers अनुभव