راپور به د ځینې DevOps کړنو په اړه وغږیږي، مګر د پراختیا کونکي له نظره. عموما، ټول انجنیران چې د DevOps سره یوځای کیږي دمخه د دوی د بیلټ لاندې د څو کلونو اداري تجربه لري. مګر دا پدې معنی ندي چې دلته د پراختیا کونکي لپاره هیڅ ځای شتون نلري. ډیری وختونه نه ، پراختیا کونکي د "د ورځې راتلونکي عاجل جدي بګ" په حل کولو بوخت دي ، او دوی وخت نلري حتی د DevOps ساحې ته ګړندي کتنه وکړي. د لیکوال په پوهه کې، DevOps، لومړی، عام احساس دی. دوهم، دا یو فرصت دی چې ډیر اغیزمن وي. که تاسو یو پرمخ وړونکي یاست، عام احساس لرئ او غواړئ د ټیم لوبغاړي په توګه ډیر اغیزمن شئ، دا راپور ستاسو لپاره دی.
اجازه راکړئ خپل ځان معرفي کړم، زه په بشپړ ډول اعتراف کوم چې په خونه کې داسې خلک شتون لري چې ما نه پیژني. زما نوم انتون بویکو دی، زه د مایکروسافټ Azure MVP یم. MVP څه شی دی؟ دا د ماډل لید وړاندې کوونکی دی. د ماډل لید - وړاندې کوونکی په حقیقت کې زه یم.
سربیره پردې، زه اوس مهال په Ciklum کې د حل معمارۍ دنده لرم. او په دې وروستیو کې ما خپل ځان دومره ښکلی ډومین اخیستی، او ما خپل بریښنالیک تازه کړ، کوم چې زه معمولا په پریزنټشنونو کې ښکاره کوم. تاسو کولی شئ ما ته په دې پته ولیکئ: me [dog] byokoant.pro. تاسو کولی شئ ما ته د پوښتنو سره بریښنالیک وکړئ. زه معمولا دوی ته ځواب ورکوم. یوازینی شی دا دی چې زه نه غواړم د بریښنالیک له لارې پوښتنې ترلاسه کړم چې دوه موضوعاتو پورې اړه لري: سیاست او مذهب. تاسو کولی شئ ما ته د هر څه په اړه د بریښنالیک له لارې ولیکئ. یو څه وخت به تېر شي، زه به ځواب ووایم.
د خپل ځان په اړه یو څو خبرې:
- زه اوس د 10 کلونو لپاره پدې ډګر کې یم.
- ما په مایکروسافټ کې کار کاوه.
- زه د اوکراین Azure ټولنې بنسټ ایښودونکی پلار یم، کوم چې موږ په 2014 کې یو ځای تاسیس کړ. او موږ لاهم دا لرو او وده کوو.
- زه د ازور کنفرانس د بنسټ ایښودونکي پلار هم یم، کوم چې موږ په اوکراین کې کوربه یو.
- زه په کیف کې د ګلوبل ازور بوټ کیمپ تنظیم کولو کې هم مرسته کوم.
- لکه څنګه چې ما وویل، زه د مایکروسافټ Azure MVP یم.
- زه ډیری وخت په کنفرانسونو کې خبرې کوم. زه واقعیا په کنفرانسونو کې خبرې کول خوښوم. په تیر کال کې ما وکولای شول شاوخوا 40 ځله ترسره کړي. که تاسو د اوکراین، بیلاروس، پولنډ، بلغاریا، سویډن، ډنمارک، هالنډ، هسپانیې څخه تیر شئ یا په اروپا کې کوم بل هیواد ورکړئ یا یې واخلئ، نو دا خورا ممکنه ده چې تاسو هغه کنفرانس ته لاړ شئ چې په جریان کې د بادل موضوع وي، تاسو ممکن ما د ویناوالو په لیست کې وګورئ.
- زه هم د سټار ټریک مینه وال یم.
راځئ چې د اجنډا په اړه لږ څه خبرې وکړو. زموږ اجنډا خورا ساده ده:
- موږ به د دې په اړه وغږیږو چې DevOps څه شی دی. راځئ چې خبرې وکړو چې ولې دا مهم دی. مخکې، DevOps یوه کلیدي کلمه وه چې تاسو په خپل بیا پیل کې لیکلې وه او سمدلاسه یې + $ 500 معاش ترلاسه کړ. اوس تاسو اړتیا لرئ چې ولیکئ، د بیلګې په توګه، په خپل بیا پیل کې بلاکچین ولیکئ ترڅو خپل معاش ته +500 ډالر ترلاسه کړئ.
- او بیا، کله چې موږ د دې په اړه لږ څه پوهیږو، موږ به په دې اړه وغږیږو چې د DevOps کړنې څه دي. مګر په عموم کې د DevOps په شرایطو کې دومره نه ، مګر د دې DevOps کړنو په اړه چې ممکن د پراختیا کونکو لپاره علاقه ولري. زه به تاسو ته ووایم چې ولې دوی ممکن ستاسو لپاره علاقه ولري. زه به تاسو ته ووایم چې ولې تاسو باید دا په بشپړ ډول ترسره کړئ او دا څنګه کولی شي تاسو سره د لږ درد تجربه کولو کې مرسته وکړي.
یو دودیز انځور چې ډیری خلک یې ښیې. دا هغه څه دي چې په ډیری پروژو کې پیښیږي. دا هغه وخت دی چې موږ د پراختیا او عملیاتو څانګې لرو چې زموږ د سافټویر ملاتړ کوي. او دا څانګې یو له بل سره اړیکه نه لري.
شاید، که تاسو نشو کولی دا د DevOps او عملیاتي څانګو کې په واضح ډول احساس کړئ، تاسو کولی شئ د دیو او QA ډیپارټمنټونو سره ورته والی راوباسئ. داسې خلک شتون لري چې سافټویر رامینځته کوي او د QA خلک شتون لري چې د پراختیا کونکو له نظره خراب دي. د مثال په توګه، زه خپل په زړه پورې کوډ ذخیره ته سپارم، او هلته یو بدکار ناست دی چې دا کوډ ما ته راګرځوي او وايي چې ستاسو کوډ خراب دی.
دا ټول پیښیږي ځکه چې خلک یو بل سره اړیکه نلري. او دوی ځینې کڅوړې ، ځینې غوښتنلیکونه یو بل ته د غلط فهمۍ د دیوال له لارې اچوي او هڅه کوي له دوی سره یو څه وکړي.
دا دقیقا دا دیوال دی چې د DevOps کلتور د ویجاړولو لپاره ډیزاین شوی، د بیلګې په توګه. خلک مجبور کړئ چې له یو بل سره اړیکه ونیسي او لږترلږه په دې پوه شي چې په پروژه کې مختلف خلک څه کوي او ولې د دوی کار مهم دی.
او کله چې موږ د DevOps په اړه وغږیږو، یو څوک به تاسو ته ووایي چې DevOps هغه وخت دی کله چې پروژه دوامداره ادغام ولري؛ یو څوک به ووایی چې DevOps هغه دی که چیرې پروژه د "کوډ په توګه زیربنا" تمرین پلي کړي؛ یو څوک به ووایی چې د DevOps لپاره لومړی ګام د فیچر برانچینګ ، فیچر بیرغونه دي.
په اصل کې، دا ټول په خپله طریقه ریښتیا دي. مګر دا یوازې وروستي تمرینونه دي چې موږ یې لرو. مخکې لدې چې دې تمرینونو ته لاړ شو ، زه وړاندیز کوم چې دې سلایډ ته وګورم ، کوم چې ستاسو په شرکت کې ستاسو په پروژه کې د Dev-Ops میتودولوژي پلي کولو 3 مرحلې ښیې.
دا سلایډ دوهم غیر رسمي نوم هم لري. تاسو کولی شئ آنلاین لټون وکړئ ترڅو ومومئ چې د DevOps 3 Musketeers څه دي. دا ممکنه ده چې تاسو به دا مقاله ومومئ. ولې 3 Musketeers؟ لاندې دا وايي: خلک، پروسې او محصولات، i.e. PPP - پورتوس، پورتوس او پورتوس. دلته د DevOps 3 Musketeers دي. دا مقاله په ډیر تفصیل سره تشریح کوي چې ولې دا مهم دی او څه پکې شامل دي.
کله چې تاسو د DevOps کلتور پلي کول پیل کړئ ، نو دا خورا مهم دي چې دا په لاندې ترتیب کې پلي کیږي.
په پیل کې تاسو باید د خلکو سره خبرې وکړئ. او تاسو اړتیا لرئ خلکو ته تشریح کړئ چې دا څه دي او دوی څنګه کولی شي له دې څخه ځینې ګټې ترلاسه کړي.
زموږ کنفرانس د DotNet Fest په نوم یادیږي. او لکه څنګه چې تنظیم کونکو ما ته وویل ، موږ په عمده ډول دلته د پراختیا کونکو لیدونکو ته بلنه ورکړه ، نو زه امید لرم چې په تالار کې ډیری خلک په پراختیا کې دخیل وي.
موږ به د خلکو په اړه وغږیږو، موږ به د هغه څه په اړه وغږیږو چې پراختیا کونکي هره ورځ غواړي. دوی ډیر څه غواړي؟ دوی غواړي یو څه نوي کوډ ولیکي، نوي چوکاټونه وکاروي، نوي ځانګړتیاوې رامینځته کړي. پراختیا کونکي لږترلږه څه غواړي؟ زاړه کیچونه حل کړئ. هیله ده راسره موافق یاست. دا هغه څه دي چې پراختیا کونکي یې غواړي. دوی غواړي نوي ځانګړتیاوې ولیکي، دوی نه غواړي چې کیګونه حل کړي.
د کیګونو شمیر چې یو ځانګړی پراختیا کونکی تولیدوي پدې پورې اړه لري چې د هغه لاسونه څومره مستقیم دي او څومره د هغه له اوږو څخه وده کوي ، نه د هغه د بټ جیب څخه. مګر په هرصورت، کله چې موږ لویه پروژه لرو، ځینې وختونه داسې پیښیږي چې د هر څه تعقیب کول ناممکن دي، نو دا به زموږ لپاره ښه وي چې ځینې طریقې وکاروو چې موږ سره به د ډیر باثباته او لوړ کیفیت کوډ لیکلو کې مرسته وکړي.
QAs ډیر څه غواړي؟ زه نه پوهیږم چې دوی په تالار کې دي که نه. دا زما لپاره سخته ده چې ووایم چې زه QA غواړم، ځکه چې زه هیڅکله نه وم. او هلکانو ته هیڅ تاوان نه رسوي، دا به ویل کیږي چې زه امید لرم چې هیڅکله به نه. خو په دې خاطر نه چې زه د دوی کار بې مانا او بې ګټې ګڼم، بلکې دا چې زه خپل ځان داسې شخص نه ګڼم چې دا کار په ښه توګه ترسره کړي، نو زه به یې هم هڅه ونه کړم. مګر د هغه څه څخه چې زه پوهیږم، هغه څه چې QA ډیر نه خوښوي په سهار کې کار کول دي، په دوامداره توګه د یو ډول ریګریشن ازموینې پرمخ وړل، په ورته بګونو باندې ګام پورته کول چې دوی 3 سپرینټ مخکې پراختیا کونکو ته راپور ورکړی او وايي: "تاسو به کله , Monsieur D 'Artagnan، دا ستونزه حل کړئ. او مونسيور ارټاګن ورته ځواب ورکوي: "هو ، هو ، هو ، ما دمخه دا تنظیم کړی دی." او دا څنګه پیښیږي چې ما یوه بګ حل کړ او په لاره کې یې 5 جوړ کړل.
هغه خلک چې په تولید کې د دې حل ملاتړ کوي غواړي دا حل د بګ پرته کار وکړي، نو دوی اړتیا نلري چې سرور هره جمعه بیا پیل کړي، کله چې ټول نورمال خلک بار ته ځي. پراختیا کونکي د جمعې په ورځ ګمارل شوي، مدیران د شنبې تر ورځې پورې ناست دي، هڅه کوي چې دا ګمارل او تنظیم کړي.
او کله چې تاسو خلکو ته تشریح کوئ چې دوی د ورته ستونزو حل کولو په هدف دي، تاسو کولی شئ د پروسې رسمي کولو ته لاړ شئ. دا ډیره مهمه ده. ولې؟ ځکه چې کله موږ "رسمي کول" وایو، دا ستاسو لپاره مهمه ده چې تشریح کړئ چې ستاسو پروسې لږترلږه په یو رومال کې واقع کیږي. تاسو اړتیا لرئ پوه شئ چې که تاسو د مثال په توګه د QA چاپیریال یا تولید چاپیریال ته ځای په ځای کړئ ، نو دا تل پدې ترتیب کې پیښیږي؛ پدې مرحلو کې موږ چلوو ، د مثال په توګه ، د اتوماتیک واحد ازموینې او UI ازموینې. د ګمارنې وروسته، موږ ګورو چې ایا ګمارل ښه یا خراب شوي. مګر تاسو دمخه د عملونو روښانه لیست لرئ چې باید په مکرر ډول تکرار شي کله چې تاسو تولید ته ځای په ځای کوئ.
او یوازې کله چې ستاسو پروسې رسمي شي ، ایا تاسو د محصولاتو غوره کولو پیل کوئ چې تاسو سره به د دې پروسې اتومات کولو کې مرسته وکړي.
له بده مرغه، زه ډیری وختونه ګورم چې دا په برعکس واقع کیږي. هرڅومره ژر چې څوک د "DevOps" کلمه واوري ، دوی سمدلاسه د جینکنز نصبولو وړاندیز کوي ، ځکه چې دوی باور لري هرڅومره ژر چې دوی جینکنز نصب کړي ، دوی به DevOps ولري. دوی جینکنز نصب کړ ، د جینکنز ویب پا onه کې یې "څنګه" مقالې ولوستلې ، هڅه یې وکړه چې د دې څنګه مقالې کې پروسې ډکې کړي ، او بیا خلکو ته راغلل او خلک یې ودرول او ویې ویل چې کتاب وايي چې تاسو ورته اړتیا لرئ دا کار وکړئ ، نو موږ دا په دې ډول کوو.
دا نده چې جینکنز یو بد وسیله ده. زما مطلب دا نه دی چې ووایم په هیڅ ډول. مګر دا یوازې یو له محصولاتو څخه دی. او کوم محصول چې تاسو یې کاروئ باید ستاسو وروستۍ پریکړه وي، او په هیڅ ډول ستاسو لومړی. ستاسو محصول باید د کلتور او چلندونو پلي کولو لخوا پرمخ نه ځي. دا د پوهیدلو لپاره خورا مهم دی ، له همدې امله زه پدې سلایډ کې دومره وخت تیروم او دا ټول د اوږدې مودې لپاره تشریح کوم.
راځئ چې په عمومي ډول د DevOps کړنو په اړه وغږیږو. دا څه دي؟ توپیر څه دی؟ دوی څنګه هڅه وکړئ؟ ولې دوی مهم دي؟
لومړی تمرین چې تاسو یې اوریدلی وي د دوامداره ادغام په نوم یادیږي. شاید یو څوک په پروژه کې دوامداره ادغام (CI) ولري.
لویه ستونزه دا ده چې ډیری وختونه کله چې زه له یو کس څخه پوښتنه کوم: "ایا تاسو په پروژه کې CI لرئ؟" او هغه وايي: "هو،" بیا کله چې زه وپوښتم چې هغه څه کوي، هغه ماته د اتوماتیک بشپړ بهیر بیانوي. دا په بشپړه توګه ریښتیا نه ده.
په حقیقت کې، د CI تمرین یوازې د کوډ ادغام په هدف دی چې مختلف خلک په یو ډول واحد کوډ بیس کې لیکي. بس نور څه نه.
د CI سره سره، په لاره کې معمولا نور تمرینونه شتون لري - لکه دوامداره ګمارنه، د خوشې کولو مدیریت، مګر موږ به وروسته په دې اړه وغږیږو.
CI پخپله موږ ته وايي چې مختلف خلک کوډ لیکي او دا کوډ باید په دوامداره توګه په یو واحد کوډ بیس کې مدغم شي.
دا موږ ته څه راکوي او ولې مهم دی؟ که موږ DotNet ولرو، نو دا ښه ده، دا یوه جوړه شوې ژبه ده، موږ کولی شو خپل غوښتنلیک تالیف کړو. که دا تالیف کړي، نو دا لا دمخه یو ښه نښه ده. دا لا تر اوسه هیڅ معنی نه لري، مګر دا لومړی ښه نښه ده چې موږ لږترلږه تالیف کولی شو.
بیا موږ کولی شو ځینې ازموینې ترسره کړو، کوم چې یو جلا تمرین دی. ازموینې ټول شنه دي - دا دویمه ښه نښه ده. مګر بیا، دا هیڅ معنی نلري.
خو ته به ولې داسې کوې؟ ټول هغه عملونه چې زه به یې نن په اړه وغږیږم تقریبا ورته ارزښت لري، د بیلګې په توګه نږدې ورته ګټې او هم نږدې ورته اندازه اندازه کیږي.
لومړی، دا تاسو ته اجازه درکوي د سپارلو چټکتیا. دا څنګه تاسو ته د سپارلو ګړندی کولو اجازه درکوي؟ کله چې موږ زموږ د کوډ بیس کې ځینې نوي بدلونونه راوړو، موږ کولی شو سمدستي هڅه وکړو چې د دې کوډ سره یو څه وکړو. موږ انتظار نه کوو تر هغه چې پنجشنبه راشي ځکه چې د پنجشنبې په ورځ موږ دا د QA چاپیریال ته خوشې کوو، موږ دا دلته او دلته کوو.
زه به تاسو ته د خپل ژوند څخه یوه غمجنه کیسه وکړم. دا ډیر وخت دمخه وو، کله چې زه لاهم ځوان او ښکلی وم. اوس زه لا دمخه ځوان، ښکلی او هوښیار او معتدل یم. څه موده وړاندې زه په یوه پروژه کې وم. موږ د شاوخوا 30 پراختیا کونکو لوی ټیم درلود. او موږ یوه لویه ، لویه تصدۍ پروژه درلوده چې د شاوخوا 10 کلونو لپاره وده کړې. او موږ مختلف څانګې درلودې. په ذخیره کې موږ یوه څانګه درلوده په کوم کې چې پراختیا کونکي تلل. او دلته یوه څانګه وه چې د کوډ نسخه یې ښودلې چې په تولید کې ده.
د تولید څانګه د هغه شاخ څخه 3 میاشتې وروسته وه چې پراختیا کونکو ته شتون درلود. دا څه مانا لري؟ د دې معنی دا ده چې هرڅومره ژر چې زه په کوم ځای کې بګ لرم چې د پراختیا کونکو د خطا له امله تولید ته ځي ، ځکه چې دوی ورته اجازه ورکړې ، او د QA غلطی له امله ، ځکه چې دوی ورته ګوري ، نو د دې معنی دا ده چې که زه ترلاسه کړم د تولید لپاره د هاټ فکس لپاره دنده، نو زه باید د 3 میاشتې دمخه زما د کوډ بدلونونه بیرته راوګرځوم. زه باید هغه څه په یاد ولرم چې ما 3 میاشتې دمخه درلودل او هڅه یې وکړه چې دا هلته حل کړم.
که تاسو تراوسه دا تجربه نه لرئ، تاسو کولی شئ دا په خپل کور پروژه کې هڅه وکړئ. اصلي شی دا دی، دا په سوداګریزه هڅه مه کوئ. د کوډ څو کرښې ولیکئ، د شپږو میاشتو لپاره یې هیر کړئ، او بیا بیرته راشئ او هڅه وکړئ چې ژر تر ژره تشریح کړئ چې د کوډ کرښې دا څه دي او تاسو څنګه کولی شئ دوی اصلاح یا اصلاح کړئ. دا یوه ډیره، ډیره په زړه پوری تجربه ده.
که موږ د دوامداره ادغام تمرین ولرو، نو دا موږ ته اجازه راکوي چې دا دلته او همدا اوس د یو شمیر اتوماتیک وسیلو سره وګورو، کله چې ما خپل کوډ لیکلی وي. دا ممکن ماته بشپړ عکس ونه راکوي ، مګر سره له دې ، دا به لږترلږه ځینې خطرونه لرې کړي. او که کوم احتمالي بګ شتون ولري ، زه به همدا اوس د هغې په اړه پوه شم ، دا په لفظي ډول په څو دقیقو کې. زه اړتیا نلرم چې 3 میاشتې بیرته وګرځم. زه به یوازې 2 دقیقو بیرته راوګرځم. د کافي ښه ماشین به حتی په 2 دقیقو کې د کافي څښلو لپاره وخت ونه لري ، نو دا خورا ښه دی.
دا ارزښت لري چې دا په هره پروژه کې وخت په وخت تکرار کیدی شي، د بیلګې په توګه. نه یوازې هغه چې تاسو یې تنظیم کړی. تاسو کولی شئ پخپله دواړه تمرینونه تکرار کړئ او پخپله CI به د هر نوي بدلون لپاره تکرار شي چې تاسو په پروژه کې رامینځته کوئ. دا تاسو ته اجازه درکوي سرچینې اصلاح کړئ ځکه چې ستاسو ټیم ډیر اغیزمن کار کوي. تاسو به نور داسې وضعیت ونه لرئ چیرې چې تاسو ته د هغه کوډ څخه بګ راځي چې تاسو 3 میاشتې دمخه ورسره کار کړی و. تاسو به نور د شرایطو بدلون ونه لرئ کله چې تاسو ناست یاست او لومړی دوه ساعته هڅه کوئ چې پوه شئ چې څه پیښ شوي او د شرایطو جوهر ته ورشئ مخکې لدې چې تاسو د یو څه سم کول پیل کړئ.
موږ څنګه کولی شو د دې تمرین بریالیتوب یا ناکامي اندازه کړو؟ که تاسو لوی باس ته راپور ورکړئ چې موږ د CI پروژه کې څه پلي کړي، هغه د بلا بله بله اوري. موږ دا پلي کړل، سمه ده، مګر ولې، دا موږ ته څه راوړي، موږ یې څنګه اندازه کوو، موږ یې په سمه توګه یا په غلط ډول پلي کوو؟
لومړی دا چې ، د CI څخه مننه ، موږ کولی شو ډیر ځله ځای په ځای کړو ، او ډیر ځله دقیقا ځکه چې زموږ کوډ په احتمالي توګه ډیر مستحکم دی. په ورته ډول، زموږ د غلطۍ موندلو وخت کم شوی او د دې غلطۍ سمولو وخت دقیقا د دې دلیل لپاره کم شوی چې موږ د سیسټم څخه ځواب ترلاسه کوو همدا اوس او همدا اوس، زموږ په کوډ کې څه غلط دی.
بل تمرین چې موږ یې لرو د اتوماتیک ازموینې تمرین دی، کوم چې ډیری وختونه د CI تمرین سره راځي. دوی لاس په لاس ځي.
دلته د پوهیدو لپاره څه مهم دي؟ دا مهمه ده چې پوه شئ چې زموږ ازموینې توپیر لري. او هر اتوماتیک ازموینه د خپلو ستونزو حل کولو په هدف دی. موږ د بیلګې په توګه، د واحد ازموینې لرو چې موږ ته اجازه راکوي چې په جلا توګه ماډل ازموینه وکړو، د بیلګې په توګه. دا څنګه په خلا کې کار کوي؟ دا ښه دی.
موږ د ادغام ازموینې هم لرو چې موږ ته اجازه راکوي پوه شو چې مختلف ماډلونه څنګه یو له بل سره مدغم کیږي. دا هم ښه ده.
موږ ممکن د UI اتومات ازموینې ولرو چې موږ ته اجازه راکوي وګورو چې د UI سره کار څومره د پیرودونکي لخوا ټاکل شوي ځانګړي اړتیاوې پوره کوي ، او داسې نور.
هغه ځانګړي ازموینې چې تاسو یې پرمخ وړئ کولی شي تاثیر وکړي چې تاسو یې څو ځله پرمخ وړئ. د واحد ازموینې معمولا لنډ او کوچني لیکل کیږي. او دوی په منظم ډول پیل کیدی شي.
که موږ د UI اتومات ازموینې په اړه وغږیږو ، نو دا ښه ده که ستاسو پروژه کوچنۍ وي. ستاسو د UI اتومات ازموینې کولی شي یو څه مناسب وخت ونیسي. مګر معمولا د UI اتومات ازموینه هغه څه دي چې په لویه پروژه کې څو ساعته وخت نیسي. او دا ښه ده که دا څو ساعته وي. یوازینی شی دا دی چې د هرې جوړونې لپاره د دوی چلولو کې هیڅ معنی نشته. دا د شپې لخوا د دوی چلول معنی لري. او کله چې هرڅوک په سهار کې کار ته راغلل: دواړه ټیسټران او پراختیا کونکي، دوی یو ډول راپور ترلاسه کړ چې موږ د شپې د UI اتوماتیک ازموینه واخیسته او دا پایلې یې ترلاسه کړې. او دلته، د یو سرور یو ساعت کار چې وګوري چې ستاسو محصول ځینې اړتیاوې پوره کوي د ورته QA انجنیر د یو ساعت کار په پرتله خورا ارزانه وي، حتی که هغه د QA ځوان انجنیر وي چې د خواړو او مننه لپاره کار کوي. په ورته ډول، د ماشین عملیات یو ساعت به ارزانه وي. له همدې امله دا معنی لري چې پدې کې پانګه اچونه وکړئ.
زه بله پروژه لرم چې زه پرې کار کوم. موږ په دې پروژه کې دوه اونۍ سپرینونه درلودل. پروژه لویه وه، د مالي سکټور لپاره مهمه وه، او هیڅ غلطی نشو کولی. او د دوه اونیو سپرینټ وروسته، د پراختیا دوره د ازموینې پروسې تعقیب شوه، کوم چې نور 4 اونۍ وخت واخیست. هڅه وکړئ د تراژیدي پیمانه تصور کړئ. موږ د دوو اونیو لپاره کوډ لیکو، بیا موږ دا د ala CodeFreeze کوو، دا د غوښتنلیک په نوې نسخه کې بسته بندي کوو، او ازموینه کونکو ته یې وړاندې کوو. ټیسټران دا د نورو 4 اونیو لپاره ازموینه کوي، د بیلګې په توګه. پداسې حال کې چې دوی دا ازموینه کوي، موږ وخت لرو چې د دوی لپاره دوه نورې نسخې چمتو کړو. دا واقعا یوه غمجنه قضیه ده.
او موږ دوی ته وویل چې که تاسو غواړئ ډیر ګټور اوسئ ، نو دا ستاسو لپاره معنی لري چې د اتوماتیک ازموینې تمرینونه پلي کړئ ، ځکه چې دا هغه څه دي چې تاسو دلته همدا اوس درد کوي.
د دوامداره ګمارنې تمرین وکړئ. ښه، تاسو جوړ کړی دی. دا لا دمخه ښه دی. ستاسو کوډ تالیف شوی. اوس دا به ښه وي چې دا جوړښت په یو څه چاپیریال کې ځای په ځای کړئ. راځئ چې د پراختیا کونکو لپاره په چاپیریال کې ووایو.
ولې دا مهمه ده؟ لومړی، تاسو کولی شئ وګورئ چې تاسو پخپله د ګمارنې پروسې سره څومره بریالي یاست. ما د دې په څیر پروژې لیدلي، کله چې ما پوښتنه وکړه: "تاسو د غوښتنلیک نوې نسخه څنګه ځای په ځای کوئ؟"، هلکانو ما ته وویل: "موږ یې راټولوو او په زپ آرشیف کې یې بسته کوو. موږ دا د بریښنالیک له لارې مدیر ته لیږو. مدیر دا آرشیف ډاونلوډ او پراخوي. او ټول دفتر په دعا پیل کوي چې سرور به نوې نسخه غوره کړي.
راځئ چې د یو څه ساده سره پیل وکړو. د مثال په توګه، دوی په آرشیف کې د CSS ایښودل هیر کړي یا د جاوا سکریپټ فایل نوم کې د هشټاګ بدلول هیر کړي. او کله چې موږ سرور ته غوښتنه کوو، براوزر فکر کوي چې دا دمخه د جاوا سکریپټ فایل لري او پریکړه کوي چې دا ډاونلوډ نه کړي. او یو زوړ نسخه وه، یو څه ورک و. په عموم کې، ډیری ستونزې شتون لري. له همدې امله، د دوامداره ګمارنې تمرین تاسو ته اجازه درکوي لږترلږه ازموینه وکړئ چې څه به پیښ شي که تاسو د پاکې حوالې عکس اخیستی او په بشپړ ډول پاک نوي چاپیریال ته یې اپلوډ کړئ. تاسو کولی شئ وګورئ چې دا چیرته ځي.
همچنان ، کله چې تاسو د یو بل ترمینځ کوډ مدغم کړئ ، د مثال په توګه د کمانډ تر مینځ، دا تاسو ته اجازه درکوي چې دا هم وګورئ چې دا په UI کې څنګه ښکاري.
یو له هغو ستونزو څخه چې پیښیږي چیرې چې ډیری وینیلا جاوا سکریپټ کارول کیږي دا دي چې دوه پراختیا کونکو په ګړندۍ توګه د کړکۍ اعتراض کې د ورته نوم سره متغیر اعلان کړ. او بیا، ستاسو په قسمت پورې اړه لري. د چا د جاوا سکریپټ فایل دوهمه ایستل کیږي د بل بدلونونه به له سره لیکي. دا هم ډیره په زړه پوری ده. تاسو دننه شئ: یو شی د یو کس لپاره کار کوي، بل د بل لپاره کار نه کوي. او دا "په زړه پوری" دی کله چې دا ټول په تولید کې راځي.
راتلونکی تمرین چې موږ یې لرو د اتوماتیک بیا رغولو تمرین دی، د بیلګې په توګه د غوښتنلیک پخوانۍ نسخې ته بیرته راګرځول.
ولې دا د پراختیا کونکو لپاره مهم دی؟ اوس هم داسې کسان شته چې د 90 لسیزې لرې، لرې په یاد لري، کله چې کمپیوټر لوی و او پروګرامونه کوچني وو. او د ویب پراختیا یوازینۍ لار د PHP له لارې وه. دا نده چې پی ایچ پی یوه خرابه ژبه ده، که څه هم دا ده.
خو ستونزه بل ډول وه. کله چې موږ د خپل پی ایچ پی سایټ نوې نسخه ځای په ځای کړه، موږ دا څنګه ځای پرځای کړل؟ ډیری وختونه موږ د لرې مدیر یا بل څه خلاص کړل. او دا فایلونه یې FTP ته اپلوډ کړل. او موږ ناڅاپه پوه شو چې موږ یو څه کوچنۍ ، کوچنۍ بګ لرو ، د مثال په توګه ، موږ د سیمیکولون ایښودل هیر کړل یا د ډیټابیس لپاره پاسورډ بدلول هیر کړل ، او د ډیټابیس لپاره پاسورډ شتون لري ، کوم چې په محلي کوربه کې دی. او موږ پریکړه کوو چې ژر تر ژره د FTP سره وصل شو او فایلونه سمدلاسه ایډیټ کړو. دا یوازې اور دی! دا هغه څه دي چې په 90s کې مشهور وو.
مګر، که تاسو کیلنڈر ته نه وي کتلی، نو 90 شاوخوا 30 کاله وړاندې وو. اوس هر څه یو څه بل ډول پیښیږي. او هڅه وکړئ د تراژیدۍ پیمانه تصور کړئ کله چې دوی تاسو ته ووایی: "موږ تولید ته ځای په ځای شوي یو ، مګر هلته یو څه غلط شو. دلته ستاسو د FTP ننوتل او پاسورډ دی، تولید سره وصل کړئ او ژر تر ژره یې هلته حل کړئ. که تاسو چک نوریس یاست، دا به کار وکړي. که نه، نو بیا تاسو خطر لرئ چې که تاسو یوه بګ حل کړئ، تاسو به 10 نور جوړ کړئ. دا دقیقا د دې لپاره چې پخوانۍ نسخې ته بیرته ستنیدل تاسو ته اجازه درکوي ډیر څه ترلاسه کړئ.
حتی که یو څه بد څه په یو ځای کې تولید ته راشي، نو دا بد دی، مګر وژونکی ندی. تاسو کولی شئ بیرته مخکینۍ نسخه ته لاړ شئ چې تاسو یې لرئ. دې ته بیک اپ ووایاست ، که چیرې دا په دې اصطلاحاتو کې درک کول اسانه وي. تاسو کولی شئ دې پخوانۍ نسخې ته بیرته راشئ، او کاروونکي به بیا هم د دې توان ولري چې ستاسو د محصول سره کار وکړي، او تاسو به کافي بفر وخت ولرئ. تاسو کولی شئ په آرامۍ سره، پرته له ګړندي، دا ټول واخلئ او په محلي ډول یې ازموینه وکړئ، دا یې حل کړئ، او بیا نوې نسخه اپلوډ کړئ. دا واقعیا د دې کولو لپاره معنی لري.
اوس راځئ هڅه وکړو چې په یو څه ډول دوه پخواني عملونه سره یوځای کړو. موږ به دریم ترلاسه کړو چې د خوشې مدیریت په نوم یادیږي.
کله چې موږ په کلاسیک شکل کې د دوامداره تعیین په اړه خبرې کوو، موږ وایو چې موږ باید د ذخیره کولو څخه د یوې څانګې څخه کوډ راوباسئ، هغه یې تالیف کړئ او ځای په ځای کړئ. دا ښه ده که موږ ورته چاپیریال ولرو. که موږ څو چاپیریالونه ولرو، دا پدې مانا ده چې موږ باید هر ځل کوډ راوباسئ، حتی د ورته ژمنې څخه. موږ به دا هر وخت وباسو، هر ځل به یې جوړ کړو او نوي چاپیریال ته به یې ځای په ځای کړو. لومړی، دا وخت دی، ځکه چې د یوې پروژې جوړولو لپاره، که تاسو لوی لرئ او د 90 لسیزې څخه راغلی یاست، نو دا څو ساعته وخت نیسي.
برسېره پر دې، یو بل غم دی. کله چې تاسو جوړ کړئ، حتی په ورته ماشین کې، تاسو به ورته سرچینې جوړ کړئ، تاسو لاهم هیڅ تضمین نلرئ چې دا ماشین په ورته حالت کې وي لکه څنګه چې د وروستي جوړونې پرمهال و.
راځئ چې ووایو یو څوک راغلی او ستاسو لپاره یې DotNet تازه کړی یا په برعکس ، یو چا پریکړه کړې چې یو څه حذف کړي. او بیا تاسو ادراکي اختلاف لرئ چې د دې ژمنې څخه دوه اونۍ دمخه موږ یو ساختمان جوړوو او هرڅه سم وو، مګر اوس داسې ښکاري چې ورته ماشین، ورته ژمنې، ورته کوډ چې موږ یې د جوړولو هڅه کوو، مګر دا کار نه کوي. . تاسو به د دې سره د اوږدې مودې لپاره معامله کوئ او دا حقیقت ندی چې تاسو به یې ومومئ. لږترلږه، تاسو به خپل اعصاب ډیر خراب کړئ.
له همدې امله، د ریلیز مدیریت تمرین وړاندیز کوي چې یو اضافي خلاصون معرفي کړي چې د هنري آثارو ذخیره یا ګالري یا کتابتون نومیږي. تاسو کولی شئ دا هر څه چې تاسو یې غواړئ غږ کړئ.
اصلي نظر دا دی چې هرڅومره ژر چې موږ هلته یو ډول ژمنې ولرو ، ووایه ، په یوه څانګه کې چې موږ چمتو یو چې خپل مختلف چاپیریال ته ځای په ځای کړو ، موږ له دې ژمنې څخه غوښتنلیکونه راټولوو او هرڅه چې موږ د دې غوښتنلیک لپاره اړتیا لرو ، موږ یې بسته کوو. په زپ آرشیف کې وساتئ او په یو معتبر ذخیره کې یې وساتئ. او د دې ذخیرې څخه موږ کولی شو دا زپ آرشیف هر وخت ترلاسه کړو.
بیا موږ دا اخلو او په اتوماتيک ډول یې د dev چاپیریال ته ځای په ځای کوو. موږ هلته سیالي کوو، او که هرڅه ښه وي، نو موږ مرحلې ته ځای په ځای کوو. که هرڅه سم وي، نو بیا موږ ورته آرشیف تولید ته ځای په ځای کوو، ورته بائنریونه، په سمه توګه یو ځل تالیف شوي.
سربیره پردې، کله چې موږ د دې په څیر ګالري لرو، دا موږ سره د خطرونو په نښه کولو کې هم مرسته کوي چې موږ په وروستي سلایډ کې په ګوته کړي کله چې موږ پخوانۍ نسخې ته د رول بیک په اړه خبرې وکړې. که تاسو په ناڅاپي ډول یو څه غلط ځای په ځای کړی وي ، تاسو کولی شئ تل د دې ګالري څخه کوم بل پخوانۍ نسخه واخلئ او په ورته ډول دې چاپیریالونو ته بې ځایه کړئ. دا تاسو ته اجازه درکوي په اسانۍ سره پخوانۍ نسخې ته بیرته راشئ که چیرې یو څه غلط شي.
یو بل لوی تمرین دی. تاسو او زه ټول پوهیږو چې کله موږ خپل غوښتنلیکونه پخوانۍ نسخې ته واړوو، نو دا پدې معنی ده چې موږ د پخوانۍ نسخې زیربنا ته هم اړتیا لرو.
کله چې موږ د مجازی زیربنا په اړه وغږیږو، ډیری خلک فکر کوي چې دا هغه څه دي چې اداره یې جوړه کړې. او که تاسو اړتیا لرئ ، ووایاست ، د نوي سرور ترلاسه کولو لپاره چې تاسو غواړئ د خپل غوښتنلیک نوې نسخه ازموینه وکړئ ، نو تاسو باید مدیرانو یا ډیوپس ته ټکټ ولیکئ. Devops به د دې لپاره 3 اونۍ وخت ونیسي. او د 3 اونیو وروسته به دوی تاسو ته ووایي چې موږ ستاسو لپاره یو مجازی ماشین نصب کړی، یو کور، دوه ګیګابایټ RAM او د وینډوز سرور پرته له DotNet. تاسو ووایاست: "مګر ما ډاټ نیټ غوښتل." دوی: "ښه، په 3 اونیو کې بیرته راشئ."
نظر دا دی چې د کوډ تمرینونو په توګه د زیربنا کارولو سره، تاسو کولی شئ خپل مجازی زیربنا یوازې د بلې سرچینې په توګه چلند وکړئ.
شاید، که ستاسو څخه څوک په DotNet کې غوښتنلیکونه رامینځته کوي، تاسو ممکن د یو کتابتون په اړه اوریدلي وي چې د وجود چوکاټ نومیږي. او تاسو ممکن حتی اوریدلي وي چې د ادارې چوکاټ یو له هغه لارو څخه دی چې مایکروسافټ په فعاله توګه فشار راوړي. د ډیټابیس سره د کار کولو لپاره، دا یو طریقه ده چې د کوډ لومړی نومیږي. دا هغه وخت دی چې تاسو په کوډ کې تشریح کوئ چې تاسو څنګه غواړئ خپل ډیټابیس وګورئ. او بیا تاسو غوښتنلیک ځای په ځای کړئ. دا د ډیټابیس سره نښلوي، دا پخپله ټاکي چې کوم میزونه شتون لري او کوم میزونه ندي، او هرڅه چې تاسو ورته اړتیا لرئ رامینځته کوي.
تاسو کولی شئ د خپل زیربنا سره ورته کار وکړئ. پدې کې هیڅ توپیر نشته چې ایا تاسو د پروژې لپاره ډیټابیس ته اړتیا لرئ یا ایا تاسو د پروژې لپاره وینډوز سرور ته اړتیا لرئ. دا یوازې یوه سرچینه ده. او تاسو کولی شئ د دې سرچینې رامینځته کول اتومات کړئ ، تاسو کولی شئ د دې سرچینې ترتیب اتومات کړئ. په دې اساس، هرکله چې تاسو غواړئ یو څه نوي مفهوم، یو څه نوې طریقه و ازموئ، تاسو به اړتیا ونلرئ چې ډیوپس ته ټکټ ولیکئ، تاسو کولی شئ په ساده ډول د چمتو شوي ټیمپلیټونو څخه، د چمتو شوي سکریپټونو څخه د ځان لپاره یو جلا زیربنا ځای پرځای کړئ او پلي یې کړئ. هلته ستاسو ټولې تجربې. تاسو کولی شئ دا حذف کړئ، ځینې پایلې ترلاسه کړئ او د دې په اړه نور راپور ورکړئ.
راتلونکی تمرین، چې هم شتون لري او هم مهم دی، مګر چې لږ خلک یې کاروي، د غوښتنلیک د فعالیت څارنه ده.
ما غوښتل د غوښتنلیک د فعالیت نظارت په اړه یوازې یو شی ووایم. د دې تمرین په اړه خورا مهم څه دي؟ دا هغه څه دي چې د غوښتنلیک فعالیت نظارت د اپارتمان ترمیم کولو په څیر دی. دا وروستی حالت نه دی، دا یوه پروسه ده. تاسو اړتیا لرئ چې دا په منظمه توګه ترسره کړئ.
په ښه توګه، دا به ښه وي چې د غوښتنلیک د فعالیت څارنه په نږدې هر جوړښت کې ترسره کړئ، که څه هم، لکه څنګه چې تاسو پوهیږئ، دا تل ممکن نه وي. مګر، لږترلږه، دا باید د هرې خوشې کولو لپاره ترسره شي.
ولې دا مهمه ده؟ ځکه چې که تاسو ناڅاپه په فعالیت کې کمښت تجربه کړئ ، نو تاسو اړتیا لرئ په روښانه ډول پوه شئ چې ولې. که ستاسو ټیم دوه اونۍ سپرینټونه ولري، ووایه، نو بیا لږترلږه په هرو دوو اونیو کې یو ځل تاسو باید خپل غوښتنلیک یو جلا سرور ته ځای په ځای کړئ، چیرې چې تاسو په واضح ډول ثابت پروسیسر، RAM، ډیسکونه، او نور لرئ او د ورته فعالیت ازموینې پرمخ وړئ. . تاسو پایله ترلاسه کوئ. وګورئ چې دا د تیر سپرنټ څخه څنګه بدل شوی.
او که تاسو ومومئ چې کمښت په کوم ځای کې په ګړندۍ توګه ښکته شوی ، نو دا به پدې معنی وي چې دا یوازې د تیرو دوه اونیو په اوږدو کې د بدلونونو له امله و. دا به تاسو ته اجازه درکړي چې ستونزه په چټکۍ سره وپیژني او حل کړي. او بیا، دا تقریبا ورته میټریکونه دي چې تاسو یې اندازه کولی شئ په بریالیتوب سره یې ترسره کړئ.
راتلونکی تمرین چې موږ یې لرو د ترتیب مدیریت تمرین دی. ډیر لږ دي چې دا په جدي توګه اخلي. مګر په ما باور وکړئ، دا واقعیا خورا جدي شی دی.
په دې وروستیو کې یوه مسخره کیسه وه. هلکان ما ته راغلل او ویې ویل: "زموږ سره د غوښتنلیک د امنیت پلټنې په ترسره کولو کې مرسته وکړئ." موږ د اوږدې مودې لپاره کوډ ته وکتل، دوی ما ته د غوښتنلیک په اړه وویل، ډیاګرامونه یې رسم کړل. او جمع یا منفي هرڅه منطقي ، د پوهیدو وړ ، خوندي وو ، مګر یو خو شتون درلود! دوی د دوی د سرچینې کنټرول کې د ترتیب کولو فایلونه درلودل، په شمول د IP ډیټابیس سره د تولید څخه، د دې ډیټابیسونو سره د نښلولو لپاره د ننوتلو او پاسورډونو سره، او نور.
او زه وایم: "هلکانو، سمه ده، تاسو د خپل تولید چاپیریال د فایر وال سره تړلی دی، مګر دا حقیقت چې تاسو د سرچینې کنټرول کې د تولید ډیټابیس لپاره ننوت او پټنوم لرئ او کوم پرمخ وړونکی کولی شي لوستل شي دا دمخه یو لوی امنیتي خطر دی. . او مهمه نده چې ستاسو غوښتنلیک د کوډ له نظره څومره خورا خوندي وي ، که تاسو دا د سرچینې کنټرول کې پریږدئ ، نو تاسو به هیڅکله هیڅ پلټنه له کوم ځای څخه تیر نه کړئ. دا هغه څه دي چې زه یې په اړه خبرې کوم.
د تنظیم کولو مدیریت. موږ ممکن په مختلف چاپیریال کې مختلف ترتیبات ولرو. د مثال په توګه، موږ ممکن د QA، ډیمو، تولید چاپیریال، او داسې نورو لپاره ډیټابیسونو لپاره مختلف ننوتل او پاسورډونه ولرو.
دا ترتیب هم اتومات کیدی شي. دا باید تل د غوښتنلیک څخه جلا وي. ولې؟ ځکه چې تاسو یو ځل اپلیکیشن جوړ کړی، او بیا غوښتنلیک پروا نه کوي چې ایا تاسو د داسې او داسې IP یا داسې او داسې IP له لارې د SQL سرور سره وصل یاست، دا باید ورته کار وکړي. له همدې امله ، که چیرې په ناڅاپه ستاسو څخه یو څوک لاهم په کوډ کې د پیوستون تار هارډ کوډ کوي ، نو په یاد ولرئ چې زه به تاسو ومومئ او تاسو ته به سزا درکړم که تاسو زما سره په ورته پروژه کې ومومئ. دا تل په جلا ترتیب کې ځای پرځای کیږي، د بیلګې په توګه، په web.config کې.
او دا ترتیب دمخه په جلا توګه اداره شوی ، د بیلګې په توګه دا دقیقا هغه شیبه ده کله چې پراختیا کونکی او مدیر کولی شي راشي او په ورته خونه کې ناست وي. او پراختیا کونکی کولی شي ووایی: "وګورئ ، دلته زما د غوښتنلیک بائنریونه دي. دوی کار کوی. غوښتنلیک د کار کولو لپاره ډیټابیس ته اړتیا لري. دلته د بائنری تر څنګ یو فایل دی. په دې فایل کې، دا ساحه د ننوتلو مسولیت لري، دا د پټنوم لپاره دی، دا د IP لپاره دی. په هر ځای کې یې ځای پرځای کړئ." او دا د مدیر لپاره ساده او روښانه دی. هغه کولی شي دا د دې ترتیب په اداره کولو سره واقعیا هرچیرې ځای په ځای کړي.
او وروستی تمرین چې زه غواړم په اړه یې وغږیږم یو عمل دی چې د بادل سره خورا ډیر تړاو لري. او دا اعظمي تاثیر راوړي که تاسو په بادل کې کار کوئ. دا ستاسو د چاپیریال اتوماتیک لرې کول دي.
زه پوهیږم چې پدې کنفرانس کې ډیری خلک شتون لري د ټیمونو څخه چې زه ورسره کار کوم. او د ټولو ټیمونو سره چې زه ورسره کار کوم، موږ دا تمرین کاروو.
ولې؟ البته، دا به ښه وي که هر یو پرمخ وړونکي یو مجازی ماشین ولري چې 24/7 کار وکړي. مګر شاید دا تاسو ته خبر وي، شاید تاسو پام نه وي کړی، مګر پراختیا کونکی پخپله 24/7 کار نه کوي. یو پرمخ وړونکی معمولا په ورځ کې 8 ساعته کار کوي. حتی که هغه ژر کار ته راشي، هغه د غرمې ډوډۍ لري چې په جریان کې هغه جم ته ځي. اجازه راکړئ چې په ورځ کې 12 ساعته وي کله چې پراختیا کونکي واقعیا دا سرچینې کاروي. زموږ د قانون له مخې، موږ په اونۍ کې له 5 ورځو څخه 7 لرو چې کاري ورځې ګڼل کیږي.
په دې اساس، د اونۍ په ورځو کې دا ماشین باید 24 ساعته کار ونه کړي، مګر یوازې 12، او د اونۍ په پای کې باید دا ماشین کار ونه کړي. داسې ښکاري چې هرڅه خورا ساده دي، مګر دلته څه ویل مهم دي؟ په دې اساسي مهالویش کې د دې ساده تمرین په پلي کولو سره، دا تاسو ته اجازه درکوي چې د دې چاپیریال ساتلو لګښت 70٪ راټیټ کړي، د بیلګې په توګه تاسو د خپل dev، QA، ډیمو، چاپیریال قیمت اخیستی او دا یې په 3 ویشلی.
پوښتنه دا ده چې د پاتې پیسو سره څه وکړي؟ د مثال په توګه، پراختیا کونکي باید ReSharper واخلي که دوی لا دمخه نه وي. یا د کاکټیل ګوند ولرئ. که تاسو دمخه یو چاپیریال درلود چې په هغه کې dev او QA دواړه څرلي، او دا دی، اوس تاسو کولی شئ 3 مختلف جوړ کړئ چې جلا به وي، او خلک به د یو بل سره مداخله ونه کړي.
د دوامداره فعالیت اندازه کولو سره د سلایډ په اړه، موږ څنګه کولی شو فعالیت پرتله کړو که موږ په پروژه کې ډیټابیس کې 1 ریکارډونه درلودل، دوه میاشتې وروسته یو ملیون شتون لري؟ څنګه پوه شو چې ولې او د فعالیت اندازه کولو نقطه څه ده؟
دا یوه ښه پوښتنه ده، ځکه چې تاسو باید تل د ورته سرچینو فعالیت اندازه کړئ. دا دی، تاسو نوی کوډ راوباسئ، تاسو په نوي کوډ کې فعالیت اندازه کوئ. د مثال په توګه، تاسو اړتیا لرئ د مختلف فعالیت سناریو ازموینه وکړئ، راځئ چې ووایو چې تاسو غواړئ ازموینه وکړئ چې غوښتنلیک څنګه په سپک بار کې ترسره کوي، چیرته چې 1 کاروونکي شتون لري او د ډیټابیس اندازه 000 ګیګابایټ ده. تاسو یې اندازه کړې او شمیرې یې ترلاسه کړې. بیا موږ یو بل سناریو اخلو. د مثال په توګه، 5 کاروونکي، د ډیټابیس اندازه 5 terabyte. موږ پایلې ترلاسه کړې او دوی یې یاد کړل.
دلته څه مهم دي؟ دلته مهمه خبره دا ده چې د سناریو پورې اړه لري، د معلوماتو حجم، د یوځل کاروونکو شمیر، او داسې نور، تاسو ممکن ځینې محدودیتونو ته ورسیږئ. د مثال په توګه، د شبکې کارت حد ته، یا د هارډ ډرایو محدودیت، یا د پروسیسر ظرفیتونو حد ته. دا هغه څه دي چې ستاسو د پوهیدو لپاره مهم دي. په مختلفو سناریوګانو کې تاسو ځینې محدودیتونو ته ځئ. او تاسو اړتیا لرئ په شمیرو پوه شئ کله چې تاسو یې ووهئ.
ایا موږ د ځانګړي ازموینې چاپیریال کې د فعالیت اندازه کولو په اړه خبرې کوو؟ یعني دا تولید نه دی؟
هو ، دا تولید ندی ، دا د ازموینې چاپیریال دی ، کوم چې تل ورته وي نو تاسو کولی شئ دا د تیرو اندازه کولو سره پرتله کړئ.
پوه شو مننه!
که کومه پوښتنه نه وي، زه فکر کوم چې موږ کولی شو پای ته ورسوو. له تاسو مننه!
سرچینه: www.habr.com