"कोड के रूप में डेटाबेस" अनुभव

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

और चलिए यहीं से शुरू करते हैं साँप. "एसक्यूएल बनाम ओआरएम" प्रकार की पहली लड़ाइयाँ वापस देखी गईं प्री-पेट्रिन रस'.

ऑब्जेक्ट-रिलेशनल मैपिंग

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

यह आमतौर पर कुछ इस तरह दिखता है...

@Entity
@Table(name = "stock", catalog = "maindb", uniqueConstraints = {
        @UniqueConstraint(columnNames = "STOCK_NAME"),
        @UniqueConstraint(columnNames = "STOCK_CODE") })
public class Stock implements java.io.Serializable {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    @Column(name = "STOCK_ID", unique = true, nullable = false)
    public Integer getStockId() {
        return this.stockId;
    }
  ...

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

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

क्या होगा यदि हमारे पास दोनों दुनियाओं का सर्वश्रेष्ठ हो? जीवन-पुष्टि नाम वाले एक अद्भुत उपकरण में यह कैसे किया जाता है हाँएसक्यूएल. मैं अपने मुफ़्त अनुवाद में सामान्य अवधारणा से कुछ पंक्तियाँ दूंगा, और आप इससे अधिक विस्तार से परिचित हो सकते हैं यहां.

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

तो मुझे क्या करना चाहिए? आइए SQL को नियमित SQL के रूप में छोड़ दें - प्रति अनुरोध एक फ़ाइल:

-- name: users-by-country
select *
  from users
 where country_code = :country_code

... और फिर इस फ़ाइल को नियमित क्लोजर फ़ंक्शन में बदलकर पढ़ें:

(defqueries "some/where/users_by_country.sql"
   {:connection db-spec})

;;; A function with the name `users-by-country` has been created.
;;; Let's use it:
(users-by-country {:country_code "GB"})
;=> ({:name "Kris" :country_code "GB" ...} ...)

"SQL अपने आप से, क्लोजर अपने आप से" सिद्धांत का पालन करके, आपको मिलता है:

• कोई वाक्यात्मक आश्चर्य नहीं. आपका डेटाबेस (किसी भी अन्य की तरह) SQL मानक के साथ 100% अनुरूप नहीं है - लेकिन यह Yesql के लिए कोई मायने नहीं रखता। आप SQL समतुल्य सिंटैक्स वाले फ़ंक्शंस की खोज में कभी भी समय बर्बाद नहीं करेंगे। आपको कभी भी किसी समारोह में वापस नहीं लौटना पड़ेगा (कच्चा-एसक्यूएल "कुछ('फंकी'::सिंटैक्स)")).
• सर्वश्रेष्ठ संपादक समर्थन. आपके संपादक के पास पहले से ही उत्कृष्ट SQL समर्थन है। SQL को SQL के रूप में सहेजकर आप आसानी से इसका उपयोग कर सकते हैं।
• टीम अनुकूलता. आपके डीबीए आपके क्लोजर प्रोजेक्ट में आपके द्वारा उपयोग किए जाने वाले एसक्यूएल को पढ़ और लिख सकते हैं।
• आसान प्रदर्शन ट्यूनिंग. किसी समस्याग्रस्त प्रश्न के लिए एक योजना बनाने की आवश्यकता है? जब आपकी क्वेरी नियमित SQL हो तो यह कोई समस्या नहीं है।
• क्वेरीज़ का पुन: उपयोग करना. उन्हीं SQL फ़ाइलों को अन्य प्रोजेक्ट्स में खींचें और छोड़ें क्योंकि यह बिल्कुल सादा पुराना SQL है - बस इसे साझा करें।

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

आईडीई और डीबी प्रबंधक

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

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

select table_name
     , ...
  from information_schema.tables
 where schema = 'HR'

डेटाबेस से डेटाबेस तक, ऐसी संदर्भ तालिकाओं की सामग्री प्रत्येक DBMS की क्षमताओं के आधार पर भिन्न होती है। और, उदाहरण के लिए, MySQL के लिए, उसी संदर्भ पुस्तक से आप इस DBMS के लिए विशिष्ट तालिका पैरामीटर प्राप्त कर सकते हैं:

select table_name
     , storage_engine -- Используемый "движок" ("MyISAM", "InnoDB" etc)
     , row_format     -- Формат строки ("Fixed", "Dynamic" etc)
     , ...
  from information_schema.tables
 where schema = 'HR'

Oracle को information_schema की जानकारी नहीं है, लेकिन पता है ओरेकल मेटाडेटा, और कोई बड़ी समस्या उत्पन्न नहीं होती:

select table_name
     , pct_free       -- Минимум свободного места в блоке данных (%)
     , pct_used       -- Минимум используемого места в блоке данных (%)
     , last_analyzed  -- Дата последнего сбора статистики
     , ...
  from all_tables
 where owner = 'HR'

क्लिकहाउस कोई अपवाद नहीं है:

select name
     , engine -- Используемый "движок" ("MergeTree", "Dictionary" etc)
     , ...
  from system.tables
 where database = 'HR'

कैसंड्रा में भी कुछ ऐसा ही किया जा सकता है (जिसमें टेबल के बजाय कॉलमफैमिली और स्कीमा के बजाय कीस्पेस हैं):

select columnfamily_name
     , compaction_strategy_class  -- Стратегия сборки мусора
     , gc_grace_seconds           -- Время жизни мусора
     , ...
  from system.schema_columnfamilies
 where keyspace_name = 'HR'

अधिकांश अन्य डेटाबेस के लिए, आप भी इसी तरह के प्रश्न पूछ सकते हैं (यहां तक ​​कि मोंगो के पास भी है)। विशेष प्रणाली संग्रह, जिसमें सिस्टम के सभी संग्रहों के बारे में जानकारी शामिल है)।

बेशक, इस तरह से आप न केवल तालिकाओं के बारे में, बल्कि सामान्य तौर पर किसी भी वस्तु के बारे में जानकारी प्राप्त कर सकते हैं। समय-समय पर, दयालु लोग विभिन्न डेटाबेस के लिए ऐसे कोड साझा करते हैं, उदाहरण के लिए, हाबरा लेखों की श्रृंखला में "पोस्टग्रेएसक्यूएल डेटाबेस के दस्तावेजीकरण के लिए कार्य" (अयब, बेन, जिम). बेशक, प्रश्नों के इस पूरे पहाड़ को अपने दिमाग में रखना और उन्हें लगातार टाइप करना बहुत आनंददायक है, इसलिए मेरे पसंदीदा आईडीई/संपादक में मेरे पास अक्सर उपयोग किए जाने वाले प्रश्नों के लिए स्निपेट्स का एक पूर्व-तैयार सेट है, और जो कुछ बचा है वह टाइप करना है टेम्पलेट में ऑब्जेक्ट नाम.

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

वस्तुओं के साथ संचालन

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

यह कोई रहस्य नहीं है कि किसी तालिका को हटाने से लगभग सभी डेटाबेस में एक जैसा दिखेगा:

drop table hr.persons

लेकिन तालिका के निर्माण के साथ यह और अधिक दिलचस्प हो जाता है। लगभग कोई भी DBMS (कई NoSQL सहित) एक या दूसरे रूप में "तालिका बना सकता है", और इसका मुख्य भाग थोड़ा अलग भी होगा (नाम, कॉलम की सूची, डेटा प्रकार), लेकिन अन्य विवरण नाटकीय रूप से भिन्न हो सकते हैं और इस पर निर्भर करते हैं एक विशिष्ट DBMS की आंतरिक डिवाइस और क्षमताएं। मेरा पसंदीदा उदाहरण यह है कि Oracle दस्तावेज़ में "तालिका बनाएं" सिंटैक्स के लिए केवल "नग्न" BNF हैं 31 पृष्ठों पर कब्जा करें. अन्य DBMS में अधिक सामान्य क्षमताएं हैं, लेकिन उनमें से प्रत्येक में टेबल बनाने के लिए कई दिलचस्प और अनूठी विशेषताएं भी हैं (postgres, MySQL, तिलचट्टा, कैसेंड्रा). यह संभावना नहीं है कि किसी अन्य आईडीई (विशेष रूप से एक सार्वभौमिक) से कोई भी ग्राफिकल "जादूगर" इन सभी क्षमताओं को पूरी तरह से कवर करने में सक्षम होगा, और यदि यह कर भी सकता है, तो यह कमजोर दिल के लिए एक तमाशा नहीं होगा। साथ ही, एक सही और समय पर लिखित बयान तालिका बनाएं आपको उन सभी का आसानी से उपयोग करने, भंडारण और आपके डेटा तक पहुंच को विश्वसनीय, इष्टतम और यथासंभव आरामदायक बनाने की अनुमति देगा।

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

अब आइए थोड़ा चित्र बनाएं

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

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

प्लांटयूएमएल और का उपयोग करके यह कैसा दिख सकता है इसका एक छोटा सा उदाहरण यहां दिया गया है PostgreSQL के लिए डेमो डेटाबेस (बाईं ओर एक SQL क्वेरी है जो प्लांटयूएमएल के लिए आवश्यक निर्देश उत्पन्न करेगी, और दाईं ओर परिणाम है):

select '@startuml'||chr(10)||'hide methods'||chr(10)||'hide stereotypes' union all
select distinct ccu.table_name || ' --|> ' ||
       tc.table_name as val
  from table_constraints as tc
  join key_column_usage as kcu
    on tc.constraint_name = kcu.constraint_name
  join constraint_column_usage as ccu
    on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and tc.table_name ~ '.*' union all
select '@enduml'

और अगर आप थोड़ा प्रयास करें तो उसके आधार पर प्लांटयूएमएल के लिए ईआर टेम्पलेट आप वास्तविक ईआर आरेख के समान कुछ प्राप्त कर सकते हैं:

SQL क्वेरी थोड़ी अधिक जटिल है

-- Шапка
select '@startuml
        !define Table(name,desc) class name as "desc" << (T,#FFAAAA) >>
        !define primary_key(x) <b>x</b>
        !define unique(x) <color:green>x</color>
        !define not_null(x) <u>x</u>
        hide methods
        hide stereotypes'
 union all
-- Таблицы
select format('Table(%s, "%s n information about %s") {'||chr(10), table_name, table_name, table_name) ||
       (select string_agg(column_name || ' ' || upper(udt_name), chr(10))
          from information_schema.columns
         where table_schema = 'public'
           and table_name = t.table_name) || chr(10) || '}'
  from information_schema.tables t
 where table_schema = 'public'
 union all
-- Связи между таблицами
select distinct ccu.table_name || ' "1" --> "0..N" ' || tc.table_name || format(' : "A %s may haven many %s"', ccu.table_name, tc.table_name)
  from information_schema.table_constraints as tc
  join information_schema.key_column_usage as kcu on tc.constraint_name = kcu.constraint_name
  join information_schema.constraint_column_usage as ccu on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and ccu.constraint_schema = 'public'
   and tc.table_name ~ '.*'
 union all
-- Подвал
select '@enduml'

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

मेट्रिक्स और निगरानी

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

लेकिन निगरानी प्रक्रिया अधिक मज़ेदार और मैत्रीपूर्ण, और सबसे महत्वपूर्ण, सभी के लिए सुलभ और पारदर्शी दिख सकती है। कम से कम इसका मूल भाग, मुख्य निगरानी प्रणालियों के अतिरिक्त (जो निश्चित रूप से उपयोगी हैं और कई मामलों में अपूरणीय हैं)। कोई भी डीबीएमएस अपनी वर्तमान स्थिति और प्रदर्शन के बारे में जानकारी साझा करने के लिए स्वतंत्र और बिल्कुल नि:शुल्क है। उसी "खूनी" ओरेकल डीबी में, प्रदर्शन के बारे में लगभग कोई भी जानकारी सिस्टम दृश्यों से प्राप्त की जा सकती है, प्रक्रियाओं और सत्रों से लेकर बफर कैश की स्थिति तक (उदाहरण के लिए, डीबीए स्क्रिप्ट्स, अनुभाग "निगरानी")। Postgresql के पास सिस्टम दृश्यों का एक पूरा समूह भी है डेटाबेस निगरानी, विशेष रूप से वे जो किसी भी डीबीए के दैनिक जीवन में अपरिहार्य हैं, जैसे pg_stat_activity, pg_stat_डेटाबेस, pg_stat_bgwriter. MySQL के पास इसके लिए एक अलग स्कीमा भी है। Performance_schema. ए इन मोंगो बिल्ट-इन प्रोफाइलर प्रदर्शन डेटा को सिस्टम संग्रह में एकत्रित करता है सिस्टम.प्रोफ़ाइल.

इस प्रकार, कुछ प्रकार के मेट्रिक्स कलेक्टर (टेलीग्राफ, मेट्रिकबीट, कलेक्टेड) ​​से लैस जो कस्टम एसक्यूएल क्वेरी कर सकता है, इन मेट्रिक्स का भंडारण (इन्फ्लक्सडीबी, इलास्टिक्सर्च, टाइमस्केल्डब) और एक विज़ुअलाइज़र (ग्राफाना, किबाना), आप काफी आसान प्राप्त कर सकते हैं और एक लचीली निगरानी प्रणाली जो अन्य सिस्टम-वाइड मेट्रिक्स (उदाहरण के लिए, एप्लिकेशन सर्वर से, ओएस आदि से प्राप्त) के साथ निकटता से एकीकृत होगी। उदाहरण के लिए, यह pgwatch2 में किया जाता है, जो InfluxDB + Grafana संयोजन और सिस्टम दृश्यों के लिए प्रश्नों के एक सेट का उपयोग करता है, जिसे एक्सेस भी किया जा सकता है कस्टम क्वेरीज़ जोड़ें.

कुल मिलाकर

और यह केवल एक अनुमानित सूची है कि नियमित SQL कोड का उपयोग करके हमारे डेटाबेस के साथ क्या किया जा सकता है। मुझे यकीन है कि आपको कई और उपयोग मिल सकते हैं, टिप्पणियों में लिखें। और हम इस बारे में बात करेंगे कि कैसे (और सबसे महत्वपूर्ण क्यों) यह सब स्वचालित करें और अगली बार इसे अपनी सीआई/सीडी पाइपलाइन में शामिल करें।

स्रोत: www.habr.com