մեր մասին
1C-ում մենք մշակում ենք ոչ միայն հարթակ մասին и , այլ նաև Java հավելվածներ, մասնավորապես՝ զարգացման նոր միջավայր հիմնված Eclipse-ի և մեսենջեր սերվերի վրա, որը խորապես ինտեգրված է հարթակին. .
Մուտք
Մենք ամենից հաճախ օգտագործում ենք maven-ը որպես Java հավելվածների կառուցման համակարգ, և այս կարճ հոդվածում մենք կցանկանայինք խոսել այն խնդիրներից մեկի մասին, որը մենք ստիպված էինք հանդիպել զարգացման կազմակերպման գործընթացում, և այն մոտեցման մասին, որը թույլ տվեց մեզ հաղթահարել դա: խնդիր.
Նախադրյալները և աշխատանքի ընթացքը
Մեր maven նախագծերի զարգացման առանձնահատկությունների պատճառով մենք օգտագործում ենք բավականին շատ մոդուլներ, կախվածություններ և մանկական նախագծեր: Պոմ ֆայլերի թիվը մեկ ծառում կարող է լինել տասնյակ կամ նույնիսկ հարյուրավոր:
Կարծես թե մեծ բան չէ, մի անգամ ստեղծեցին ու մոռացան։ Եթե Ձեզ անհրաժեշտ է միանգամից ինչ-որ բան փոխել կամ ավելացնել բոլոր ֆայլերում, խմբագրիչներում և IDE-ներում կան շատ հարմար գործիքներ: Ո՞րն է pom.xml-ի ամենատարածված կանոնավոր փոփոխությունը: Մենք հավատում ենք, որ փոփոխությունները նախագծի տարբերակներում և կախվածություններում: Միգուցե ինչ-որ մեկը ցանկանա վիճել սրա հետ, բայց մեզ մոտ հենց այսպիսի իրավիճակ է։ Պատճառը կայանում է նրանում, որ միջուկի հետ միասին մենք միաժամանակ զարգացնում ենք մեր սեփական գրադարաններից շատերը, և կառուցման և թեստավորման արդյունքների մշտական վերարտադրելիության համար snapshot-ների օգտագործումը մեզ հարմար մոտեցում չի թվում: Այդ իսկ պատճառով, անհրաժեշտ է ավելացնել տարբերակի համարը նախագծերում յուրաքանչյուր կառուցման հետ:
Բացի այդ, ժամանակ առ ժամանակ մշակողը պետք է կառուցի գրադարանի իր մասնաճյուղը և ստուգի դրա ֆունկցիոնալությունը բոլոր կախվածություններից, ինչի համար նա պետք է ձեռքով փոխի դրանց բոլորի տարբերակը:
Նախնական լուծում
Նման հաճախակի և բազմակի տարբերակի փոփոխություններով ես ուզում եմ պարզեցնել և ավտոմատացնել գործընթացը CI-ի ներսում: Այստեղ է, որ օգնության է հասնում հարմար, հայտնի պլագինը: versions-maven-plugin - միացրեք այն և գործարկեք այն
mvn -N տարբերակներ:set -DnewVersion=2.0.1
և Maven-ը կանի ամեն ինչ այնպես, ինչպես պետք է. այն կանցնի հիերարխիայի միջով վերևից ներքև՝ փոխարինելով բոլոր տարբերակները՝ գեղեցկություն: Այժմ մնում է միայն բարձրացնել ձգման հարցումը, գործընկերները կվերանայեն փոփոխությունները, և դուք կարող եք արագ միանալ բեռնախցիկին: Արագ? Անկախ նրանից, թե ինչպես է դա: Մի երկու հարյուր pom.xml վերանայման համար, և սա չի հաշվում ծածկագիրը: Բացի այդ, ոչ ոք ապահովագրված չէ միաձուլման կոնֆլիկտներից այդքան մեծ թվով փոխված ֆայլերի հետ: Այստեղ պետք է նշել, որ CI գործընթացում տարբերակի փոփոխություններն ինքնաբերաբար տեղի են ունենում ֆունկցիոնալության փոփոխության հետ մեկտեղ, և ոչ թե առանձին-առանձին:
Նոր առանձնահատկություններ
Մի որոշ ժամանակ հանգստացանք ու, հրաժարական տալով, այդպես ապրեցինք մինչև տղերքը Սկսած 3.5.0-բետա-1 տարբերակից, Maven-ը չէր ներառում այսպես կոչված «տեղապահների» աջակցությունը: Այս փոխարինողների էությունն այն է pom.xml Ծրագրի տարբերակի հատուկ նշման փոխարեն օգտագործվում են փոփոխականներ ${revision}, ${sha1} и ${changelist}. Այս հատկությունների արժեքներն իրենք են սահմանվում կամ տարրումհատկությունները>, կամ դրանք կարող են սահմանվել համակարգի հատկության միջոցով
mvn -Drevision=2.0.0 մաքուր փաթեթ
Համակարգի գույքի արժեքները գերակայում են դրանում սահմանված արժեքներիցհատկությունները>.
Ծնողը
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-ծնող
Առաջին CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-ՊԱՏԿԵՐ
Հետնորդ
4.0.0
org.apache.maven.ci
ci-ծնող
${revision}${sha1}${changelist}
org.apache.maven.ci
ք-երեխա
...
Եթե ցանկանում եք կառուցել 2.0.0-SNAPSHOT տարբերակը, ապա պարզապես օգտագործեք
mvn -Drevision=2.0.0 մաքուր փաթեթ
Եթե ցանկանում եք թողարկել, ապա պարզապես վերակայեք SNAPSHOT-ը
mvn -Dchangelist= մաքուր փաթեթ
* Վերը նշված օրինակները վերցված են Maven Apache Project կայքում
դաժան իրականություն
Ամեն ինչ լավ է և առողջ, ժամանակն է բավարարվածության զգացում զգալու, բայց ոչ: Ստացվում է, որ այս մեթոդը չի աշխատի տեղադրման և տեղակայման համար, քանի որ այն չի փոխարինվի պահեստում հրապարակված արտեֆակտների նկարագրություններում: ${revision} դրա իմաստով, և մեյվենն այլևս չի հասկանա, թե ինչի մասին է խոսքը:
org.apache
apache
${revision}
Լույս թունելի վերջում
Պետք է խնդրի լուծում փնտրել։ Կարող էր փրկել իրավիճակը . Այս փլագինը լուծում է պոմի բոլոր փոփոխականները, բայց միևնույն ժամանակ կտրում է բազմաթիվ այլ տեղեկություններ, որոնք անհրաժեշտ են միայն հավաքման ժամանակ և անհրաժեշտ չեն հրապարակված արտեֆակտները այլ նախագծեր ներմուծելիս: Փլագինը նաև «ուղղում է» ծնող-երեխա բոլոր կախվածությունները, և արդյունքում դուք ստանում եք հարթ պոմ, որը ներառում է ձեզ անհրաժեշտ ամեն ինչ: Անհարմարությունն այն էր, որ այն կտրում է չափազանց շատ «ավելորդ», ինչը մեզ բոլորովին չէր սազում։ Այս փլագինի մշակման մասին տեղեկատվությունը ուսումնասիրելուց հետո պարզվեց, որ մենք միակը չենք տիեզերքում, և դեռ 2018 թվականի օգոստոսին Github-ում ստեղծվել է ձգման հարցում՝ plugin-ի պահոցում՝ ցանկությամբ դա հնարավոր դարձնել։ ինքնուրույն որոշել, թե ինչպես «փչացնել» pom.xml: Մշակողները լսեցին տառապողների ձայները, և արդեն դեկտեմբերին, 1.1.0 նոր տարբերակի թողարկմամբ, flatten-maven-plugin-ում հայտնվեց նոր ռեժիմ՝ solveCiFriendliesOnly, որն ավելի հարմար էր, քան երբևէ. pom.xml ինչպես կա, բացառությամբ տարրի և թույլ է տալիս ${revision}, ${sha1} и ${changelist}.
Ծրագրին պլագին ավելացնելը
org.codehaus.mojo
flatten-maven-plugin
1.1.0
ճիշտ
լուծելCiFriendliesOnly
հարթեցնել
գործընթաց-ռեսուրսներ
հարթեցնել
հարթեցնել.մաքուր
մաքուր
մաքուր
Կատարված!
Երջանիկ ավարտ
Այսուհետ ամբողջ նախագծի տարբերակը փոխելու և դրա մասին բոլոր կախվածություններին տեղեկացնելու համար մենք պարզապես պետք է խմբագրենք տարրըվերանայում> միայն արմատի մեջ pom.xml. Այս նույն փոփոխությամբ ոչ թե հարյուր կամ երկու ֆայլ է գալիս վերանայման, այլ մեկը։ Դե, կարիք չկա օգտագործելու versions-maven-plugin.
Source: www.habr.com