چلند IaC (د کوډ په توګه زیربنا) نه یوازې د هغه کوډ څخه جوړه ده چې په ذخیره کې ساتل کیږي، بلکې د خلکو او پروسو څخه هم شامل دي چې د دې کوډ شاوخوا ګرځي. ایا دا ممکنه ده چې د سافټویر پراختیا څخه د زیربنا مدیریت او توضیحاتو ته د تګلارې بیا کار واخیستل شي؟ دا به ښه نظر وي چې دا نظر په ذهن کې وساتئ پداسې حال کې چې تاسو مقاله لوستلئ.
دا زما یو نقل دی په .
سلایډونه او ویډیوګانې
- وچه لوبه 2019-04-24
زیربنا د باش تاریخ په توګه
فرض کړئ چې تاسو یوې نوې پروژې ته راشئ، او دوی تاسو ته وایي: "موږ لرو د کوډ په توګه زیربنا". په حقیقت کې دا معلومه شوه زیربنا د باش تاریخ په توګه یا د مثال په توګه د باش تاریخ په توګه اسناد. دا یو ډیر ریښتینی حالت دی، د بیلګې په توګه، ورته قضیه د ډینس لیسینکو لخوا په یوه وینا کې بیان شوې ، هغه وویل چې څنګه دوی د باش تاریخ څخه د پروژې لپاره همغږي زیربنا ترلاسه کړه.
د یو څه لیوالتیا سره، موږ کولی شو ووایو زیربنا د باش تاریخ په توګه دا د کوډ په څیر دی:
- د تولید وړتیا: تاسو کولی شئ د بش تاریخ واخلئ، له هغه ځای څخه کمانډونه پرمخ وړئ، او تاسو ممکن، په لاره کې، د محصول په توګه کاري ترتیب ترلاسه کړئ.
- نسخه کول: تاسو پوهیږئ چې څوک راغلل او څه یې وکړل، بیا، دا حقیقت ندی چې دا به تاسو د کاري محصول ترتیب ته الر پیدا کړي.
- تاریخ: کیسه چې چا څه وکړل. یوازې تاسو به نشئ کولی دا وکاروئ که تاسو سرور له لاسه ورکړئ.
زه باید څه وکړم؟
د کوډ په توګه زیربنا
حتی داسې عجیب قضیه زیربنا د باش تاریخ په توګه تاسو کولی شئ دا د غوږونو لخوا راوباسئ د کوډ په توګه زیربنا، مګر کله چې موږ غواړو د ښه زوړ LAMP سرور څخه ډیر پیچلي یو څه ترسره کړو، نو موږ به دې پایلې ته ورسیږو چې دا کوډ باید یو څه تعدیل، بدل، ښه شي. بیا موږ غواړو تر منځ موازي په پام کې ونیسو د کوډ په توګه زیربنا او د سافټویر پراختیا.
وچ
د ذخیره کولو سیسټم پراختیا پروژه کې، یو فرعي کار شتون درلود : موږ یو نوی ریلیز خپروو - دا باید د نورو ازموینو لپاره راوګرځول شي. دنده خورا ساده ده:
- دلته د ssh له لارې ننوتل او کمانډ اجرا کړئ.
- فایل هلته کاپي کړئ.
- دلته تشکیل سم کړئ.
- هلته خدمت پیل کړئ
- ...
- خونديتوب!
د بیان شوي منطق لپاره، bash د کافی څخه ډیر دی، په ځانګړې توګه د پروژې په لومړیو مرحلو کې، کله چې دا یوازې پیل کیږي. دا ، مګر د وخت په تیریدو سره د ورته یو څه ځای په ځای کولو غوښتنې شتون لري ، مګر یو څه توپیر لري. لومړی شی چې ذهن ته راځي کاپي پیسټ دی. او اوس موږ دمخه دوه ورته ورته سکریپټونه لرو چې نږدې ورته کار کوي. د وخت په تیریدو سره، د سکریپټونو شمیر ډیر شو، او موږ د دې حقیقت سره مخ شو چې د نصب کولو لپاره یو ځانګړی سوداګریز منطق شتون لري چې د مختلف سکریپټونو ترمنځ همغږي کولو ته اړتیا لري، دا خورا پیچلې ده.
دا معلومه شوه چې داسې یو عمل شتون لري لکه D.R.Y. (خپل ځان مه تکراروئ). نظر د موجوده کوډ بیا کارولو لپاره دی. دا ساده ښکاري، مګر موږ سمدلاسه دې ته نه یو راغلي. زموږ په قضیه کې، دا یو ساده نظر و: د سکریپټونو څخه د ترتیبونو جلا کول. هغوی. د سوداګرۍ منطق چې څنګه نصب په جلا توګه ځای په ځای شوی دی، په جلا توګه ترتیب کوي.
S.O.L.I.D. د CFM لپاره
د وخت په تیریدو سره پروژه وده وکړه او د ځواب وړ ظهور وه. د هغې د څرګندیدو اصلي لامل دا دی چې په ټیم کې تخصص شتون لري او دا باش د پیچلي منطق لپاره ډیزاین شوی نه دی. ځواب هم د پیچلي منطق درلودل پیل کړل. د دې لپاره چې پیچلي منطق په ګډوډۍ بدل شي، د سافټویر پراختیا کې د کوډ تنظیم کولو اصول شتون لري سولیډ همچنان ، د مثال په توګه ، ګریګوري پیټروف په راپور کې "ولې د معلوماتي ټیکنالوژۍ متخصص شخصي برانډ ته اړتیا لري" دا پوښتنه راپورته کړې چې یو شخص په داسې ډول ډیزاین شوی چې د هغه لپاره د ځینې ټولنیزو ادارو سره کار کول اسانه دي ، د سافټویر پراختیا کې توکي دي. که موږ دا دوه نظرونه یوځای کړو او د دوی پراختیا ته دوام ورکړو، نو موږ به پوه شو چې موږ هم کارولی شو سولیډ د دې لپاره چې په راتلونکي کې د دې منطق ساتل او ترمیم کول اسانه کړي.
د واحد مسؤلیت اصول
هر ټولګي یوازې یوه دنده ترسره کوي.
اړتیا نشته چې د کوډ مخلوط کړئ او د monolithic الهی سپیګیټي راکشسونه جوړ کړئ. زیربنا باید د ساده خښتو څخه جوړه وي. دا معلومه شوه چې که تاسو د ځواب وړ لوبې کتاب په کوچنیو ټوټو وویشئ، د ځواب وړ رولونه ولولئ، نو بیا یې ساتل اسانه دي.
د خلاص تړلو اصول
د خلاص او تړلو اصول.
- د تمدید لپاره خلاص: پدې معنی چې د ادارې چلند د نوي وجود ډولونو رامینځته کولو سره غزیدلی شي.
- د بدلون سره تړلی: د یوې ادارې د چلند د غزولو په پایله کې، باید په هغه کوډ کې کوم بدلون نه وي چې دا ادارې کاروي.
په پیل کې ، موږ د ازموینې زیربنا په مجازی ماشینونو کې ځای په ځای کړه ، مګر د دې حقیقت له امله چې د ګمارنې سوداګرۍ منطق له پلي کیدو څخه جلا و ، موږ پرته له کومې ستونزې baremetall ته رول ورکول اضافه کړل.
د لیسکوف بدیل اصول
د باربرا لیسکوف د بدیل اصول. په برنامه کې توکي باید د برنامه سم اجرا کولو بدلولو پرته د دوی فرعي ډولونو مثالونو سره د بدلولو وړ وي
که تاسو ورته په پراخه توګه وګورو، دا د کومې ځانګړې پروژې ځانګړتیا نه ده چې هلته پلي کیدی شي سولیډ، دا عموما د CFM په اړه دی، د بیلګې په توګه، په بله پروژه کې دا اړینه ده چې د جاوا د مختلفو جاوا، غوښتنلیک سرورونو، ډیټابیسونو، OS، او نورو په سر کې د بکس شوي جاوا غوښتنلیک ځای پرځای کړئ. د دې مثال په کارولو سره، زه به نور اصول په پام کې ونیسو سولیډ
زموږ په قضیه کې، د زیربنا ټیم کې یو تړون شتون لري چې که موږ د امبجاوا یا اوریکلجاوا رول نصب کړی وي، نو موږ د جاوا بائنری اجرا وړ لرو. دا اړینه ده ځکه چې پورته رولونه پدې چلند پورې اړه لري؛ دوی د جاوا تمه لري. په ورته وخت کې، دا موږ ته اجازه راکوي چې د یو جاوا تطبیق / نسخه د بل سره د غوښتنلیک د ځای پرځای کولو منطق بدلولو پرته بدل کړو.
دلته ستونزه په دې کې ده چې په ځواب کې د دې پلي کول ناشوني دي، چې په پایله کې د ټیم دننه ځینې موافقې ښکاري.
د انٹرفیس جلا کولو اصول
د انٹرفیس جلا کولو اصول: "ډیری پیرودونکي ځانګړي انٹرفیسونه د یو عمومي هدف انٹرفیس څخه غوره دي.
په پیل کې ، موږ هڅه وکړه چې د غوښتنلیک پلي کولو ټول تغیرات په یو ځواب ورکونکي لوبو کتاب کې واچوو ، مګر دا ملاتړ کول ګران وو ، او هغه طریقه کله چې موږ بهرنۍ انٹرفیس مشخص کړو (پیرودونکي د 443 پورټ تمه لري) نو بیا زیربنا له انفرادي څخه راټول کیدی شي. د ځانګړي پلي کولو لپاره خښتې.
د انحصار انعطاف اصول
د انحصار د انعطاف اصول. په لوړو کچو کې ماډلونه باید په ټیټو کچو ماډلونو پورې اړه ونلري. دواړه ډوله ماډلونه باید په خلاصون پورې اړه ولري. خلاصون باید په جزیاتو پورې اړه ونلري. توضیحات باید په خلاصون پورې اړه ولري.
دلته مثال به د ضد نمونې پر بنسټ وي.
- د پیرودونکو څخه یو شخصي بادل درلود.
- موږ په بادل کې د مجازی ماشینونو امر وکړ.
- مګر د کلاوډ طبیعت له امله ، د غوښتنلیک ګمارل د کوم هایپروایسر سره تړلي و چې VM روان و.
هغوی. د لوړې کچې غوښتنلیک پلي کولو منطق د انحصار سره د هایپروایزر ټیټ کچې ته روان و ، او دا د دې منطق له بیا کارولو سره ستونزې درلودې. داسې مه کوئ.
متقابل عمل
د کوډ په توګه زیربنا یوازې د کوډ په اړه نه ده، بلکې د کوډ او خلکو ترمنځ د اړیکو په اړه، د زیربناوو پراختیا کونکو ترمنځ د اړیکو په اړه هم.
د بس فکتور
راځئ فرض کړئ چې تاسو په خپله پروژه کې واسیا لرئ. واسیا ستاسو د زیربنا په اړه هرڅه پوهیږي، که چیرې واسیا ناڅاپه ورک شي نو څه به پیښ شي؟ دا یو ډیر ریښتینی حالت دی، ځکه چې هغه د بس لخوا ټکر کیدی شي. ځینې وختونه دا پیښیږي. که دا پیښ شي او د کوډ په اړه پوهه، د هغې جوړښت، دا څنګه کار کوي، ظاهري بڼه او پاسورډونه د ټیم ترمنځ نه ویشل شوي، نو تاسو ممکن د یو شمیر ناخوښ حالتونو سره مخ شئ. د دې خطرونو کمولو او په ټیم کې د پوهې ویشلو لپاره، تاسو کولی شئ مختلف طریقې وکاروئ
جوړه Devopsing
داسې نه ده ، چې مدیرانو بیر وڅښل ، پاسورډونه یې بدل کړل ، او د جوړه برنامې انالوګ. هغوی. دوه انجینران په یوه کمپیوټر، یو کیبورډ کې ناست دي او ستاسو د زیربنا په یوځای کولو پیل کوي: د سرور ترتیب کول، د ځواب وړ رول لیکل، او داسې نور. دا ښه ښکاري، مګر دا زموږ لپاره کار نه کوي. مګر د دې تمرین ځانګړي قضیې کار کاوه. یو نوی کارکوونکی راځي، د هغه ښوونکی د هغه سره یوځای ریښتینې دنده ترسره کوي، کار کوي او پوهه لیږدوي.
بله ځانګړې قضیه د پیښې کال دی. د یوې ستونزې په جریان کې، د وظیفو او ښکیلو کسانو یوه ډله راټولیږي، یو مشر ټاکل کیږي، څوک چې خپله پرده شریکوي او د فکر روزل غږوي. نور برخه اخیستونکي د مشر افکار تعقیبوي، د کنسول څخه په چلونو جاسوسي کوي، وګورئ چې دوی په لاګ کې یوه کرښه له لاسه ورکړې نه ده، او د سیسټم په اړه نوي شیان زده کوي. دا طریقه د نه په پرتله ډیر ځله کار کوي.
کوډ بیاکتنه
په موضوعي توګه، دا د زیربنا په اړه د پوهې خپرولو لپاره خورا اغیزمن و او دا څنګه د کوډ بیاکتنې په کارولو سره کار کوي:
- زیربنا په ذخیره کې د کوډ لخوا تشریح شوې.
- بدلونونه په جلا څانګه کې واقع کیږي.
- د ادغام غوښتنې په جریان کې ، تاسو کولی شئ په زیربنا کې د بدلونونو ډیلټا وګورئ.
دلته مهمه خبره دا وه چې بیاکتونکي د یو مهال ویش سره سم یو یو انتخاب شوي وو، i.e. د یو څه احتمال سره تاسو به د زیربنا یوې نوې برخې ته ورشئ.
کوډ سټایل
د وخت په تیریدو سره، د بیاکتنې په جریان کې شخړه ښکاره شوه، ځکه چې ... بیاکتونکو خپل سټایل درلود او د بیاکتونکو گردش دوی د مختلف سټایلونو سره ډک کړل: 2 ځایونه یا 4 ، کیمل کیس یا سانپ_کیس. دا ممکنه نه وه چې دا سمدلاسه پلي شي.
- لومړی نظر دا و چې د لینټر کارولو وړاندیز وکړئ ، وروسته له دې ، هرڅوک انجینر دی ، هرڅوک هوښیار دی. مګر مختلف مدیران، OS، مناسب ندي
- دا په یو بوټ کې رامینځته شوی چې د هرې ستونزې ژمنې لپاره سست لیکلی او د لینټ محصول سره ضمیمه شوی. مګر په ډیری قضیو کې د کولو لپاره ډیر مهم شیان شتون درلود او کوډ غیر ثابت پاتې و.
د شنه جوړونې ماسټر
وخت تیریږي، او موږ دې پایلې ته رسیدلي یو چې هغه ژمنې چې ځینې ازموینې نه تیریږي ماسټر ته اجازه نه ورکول کیږي. وایلا! موږ د ګرین بلډ ماسټر ایجاد کړی، کوم چې د اوږدې مودې لپاره د سافټویر پراختیا کې تمرین شوی:
- پراختیا په جلا څانګه کې روانه ده.
- په دې موضوع کې ازموینې روانې دي.
- که ازموینه ناکامه شي، کوډ به دا ماسټر ته نه کړي.
دا پریکړه کول خورا دردناک وو، ځکه چې ... د ډیری تناقض لامل شو ، مګر دا د ارزښت وړ و ، ځکه ... بیاکتنې په سټایل کې توپیر پرته د ادغام لپاره غوښتنې ترلاسه کول پیل کړل ، او د وخت په تیریدو سره د ستونزو ساحو شمیر کمیدل پیل کړل.
د IaC ازموینه
د سټایل چیک کولو سربیره ، تاسو کولی شئ نور شیان وکاروئ ، د مثال په توګه ، دا چیک کړئ چې ستاسو زیربنا واقعیا ځای په ځای کولی شي. یا وګورئ چې په زیربنا کې بدلون به د پیسو ضایع کیدو لامل نشي. ولې دې ته اړتیا لیدل کیدی شي؟ پوښتنه پیچلې او فلسفه ده، دا غوره ده چې د یوې کیسې سره ځواب ووایاست چې په یو څه ډول په پاورشیل کې یو اتوماتیک سکیلر شتون درلود چې د حد شرایط یې ندي چیک کړي => ډیر VMs د اړتیا په پرتله رامینځته شوي => پیرودونکي د پلان شوي څخه ډیرې پیسې مصرف کړې. دا خورا خوندور نه دی، مګر دا به خورا ممکنه وي چې دا تېروتنه په لومړیو مرحلو کې ونیول شي.
یو څوک شاید پوښتنه وکړي، ولې پیچلې زیربنا نوره هم پیچلې کوي؟ د زیربنا لپاره ازموینې، لکه د کوډ په څیر، د ساده کولو په اړه ندي، مګر پدې پوهیدل چې ستاسو زیربنا باید څنګه کار وکړي.
د IaC ټیسټ پیرامایډ
د IaC ازموینه: جامد تحلیل
که تاسو ټول زیربناوې په یوځل کې ځای په ځای کړئ او وګورئ چې دا کار کوي، تاسو ممکن ومومئ چې دا ډیر وخت نیسي او ډیر وخت ته اړتیا لري. نو ځکه، اساس باید هغه څه وي چې په چټکۍ سره کار کوي، ډیری یې شتون لري، او دا ډیری لومړني ځایونه پوښي.
باش پیچلی دی
راځئ چې یو کوچنی مثال وګورو. په اوسني لارښود کې ټولې فایلونه غوره کړئ او بل ځای ته کاپي کړئ. لومړی شی چې ذهن ته راځي:
for i in * ; do
cp $i /some/path/$i.bak
doneکه چیرې د فایل په نوم کې ځای شتون ولري څه شی دی؟ ښه، ښه، موږ هوښیار یو، موږ پوهیږو چې د نرخونو کارولو څرنګوالی:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneډیر ښه؟ نه! څه که چیرې په لارښود کې هیڅ نه وي، د بیلګې په توګه ګلوب کول به کار ونکړي.
find . -type f -exec mv -v {} dst/{}.bak ;اوس ښه شو؟ نه... هېر مې کړه چې د دوتنې په نوم کې څه کېدای شي n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirد جامد تحلیل وسیلې
د مخکیني مرحلې ستونزه هغه وخت نیول کیدی شي کله چې موږ نرخونه هیر کړل ، د دې لپاره په طبیعت کې ډیری درملنې شتون لري. په عموم کې د دوی ډیری شتون لري، او ډیری احتمال تاسو کولی شئ د خپل IDE لاندې ستاسو د سټیک لپاره لینټ ومومئ.
ژبه
وسیله
بش
روبي
پيډون
ځواب ویونکی
د IaC ازموینه: د واحد ازموینې
لکه څنګه چې موږ د تیرې بیلګې څخه ولیدل، لیټرونه ټول ځواکمن ندي او نشي کولی ټولې ستونزې سیمې په ګوته کړي. برسېره پردې، د سافټویر پراختیا کې د ازموینې سره د انډول په واسطه، موږ کولی شو د واحد ازموینې یاد کړو. هغه څه چې سمدلاسه ذهن ته راځي , , , . مګر د ځواب ورکوونکي، شیف، مالګې سټیک او د دوی په څیر نورو سره څه وکړي؟
په پیل کې موږ په اړه خبرې وکړې سولیډ او دا چې زموږ زیربنا باید د کوچنیو خښتو څخه جوړه وي. د دوی وخت راغلی دی.
- زیربنا په کوچنیو خښتو ویشل شوې ده، د بیلګې په توګه، ځواب ورکوونکي رولونه.
- یو ډول چاپیریال ګمارل شوی ، دا ډاکر یا VM وي.
- موږ د دې ازموینې چاپیریال کې زموږ ځواب ورکوونکی رول پلي کوو.
- موږ ګورو چې هرڅه لکه څنګه چې موږ تمه درلوده کار وکړ (موږ ازموینې پرمخ وړو).
- موږ پریکړه کوو چې سمه ده یا سمه نه ده.
د IaC ازموینه: د واحد ازموینې وسیلې
پوښتنه، د CFM لپاره ازموینې څه دي؟ تاسو کولی شئ په ساده ډول سکریپټ چل کړئ، یا تاسو کولی شئ د دې لپاره چمتو شوي حلونه وکاروئ:
CFM
وسیله
ناڅاپي
مشر
مشر
مالګه
د testinfra لپاره مثال، د کاروونکو چک کول test1, test2 شتون لري او په یوه ډله کې دي sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsڅه غوره کول؟ پوښتنه پیچلې او مبهم ده، دلته د 2018-2019 لپاره د ګیتوب په پروژو کې د بدلونونو مثال دی:
د IaC ازموینې چوکاټونه
پوښتنه راپورته کیږي: دا ټول څنګه یوځای کول او پیل کول؟ کولی شي که چیرې کافي شمیر انجینران شتون ولري. یا تاسو کولی شئ چمتو شوي حلونه واخلئ، که څه هم ډیری یې شتون نلري:
CFM
وسیله
ناڅاپي
مشر
تیرافیف
د 2018-2019 لپاره په ګیتوب کې په پروژو کې د بدلونونو مثال:
مالیکول بمقابله ټیسټ کیچن
په پیل کې موږ :
- په موازي توګه VM جوړ کړئ.
- ځواب ورکوونکي رولونه پلي کړئ.
- معاینه ترسره کړئ.
د 25-35 رولونو لپاره دا د 40-70 دقیقو کار کاوه، کوم چې اوږد و.
بل ګام د جینکنز/ډاکر/انسیبل/مالیکول ته لیږد و. په ایډیولوژیک ډول هرڅه یو شان دي
- د لوبو کتابونه لینټ.
- رولونه ترتیب کړئ.
- کانټینر پیل کړئ
- ځواب ورکوونکي رولونه پلي کړئ.
- ټیسټینفرا چل کړئ.
- هوښیارتیا چیک کړئ.
د 40 رولونو لپاره لینټینګ او د درجن لپاره ازموینې شاوخوا 15 دقیقې وخت نیسي.
څه شی غوره کول په ډیری فکتورونو پورې اړه لري، لکه کارول شوي سټیک، په ټیم کې تخصص، او نور. دلته هرڅوک د ځان لپاره پریکړه کوي چې څنګه د واحد ازموینې پوښتنې بندې کړي
د IaC ازموینه: د ادغام ازموینې
د زیربنا ازموینې پیرامیډ کې بل ګام به د ادغام ازموینې وي. دوی د واحد ازموینې سره ورته دي:
- زیربنا په کوچنیو خښتو ویشل شوې ده، د بیلګې په توګه ځواب ورکوونکي رولونه.
- یو ډول چاپیریال ګمارل شوی ، دا ډاکر یا VM وي.
- د دې ازموینې چاپیریال لپاره غوښتنه وکړئ یو بنډل د ځواب ورکوونکي رولونه.
- موږ ګورو چې هرڅه لکه څنګه چې موږ تمه درلوده کار وکړ (موږ ازموینې پرمخ وړو).
- موږ پریکړه کوو چې سمه ده یا سمه نه ده.
په لنډه توګه، موږ د سیسټم د انفرادي عنصر فعالیت نه ګورو لکه څنګه چې د واحد ازموینې کې، موږ ګورو چې سرور څنګه په بشپړ ډول ترتیب شوی.
د IaC ازموینه: له پای څخه تر پای پورې ازموینې
د اهرام په پورتنۍ برخه کې موږ د پای څخه پای ازموینې ته ښه راغلاست وایو. هغوی. موږ د جلا سرور فعالیت، جلا سکریپټ، یا زموږ د زیربنا جلا خښته نه ګورو. موږ ګورو چې ډیری سرورونه یوځای سره وصل شوي، زموږ زیربنا کار کوي لکه څنګه چې موږ یې تمه کوو. له بده مرغه، ما هیڅکله چمتو شوي بکس شوي حلونه ندي لیدلي، شاید ځکه چې ... زیربنا اکثرا ځانګړی او ستونزمن وي چې نمونه جوړه کړي او د ازموینې لپاره چوکاټ رامینځته کړي. د پایلې په توګه، هرڅوک خپل حلونه جوړوي. غوښتنه شته خو ځواب نشته. له همدې امله، زه به تاسو ته ووایم چې د دې لپاره څه شتون لري چې نور د سمو افکارو لپاره فشار راوړي یا زما پوزه په دې حقیقت کې واچوي چې هرڅه زموږ څخه مخکې اختراع شوي.
یوه پروژه د بډایه تاریخ سره. دا په لویو سازمانونو کې کارول کیږي او شاید ستاسو څخه هر یو په غیر مستقیم ډول له دې سره تیریږي. غوښتنلیک د ډیری ډیټابیسونو ، ادغامونو او نورو ملاتړ کوي. پدې پوهیدل چې زیربنا څه ډول ښکاري ډیری ډاکر - کمپوز فایلونه دي ، او پدې پوهیدل چې کوم ازموینې په کوم چاپیریال کې پرمخ وړل کیږي جینکنز.
دا سکیم د اوږدې مودې لپاره کار کاوه، تر هغه چې د چوکاټ دننه موږ هڅه نه ده کړې چې دا Openshift ته انتقال کړو. کانټینرونه ورته پاتې دي، مګر د لانچ چاپیریال بدل شوی (د بیا بیا سلام DRY).
د څیړنې مفکوره نوره هم لاړه، او په پرانیستې شیف کې دوی داسې شیان وموندل لکه APB (د ځواب وړ Playbook بنډل)، کوم چې تاسو ته اجازه درکوي چې په کانټینر کې د زیربنا د ځای پرځای کولو څرنګوالي په اړه پوهه بسته کړئ. هغوی. د زیربنا د ځای پرځای کولو څرنګوالي په اړه د تکرار وړ ، د ازموینې وړ پوهه شتون لري.
دا ټول ښه ښکاري تر هغه چې موږ یو متفاوت زیربنا ته لاړ شو: موږ د ازموینو لپاره وینډوز ته اړتیا درلوده. د پایلې په توګه، د څه شی، چیرته، څنګه ځای پرځای کول، او ازموینه په جینکنز کې ده.
پایله
زیربنا لکه څنګه چې کوډ دی
- په ذخیره کې کوډ.
- د انسان تعامل.
- د زیربنا ازموینه.
تړنې
- وچه لوبه 2019-04-24
- &
سرچینه: www.habr.com