دوره آموزش پروژه محور Retrofit و LiveData در اندروید منتشر شد! جهت تهیه پیش‌فروش دوره با تخفیف ویژه کلیک کنید!  

چگونه در کمتر از شش ماه به یک مهندس دواپس (DevOps) تبدیل شویم؟ بخش سوم: نسخه

چهارشنبه ۰۶ شهریور ۹۸ توسط سالار ساری نوایی

یک مرور سریع!

پیش از هر کاری، بگذارید آن چه گفته شده است را به شکلی سریع مرور کنیم.

به طور خلاصه، این مجموعه از پست‌ها یک داستان را روایت می‌کنند. این داستان هم عبارت از این است که چگونه می‌توانیم در کمترین زمان ممکن از یک ایده درآمد کسب کنیم – پایه و اساس دواپس مدرن.

اما به طور دقیق‌تر، در بخش اول از این مجموعه درباره‌ی فرهنگ دواپس و اهداف آن صحبت کردیم.

در بخش دوم به معرفی Terraform و روش فراهم‌سازی بستر استفاده از کد در آینده به کمک آن پرداختیم.

در ادامه و به طور ویژه در این مطلب بررسی می‌کنیم که چگونه می‌توانیم بخش‌های مختلف کد را با نظم جدا از هم نگه داریم و از درهم ریختگی آن‌ها جلوگیری کنیم. اسپویلر! همه‌ی این‌ها کار گیت است. همچنین درباره‌ی روش استفاده از گیت برای ایجاد و ترویج برند شخصی خودتان نیز توضیحاتی ارائه می‌دهیم.

برای یادآوری باید اشاره کنم که در حال حاضر در این نقطه از ماجرا هستیم:

چه نیازی به این کار است؟

وقتی از نسخه‌گذاری صحبت می‌کنیم، منظورمان چیست؟

تصور کنید که در حال کار بر روی قطعه‌ای از یک نرم‌افزار هستید. دائما آن را تغییر می‌دهید و بر حسب نیاز ویژگی‌هایی را به آن اضافه می‌کنید یا از آن حذف می‌کنید. معمولا آخرین تغییری که ایجاد می‌کنید یک تغییر "شکننده" خواهد بود. به عبارتی دیگر، هر کاری که آخرین بار انجام دادید، باعث شد که زحماتی که تا آن مرحله کشیده‌ بودید از کار بیافتند.

در این صورت باید چه کاری انجام داد؟

اگر بخواهید به روش گذشته عمل کنید، احتمالا اولین قطعه کدتان را این گونه نام‌گذاری خواهید کرد:

awesome_code.p1

سپس شروع به اعمال تغییرات می‌کنید و می‌خواهید قطعه کدی که سالم‌ کار می‌کند را نگه دارید تا در صورت نیاز به سراغ آن بروید.

پس فایل کدتان را به این شکل نام‌گذاری می‌کنید:

awesome_code.01.01.2019.p1

تا این لحظه مشکلی وجود ندارد. اما ممکن است یک روز بخواهید بیش از یک تغییر اعمال کنید، پس مجبور می‌شوید که به چنین شکلی کدتان را ذخیره کنید:

awesome_code.GOOD.01.01.2019.p1

و الی آخر.

البته در یک محیط حرفه‌ای، تیم‌های متعددی به طور همزمان در حال کار بر روی یک کد پایه هستند که باعث می‌شود این مدل پیچیده‌تر از این بشود.

نیاز به گفتن ندارد که این روش پایان خوشی نخواهد داشت!

کنترل سورس کد

در این مرحله به سراغ کنترل سورس کد می‌رویم: یک روش برای نگهداری فایل‌ها در یک مکان متمرکز که در آن چندین تیم می‌توانند با یکدیگر روی یک کد پایه‌ی مشترک فعالیت کنند.

این ایده‌ی جدیدی نیست. برای اولین بار در سال 1972 از به‌کارگیری چنین روشی صحبت شد. پس این که باید کدهایمان را در یک مکان متمرکز ذخیره کنیم به هیچ وجه چیز جدیدی نیست.

با این حال چیزی که می‌توان آن را جدید نامید، ایده‌ی نسخه‌گذاری تمامی مصنوعات تولید شده است.

اما این یعنی چه؟

این یعنی هر چیزی که در محیط تولید شما به کار گرفته می‌شود باید طبق پیگیری، بررسی و تاریخچه‌ی تغییرات در کنترل نسخه ذخیره شود. علاوه بر این، پیاده‌سازی قانون "تمامی مصنوعات تولیدی باید نسخه‌گذاری شوند" باعث می‌شود که با ذهنیت اتوماسیون به سراغ مشکلات بروید.

برای نمونه، وقتی تصمیم می‌گیرید که در محیط Dev AWS خود با کلیک کردن از یک مشکل پیچیده بگذرید، ممکن است با خود فکر کنید که آیا این کلیک کردن‌ها یک مصنوع نسخه‌گذاری شده است؟

البته که جواب این سوال خیر است! با وجود این که ایجاد سریع نمونه‌های اولیه با کمک رابط کاربری برای چک کردن مشکلات ایرادی ندارد، اما این اعمال باید در زمان کوتاهی پایان بیابند. اگر قصد دارید که بلند مدت از آن استفاده کنید، مطمئن شوید که تمامی کارها را در Terraform یا یک ابزار مشابه آن انجام می‌دهید.

بسیار خب، فرض بر این است که همه چیز یک مصنوع نسخه‌گذاری شده است. حالا چگونه باید این موارد را ذخیره و مدیریت کنیم؟

جواب این سوال در گیت خلاصه می‌شود.

گیت

تا قبل از روی کار آمدن گیت، سیستم‌های کنترل سورس کد مانند SVN ساده و کاربرپسند نبودند و در مجموع تجربه‌ی جالبی به کاربر القا نمی‌کردند.

تفاوت گیت با سایرین در این است که گیت مفهوم کنترل توزیع‌شده‌ی سورس کد را به خوبی پذیرفته است.

به عبارتی دیگر، زمانی که شما در حال کار بر روی کد هستید، سایر تیم‌ها نیز قابلیت دسترسی همزمان به آن کد را دارند و سیستم برای آن‌ها قفل نمی‌شود. شما بر روی یک کپی از کد تغییرات را اعمال می‌کنید و سپس آن کپی در فضای اصلی ذخیره‌سازی ادغام می‌شود.

در نظر داشته باشید که این تنها یک توضیح بسیار ساده از طرز کار گیت است. اما برای کاربرد ما در این مطلب همین میزان کفایت می‌کند. با این حال نگاهی مفصل به طرز کار درونی گیت می‌تواند برای یک مهندس دواپس بسیار کارآمد باشد.

در حال حاضر همین را بدانید که گیت مانند SVN نیست. گیت یک سیستم کنترل سورس کد توزیع‌شده است که در آن چندین تیم می‌توانند با اطمینان روی یک کد مشترک کار کنند.

چه نیازی به این کار است؟

رک و راست بگویم، به عقیده‌ی من امکان ندارد که بدون آگاهی از طرز کار گیت بتوانید به یک مهندس دواپس حرفه‌ای تبدیل شوید. تمام!

بسیار خب، یادگیری گیت چقدر زمان می‌برد؟

متاسفانه اگر در گوگل آموزش گیت را جستجو کنید، نتایج متعدد و معمولا پیچیده‌ای به نمایش گذاشته می‌شود که می‌تواند گیج‌کننده باشد. اما آموزش‌هایی نیز وجود دارد که بسیار خوب و مفید هستند.

یکی از این مجموعه‌ها که به همه توصیه می‌کنم آن را مطالعه کنند و یاد بگیرند، آموزش‌های گیت Atlassian است. همه‌ی بخش‌های این آموزش بسیار جالب است اما یک بخش آن توسط تمامی مهندسان نرم‌افزار حرفه‌ای در سراسر دنیا استفاده می‌شود و آن هم روندهای کاری گیت است.

یکی دیگر از آموزش‌های مناسب برای گیت، Learn Git Branching است.

آموزش‌های Atlassian به صورت خواندنی و آموختنی است، در صورتی که آموزش‌های Learn Git Branching به صورت اینترکتیو است و کاربر را درگیر می‌کند. در هر صورت نیاز است که گیت را بیاموزید، چرا که بدون داشتن درک درستی از طرز کار گیت نمی‌توانید پیشرفت به خصوصی در شغلتان داشته باشید.

حس می‌کنم باز هم باید تاکید کنم! بارها و بارها اتفاق افتاده است که عدم آگاهی از ویژگی شاخه‌ای (انشعابی) گیت یا ناتوانی در توضیح طرز کار Gitflow باعث شده که کاندیداهای مهندسی دواپس در یک شرکت پذیرفته نشوند.

نکته‌ی اساسی همین است. شما می‌توانید برای مصاحبه وارد شرکت شوید و از Terraform یا ابزارهای زیرساخت به عنوان کد روز آگاهی نداشته باشید. این ایرادی ندارد. می‌توان حین کار بر آن تسلط پیدا کرد. اما ناآگاهی از گیت و طرز کار آن به مدیران اعلام می‌کند که شما درک اساسی از بهترین شیوه‌های مهندسی نرم‌افزار مدرن یا دواپس را ندارید و شیب یادگیری شما بسیار کند خواهد بود! یقینا شما هم نمی‌خواهید که چنین برداشتی از شما داشته باشند.

اما بر خلاف آن، اگر بتوانید با اعتماد به نفس از گیت و بهترین شیوه‌های کار با آن صحبت کنید، به مدیران شرکت‌ها اعلام می‌کنید که یک ذهنیت عالی برای مهندسی نرم‌افزار در اختیار دارید و این دقیقا چیزی است که شما می‌خواهید به آن‌ها نشان بدهید.

پس به طور خلاصه: نیازی نیست که حرفه‌ای‌ترین متخصص گیت باشید تا بتوانید شغل دواپس مورد نظرتان را برای خود کنید، اما باید مدتی با گیت زندگی کنید و پیچ و خم‌های آن را بدانید تا بتوانید با اعتماد به نفس درباره‌ی آن صحبت کنید و تصویر درستی از خودتان به کارفرما ارائه بدهید.

در کمترین حالت باید بتوانید کارهای زیر را انجام بدهید:

  1. یک مخزن را فورک کنید.
  2. شاخه (انشعاب) ایجاد کنید.
  3. تغییرات رو به عقب و رو به جلو را ادغام کنید.
  4. درخواست Pull ارائه بدهید.

قدم بعد چیست؟

بعد از این که آموزش‌های مقدماتی گیت را گذراندید، برای خودتان یک اکانت در گیت‌هاب بسازید.

نکته: گیت‌لب نیز گزینه‌ی مناسبی است اما در زمان نوشته شدن این مطلب، گیت‌هاب رایج‌ترین مخزن کد باز گیت است، پس سعی کنید جایی باشید که دیگران هم هستند.

پس از این که اکانت گیت‌هاب خودتان را ساختید، کدتان را در آن قرار دهید. مطمئن شوید هر چیزی که یاد می‌گیرید و نیاز به کد زدن دارد، به طور پیوسته در گیت‌هاب شما قرار می‌گیرد.

با این کار نه تنها نظم خوبی برای کنترل سورس کدتان دارید، بلکه به ایجاد برند شخصی شما نیز کمک می‌کند.

نکته: زمانی که در حال یادگیری گیت و گیت‌هاب هستید، توجه ویژه‌ای به درخواست Pull داشته باشید.

برند

برند روشی است که به دنیا نشان بدهید چه کارهایی از شما بر می‌آید.

یک راه (در حال حاضر یکی از بهترین راه‌ها!) این است که حضوری پررنگ در گیت‌هاب داشته باشید و از آن به عنوان یک پروکسی برای برندتان استفاده کنید. تقریبا تمامی کارفرماها چنین چیزی را از شما می‌خواهند.

به همین دلیل، سعی کنید که یک اکانت گیت‌هاب ایده‌آل داشته باشید و دائما به آن رسیدگی کنید، به طوری که بتوانید آن را روی رزومه‌ی خود قرار دهید و به آن افتخار کنید.

در بخش‌های بعد درباره‌ی ایجاد یک وبسایت ساده اما جذاب روی گیت‌هاب و با کمک فریمورک Hugo صحبت خواهیم کرد. اما فعلا تنها قرار دادن کدهایتان در گیت‌هاب کفایت می‌کند.

با مرور زمان و کسب تجربه، شاید بهتر باشد که دو اکانت در گیت‌هاب داشته باشید. یکی از آن‌ها برای موارد شخصی و ذخیره‌ی کدهای تمرینی و دیگری برای دخیره‌ی کدهایی که می‌خواهید دیگران مشاهده کنند.

برای جمع‌بندی می‌توان گفت:

  • گیت را یاد بگیرید.
  • هر چیزی که آموخته‌اید را در گیت‌هاب قرار بدهید.
  • از موارد اول و دوم برای نمایش تمام چیزهایی که تا کنون آموخته‌اید استفاده کنید.
  • پیشرفت کنید!

سخن پایانی

در انتها، نیاز است که به پیشرفت‌های اخیر در این زمینه مانند GitOps هم توجه داشته باشید.

GitOps تمامی مواردی که درباره‌شان صحبت کردیم را به سطح دیگری می‌برد که در آن تمامی کارها از طریق گیت، درخواست Pull و خط لوله‌های به‌کارگیری انجام می‌شود.

توجه داشته باشید که مخاطب GitOps و رویکردهای مشابه آن‌، قسمت تجاری داستان است. به این معنی که قرار نیست از موارد پیچیده‌ای مانند گیت به این دلیل که خفن هستند استفاده کنیم! بلکه می‌خواهیم از گیت برای بهبود چابکی کسب و کار، افزایش سرعت نوآوری و ارائه‌ی سریع‌تر ویژگی‌ها استفاده کنیم. چرا که در نهایت این‌ها باعث می‌شوند که کسب و کارمان به درآمد بیشتری برسد.

قسمت چهارم این مقاله را می‌توانید از اینجا مطالعه کنید.


کلیدواژه: آموزش devops آموزش دواپس آموزش داکر آموزش Docker

منابع: medium.com

ارسال دیدگاه:
برای ارسال دیگاه باید به سیستم وارد شوید و یا ثبت نام کنید. ثبت نام چند لحظه بیشتر زمان شما را نمیگیرد.