نن ورځ، ډیری سافټویر محصولات په ټیمونو کې رامینځته شوي. د بریالي ټیم پرمختګ لپاره شرایط د ساده ډیاګرام په بڼه ښودل کیدی شي.

یوځل چې تاسو خپل کوډ ولیکی، تاسو اړتیا لرئ ډاډ ترلاسه کړئ:

1. .
2. دا هیڅ شی نه ماتوي، پشمول هغه کوډ چې ستاسو همکارانو لیکلي.

که دواړه شرایط پوره شي، نو تاسو د بریالیتوب په لاره کې یاست. د دې لپاره چې دا شرایط په اسانۍ سره وګورو او د ګټورې لارې څخه انحراف ونه کړو، موږ د دوامداره ادغام سره مخ شو.

CI یو کاري فلو دی چیرې چې تاسو خپل کوډ د عمومي محصول کوډ کې د امکان تر حده مدغم کړئ. او تاسو یوازې مدغم نه یاست ، بلکه په دوامداره توګه چیک کړئ چې هرڅه کار کوي. څرنګه چې تاسو اړتیا لرئ ډیری او ډیری وختونه وګورئ، دا د اتوماتیک په اړه فکر کولو ارزښت لري. تاسو کولی شئ هرڅه په لاسي ډول چیک کړئ ، مګر تاسو باید ونه کړئ ، او دلته یې دی.

• ګرانو خلکو. د هر پروګرامر یو ساعت کار د هر سرور د کار یو ساعت څخه ډیر ګران دی.
• خلک تېروتنې کوي. له همدې امله ، شرایط رامینځته کیدی شي کله چې ازموینې په غلط څانګ کې پرمخ وړل شوي یا د ازموینو لپاره غلط تعهد ترتیب شوی و.
• خلک سست دي. وخت په وخت ، کله چې زه یو کار پای ته رسوم ، فکر راپورته کیږي: "د چک کولو لپاره څه شتون لري؟ ما دوه کرښې لیکلي - هرڅه کار کوي! زه فکر کوم چې ستاسو څخه ځینې هم کله ناکله داسې فکرونه لري. مګر تاسو باید تل وګورئ.

څنګه دوامداره ادغام د Avito ګرځنده پرمختیایی ټیم کې پلي شوی او رامینځته شوی ، څنګه دوی هره ورځ له 0 څخه تر 450 جوړونو پورې ځي ، او دا چې د جوړولو ماشینونه په ورځ کې 200 ساعته راټولیږي ، نیکولای نیسټروف وايي)nnesterov) د CI/CD Android اپلیکیشن په ټولو ارتقايي بدلونونو کې برخه اخیستونکی دی.

کیسه د Android کمانډ مثال پراساس ده ، مګر ډیری لارې په iOS کې هم پلي کیږي.

په یو وخت کې، یو کس د Avito Android ټیم کې کار کاوه. د تعریف له مخې، هغه د دوامداره ادغام څخه هیڅ شی ته اړتیا نه درلوده: هیڅ څوک شتون نلري چې ورسره یوځای شي.

مګر غوښتنلیک وده وکړه ، ډیر او ډیر نوي دندې څرګندې شوې ، او ټیم په همدې اساس وده وکړه. په ځینو وختونو کې، دا وخت دی چې په رسمي توګه د کوډ ادغام پروسه رامینځته کړئ. پریکړه وشوه چې د Git جریان وکاروئ.

د Git جریان مفهوم ښه پیژندل شوی: یوه پروژه یوه عامه پراختیا څانګه لري، او د هرې نوې بڼې لپاره، پراختیا کونکي جلا څانګه پرې کوي، ژمنې کوي، فشار راوړي، او کله چې دوی غواړي خپل کوډ د پراختیایي څانګې سره یوځای کړي، یو خلاص کړئ. د ایستلو غوښتنه د پوهې شریکولو او د لارو چارو په اړه بحث کولو لپاره، موږ د کوډ بیاکتنه معرفي کړه، دا دی، همکاران باید د یو بل کوډ وګوري او تایید کړي.

چک کوي

ستاسو د سترګو سره کوډ لیدل ښه دي، مګر کافي ندي. له همدې امله ، اتوماتیک چیکونه معرفي کیږي.

• لومړی، موږ چک کوو د ARK مجلس.
• ډیر د جنیټ ازموینې.
• موږ د کوډ پوښښ په پام کې نیسو، ځکه چې موږ ازموینې پرمخ وړو.

د دې پوهیدو لپاره چې دا چکونه باید څنګه پرمخ وړل شي، راځئ چې په Avito کې د پراختیا بهیر وګورو.

دا په لاندې ډول په سکیمیک ډول ښودل کیدی شي:

• یو پرمخ وړونکی په خپل لپ ټاپ کې کوډ لیکي. تاسو کولی شئ دلته د ادغام چکونه پرمخ وړئ - یا د ژمنې هک سره ، یا په ساده ډول په شالید کې چیکونه پرمخ وړئ.
• وروسته له دې چې پراختیا کونکي کوډ فشار راوړي، هغه د پلولو غوښتنه پرانیزي. د دې لپاره چې د دې کوډ په پراختیایی څانګه کې شامل شي، دا اړینه ده چې د کوډ بیاکتنې ته لاړ شئ او د اړتیا وړ شمیر تاییدونه راټول کړئ. تاسو کولی شئ دلته چیکونه او جوړونه فعال کړئ: تر هغه چې ټول جوړونه بریالي نه وي، د پلولو غوښتنه نشي یوځای کیدی.
• وروسته له دې چې د پلې غوښتنې ضمیمه شي او کوډ په پراختیا کې شامل شي، تاسو کولی شئ یو مناسب وخت وټاکئ: د مثال په توګه، د شپې، کله چې ټول سرورونه وړیا وي، او هرڅومره چکونه چې تاسو یې غواړئ پرمخ وړئ.

هیڅوک په خپل لیپ ټاپ کې سکین چلول خوښ نه کړل. کله چې یو پرمخ وړونکي یو فیچر پای ته ورسوي، هغه غواړي ژر تر ژره دا فشار ورکړي او د پلولو غوښتنه پرانیزي. که پدې وخت کې یو څه اوږد چیکونه پیل شي، دا نه یوازې خورا خوندور دی، بلکې پراختیا هم ورو کوي: پداسې حال کې چې لیپ ټاپ یو څه چک کوي، په عادي توګه کار کول ناممکن دي.

موږ واقعیا د شپې چلول خوښ کړل ، ځکه چې ډیر وخت او سرور شتون لري ، تاسو کولی شئ شاوخوا وګرځئ. مګر، له بده مرغه، کله چې د فیچر کوډ پراختیا ومومي، پراختیاګر د هغه غلطیو د حل کولو لپاره خورا لږ هڅونه لري چې CI موندلي. ما وخت په وخت خپل ځان په دې فکر کې نیولی چې ما د سهار په راپور کې موندلې ټولې غلطۍ لیدلې چې زه به یې یوه ورځ وروسته حل کړم، ځکه چې اوس په جیرا کې یو ښه نوی کار دی چې زه یې یوازې پیل کول غواړم.

که چیرې چکونه د پلولو غوښتنه بنده کړي ، نو کافي هڅونه شتون لري ، ځکه چې تر هغه چې جوړونه شنه نه وي ، کوډ به پراختیا ته ونه رسیږي ، پدې معنی چې دنده به بشپړ نشي.

د پایلې په توګه، موږ لاندې ستراتیژي غوره کړه: موږ د شپې په وخت کې د چکونو ترټولو ممکنه سیټ چلوو، او د دوی خورا مهم او تر ټولو مهم، د پلټ غوښتنې په اړه ترټولو ګړندۍ پیل کوو. مګر موږ هلته نه ودریږو - په موازي ډول، موږ د چکونو سرعت اصلاح کوو ترڅو دوی د شپې حالت څخه د غوښتنې چکونو ایستلو لپاره انتقال کړو.

په هغه وخت کې، زموږ ټول جوړونه په چټکۍ سره بشپړ شوي، نو موږ په ساده ډول د ARK جوړونه، د جونیټ ازموینې او د کوډ پوښښ حسابونه د پلې غوښتنې لپاره د بلاکر په توګه شامل کړل. موږ دا فعال کړ، د هغې په اړه یې فکر وکړ، او د کوډ پوښښ یې پریښود ځکه چې موږ فکر کاوه چې موږ ورته اړتیا نه لرو.

دا موږ دوه ورځې وخت نیولی چې په بشپړ ډول اساسی CI تنظیم کړو (له دې وروسته د وخت اټکل نږدې دی ، د پیمانې لپاره اړین دی).

له هغې وروسته، موږ نور فکر کولو پیل وکړ - ایا موږ حتی په سمه توګه چک کوو؟ ایا موږ په سم ډول د پلولو غوښتنو باندې جوړونه پرمخ وړئ؟

موږ د څانګې په وروستي ژمنې کې جوړونه پیل کړه چې له هغې څخه د پلولو غوښتنه پرانستل شوه. مګر د دې ژمنې ازموینې یوازې کولی شي وښیې چې هغه کوډ چې پراختیا کونکي لیکلي کار کوي. مګر دوی دا نه ثابتوي چې هغه هیڅ شی نه دی مات کړی. په حقیقت کې، تاسو اړتیا لرئ د پراختیا څانګې حالت وګورئ وروسته له دې چې یو خصوصیت په کې ضمیمه شي.

د دې کولو لپاره، موږ یو ساده باش سکریپټ لیکلی premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

دلته د پراختیا څخه ټول وروستي بدلونونه په ساده ډول را ایستل شوي او په اوسني څانګه کې یوځای شوي. موږ د premerge.sh سکریپټ په ټولو جوړښتونو کې د لومړي ګام په توګه اضافه کړ او دقیقا یې چک کول پیل کړل چې موږ یې غواړو، دا دی ادغام.

دا درې ورځې وخت ونیو چې ستونزه ځای پر ځای کړي، د حل لاره ومومي او دا سکریپټ ولیکي.

اپلیکیشن وده وکړه، ډیر او ډیر کارونه ښکاره شول، ټیم وده وکړه، او premerge.sh کله ناکله موږ ته زیان رسوي. پراختیا متضاد بدلونونه درلودل چې جوړښت یې مات کړ.

یو مثال چې دا څنګه پیښیږي:

دوه پراختیا کونکي په ورته وخت کې د A او B ځانګړتیاو باندې کار پیل کوي. answer() او، د یو ښه هلک سکاوټ په څیر، دا لیرې کوي. په ورته وخت کې، د ب خصوصیت پراختیا کونکي په خپله څانګه کې دې فنکشن ته یو نوی کال اضافه کوي.

پراختیا کونکي خپل کار پای ته رسوي او په ورته وخت کې د پلولو غوښتنه خلاصوي. جوړونه پیل شوي، premerge.sh د وروستي پرمختیایي حالت په اړه دواړه پلې غوښتنې چک کوي - ټول چکونه شنه دي. له هغې وروسته، د فیچر A د پلولو غوښتنه یوځای کیږي، د فیچر B پل غوښتنه یوځای کیږي ... بوم! د وقفې پراختیا ځکه چې د پراختیا کوډ غیر موجود فعالیت ته زنګ لري.

کله چې دا پرمختګ نه کوي، دا دی سیمه ایز ناورین. ټول ټیم ​​نشي کولی هیڅ شی راټول کړي او د ازموینې لپاره یې وسپاري.

دا داسې پیښ شوي چې ما ډیری وختونه د زیربناوو په کارونو کې کار کاوه: تحلیلات، شبکه، ډیټابیس. دا ، دا زه وم چې هغه دندې او ټولګي یې لیکلي چې نور پراختیا کونکي یې کاروي. د دې له امله، ما خپل ځان ډیر ځله په ورته حالت کې وموند. ما حتی دا عکس د یو څه وخت لپاره ځړول.

څرنګه چې دا زموږ سره مناسب نه و، موږ د دې مخنیوي څرنګوالي په اړه د اختیارونو په لټه کې شو.

څنګه د پرمختګ مخه ونیسئ

لومړی انتخاب: د پراختیا تازه کولو په وخت کې ټولې پلې غوښتنې بیا رغول. که ، زموږ په مثال کې ، د فیچر A سره د پل غوښتنه لومړی وي چې په پراختیا کې شامله وي ، د ب خصوصیت پل غوښتنه به بیا جوړه شي ، او په وینا یې ، چکونه به د تالیف غلطی له امله ناکام شي.

د پوهیدو لپاره چې دا به څومره وخت ونیسي، د دوه PRs سره یو مثال په پام کې ونیسئ. موږ دوه PRs خلاصوو: دوه جوړونه ، دوه د چیکونو دوه منډې. وروسته له دې چې لومړی PR په پراختیا کې یوځای شي، دویم باید بیا جوړ شي. په مجموع کې، دوه PRs د چیکونو درې منډو ته اړتیا لري: 2 + 1 = 3.

په اصولو کې، دا ښه ده. مګر موږ احصایو ته وکتل ، او زموږ په ټیم کې عادي حالت 10 خلاص PRs و ، او بیا د چکونو شمیر د پرمختګ مجموعه ده: 10 + 9 + ... + 1 = 55. دا د 10 منل دي. PRs، تاسو اړتیا لرئ چې 55 ځلې بیا جوړ کړئ. او دا په یو مناسب حالت کې دی، کله چې ټول چکونه لومړی ځل تیریږي، کله چې هیڅوک د اضافي پلولو غوښتنه نه خلاصوي پداسې حال کې چې دا درجن پروسس کیږي.

خپل ځان د یو پرمختلونکي په توګه تصور کړئ چې د "ضم کولو" تڼۍ باندې کلیک کولو ته اړتیا لري، ځکه چې که یو ګاونډی دا کار وکړي، نو تاسو به انتظار وکړئ تر هغه چې ټول جوړونه بیا پیل شي ... نه، دا به کار ونکړي. ، دا به په جدي توګه پرمختګ ورو کړي.

دوهمه ممکنه لاره: د کوډ بیاکتنې وروسته د پلولو غوښتنې راټول کړئ. دا دی، تاسو د پلولو غوښتنه پرانیزئ، د همکارانو څخه د تصویب اړین شمیر راټول کړئ، هغه څه سم کړئ چې اړتیا ورته وي، او بیا جوړونه پیل کړئ. که دوی بریالي وي، د پلولو غوښتنه په پراختیا کې یوځای کیږي. پدې حالت کې ، هیڅ اضافي بیا پیل شتون نلري ، مګر فیډبیک خورا ورو شوی. د پراختیا کونکي په توګه ، کله چې زه د پل غوښتنه خلاصوم ، زه سمدلاسه غواړم وګورم چې ایا دا کار کوي. د مثال په توګه، که ازموینه ناکامه شي، تاسو اړتیا لرئ چې ژر تر ژره یې حل کړئ. د ځنډیدلو جوړیدو په صورت کې، فیډبیک ورو کیږي، او له همدې امله ټول پرمختګ. دا هم موږ ته مناسب نه و.

د پایلې په توګه، یوازې دریم اختیار پاتې شو - بايسکل. زموږ ټول کوډ، زموږ ټولې سرچینې د Bitbucket سرور په ذخیره کې زیرمه شوي. په دې اساس، موږ باید د Bitbucket لپاره یو پلگ ان جوړ کړو.

دا پلگ ان د پل غوښتنه ادغام میکانیزم له پامه غورځوي. پیل معیاري دی: PR خلاصیږي ، ټولې غونډې پیل شوي ، د کوډ بیاکتنه بشپړه شوې. مګر وروسته له دې چې د کوډ بیاکتنه بشپړه شي او پراختیا کونکي پریکړه کوي چې په "ضم" باندې کلیک وکړئ، پلگ ان چیک کوي چې د کوم حالت په وړاندې چکونه پرمخ وړل شوي. که چیرې پراختیا د جوړیدو وروسته تازه شوې وي ، نو پلگ ان به اجازه ورنکړي چې دا ډول پلې غوښتنې په اصلي څانګه کې ضمیمه شي. دا به په ساده ډول د نسبتا وروستي پرمختګ جوړونه بیا پیل کړي.

زموږ په مثال کې د متضاد بدلونونو سره، دا ډول جوړونه به د تالیف غلطی له امله ناکام شي. په دې اساس، د ب خصوصیت پراختیا کونکی باید کوډ سم کړي، چکونه بیا پیل کړي، بیا به پلگ ان په اتوماتيک ډول د پل غوښتنه پلي کړي.

د دې پلگ ان پلي کولو دمخه ، موږ د هر پلګ غوښتنې اوسط 2,7 بیاکتنې منډې درلودې. د پلگ ان سره 3,6 لانچونه شتون درلود. دا موږ ته مناسب و.

دا د یادونې وړ ده چې دا پلگ ان یو نیمګړتیا لري: دا یوازې یوځل جوړونه بیا پیل کوي. یعني، لا هم یوه کوچنۍ کړکۍ شتون لري چې له لارې یې متضاد بدلونونه پراختیا ومومي. مګر د دې احتمال کم دی، او موږ د پیل شمیرې او د ناکامۍ احتمال تر منځ دا تجارت جوړ کړ. په دوو کلونو کې دا یوازې یو ځل ډزې وشوې، نو دا شاید بې ګټې نه وي.

دا موږ د Bitbucket پلگ ان لومړۍ نسخه لیکلو لپاره دوه اونۍ وخت واخیست.

نوي چکونه

په عین وخت کې، زموږ ټیم وده ته دوام ورکړ. نوي چکونه اضافه شوي.

موږ فکر وکړ: ولې تېروتنې کوي که مخنیوی یې وشي؟ او له همدې امله دوی پلي کړي د جامد کوډ تحلیل. موږ د لینټ سره پیل وکړ، کوم چې د Android SDK کې شامل دی. مګر په هغه وخت کې هغه نه پوهیده چې څنګه د کوټلین کوډ سره کار وکړي، او موږ دمخه د 75٪ غوښتنلیک په کوټلین کې لیکلی و. له همدې امله، جوړ شوي په لینټ کې اضافه شوي د Android سټوډیو چک کوي.

د دې کولو لپاره ، موږ باید ډیری ګډوډي ترسره کړو: د Android سټوډیو واخلئ ، په ډاکر کې یې بسته کړئ او په CI کې یې د مجازی مانیټر سره چل کړئ ، نو دا فکر کوي چې دا په ریښتیني لپ ټاپ کې روان دی. مګر دا کار وکړ.

دا هغه وخت هم و چې موږ ډیر لیکل پیل کړل د وسایلو ازموینې او پلي کیږي د سکرین شاټ ازموینه. دا هغه وخت دی چې د جلا کوچني لید لپاره د حوالې سکرین شاټ رامینځته کیږي ، او ازموینه د لید څخه د سکرین شاټ اخیستل او د پکسل لخوا مستقیم پکسل سره د معیاري سره پرتله کول دي. که چیرې توپیر شتون ولري، دا پدې مانا ده چې ترتیب چیرته غلط شوی یا په سټایلونو کې یو څه غلط دی.

مګر د وسایلو ازموینې او د سکرین شاټ ازموینې باید په وسیلو کې پرمخ وړل شي: په ایمولیټرونو یا ریښتیني وسیلو کې. د دې په پام کې نیولو سره چې ډیری ازموینې شتون لري او دوی په مکرر ډول پرمخ وړل کیږي ، یو بشپړ فارم ته اړتیا ده. ستاسو د خپل فارم پیل کول خورا ډیر کار دی، نو موږ یو چمتو شوی اختیار وموند - د Firebase Test Lab.

د Firebase ټیسټ لابراتوار

دا غوره شوی و ځکه چې Firebase د ګوګل محصول دی، پدې معنی چې دا باید د باور وړ وي او د مړینې احتمال نلري. نرخونه مناسب دي: د ریښتیني وسیلې د عملیاتو لپاره په هر ساعت کې $ 5، د ایمولیټر عملیات په ساعت کې 1 $.

زموږ په CI کې د Firebase ټیسټ لابراتوار پلي کولو لپاره نږدې درې اونۍ وخت ونیو.

مګر ټیم وده ته ادامه ورکړه، او فایربیس، له بده مرغه، موږ ته یې پریښودل پیل کړل. په هغه وخت کې، هغه هیڅ SLA نه درلود. ځینې ​​​​وختونه فایربیس موږ ته انتظار باسي تر هغه چې اړین شمیر وسایل د ازموینو لپاره وړیا وي ، او سمدلاسه یې پلي کول پیل نه کړل لکه څنګه چې موږ غواړو. په لیکه کې انتظار نیم ساعت وخت نیسي، کوم چې ډیر اوږد وخت دی. د وسایلو ازموینې په هر PR کې پرمخ وړل شوي، ځنډ واقعیا پرمختګ ورو کړ، او بیا میاشتنی بل د ګردي پیسو سره راغی. په عموم کې، پریکړه وشوه چې د Firebase پریږدي او په کور کې کار وکړي، ځکه چې ټیم کافي وده کړې وه.

Docker + Python + bash

موږ ډاکر واخیست ، په دې کې ډک شوي ایمولیټرونه ، په پایتون کې یو ساده برنامه لیکلې ، کوم چې په سم وخت کې په اړین نسخه کې اړین شمیر ایمولیټرونه راوړي او کله چې اړتیا وي ودروي. او البته، یو څو د باش سکریپټونه - موږ به د دوی پرته چیرته یو؟

زموږ د ازموینې چاپیریال رامینځته کولو لپاره پنځه اونۍ وخت ونیو.

د پایلې په توګه، د هرې پلې غوښتنې لپاره د چکونو پراخه ادغام بلاک کولو لیست شتون درلود:

• د ARK مجلس؛
• د جنیټ ازموینې؛
• لينټ;
• د Android سټوډیو چکونه؛
• د وسایلو ازموینې؛
• د سکرین شاټ ازموینې.

دا د ډیری احتمالي ماتیدو مخه ونیوله. تخنیکي پلوه هرڅه کار وکړ، مګر پراختیا کونکو شکایت وکړ چې د پایلو انتظار خورا اوږد و.

څومره وخت ډیر اوږد دی؟ موږ د Bitbucket او TeamCity څخه ډاټا د تحلیل سیسټم ته پورته کړه او پوه شو چې د انتظار اوسط وخت 45 دقیقې. دا دی ، یو پراختیا کونکی ، کله چې د پل غوښتنه خلاصوي ، د جوړیدو پایلو لپاره په اوسط ډول 45 دقیقې انتظار کوي. زما په نظر، دا ډیر دی، او تاسو د دې په څیر کار نشئ کولی.

البته، موږ پریکړه وکړه چې زموږ ټول جوړونه ګړندي کړو.

راځئ چې سرعت وکړو

لیدل چې جوړونه اکثرا په کتار کې ودریږي، لومړی شی چې موږ یې کوو نور هارډویر اخیستی - پراخه پراختیا ترټولو ساده ده. ودانیو قطار بند کړ، مګر د انتظار وخت یوازې یو څه کم شوی، ځکه چې ځینې چکونه پخپله ډیر وخت نیسي.

د چکونو لرې کول چې ډیر وخت نیسي

زموږ دوامداره ادغام کولی شي دا ډول خطاګانې او ستونزې ونیسي.

• ته نه ځي. CI کولی شي د تالیف غلطی ونیسي کله چې یو څه د متضاد بدلونونو له امله رامینځته نشي. لکه څنګه چې ما مخکې وویل، بیا هیڅوک نشي کولی یو څه راټول کړي، پرمختګ ودریږي، او هرڅوک عصبي کیږي.
• په چلند کې خرابي. د مثال په توګه، کله چې اپلیکیشن جوړ شوی وي، مګر کله چې تاسو تڼۍ فشاروئ، یا تڼۍ په بشپړه توګه نه فشارول کیږي. دا خراب دی ځکه چې دا ډول بګ کارونکي ته رسیدلی شي.
• په ترتیب کې بګ. د مثال په توګه، یو تڼۍ کلیک شوی، مګر 10 پیکسل کیڼ لور ته لیږدول شوی.
• د تخنیکي پورونو زیاتوالی.

د دې لیست په کتلو سره، موږ پوهیږو چې یوازې لومړی دوه ټکي مهم دي. موږ غواړو لومړی دا ډول ستونزې راوباسي. په ترتیب کې بګونه د ډیزاین بیاکتنې مرحله کې کشف شوي او بیا په اسانۍ سره سم کیدی شي. د تخنیکي پور سره معامله کول جلا پروسې او پلان کولو ته اړتیا لري، نو موږ پریکړه وکړه چې دا د پلټ غوښتنې په اړه ازموینه ونه کړو.

د دې ډلبندۍ پراساس، موږ د چکونو ټول لیست راټیټ کړ. لینټ کراس شوی او د شپې لخوا یې پیل وځنډاوه: یوازې د دې لپاره چې دا راپور چمتو کړي چې په پروژه کې څومره ستونزې شتون لري. موږ موافقه وکړه چې د تخنیکي پور سره په جلا توګه کار وکړو، او د Android سټوډیو چیکونه په بشپړ ډول پریښودل شوي. د چلولو تفتیشونو لپاره په ډاکر کې د Android سټوډیو په زړه پوري ښکاري ، مګر په ملاتړ کې د ډیری ستونزو لامل کیږي. د Android سټوډیو نسخو ته هرډول تازه کول د نه پوهیدو وړ کیګونو سره مبارزه معنی لري. د سکرین شاټ ازموینو ملاتړ کول هم ستونزمن وو ، ځکه چې کتابتون خورا مستحکم نه و او غلط مثبت شتون درلود. د سکرین شاټ ازموینې د چک لیست څخه لرې شوي.

د پایلې په توګه، موږ پاتې شو:

• د ARK مجلس؛
• د جنیټ ازموینې؛
• د وسایلو ازموینې.

Gradle ریموټ کیچ

د درنو چکونو پرته، هرڅه ښه شول. مګر د کمال حد شتون نلري!

زموږ غوښتنلیک دمخه په شاوخوا 150 درجې ماډلونو ویشل شوی و. د ګرډل ریموټ کیچ معمولا پدې قضیه کې ښه کار کوي ، نو موږ پریکړه وکړه چې دا هڅه وکړو.

د ګریډل ریموټ کیچ یو خدمت دی چې کولی شي په انفرادي ماډلونو کې د انفرادي دندو لپاره هنري اثار جوړ کړي. ګرډل د دې پرځای چې واقعیا د کوډ تالیف کړي ، د ریموټ کیچ ټکولو لپاره HTTP کاروي او پوښتنه کوي چې ایا چا دمخه دا دنده ترسره کړې. که هو، دا په ساده ډول پایله ډاونلوډ کوي.

د ګرډل ریموټ کیچ چلول اسانه دي ځکه چې ګرډل د ډاکر عکس چمتو کوي. موږ دا په دریو ساعتونو کې ترسره کړو.

ټول هغه څه چې تاسو یې باید ترسره کړئ د ډاکر لانچ کول او په پروژه کې یوه کرښه ولیکئ. مګر که څه هم دا په چټکۍ سره پیل کیدی شي، دا به د هرڅه ښه کار کولو لپاره ډیر وخت ونیسي.

لاندې د کیچ یاد ګراف دی.

په لومړي سر کې، د کیش د ورکیدو سلنه شاوخوا 65 وه. له دریو اونیو وروسته، موږ وکولی شو چې دا ارزښت 20٪ ته لوړ کړو. دا معلومه شوه چې هغه دندې چې د Android غوښتنلیک راټولوي عجیب انتقالي انحصارونه لري، چې له امله یې ګرډل کیچ له لاسه ورکړ.

د کیچ سره وصل کولو سره، موږ جوړونه خورا ګړندۍ کړه. مګر د مجلس سربیره، د وسایلو ازموینې هم شتون لري، او دوی ډیر وخت نیسي. شاید ټولې ازموینې ته اړتیا ونلري چې د هر پل غوښتنې لپاره پرمخ لاړ شي. د موندلو لپاره، موږ د اغیزو تحلیل کاروو.

د اغیزو تحلیل

د پل په غوښتنه، موږ د git diff راټولوو او د تعدیل شوي Gradle ماډلونه ومومئ.

دا یوازې د وسیلو ازموینې پرمخ وړل معنی لري چې بدل شوي ماډلونه او ټول ماډلونه چیک کوي چې په دوی پورې اړه لري. د ګاونډیو ماډلونو لپاره د ازموینو چلولو کې هیڅ معنی نشته: هلته کوډ ندی بدل شوی او هیڅ شی نشي ماتیدلی.

د وسایلو ازموینې دومره ساده ندي، ځکه چې دوی باید د لوړې کچې غوښتنلیک ماډل کې موقعیت ولري. موږ د بایټکوډ تحلیل سره هیوریسټیک کارولی ترڅو پوه شو چې هر ټیسټ کوم ماډل پورې اړه لري.

د وسایلو ازموینو عملیاتو ته وده ورکول ترڅو دوی یوازې د هغه ماډلونو ازموینه وکړي چې شاوخوا اته اونۍ وخت نیسي.

د تفتیشونو د چټکولو لپاره اقدامات په بریالیتوب سره کار کوي. له 45 دقیقو څخه موږ شاوخوا 15 ته پورته شو. دا دمخه عادي خبره ده چې د جوړولو لپاره د یو ساعت څلورمه برخه انتظار وکړئ.

مګر اوس پراختیا کونکو شکایت کول پیل کړي چې دوی نه پوهیږي چې کوم جوړونه په لاره اچول کیږي ، چیرې چې لاګ وګوري ، ولې جوړښت سور دی ، کوم ازموینه ناکامه شوې ، او داسې نور.

د فیډبیک ستونزې د پرمختګ ورو کوي، نو موږ هڅه وکړه چې د هر PR په اړه روښانه او مفصل معلومات چمتو کړو او څومره چې ممکنه وي جوړ کړو. موږ PR ته په بټ بکټ کې د نظرونو سره پیل وکړ، دا په ګوته کوي چې کوم جوړونه ناکامه شوې او ولې، او په سلیک کې هدف شوي پیغامونه لیکلي. په پای کې، موږ د پاڼې لپاره د PR ډشبورډ د ټولو ودانیو لیست سره جوړ کړ چې اوس مهال روان دي او د دوی حالت: قطار، چلول، ټکر شوی یا بشپړ شوی. تاسو کولی شئ په جوړښت کلیک وکړئ او د هغې لاګ ته ورشئ.

شپږ اونۍ په تفصیلي فیډبیک مصرف شوي.

پلانونه

راځئ چې وروستي تاریخ ته لاړ شو. د فیډبیک مسلې حل کولو سره ، موږ یوې نوې کچې ته ورسیدو - موږ پریکړه وکړه چې خپل د ایمولیټر فارم جوړ کړو. کله چې ډیری ازموینې او ایمولیټر شتون ولري، دوی اداره کول ستونزمن دي. د پایلې په توګه، زموږ ټول ایمولیټران د انعطاف وړ سرچینو مدیریت سره د k8s کلستر ته لاړل.

سربیره پردې، نور پلانونه شتون لري.

• لینټ بیرته راستانه کړئ (او نور جامد تحلیل). موږ لا دمخه په دې لار کې کار کوو.
• هرڅه په PR بلاکر کې پرمخ وړئ له پای څخه تر پای پورې ازموینې په ټولو SDK نسخو کې.

نو، موږ په Avito کې د دوامداره ادغام د پراختیا تاریخ موندلی دی. اوس زه غواړم د تجربه لرونکي نظر څخه یو څه مشوره ورکړم.

Советы

که زه کولی شم یوازې یوه برخه مشوره ورکړم دا به دا وي:

مهرباني وکړئ د شیل سکریپټونو سره محتاط اوسئ!

باش خورا انعطاف منونکی او ځواکمن وسیله ده ، دا د سکریپټونو لیکلو لپاره خورا اسانه او ګړندی دی. مګر تاسو کولی شئ د دې سره په جال کې راښکته شئ ، او له بده مرغه موږ پدې کې راګیر شو.

دا ټول د ساده سکریپټونو سره پیل شوي چې زموږ د جوړولو ماشینونو کې روان دي:

#!/usr/bin/env bash
./gradlew assembleDebug

مګر، لکه څنګه چې تاسو پوهیږئ، هر څه وده کوي او د وخت په تیریدو سره ډیر پیچلي کیږي - راځئ چې یو سکریپټ له بل څخه پرمخ بوځو، راځئ چې هلته ځینې پیرامیټونه تیر کړو - په پای کې موږ باید یو فنکشن ولیکو چې دا معلومه کړي چې د باش نیسټنګ په کومه کچه کې موږ اوس په ترتیب کې یو. د اړینو نرخونو داخلولو لپاره، دا ټول پیل کړئ.

تاسو کولی شئ د دې ډول سکریپټونو پراختیا لپاره د کار لګښتونه تصور کړئ. زه تاسو ته مشوره درکوم چې په دې جال کې مه ځئ.

څه شی بدل کیدی شي؟

• د سکریپټ هره ژبه. ته ولیکئ پایتون یا کوټلین سکریپټ ډیر اسانه ځکه چې دا پروګرامینګ دی، نه سکریپټونه.
• یا په فورمه کې د جوړونې ټول منطق تشریح کړئ د ګمرکي درجې دندې ستاسو د پروژې لپاره.

موږ پریکړه وکړه چې دوهم انتخاب غوره کړو، او اوس موږ په سیستماتیک ډول ټول د بش سکریپټونه حذف کوو او ډیری دودیز ګریډ دندې لیکو.

لارښوونه #2: په کوډ کې زیربنا ذخیره کړئ.

دا مناسبه ده کله چې د دوامداره ادغام ترتیب د جینکنز یا ټیم سیټي او نور په UI انٹرفیس کې زیرمه شوی نه وي ، مګر د متن فایلونو په مستقیم ډول د پروژې ذخیره کې. دا د نسخې وړتیا ورکوي. دا به ستونزمن نه وي چې په بلې څانګې کې د کوډ رول بیک یا جوړ کړئ.

سکریپټونه په پروژه کې زیرمه کیدی شي. د چاپیریال سره څه وکړي؟

لارښوونه #3: ډاکر کولی شي د چاپیریال سره مرسته وکړي.

دا به خامخا د Android پراختیا کونکو سره مرسته وکړي؛ iOS لاهم نلري ، له بده مرغه.

دا د ساده ډاکر فایل یوه بیلګه ده چې jdk او android-sdk لري:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

د دې ډاکر فایل په لیکلو سره (زه به تاسو ته یو راز ووایم ، تاسو اړتیا نلرئ دا ولیکئ ، مګر یوازې دا د GitHub څخه چمتو شوی راوباسئ) او عکس راټول کړئ ، تاسو یو مجازی ماشین ترلاسه کوئ چې تاسو کولی شئ غوښتنلیک جوړ کړئ. او د جونیټ ازموینې پرمخ وړي.

دوه اصلي دلیلونه چې ولې دا معنی لري د توزیع او تکرار وړتیا دي. د ډاکر په کارولو سره ، تاسو کولی شئ په چټکۍ سره یو درجن جوړونکي اجنټان پورته کړئ چې د تیر په څیر به ورته ورته چاپیریال ولري. دا د CI انجینرانو ژوند خورا اسانه کوي. دا خورا اسانه ده چې د android-sdk په ډاکر کې واچوئ ، مګر د ایمولیټرونو سره دا یو څه ډیر ستونزمن دی: تاسو باید یو څه سخت کار وکړئ (یا د GitHub څخه بشپړ شوی بیا ډاونلوډ کړئ).

څلورمه لارښوونه: مه هېروئ چې تفتیشونه د تفتیش لپاره نه ، بلکې د خلکو لپاره ترسره کیږي.

ګړندي او خورا مهم ، روښانه فیډبیک د پراختیا کونکو لپاره خورا مهم دی: څه مات شوي ، کوم ازموینه ناکامه شوې ، زه چیرې کولی شم د جوړونې لاګ وګورم.

لارښوونه #5: د دوامداره ادغام په وخت کې عملي اوسئ.

په روښانه توګه پوه شئ چې تاسو د کوم ډول غلطیو مخه نیول غواړئ، څومره سرچینې، وخت، او کمپیوټر وخت چې تاسو یې مصرف کولو ته لیواله یاست. هغه چکونه چې ډیر وخت نیسي، د بیلګې په توګه، د شپې ځنډول کیدی شي. او هغه څوک چې خورا مهمې خطاګانې نه نیسي باید په بشپړ ډول پریښودل شي.

لارښوونه #6: چمتو شوي وسایل وکاروئ.

اوس ډیری شرکتونه شتون لري چې کلاوډ CI چمتو کوي.

دا د کوچنیو ټیمونو لپاره ښه حل دی. تاسو اړتیا نلرئ د هیڅ شی ملاتړ وکړئ، یوازې لږې پیسې ورکړئ، خپل غوښتنلیک جوړ کړئ او حتی د وسیلو ازموینې ترسره کړئ.

لارښوونه #7: په لوی ټیم کې، د کور دننه حلونه ډیر ګټور دي.

مګر ژر یا وروسته، لکه څنګه چې ټیم وده کوي، د کور دننه حلونه به ډیر ګټور شي. د دې پریکړو سره یوه ستونزه شتون لري. په اقتصاد کې د عوایدو کمولو قانون شتون لري: په هره پروژه کې، هر راتلونکی پرمختګ خورا ستونزمن وي او ډیرې پانګونې ته اړتیا لري.

اقتصاد زموږ ټول ژوند بیانوي، په شمول د دوامداره ادغام. ما زموږ د دوامداره ادغام د پراختیا د هرې مرحلې لپاره د کار لګښتونو مهالویش جوړ کړ.

دا روښانه ده چې هر ډول پرمختګ ورځ تر بلې ستونزمن کیږي. د دې ګراف په لټه کې، تاسو کولی شئ پوه شئ چې دوامداره ادغام ته اړتیا ده چې د ټیم د اندازې د ودې سره سم پراختیا ومومي. د دوه کسانو ټیم لپاره ، د داخلي ایمولیټر فارم رامینځته کولو لپاره د 50 ورځو مصرف کول یو متوسط ​​نظر دی. مګر په ورته وخت کې، د لوی ټیم لپاره، د دوامداره ادغام نه کول هم یو بد نظر دی، ځکه چې د ادغام ستونزې، د اړیکو تنظیم کول، او نور. دا به ډیر وخت ونیسي.

موږ د دې مفکورې سره پیل وکړ چې اتومات ته اړتیا ده ځکه چې خلک ګران دي، دوی غلطي کوي او سست دي. مګر خلک هم اتومات کوي. له همدې امله، ټولې ورته ستونزې په اتوماتیک کې پلي کیږي.

• اتومات ګران دی. د کار مهال ویش په یاد ولرئ.
• کله چې د اتومات کولو خبره راځي، خلک غلطي کوي.
• ځینې ​​​​وختونه دا د اتومات کولو لپاره خورا سست دی ، ځکه چې هرڅه پدې ډول کار کوي. ولې نور څه ښه کول، ولې دا ټول دوامداره ادغام؟

مګر زه احصایې لرم: تېروتنې په 20٪ مجلسونو کې نیول شوي. او دا د دې لپاره ندي چې زموږ پراختیا کونکي کوډ په خراب ډول لیکي. دا ځکه چې پراختیا کونکي ډاډه دي چې که دوی یو څه غلطي وکړي، دا به په پراختیا کې پای ته ونه رسیږي، دا به د اتوماتیک چکونو لخوا ونیول شي. په دې اساس، پراختیا کونکي کولی شي د کوډ او په زړه پورې شیانو په لیکلو کې ډیر وخت ولګوي، د دې پرځای چې په محلي توګه د یو څه چلولو او ازموینې پرځای.

د دوامداره ادغام تمرین وکړئ. مګر په اعتدال کې.

په هرصورت، نیکولای نیسټروف نه یوازې پخپله لوی راپورونه ورکوي، بلکې د پروګرام کمیټې غړی هم دی. AppsConf او له نورو سره مرسته کوي چې ستاسو لپاره معنی لرونکي ویناوې چمتو کړي. د راتلونکي کنفرانس برنامه بشپړتیا او ګټورتوب د موضوعاتو له مخې ارزول کیدی شي مهال ویش. او د جزیاتو لپاره، د اپریل په 22-23 Infospace ته راشئ.

سرچینه: www.habr.com