برای درک بهتر این موضوع که مهندسان دوآپس دقیقاً چه کاری انجام میدهند، بهتر است به چرخهٔ تولید نرمافزار نگاهی داشته باشیم اما پیش از آن، نیمنگاهی به تعریف این اصطلاح از نگاه ویکیپدیا خواهیم داشت:
دوآپس یک فرایند تولید نرمافزار است که بر مبنای ارتباط و همکاری هرچه بیشتر میان تیمهای توسعهٔ نرمافزار و تیمهای اجرایی بنا شده است که در طی این فرآیند عملیات توسعهٔ نرمافزار و همچنین اِعمال تغییرات زیرساختی به صورت خودکار درمیآیند و در کل هدف از چنین فرایندی ایجاد فرهنگی است که در آن تولید، تست و انتشار نرمافزار به شیوهای سریع، مداوم و مطمئن انجام شود.
حال بپردازیم به بررسی فرایند توسعهٔ نرمافزار به طوری که این فرایند را میتوان به پنج مرحلهٔ اصلی تقسیم کرد که عبارتند از:
Planning (طرحریزی)
در این مرحله از فرآیند توسعهٔ نرمافزار، تیمی متشکل از دولوپرها، مدیران تولید و … اهداف پروژه را ترسیم نموده و ساختار کلی نرمافزار را تعیین میکنند و در این مرحله مهندس دوآپس باید از دانش فنی اعضای تیم و تسلط آنها بر پلتفرمهای مورد استفاده بهره برده و بررسی نماید که چگونه میتوان در قالب یک سیستم جامع و یکپارچه به تمام اهداف مورد نظر تیم جامهٔ عمل پوشاند (در کل، این مرحله از کار یکی از گامهای زمانبَر است.)
پس از اینکه شِمای کلی سیستم اولیه پیادهسازی و اجرا شد، مهمترین مسئله هدایت تیم در جهت نحوهٔ افزودن قابلیتها و تکنولوژیهای از قبل تولیدشده به این سیستم است. در واقع، مهندس دوآپس همواره باید به دنبال راهکارهایی برای انجام خودکار فرآیندهای مختلف باشد تا بار انجام این کارها تا حد امکان از دوش اعضای تیم برداشته شود که در این مرحله مهندس دوآپس باید پاسخ سؤالات زیر را بیابد:
– دو سرویس مختلف چگونه میتوانند با هم در تعامل باشند؟
– برای مرتبط کردن این دو سرویس از چه پروتکلی باید استفاده نمود؟
– آیا سختافزاری که در اختیار ما قرار دارد پاسخگوی نیازمان هست؟
– برای اینکه بتوانیم در پروسهٔ تولید به مهندسان کمک کنیم، نیاز به چه چیزهایی داریم؟
– آیا سرویس مذکور به اصطلاح Production-Ready خواهد بود؟
– آیا تمام دیپندنسیهای مورد استفاده در نرمافزار برای ما ملموس هستند؟
– چه چیزی را لازم است بسازیم و چه چیزی را باید خریداری کنیم؟
– آیا یک تَسک خاص را میتوان به صورت خودکار انجام داد؟
– چهطور میتوان در آینده از این نرمافزار پشتیبانی نمود؟
Development (توسعه)
در این مرحله، ترکیببندی کلی کار مشخص شده و دیگر نوبت دولوپرها است تا کد بزنند و فیچرهای پیشبینیشده را برای نرمافزار توسعه دهند و هدف عمدهٔ مهندس دوآپس در چنین مرحلهای این است که به دنبال راههایی برای سریعتر انجام شدن کارها باشد. به عبارتی، وی باید راهی پیش پای دولوپرها بگذارد تا بتوانند بهترین کار را در کمترین زمان ممکن انجام دهند و این دقیقاً با هدف نهایی کار، یعنی تولید نرمافزار، هماهنگ و سازگار است.
در حقیقت، در این پروسه مهندس دوآپس به دولوپرها میگوید که از چه ابزاری استفاده کنند و همچنین ابزارهای جدید را در اختیار آنها قرار میدهد تا کارشان تسهیل گردد. همچنین این مهندس دوآپس است که باید بخشهای مختلف کدهایی که توسط دولوپرها و در محیط توسعه نوشته شدهاند را مانند قطعات پازل در کنار هم قرار داده و آنها را با محیط نهایی نرمافزار هماهنگ کند. سؤالاتی که یک مهندس دوآپس در این مرحله ممکن است با آن مواجه شود عبارتند از:
– چگونه میتوانیم دولوپرها را در فضایی مشابه فضای محصول نهایی نگاه داریم؟
– چهطور به دولوپرها اجازه دهیم تا از ابزارهای مورد علاقهٔ خود استفاده کنند؟
– چگونه میتوانیم بهرهوری و کارایی دولوپرها را افزایش دهیم؟
– چهطور باید برای دولوپرها توضیح دهیم که محیط نهایی نرمافزار چگونه خواهد بود؟
Testing (تست کردن)
در این مرحله، دولوپرها و مسئولین کنترل کیفیت (QC) کدها را تست نموده و آنها را برای یکپارچه شدن با سورسکد اصلی آماده میکنند که در این مرحله ممکن است از ابزارها و اسکریپتهایی به منظور انجام خودکار تستها استفاده شود اما هنوز هم برای اجرای دستی کدها بر روی سیستمهای داخلی شرکت به حضور دولوپرها و مسئولین کنترل کیفیت نیاز است.
در اینجا است که دوباره پای مهندس دوآپس به میان میآید به طوری که در این مرحله وظیفهاش این است که برای تکرار خودکار تستها راهی بیابد به طوری که میتواند از ابزارهایی مانند Jenkins ،Bamboo و یا Drone استفاده کند که اینها ابزارهای Continuous Integration یا به اختصار CI هستند که تست مداوم کدها را آسانتر میکنند. همچنین در این مرحله لازم است تا به سؤالات زیر پاسخ داده شود:
– چگونه میتوان به اصطلاح چندین Client Environment تکرارپذیر ایجاد نمود؟
– از کجا بدانیم تست مورد نظر در مورد کدام نسخه از سرویس در حال انجام است؟
– چگونه تاریخچهٔ تستها را دنبال کنیم و با استفاده از آن به روندهای موجود پی ببریم؟
– چگونه پس از تست نمودن کدها، مشکلات احتمالی را به دولوپرها اعلام کنیم؟
– دادههای تست را از کجا به دست آوریم؟
Deployment (استقرار)
این اصطلاح به معنای آپلود کردن کدها روی سرور اصلی نرمافزار است. به طور کلی، این مرحله در مورد این است که کدهای نوشتهشده چهطور و با چه نظمی در محصول نهایی قرار بگیرند تا کاربر نرمافزار قادر به استفاده از سرویس ما گردد. در این مرحله نیز مهندسان دوآپس از ابزارهای CI، مشابه آنچه که در بخش قبل معرفی شد، استفاده میکنند و بعضی از مهمترین سؤالاتی که در این مرحله باید پاسخ داده شوند عبارتند از:
– چه زمانی یک نسخهٔ نهایینشده از نرمافزار آمادهٔ دیپلوی شدن است؟
– چگونه بدون اینکه کاربر متوجه شود، سرویسی را دیپلوی نماییم؟
– چگونه مطمئن شویم سرویسی که به تازگی دیپلوی شده منجر به ایجاد اختلال نمیشود؟
– چگونه فرآیند دیپلوی شدن را به صورت خودکار درآوریم؟
– چگونه در صورت لزوم در فرآیند دیپلوی خودکار، مراحلی را به صورت دستی و غیرخودکار انجام دهیم؟
– چگونه فرآیند دیپلوی را با روشی تکرارپذیر انجام دهیم؟
معمولاً این مرحله زمان زیادی را از مهندسان دوآپس نمیگیرد اما بخشی که این مهندسین باید بیشترین زمان و انرژی خود را صرف آن کنند، مرحلهٔ بعدی، Maintenance، است.
Maintenance (نگهداری)
همانطور که گفتیم، مرحلهٔ نگهداریِ نرمافزار یکی از مراحلی است که بیشترین زمان یک مهندس دوآپس را به خود اختصاص میدهد و این فاز تماماً در مورد انجام کارهایی است که در نهایت موجب در دسترس قرار گرفتن یک سیستم و حفظ کارایی آن میشوند. در این مرحله سؤالاتی مانند موارد زیر باید پاسخ داده شوند:
– چگونه میتوانیم از مشکلات و باگهای موجود در محصول یا سرویس آگاه شویم؟
– چگونه باگهای مختلف موجود در محصول یا سرویس را به تیمهای مناسب ارجاع دهیم؟
– چگونه باگهای زیرساختی موجود در محصول را برطرف کنیم؟
– به عنوان یک مهندس دوآپس چگونه میتوانیم از سلامت و کارایی همهٔ سرویسها مطمئن شویم؟
جمعبندی
DevOps آمیزه و مخلوطی از چندین نقش بوده و هدف نهایی آن کنار هم قرار دادن دولوپرها و مهندسان اجرایی است. فرهنگ دوآپس ویژگیها و قابلیتهای جدید محصول را با زیرساختهای آن سازگار مینماید و سبب میشود تا این دو بتوانند در کنار هم به خوبی عمل کنند. به منظور تکمیل آنچه در بالا مورد بررسی قرار گرفت، توجه شما را به تصویر زیر جلب میکنیم: