رفتن به نوشته‌ها

قواعد ۱۲گانه ساخت SaaS – قسمت اول codebase

این روز‌ها بیشتر نرم‌افزار‌ها به عنوان یک SaaS یا Software as a Service طراحی می‌شوند، یعنی یک آدرسی روی اینترنت که روی یک پروتکلی مثل HTTP یک خدمتی رو به کاربرانش ارائه میده، مثل انواع سرویس‌هایی که گوگل در اختیار کاربرانش قرار میده.
حدس می‌زنم شما به عنوان مهندس نرم‌افزار یا تا به حال چنین نرم‌افزار‌هایی طراحی کردید یا نرم‌افزاری طراحی کردید که نقش کلاینت رو برای چنین سرویسی بازی می‌کنه(مثل یک اپ اندرویدی یا یک اپ وبی)، توی این سری از پست‌ها میخوام در مورد یک متدولوژی توضیح بدم به نام ۱۲-Factors app که یک سری بایدها و نباید‌ها در مورد طراحی و پیاده‌سازی SaaSها ارائه میده که حاصل سال‌ها تجربه طراحان این متدولوژی هستش.
این مجموعه بلاگ پست شامل ترجمه آزاد از متن اصلی هستش به علاوه توضیحات یا تجربیاتی که خودم در مورد هر کدوم از اون قواعد داشتم، اگر مایل بودید می‌تونید متن اصلی این متدولوژی رو در آدرس https://12factor.net مطالعه کنید.
ضمنا لازمه که هشدار بدم این قواعد وحی منزل نیست، بعضی وقتا رعایت کردن بعضی از این اصول باعث افزایش پیچیدگی نرم‌افزار میشه و فوایدی که براتون به ارمغان میاره اصلا مورد نیاز شما نیست!

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

 

در مورد کدبیس این مواردی هستش که باید رعایت کنید:

  1. طبیعتا اولین موضوع این هستش که باید از یک ورژن کنترل استفاده کنید، وقتی میگیم ورژن کنترل منظورمون Git یا Mercurial یا SVN هستش که البته توصیه می‌کنم از همون گیت استفاده کنید با توجه به اینکه جامعه بزرگتری داره و شانس اینکه نفر بعدیی که وارد تیم میشه بگه « اوه من گیت بلد نیستم و Mercurial یا ساب‌ورژن بلدم» به اندازه اینه که موقع استخدامش یه شهاب‌سنگ بخوره توی محل مصاحبه استخدامی، پس همون گیت رو استفاده کنید.
    با فرض اینکه از یک ورژن کنترل استفاده کردید،از این به بعد مفهوم Repository رو دقیقا متناظر با مفهوم codebase در نظر می‌گیریم.
  2. اگر کدبیس شما جوری هستش که قابل تقسیم به دو قسمت هست به طوری که هر قسمت قابلیت دیپلوی مجزا داره، پس دارید اشتباه می‌زنید(البته بر اساس این متدولوژی) و دو تا app رو داخل یک ریپو نگه‌داشتید، باید هر کدوم از اپ‌ها به یک کدبیس(ریپو) منتقل بشه.
    چند تا مثال:
    – فرض کنید شما یک سرویس دارید که یک API در اختیار کاربر قرار میده و یک اپ کلاینت‌ساید دارید که با NodeJs سمت سرور ران میشه، مثلا برای Server-side rendering ، این مورد از مواردیه که باید این ریپو رو به دو ریپوی جداگانه خورد کنید.
    – فرض کنید باز هم مثل مثال قبل شما یک سرویسی دارید که مستقیما APIای به کاربر ارائه نمیده بلکه همون‌جا توی همون سرویس یک templateای رو رندر می‌کنه و یک HTML به کلاینت برمیگردونه، اینجا نیازی نیست ریپو به دو قسمت تقسیم بشه چون دیزاین سرویس طوری نیست که بشه بخش Template rendering رو جدا کرد و جداگانه دیپلوی کرد.
    حالا ممکنه یه مسئله‌ای پیش میاد موقع جدا کردن، مثلا یه سری کتابخونه بین این دو تا app مشترک باشه و هر دو استفاده می‌کنند، اینجور مواقع باید چه کار کرد؟خب در اینجور موارد باید اون کتابخونه‌ها تبدیل به پکیج‌ها مستقل بشند و از طریق Dependency manager در اختیار هر app قرار بگیرند.(توی مطالب آینده مفصل در مورد مفهوم Dependency صحبت می‌کنیم)
  3. یکی از نکات مهم در مورد کدبیس، بحث دیپلوی کردن هستش، این که کدبیس شما چه ارتباط و تاثیری روی دیپلوی شما داره. در مورد ارتباط بین کدبیس و دیپلوی اولین چیزی که باید بهش توجه کرد اینه که شما یک کدبیس بیشتر ندارید اما همون یک کدبیس می‌تونه چندین و چند دیپلوی داشته باشه، با کانفیگ‌های مختلف روی سرور‌های مختلف در زمان‌های مختلف برای مقاصد مختلف که هر نوع دیپلوی نیاز‌های خودش رو داره. این موضوع از این جهت مهم هستش که کمک می‌کنه تصمیم بگیریم چه چیزی باید داخل ریپو قرار بگیره و چه چیزی نباید داخل ریپو قرار بگیره، بذارید چند تا حالتش رو در نظر بگیریم:
    کدبیس و دیپلوی‌ها

    • Production
      معروف‌ترین دیپلوی که و وقتی میگیم دیپلوی اکثرا اون توی ذهنشون میاد ، جایی که نسخه نهایی اونجا در اختیار کاربران قرار میگیره.در حالت پروداکشن نیاز داریم سرویس در بهینه‌ترین(Optimization) حالت ممکن خدمت‌رسانی کنه و قابل پایش(monitoring) باشه، برامون خیلی مهمه که پایدار(Stable) باشه.
    • Staging
      یکی دیگه از انواع دیپلوی که نقش مهمی توی Stable شدن و رفع نقص‌ها داره staging هستش، دیپلوی staging قرار هست که توی انواع تست‌ها شرکت کنه(مثل Integration test یا تست‌هایی که توسط تیم تست انجام میشه).برای ما مهم نیست که Staging خیلی سریع باشه یا خیلی پایدار باشه، در عوض برای ما مهم هستش که توی محیط اجرای Staging تا حد امکان شبیه پروداکشن باشه، به اندازه کافی لاگ تولید کنه که بتونیم ببینیم داخل سیستم چه خبر هستش، حتی شاید یه سری ماژول‌های اضافه هم فعال باشند تا تیم تست سریع‌تر بتونه تست کنه.
    • Development
      این از دیپلوی‌هایی هستش که بیشترین تعداد رو معمولا بین دیپلوی‌ها داره، هر وقت یکی از برنامه‌نویس‌های تیم پروژه رو روی سیستم خودش ران می‌کنه دوست داره پروژه توی حالت Development دیپلوی بشه.حالت Development نیاز داره خیلی راحت(به راحت‌ترین شکل ممکن) دیپلوی بشه، اصلا نیاز نداریم بهینه باشه، برنامه‌نویس باید بتونه حداکثر امکانات دیباگ رو در اختیار داشته باشه.

    پس ما یک کدبیس داریم و نیاز داریم بار‌ها اون رو با نیاز‌های مختلف دیپلوی کنیم، برای اینکار باید تمام مواردی که بین محیط‌های مختلف(production, staging, development ,…) تفاوت دارند رو به جای اینکه مستقیما داخل ریپو قرار بدیم از طریق کانفیگ مشخص کنیم.(توی قسمت‌های بعدی مفصل در مورد کانفیگ صحبت خواهیم کرد)

 

منتشر شده در Designدسته‌بندی نشده