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

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

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

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

ORM समर्थक पारंपरिक रूप से विकास की गति और आसानी, 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;
    }
  ...

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

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

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

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

इसलिए क्या करना है? आइए 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 अलग, क्लोजर अलग" सिद्धांत पर टिके रहने से, आपको मिलता है:

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

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

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

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

लेकिन आमतौर पर मैं माउस को फेंक देता हूं और सिर्फ कोड लिखता हूं। मान लीजिए कि आपको यह पता लगाना है कि "एचआर" स्कीमा में कौन सी तालिकाएं (और कौन से गुणधर्मों के साथ) समाहित हैं। अधिकांश DBMS में, वांछित परिणाम information_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'

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

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

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

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

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

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

drop table hr.persons

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

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

अब चलिए थोड़ा सा चित्र बनाते हैं

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

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

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

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'

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

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'

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

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

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

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

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

कुल मिलाकर

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

स्रोत: www.habr.com