हम Pics.io में कॉन्फ़िगरेशन कैसे प्रबंधित करते हैं

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

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

यह पहले उपयोगकर्ताओं को जाने देने का समय है। यह जल्दी से स्पष्ट हो गया कि वे हमारे विचार चाहते हैं, लेकिन हम जो भी प्रोग्राम करते थे उसका उपयोग नहीं करना चाहते थे। इस स्कोर पर हमें कोई भ्रम नहीं था - आप फ़ोटोशॉप के साथ छह महीने तक गड़बड़ नहीं कर सकते। कुछ समय के लिए, हमने Pics.io में नई सुविधाएँ जोड़ने का प्रयास किया। उपयोगकर्ता आए, पंजीकृत हुए, लेकिन केवल यह देखने के लिए लौट आए कि हम कैसे कर रहे हैं। यह स्पष्ट हो गया कि शुरुआती दत्तक ग्रहणकर्ताओं को एक ऐसे उत्पाद की आवश्यकता थी जिसका वे उपयोग कर सकें।

हमने एक अलग सेवा बनाने की कोशिश करने का फैसला किया, जिसका इस्तेमाल रिलीज के बाद सही तरीके से किया जा सके और जो फायदेमंद होगा। इसलिए live.pics.io था, जो ऑनलाइन तस्वीरों की ध्वनि चर्चा के लिए एक सेवा थी। हमने पहले ही यहां हेबर पर तकनीकी विवरण के बारे में एक लेख लिखा था। अपेक्षाकृत नई वेबआरटीसी प्रौद्योगिकी के साथ बड़ी संख्या में समस्याओं के बावजूद, हमें और हमारे उपयोगकर्ताओं को प्रयोग पसंद आया।

फिर हमने सोचा कि हम Pics.io को तीन सरल भागों में विभाजित कर सकते हैं और उन पर अलग से काम कर सकते हैं:

• छवि संपादन के लिए edit.pics.io
• Raw.pics.io रॉ प्रारूपों को परिवर्तित करने के लिए
• चर्चा और सहयोग के लिए Live.pics.io

फिर, इन सेवाओं को एक साथ DAM (डिजिटल एसेट्स मैनेजमेंट) टूल्स का उपयोग करके और उपयोगकर्ता खातों को जोड़ते हुए, हमें एक "बड़ा" मिला (जैसा कि हम इसे आपस में कहते हैं) Pics.io. जो बदले में, हमें अपने लक्ष्य को प्राप्त करने की अनुमति देगा - एक ब्राउज़र में फ़ोटो प्रसंस्करण के लिए एक सार्वभौमिक पैकेज बनने के लिए। कुल में, हमें चार स्वतंत्र उत्पाद प्राप्त हुए, जिनमें से प्रत्येक को उपयोगकर्ताओं के एक निश्चित खंड के कार्यों को करने के लिए डिज़ाइन किया गया है।

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

समानांतर में सोलह विभिन्न उत्पादों को चलाना स्पष्ट रूप से सात की टीम के लिए एक असंभव कार्य है। लेकिन क्या होगा अगर ये अलग-अलग उत्पाद नहीं हैं, लेकिन बस घटकों के एक सेट की तैनाती विन्यास है? अहा! यहाँ यह विन्यास प्रबंधन की सारी शक्ति है!

तो हमारे पास क्या है:

• सात की टीम
• सोलह उत्पाद
• सभी अवसरों के लिए देशी और खुले स्रोत कोड का एक गुच्छा (लॉग आउटपुट से कच्चे प्रारूपों के समानांतर प्रसंस्करण तक)

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


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

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

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

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

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

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

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

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

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