اگر آپ DevOps میں نئے ہیں، تو اپنی پہلی پائپ لائن بنانے کے لیے اس پانچ قدمی گائیڈ پر ایک نظر ڈالیں۔
DevOps سست، منقطع یا ٹوٹے ہوئے سافٹ ویئر کی ترقی کے عمل کو ٹھیک کرنے کا معیاری حل بن گیا ہے۔ مسئلہ یہ ہے کہ اگر آپ DevOps میں نئے ہیں اور نہیں جانتے کہ کہاں سے آغاز کرنا ہے، تو آپ کو ان تکنیکوں کی سمجھ کی کمی ہو سکتی ہے۔ یہ مضمون DevOps پائپ لائن کی تعریف پر بحث کرے گا اور اسے بنانے کے لیے پانچ قدمی ہدایات بھی فراہم کرے گا۔ اگرچہ یہ ٹیوٹوریل مکمل نہیں ہے، لیکن یہ آپ کو اپنا سفر شروع کرنے اور مستقبل میں اپنے علم کو بڑھانے کے لیے ایک بنیاد فراہم کرے گا۔ لیکن آئیے تاریخ سے آغاز کرتے ہیں۔
میرا DevOps سفر
میں نے پہلے Citi گروپ کلاؤڈ ٹیم پر کام کیا تھا جس میں Citi کے کلاؤڈ انفراسٹرکچر کو منظم کرنے کے لیے ایک انفراسٹرکچر-ایس-اے-سروس (IaaS) ویب ایپلیکیشن تیار کی گئی تھی، لیکن میں ہمیشہ اس بات میں دلچسپی رکھتا تھا کہ ترقی کے عمل کو مزید موثر کیسے بنایا جائے اور اس میں مثبت ثقافتی تبدیلی کیسے لائی جائے۔ ترقیاتی ٹیم. مجھے اس کا جواب Citi میں کلاؤڈ آرکیٹیکچر اور انفراسٹرکچر کے CTO گریگ لیوینڈر کی تجویز کردہ کتاب میں ملا۔ اس کتاب کا نام فینکس پروجیکٹ تھا ()، اور یہ DevOps کے اصولوں کی وضاحت کرتا ہے، لیکن یہ ایک ناول کی طرح پڑھتا ہے۔
کتاب کے پچھلے حصے میں دی گئی جدول سے پتہ چلتا ہے کہ مختلف کمپنیاں ریلیز کے ماحول میں اپنے سسٹم کو کتنی بار تعینات کرتی ہیں:
ایمیزون: 23 فی دن
گوگل: 5 فی دن
نیٹ فلکس: 500 فی دن
فیس بک: دن میں ایک بار
ٹویٹر: ہفتے میں 3 بار
عام کمپنی: ہر 9 ماہ میں ایک بار
ایمیزون، گوگل اور نیٹ فلکس فریکوئنسی کیسے ممکن ہے؟ اس کی وجہ یہ ہے کہ ان کمپنیوں نے یہ معلوم کر لیا ہے کہ تقریباً کامل DevOps پائپ لائن کیسے بنائی جائے۔
ہم اس سے بہت دور تھے جب تک کہ ہم نے Citi میں DevOps کو لاگو نہیں کیا۔ اس وقت، میری ٹیم کا ماحول مختلف تھا، لیکن ڈیولپمنٹ سرور پر تعیناتی مکمل طور پر دستی تھی۔ تمام ڈویلپرز کو IBM WebSphere Application Server Community Edition پر مبنی صرف ایک ڈویلپمنٹ سرور تک رسائی حاصل تھی۔ مسئلہ یہ تھا کہ جب بھی ایک سے زیادہ صارفین ایک ہی وقت میں تعینات کرنے کی کوشش کرتے تھے تو سرور بند ہوجاتا تھا، اس لیے ڈویلپرز کو اپنے ارادوں کو ایک دوسرے تک پہنچانا پڑتا تھا، جو کافی تکلیف دہ تھا۔ مزید برآں، کم درجے کے ٹیسٹ کوڈ کی کوریج، بوجھل دستی تعیناتی کے عمل، اور مخصوص کام یا صارف کی کہانی سے وابستہ کوڈ کی تعیناتی کو ٹریک کرنے میں ناکامی کے مسائل تھے۔
میں نے محسوس کیا کہ کچھ کرنے کی ضرورت ہے اور ایک ہم خیال ساتھی ملا۔ ہم نے ابتدائی DevOps پائپ لائن کی تعمیر میں تعاون کرنے کا فیصلہ کیا - اس نے Tomcat ورچوئل مشین اور ایپلیکیشن سرور قائم کیا جب کہ میں نے Jenkins پر کام کیا، Atlassian Jira اور BitBucket کو مربوط کیا، اور ٹیسٹ کوڈ کوریج پر کام کیا۔ یہ ضمنی منصوبہ بہت کامیاب رہا: ہم نے بہت سے عملوں کو تقریباً مکمل طور پر خودکار کیا، اپنے ڈیولپمنٹ سرور پر تقریباً 100% اپ ٹائم حاصل کیا، کوڈ کی ٹریکنگ اور بہتر ٹیسٹ کوریج فراہم کی، اور Git برانچز کو جیرا کے مسائل یا تعیناتیوں سے منسلک کرنے کی صلاحیت کو شامل کیا۔ ہم نے اپنی DevOps پائپ لائن بنانے کے لیے جو ٹولز استعمال کیے ان میں سے زیادہ تر اوپن سورس تھے۔
اب میں سمجھ گیا ہوں کہ ہماری DevOps پائپ لائن کتنی آسان تھی: ہم نے جینکنز فائلز یا جوابی جیسی ایکسٹینشنز کا استعمال نہیں کیا۔ تاہم، اس سادہ پائپ لائن نے اچھی طرح کام کیا، شاید Pareto اصول (جسے 80/20 اصول بھی کہا جاتا ہے) کی وجہ سے۔
DevOps اور CI/CD پائپ لائن کا مختصر تعارف
اگر آپ کئی لوگوں سے پوچھتے ہیں، "DevOps کیا ہے؟"، تو آپ کو شاید کئی مختلف جوابات ملیں گے۔ DevOps، Agile کی طرح، بہت سے مختلف شعبوں کو پھیلانے کے لیے تیار ہوا ہے، لیکن زیادہ تر لوگ چند چیزوں پر متفق ہوں گے: DevOps ایک سافٹ ویئر ڈویلپمنٹ پریکٹس یا سافٹ ویئر ڈویلپمنٹ لائف سائیکل (SDLC) ہے جس کا مرکزی اصول ثقافت کو تبدیل کر رہا ہے جس میں ڈویلپرز اور غیر ڈویلپرز ایسے ماحول میں موجود ہیں جس میں:
وہ آپریشن جو پہلے دستی طور پر کیے گئے تھے خودکار کر دیے گئے ہیں۔
ہر کوئی وہی کرتا ہے جو وہ بہترین کرتا ہے۔
ایک مخصوص مدت کے دوران عمل درآمد کی تعداد میں اضافہ؛ تھرو پٹ میں اضافہ؛
ترقی کی لچک میں اضافہ۔
اگرچہ ڈیو اوپس ماحول بنانے کے لیے آپ کو صرف صحیح سافٹ ویئر ٹولز کی ضرورت نہیں ہے، کچھ ٹولز ضروری ہیں۔ ایک اہم ٹول مسلسل انضمام اور مسلسل تعیناتی (CI/CD) ہے۔ اس پائپ لائن میں، ماحول کے مختلف مراحل ہوتے ہیں (جیسے DEV, INT, TST, QA, UAT, STG, PROD)، بہت سے آپریشنز خودکار ہوتے ہیں، اور ڈویلپر اعلی معیار کا کوڈ لکھ سکتے ہیں، ترقی کی چستی حاصل کر سکتے ہیں، اور اعلی تعیناتی کی شرحیں حاصل کر سکتے ہیں۔
یہ مضمون ایک DevOps پائپ لائن بنانے کے لیے پانچ قدمی نقطہ نظر کی وضاحت کرتا ہے جیسا کہ اوپن سورس ٹولز کا استعمال کرتے ہوئے درج ذیل خاکہ میں دکھایا گیا ہے۔
مرحلہ 1: CI/CD طریقے
پہلی چیز جس کی آپ کو ضرورت ہے وہ ہے CI/CD ٹول۔ جینکنز، جاوا پر مبنی ایک اوپن سورس ٹول اور MIT لائسنس کے تحت لائسنس یافتہ، وہ ٹول ہے جس نے DevOps کو مقبول بنایا اور ڈی فیکٹو سٹینڈرڈ بن گیا ہے۔
تو جینکنز کیا ہے؟ اسے کسی قسم کے جادوئی یونیورسل ریموٹ کنٹرول کے طور پر سمجھیں جو مختلف سروسز اور ٹولز سے بات کر سکتا ہے اور اسے منظم کر سکتا ہے۔ اپنے طور پر، جینکنز جیسا CI/CD ٹول بیکار ہے، لیکن یہ زیادہ طاقتور ہو جاتا ہے کیونکہ یہ مختلف ٹولز اور سروسز سے جڑتا ہے۔
جینکنز اوپن سورس CI/CD ٹولز میں سے صرف ایک ہے جسے آپ اپنی DevOps پائپ لائن بنانے کے لیے استعمال کر سکتے ہیں۔
جینکنز: تخلیقی العام اور ایم آئی ٹی
ٹریوس سی آئی: ایم آئی ٹی
کروز کنٹرول: بی ایس ڈی
بلڈ بوٹ: جی پی ایل
اپاچی گمپ: اپاچی 2.0
کیبی: جی این یو
CI/CD ٹول کے ساتھ DevOps کے عمل کی طرح نظر آتے ہیں:
آپ کے پاس اپنے لوکل ہوسٹ پر CI/CD ٹول چل رہا ہے، لیکن اس وقت آپ بہت کچھ نہیں کر سکتے۔ آئیے DevOps سفر کے اگلے مرحلے پر چلتے ہیں۔
مرحلہ 2: سورس کنٹرول سسٹمز کا نظم کریں۔
اس بات کی تصدیق کرنے کا بہترین (اور شاید سب سے آسان) طریقہ ہے کہ آپ کا CI/CD ٹول اپنا جادو کر سکتا ہے سورس کوڈ کنٹرول (SCM) ٹول کے ساتھ انضمام کرنا ہے۔ آپ کو سورس کنٹرول کی ضرورت کیوں ہے؟ مان لیں کہ آپ ایک ایپلیکیشن تیار کر رہے ہیں۔ جب بھی آپ کوئی ایپلیکیشن بناتے ہیں، آپ پروگرامنگ کر رہے ہوتے ہیں، اور اس سے کوئی فرق نہیں پڑتا کہ آپ Java، Python، C++، Go، Ruby، JavaScript، یا کروڑوں پروگرامنگ زبانوں میں سے کوئی بھی استعمال کرتے ہیں۔ آپ جو کوڈ لکھتے ہیں اسے سورس کوڈ کہتے ہیں۔ شروع میں، خاص طور پر جب آپ اکیلے کام کر رہے ہوں، تو شاید ہر چیز کو مقامی ڈائریکٹری میں ڈالنا ٹھیک ہے۔ لیکن جیسے جیسے پروجیکٹ بڑا ہوتا جاتا ہے اور آپ دوسرے لوگوں کو تعاون کی دعوت دیتے ہیں، آپ کو ترمیمات کو مؤثر طریقے سے شیئر کرتے ہوئے تنازعات کو روکنے کے لیے ایک طریقہ کی ضرورت ہوتی ہے۔ آپ کو پچھلے ورژنز کو بحال کرنے کا طریقہ بھی درکار ہے، کیونکہ بیک اپ بنانا اور ان میں کاپی/پیسٹ کرنا متروک ہوتا جا رہا ہے۔ آپ (اور آپ کے ساتھی) کو کچھ بہتر کی ضرورت ہے۔
یہ وہ جگہ ہے جہاں سورس کوڈ کنٹرول تقریباً ایک ضرورت بن جاتا ہے۔ یہ ٹول آپ کے کوڈ کو ریپوزٹریز میں اسٹور کرتا ہے، ورژنز پر نظر رکھتا ہے، اور پروجیکٹ کے شرکاء کے کام کو مربوط کرتا ہے۔
اگرچہ وہاں بہت سارے سورس کنٹرول ٹولز موجود ہیں، گٹ معیاری ہے، اور بجا طور پر۔ میں گٹ کو استعمال کرنے کی انتہائی سفارش کرتا ہوں، حالانکہ اگر آپ چاہیں تو اوپن سورس کے دیگر آپشنز موجود ہیں۔
گٹ: GPLv2 اور LGPL v2.1
بغاوت: اپاچی 2.0
کنکرنٹ ورژن سسٹم (CVS): GNU
ویسٹا: LGPL
مرکیوریل: GNU GPL v2+
سورس کوڈ کنٹرولز کے اضافے کے ساتھ ڈی او اوپس پائپ لائن کی طرح دکھائی دیتی ہے۔
ایک CI/CD ٹول جائزے، سورس کوڈ کے حصول، اور اراکین کے درمیان تعاون کے عمل کو خودکار کر سکتا ہے۔ برا نہیں ہے؟ لیکن آپ اسے ایک ورکنگ ایپلی کیشن میں کیسے تبدیل کرتے ہیں تاکہ اربوں لوگ اسے استعمال کر سکیں اور اس کی تعریف کر سکیں؟
مرحلہ 3: ایک بلڈ آٹومیشن ٹول بنائیں
زبردست! آپ کوڈ کا جائزہ لے سکتے ہیں اور سورس کنٹرول میں تبدیلیاں کر سکتے ہیں، اور اپنے دوستوں کو ڈویلپمنٹ میں تعاون کرنے کی دعوت دے سکتے ہیں۔ لیکن آپ نے ابھی تک کوئی درخواست نہیں بنائی ہے۔ ویب ایپلیکیشن بنانے کے لیے، اسے ایک قابل تعیناتی بیچ فارمیٹ میں مرتب اور پیک کیا جانا چاہیے یا ایک قابل عمل فائل کے طور پر چلایا جانا چاہیے۔ (نوٹ کریں کہ ایک تشریح شدہ پروگرامنگ زبان جیسے جاوا اسکرپٹ یا پی ایچ پی کو مرتب کرنے کی ضرورت نہیں ہے)۔
بلڈ آٹومیشن ٹول استعمال کریں۔ اس بات سے کوئی فرق نہیں پڑتا ہے کہ آپ کون سا بلڈ آٹومیشن ٹول استعمال کرنے کا فیصلہ کرتے ہیں، ان سب کا ایک ہی مقصد ہے: سورس کوڈ کو کسی مطلوبہ فارمیٹ میں بنائیں اور کسی مخصوص ماحول میں صفائی، تالیف، جانچ اور تعیناتی کے کام کو خودکار بنائیں۔ آپ کی پروگرامنگ زبان کے لحاظ سے بلڈ ٹولز مختلف ہوں گے، لیکن یہاں کچھ عام اوپن سورس آپشنز ہیں۔
نام
لائسنس
پروگرامنگ زبان
میون
اپاچی 2.0
اعلی درجے کا Java
چینٹی
اپاچی 2.0
اعلی درجے کا Java
گریڈل
اپاچی 2.0
اعلی درجے کا Java
بزل
اپاچی 2.0
اعلی درجے کا Java
بنائیں
جی این یو
N / A
گھرگھر
ایم ائی ٹی
جاوا سکرپٹ
گلپ
ایم ائی ٹی
جاوا سکرپٹ
بلڈر
اپاچی
روبی
ریک
ایم ائی ٹی
روبی
اے اے پی
جی این یو
ازگر
اسکونز
ایم ائی ٹی
ازگر
بٹ بیک
GPLv2
ازگر
کیک
ایم ائی ٹی
C#
اے ایس ڈی ایف
ایکسپیٹ (MIT)
لسپ
کیبل
BSD
ہسکیل
زبردست! آپ بلڈ آٹومیشن ٹول کنفیگریشن فائلوں کو اپنے سورس کنٹرول سسٹم میں ڈال سکتے ہیں اور اپنے CI/CD ٹول کو سب کچھ ایک ساتھ رکھ سکتے ہیں۔
سب کچھ ٹھیک ہے، ہے نا؟ لیکن آپ کی درخواست کو کہاں تعینات کرنا ہے؟
مرحلہ 4: ویب ایپلیکیشن سرور
ابھی کے لیے، آپ کے پاس ایک پیک فائل ہے جو یا تو قابل عمل یا انسٹال ہو سکتی ہے۔ کسی بھی ایپلیکیشن کے صحیح معنوں میں مفید ہونے کے لیے، اسے کسی قسم کی سروس یا انٹرفیس فراہم کرنا چاہیے، لیکن آپ کو اپنی ایپلیکیشن کی میزبانی کے لیے ایک کنٹینر کی ضرورت ہے۔
ایک ویب ایپلیکیشن سرور صرف ایک ایسا کنٹینر ہے۔ سرور ایک ایسا ماحول فراہم کرتا ہے جس میں تعینات کیے جانے والے پیکیج کی منطق کی وضاحت کی جا سکتی ہے۔ سرور ایک انٹرفیس بھی فراہم کرتا ہے اور ساکٹ کو بیرونی دنیا میں بے نقاب کرکے ویب خدمات پیش کرتا ہے۔ اسے انسٹال کرنے کے لیے آپ کو HTTP سرور کے ساتھ ساتھ کچھ ماحول (جیسے ورچوئل مشین) کی ضرورت ہے۔ ابھی کے لیے، آئیے فرض کریں کہ آپ اس کے بارے میں مزید جانیں گے (حالانکہ میں نیچے کنٹینرز کا احاطہ کروں گا)۔
کئی اوپن سورس ویب ایپلیکیشن سرورز ہیں۔
نام
لائسنس
پروگرامنگ زبان
Tomcat
اپاچی 2.0
اعلی درجے کا Java
جیٹی
اپاچی 2.0
اعلی درجے کا Java
وائلڈ فلائی
GNU کم عوامی
اعلی درجے کا Java
گلاس فش
CDDL اور GNU کم عوامی
اعلی درجے کا Java
جیانگو
3 شق BSD
ازگر
ٹورنیڈو
اپاچی 2.0
ازگر
گنکورن
ایم ائی ٹی
ازگر
ازگر
ایم ائی ٹی
ازگر
ریل
ایم ائی ٹی
روبی
Node.js
ایم ائی ٹی
جاوا سکرپٹ
آپ کی DevOps پائپ لائن استعمال کے لیے تقریباً تیار ہے۔ بہت اعلی!
جب کہ آپ وہاں رک سکتے ہیں اور خود انضمام کو سنبھال سکتے ہیں، کوڈ کا معیار ایک اہم چیز ہے جس کے بارے میں ایک ایپ ڈویلپر کو فکر کرنا ہے۔
مرحلہ 5: کوڈ ٹیسٹنگ کوریج
ٹیسٹوں کو لاگو کرنا ایک اور بوجھل ضرورت ہو سکتی ہے، لیکن ڈویلپرز کو ایپلی کیشن میں کسی بھی کیڑے کو جلد پکڑنا چاہیے اور کوڈ کے معیار کو بہتر بنانا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ آخری صارفین مطمئن ہوں۔ خوش قسمتی سے، آپ کے کوڈ کو جانچنے اور اس کے معیار کو بہتر بنانے کے لیے سفارشات دینے کے لیے بہت سے اوپن سورس ٹولز موجود ہیں۔ اس سے بھی بہتر بات یہ ہے کہ زیادہ تر CI/CD ٹولز ان ٹولز سے جڑ سکتے ہیں اور عمل کو خودکار کر سکتے ہیں۔
کوڈ ٹیسٹنگ دو حصوں پر مشتمل ہے: کوڈ ٹیسٹنگ فریم ورک جو آپ کو ٹیسٹ لکھنے اور چلانے میں مدد کرتے ہیں، اور تجویز کے ٹولز جو آپ کو اپنے کوڈ کے معیار کو بہتر بنانے میں مدد کرتے ہیں۔
کوڈ ٹیسٹنگ سسٹم
نام
لائسنس
پروگرامنگ زبان
JUnit
ایکلپس پبلک لائسنس
اعلی درجے کا Java
ایزی موک
اپاچی
اعلی درجے کا Java
موکیٹو
ایم ائی ٹی
اعلی درجے کا Java
پاور موک
اپاچی 2.0
اعلی درجے کا Java
پائیسٹ
ایم ائی ٹی
ازگر
فرضی تصور
موزیلا
ازگر
ٹاکس
ایم ائی ٹی
ازگر
کوڈ میں بہتری کے لیے تجویز کردہ نظام
نام
لائسنس
پروگرامنگ زبان
Cobertura
جی این یو
اعلی درجے کا Java
کوڈ کور
ایکلیپس پبلک (ای پی ایل)
اعلی درجے کا Java
Coverage.py
اپاچی 2.0
ازگر
یما
کامن پبلک لائسنس
اعلی درجے کا Java
جاکوکو
ایکلپس پبلک لائسنس
اعلی درجے کا Java
فرضی تصور
موزیلا
ازگر
ٹاکس
ایم ائی ٹی
ازگر
جیسمین
ایم ائی ٹی
جاوا سکرپٹ
کرما
ایم ائی ٹی
جاوا سکرپٹ
موچا
ایم ائی ٹی
جاوا سکرپٹ
جینے
ایم ائی ٹی
جاوا سکرپٹ
نوٹ کریں کہ مذکورہ بالا زیادہ تر ٹولز اور فریم ورک جاوا، ازگر اور جاوا اسکرپٹ کے لیے لکھے گئے ہیں، کیونکہ C++ اور C# ملکیتی پروگرامنگ زبانیں ہیں (حالانکہ GCC اوپن سورس ہے)۔
اب جب کہ آپ نے ٹیسٹ کوریج ٹولز کو لاگو کر دیا ہے، آپ کی DevOps پائپ لائن اس ٹیوٹوریل کے شروع میں دکھائے گئے خاکہ سے ملتی جلتی نظر آنی چاہیے۔
اضافی اقدامات
کنٹینرز
جیسا کہ میں نے کہا، آپ اپنے سرور کو ورچوئل مشین یا سرور پر ہوسٹ کر سکتے ہیں، لیکن کنٹینرز ایک مقبول حل ہیں۔
کنٹینرز کیا ہیں؟ مختصر وضاحت یہ ہے کہ ایک ورچوئل مشین کو ایپلی کیشن کے سائز سے زیادہ آپریٹنگ سسٹم میموری کی بہت زیادہ مقدار کی ضرورت ہوتی ہے، جبکہ ایک کنٹینر کو ایپلی کیشن چلانے کے لیے صرف چند لائبریریوں اور کنفیگریشنز کی ضرورت ہوتی ہے۔ ظاہر ہے، ورچوئل مشین کے لیے اب بھی اہم استعمال موجود ہیں، لیکن ایک کنٹینر ایپلی کیشن کی میزبانی کے لیے ایک ہلکا پھلکا حل ہے، بشمول ایک ایپلیکیشن سرور۔
جبکہ دیگر کنٹینر کے اختیارات موجود ہیں، سب سے زیادہ مقبول Docker اور Kubernetes ہیں۔
ڈوکر: اپاچی 2.0
کبرنیٹس: اپاچی 2.0
انٹرمیڈیٹ آٹومیشن ٹولز
ہماری DevOps پائپ لائن بنیادی طور پر باہمی تعاون کے ساتھ ایپلیکیشن کی تخلیق اور تعیناتی پر مرکوز ہے، لیکن بہت سی دوسری چیزیں ہیں جو DevOps ٹولز کے ساتھ کی جا سکتی ہیں۔ ان میں سے ایک بنیادی ڈھانچے کا بطور کوڈ (IaC) ٹولز کا استعمال ہے، جسے مڈل ویئر آٹومیشن ٹولز بھی کہا جاتا ہے۔ یہ ٹولز مڈل ویئر کے لیے خودکار تنصیب، انتظام اور دیگر کاموں میں مدد کرتے ہیں۔ لہذا، مثال کے طور پر، ایک آٹومیشن ٹول ایپلی کیشنز جیسے ویب ایپلیکیشن سرور، ڈیٹا بیس، اور مانیٹرنگ ٹول کو درست کنفیگریشن کے ساتھ نکال سکتا ہے اور انہیں ایپلیکیشن سرور پر تعینات کر سکتا ہے۔
یہاں کچھ اوپن سورس مڈل ویئر آٹومیشن ٹولز ہیں:
جواب: جی این یو پبلک
سالٹ اسٹیک: اپاچی 2.0
شیف: اپاچی 2.0
کٹھ پتلی: اپاچی یا جی پی ایل
SkillFactory سے بامعاوضہ آن لائن کورسز لے کر مہارت اور تنخواہ کے لحاظ سے شروع سے یا لیول اپ کو مطلوبہ پیشہ حاصل کرنے کے بارے میں تفصیلات معلوم کریں:
- (12 ماہ)
مزید کورسز
- (12 ہفتے)
- (12 ماہ)
- (9 ماہ)
- (9 ماہ)
استعمال کریں
ماخذ: www.habr.com