👨🏽‍💼 🕺 👨🏾‍🏭 हमने कैसे निर्माण किया 👨🏽‍⚕️ 🏾 😾

परिचय

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

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

यह लेख मावेन का उपयोग करके विधानसभाओं को लागू करने के अनुभव का वर्णन करता है, इसलिए बुनियादी मावेन ज्ञान की आवश्यकता होती है। विषय के अधिक विस्तृत विकास के लिए, http://www.apache-maven.ru साइट का अध्ययन करने के लिए पर्याप्त होगा - आपको मूल स्रोत http://maven.apache.org का उल्लेख करना चाहिए।

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

चींटी क्यों नहीं?

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

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

पर्यावरण

सबसे पहले, यह हमारी परियोजनाओं की संरचना और विकास के दृष्टिकोण के बारे में बात करने लायक है। यह बहुत महत्वपूर्ण है, इस तथ्य के कारण कि यह परियोजना कई वर्षों से विकसित हो रही है और इसमें एक संरचना है जो मावेन-वेबैप-कलाकृतियों के अनुरूप नहीं है

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

परियोजना में अक्सर एक अलग मॉड्यूल होता है, जो जावा कक्षाओं में विशिष्ट संसाधनों और तर्क को होस्ट करता है। कभी-कभी, ऐसा कोई मॉड्यूल नहीं होता है। परियोजना की अंतिम असेंबली में एकल वेब अनुप्रयोग के रूप में मॉड्यूल का एक सेट होता है।

मॉड्यूल द्वारा आवश्यक पुस्तकालयों को सीधे भंडार में लिबास फ़ोल्डर में संग्रहीत किया जाता है, वेब संसाधनों के लिए अपना स्वयं का sx-war फ़ोल्डर है। साथ ही मानक src और परीक्षण फ़ोल्डर्स।

स्वाभाविक रूप से, लगभग सभी मॉड्यूल कोर पर निर्भर करते हैं, और एक दूसरे से, आवश्यकतानुसार।

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

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

ईसा पूर्व

हमारे पास ऐसा एक वाक्यांश है। इसका मतलब है कि "यह" कंपनी में हमारे काम की शुरुआत से पहले भी एक लंबे समय से पहले था। मैं आपको बताऊंगा कि मेरे सामने असेंबली सेटअप कैसे चला गया। मुझे भी पहली बार सेट अप करने में बहुत समय बिताना पड़ा।

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

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

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

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

पहला प्रयास

हमारे पास विधानसभा के लिए विशेष लोग जिम्मेदार नहीं थे, न ही मावेन का कोई अच्छा ज्ञान था। इसलिए, परियोजनाओं पर मावेन को लागू करने का पहला प्रयास विफल रहा।

मूल pom.xml को एक अलग रिपॉजिटरी फ़ोल्डर में रखा गया है। उसके बाद, एक अलग प्रोजेक्ट फ़ोल्डर में, svn-externals कॉन्फ़िगर किए गए थे और प्रोजेक्ट के लिए आवश्यक सभी मॉड्यूल शामिल थे, साथ ही एक अलग फ़ोल्डर में पैरेंट pom.xml:

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

Http://search.maven.org पर सभी आवश्यक पुस्तकालयों की खोज नहीं की गई थी, क्योंकि उनमें से बहुत सारे हैं और वे सभी रिपॉजिटरी में अवैयक्तिक हैं (संस्करणों के बिना पुस्तकालयों को लिबर फ़ोल्डर में संग्रहीत किया जाता है। उदाहरण के लिए ax.jar, jdsds.jar, velocity.jar)। उन्होंने बस यही किया: सभी पुस्तकालयों को स्क्रिप्ट का उपयोग करके नेक्सस में लोड किया गया। GroupId और ArtifactId को मास्क sx का उपयोग करके सेट किया गया था। <लाइब्रेरी का नाम> (sx.axis)।

यहाँ एक विशिष्ट pom.xml मॉड्यूल कैसा दिखता है:

बेस pom.xml

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <!--   --> <parent> <groupId>sx.config</groupId> <artifactId>project-settings</artifactId> <version>2.0.1</version> <relativePath>project-settings/pom.xml</relativePath> </parent> <!--  --> <groupId>sx.builds</groupId> <artifactId>wfBuilder</artifactId> <version>2.0.1</version> <packaging>pom</packaging> <!--   --> <pluginRepositories> <pluginRepository> <id>sx-repository</id> <url>http://v5-neptun/nexus/content/repositories/sx-repository</url> </pluginRepository> </pluginRepositories> <!--   --> <repositories> <repository> <id>sx-repository</id> <url>http://v5-neptun/nexus/content/repositories/sx-repository</url> </repository> </repositories> <!--URL SVN--> <scm> <connection>scm:svn:svn://svn-server/buildsMaven/trunk/workflowBuild</connection> </scm> <!----> <modules> <module>core</module> <module>workflow</module> </modules> </project>

यह देखा जा सकता है कि प्रत्येक परियोजना के लिए इसमें मॉड्यूल की सूची को बदलना आवश्यक है।

असेंबली के दौरान, प्रत्येक मॉड्यूल को एक अलग युद्ध में इकट्ठा किया गया था, और फिर मावेन-ओवरले का उपयोग करके एक आम तैनात में पैक किया गया था।

असफलता का कारण

Svn-externals का उपयोग करके मावेन दृष्टिकोण के लाभों को पूरी तरह से पार कर गया। यह गुण मैन्युअल रूप से svn फ़ोल्डर के गुणों को संपादित किए बिना सभी मॉड्यूल के कोड को स्पष्ट रूप से ठीक करने की अनुमति नहीं देता है। यह 10-15 मॉड्यूल की उपस्थिति और एक निश्चित संस्करण के लिए पैच की रिहाई के साथ लगभग असंभव हो जाता है। और मैं वास्तव में मावेन रिलीज प्लगइन का उपयोग करना चाहता था।

आकर्षण आते हैं

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

विपक्ष

सभी मॉड्यूल की पूर्ण विधानसभा एक लंबी प्रक्रिया है;
आप कोड संस्करण को ठीक से लॉक नहीं कर सकते हैं;
सभी पुस्तकालयों को सार्वजनिक भंडार से नहीं लिया जाता है, एक नया जोड़ना एक अलग प्रक्रिया है;
जार-नर्क संभव है जब कोई व्यक्ति सार्वजनिक भंडार से पुस्तकालय का उपयोग करने का निर्णय लेता है और यह पहले से ही कॉर्पोरेट एक (दोनों संस्करण, या यहां तक कि तीन, तैनाती में मिल जाएगा!)। ऐसा इसलिए होता है क्योंकि GroupId: ArtifactId: संस्करण परिवर्तन;
कोड एक एसवीएन फ़ोल्डर में संग्रहीत किया गया लगता है, और यह पूरी तरह से अलग एक (svn-externals के साथ) की जांच करना आवश्यक है। पारदर्शी नहीं - सौंदर्यशास्त्र के लिए;

दूसरा प्रयास

कई पुनरावृत्तियों में विकसित विधानसभाओं को लागू करने का दूसरा प्रयास।

Iteration 1

सबसे पहले, व्यक्तिगत मॉड्यूल और संपूर्ण उत्पाद दोनों के कोड (संस्करण को जारी करने) को ठीक करने के लिए एक तंत्र प्राप्त करना आवश्यक था। ऐसा करने के लिए, हमें svn-externals के उपयोग से छुटकारा मिला। प्रत्येक मॉड्यूल स्वायत्त निकला और अलग से इकट्ठा किया गया। सभी निर्भरताएं जो मॉड्यूल अंतिम विधानसभा में मिली हैं।

मूल pom.xml को भी कार्यों के अनुसार संशोधित किया गया है। सभी मॉड्यूल इसे आधार के रूप में उपयोग करते हैं:

नया आधार pom.xml

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <!--  --> <groupId>sx.config</groupId> <artifactId>main-settings</artifactId> <version>1.1-SNAPSHOT</version> <packaging>pom</packaging> <!--URL SVN--> <scm> <connection>scm:svn:svn://svn-server/maven/main-settings/trunk</connection> </scm> <!--   --> <pluginRepositories> <pluginRepository> <id>sx-repository</id> <url>http://v5-neptun/nexus/content/repositories/sx-repository</url> </pluginRepository> </pluginRepositories> <!--   --> <repositories> <repository> <id>sx-repository</id> <url>http://v5-neptun/nexus/content/repositories/sx-repository</url> </repository> <repository> <id>releases-repository</id> <url>http://v5-neptun/nexus/content/repositories/releases</url> </repository> <repository> <id>snapshots-repository</id> <url>http://v5-neptun/nexus/content/repositories/snapshots</url> </repository> <repository> <id>central-repository</id> <url>http://v5-neptun/nexus/content/repositories/central</url> </repository> </repositories> <profiles> <profile> <id>production</id> <!--       .     --> <distributionManagement> <repository> <id>ftp-repository</id> <url>ftp://ftp.sample.com/builds</url> </repository> </distributionManagement> </profile> <profile> <id>development</id> <activation> <activeByDefault>true</activeByDefault> </activation> <!--        --> <distributionManagement> <snapshotRepository> <id>snapshots-repository</id> <url>http://v5-neptun/nexus/content/repositories/snapshots</url> </snapshotRepository> <repository> <id>releases-repository</id> <url>http://v5-neptun/nexus/content/repositories/releases</url> </repository> </distributionManagement> </profile> </profiles> <!--   --> <build> <defaultGoal>package</defaultGoal> <!--  --> <sourceDirectory>src</sourceDirectory> <testSourceDirectory>test</testSourceDirectory> <!-- --> <resources> <resource> <directory>src</directory> <includes> <include>**/*.properties</include> <include>**/*.sql</include> <include>**/*.xml</include> </includes> </resource> </resources> <extensions> <!-- Enabling the use of FTP --> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ftp</artifactId> <version>1.0-beta-6</version> </extension> </extensions> <plugins> <!-- --> <!--    --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.2</version> <configuration> <!--      --> <warSourceDirectory>sx-war</warSourceDirectory> <attachClasses>true</attachClasses> </configuration> </plugin> <!--   ,      out of memory--> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <configuration> <minmemory>256m</minmemory> <maxmemory>512m</maxmemory> </configuration> </plugin> <!--   --> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>2.4.3</version> <configuration> <encoding>cp1251</encoding> </configuration> </plugin> <!--     --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-scm-plugin</artifactId> <version>1.4</version> <configuration> <username>${SvnUsername}</username> <password>${SvnPassword}</password> </configuration> </plugin> <!--     --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <configuration> <tagBase>svn://gelios/cms/maven/main-settings/tags</tagBase> <branchBase>svn://gelios/cms/maven/main-settings/branches</branchBase> <preparationGoals>clean install</preparationGoals> <goals>deploy</goals> <autoVersionSubmodules>true</autoVersionSubmodules> </configuration> </plugin> </plugins> </build> </project>

Iteration 2

सभी प्रोजेक्ट मॉड्यूल में एक संस्करण रिलीज़ प्लगइन लागू किया गया है । ऐसा करने के लिए, प्रत्येक मॉड्यूल में ब्लॉक जोड़े गए थे:

रिलीज रिलीज प्लगइन कनेक्शन

  <!--     SVN.      --> <scm> <connection>scm:svn:svn://svnserver/module/trunk</connection> </scm> <build> <plugins> <!--     --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <configuration> <!--   SVN     --> <tagBase>svn://svnserver/module/tags</tagBase> <branchBase>svn://svnserver/module/branches</branchBase> <preparationGoals>clean install</preparationGoals> <goals>deploy</goals> <autoVersionSubmodules>true</autoVersionSubmodules> </configuration> </plugin> ... </plugins>

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

आधार pom.xml में एक नया प्रोफ़ाइल जोड़ा गया है: उत्पादन। यह असेंबली को FTP में अपलोड करता है और बाद में इसे परियोजनाओं तक बढ़ाया जा सकता है।

Iteration 3

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

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

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

गर्भाधान ४

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

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

आकर्षण आते हैं

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

विपक्ष

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

हम एक समाधान विकसित करते हैं

इस प्रक्रिया में, विधानसभा में संपादन किए जाते हैं। उन लोगों के लिए जो अभी भी "पुराने जमाने के तरीके" को इकट्ठा कर रहे हैं, ज्ञान आधार में एक पृष्ठ खोला गया है, जिसमें मॉड्यूल निर्भरताएं हैं। यह जानकारी हर रात हडसन में एक अलग कार्य के रूप में pom.xml मॉड्यूल के आधार पर अद्यतन की जाती है ( DRY के बारे में मत भूलना)।

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

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

संस्करणों का संग्रह करने के लिए गुणों का उपयोग करना

 <!--     .   ,    --> <properties> <sx.core>4.5-SNAPSHOT</sx.core> </properties> ... <profiles> <profile> <!--  --> <id>context</id> <dependencies> <dependency> <groupId>sx.core</groupId> <artifactId>core</artifactId> <version>${sx.core}</version> <type>war</type> <!--      maven-overlay --> <scope>runtime</scope> </dependency> </dependencies> </profile> </profiles> <!--   --> <dependencies> <dependency> <groupId>sx.core</groupId> <artifactId>core</artifactId> <version>${sx.core.core}</version> <classifier>classes</classifier> <!--     \ --> <scope>provided</scope> </dependency> ... </dependencies>

मावन कलाकृतियों के साथ काम करने के लिए चींटी स्क्रिप्ट

निष्कर्ष

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

नए डेवलपर्स असेंबली स्थापित करने में ज्यादा समय नहीं बिताते हैं। और यह केवल मनभावन है।

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

नए विकास दिन के दौरान विकास के संदर्भों में आते हैं, जिसका अर्थ है कि वे तेजी से ग्राहक तक पहुंचते हैं। कठिन एकीकरण त्रुटियां भी दिखाई देने लगीं, जिसका अर्थ है कि वे तेजी से तय की जा सकती हैं।

अद्यतन: टीकाकारों से कार्यान्वयन के अनुभव पर एक उपयोगी लेख: http://bazhenov.me/blog/2011/04/09/build.html

हमने कैसे निर्माण किया

परिचय

चींटी क्यों नहीं?

पर्यावरण

ईसा पूर्व

पहला प्रयास

असफलता का कारण

आकर्षण आते हैं

विपक्ष

दूसरा प्रयास

Iteration 1

Iteration 2

Iteration 3

गर्भाधान ४

आकर्षण आते हैं

विपक्ष

हम एक समाधान विकसित करते हैं

निष्कर्ष

More articles: