تحویل مستمر چیست؟
تحویل مستمر یعنی توانایی دریافت همه نوع تغییرات از جمله ویژگیهای جدید، تغییرات پیکربندی، رفع اشکالها و آزمونها است که منجر به تولید نرمافزار ایمن و کیفیت بالا میشود. هدف در تحویل مستمر این است که استقرارها را به شکل قابل پیش بینی انجام دهیم که میتواند بر اساس تقاضا انجام شود.
چرا تحویل مستمر انجام دهیم؟
اغلب فرض بر این است که اگر میخواهیم نرمافزار را به دفعات بیشتری مستقر کنیم، باید سطوح پایینتری از ثبات و قابلیت اطمینان را در سیستمهای خود بپذیریم. در واقع، تحقیقات انجامشده نشان میدهد که اینطور نیست؛ تیمهایی با عملکرد بالا به طور مداوم خدمات را سریعتر و قابل اطمینانتر از رقبای کم عملکردشان ارائه میکنند. این امر حتی در حوزه های بسیار تحت نظارت مانند خدمات مالی و دولتی نیز صادق است. این قابلیت، مزیت رقابتی باورنکردنی را برای سازمانها، فراهم می کند.
اقداماتی که در قلب تحویل مستمر وجود دارد و به ما کمک میکند تا به چندین مزیت مهم دست یابیم، به صورت کلی در زیر بیان شده است:
دیدیم که تحویل مستمر اثر جادویی دارد ولی دقت کنید که این جادو نیست؛ تحویل مستمر نیاز به یم انظبات و مدیریت دارد که باید به صورت مستمر چک کرد. خوب بریم کمی بهتر و مفصلتر با این مبحث آشنا شویم.
پنج اصل در قلب تحویل مستمر وجود دارد:
ساخت کیفیت
دبلیو ادواردز دمینگ، 14 اصل کلیدی را برای مدیریت ارائه کرده است. اصل سوم می گوید:
وابستگی به بازرسی را برای دستیابی به کیفیت متوقف کنید. با ایجاد کیفیت در محصول در وهله اول، نیاز به بازرسی انبوه را از بین ببرید.
رفع مشکلات و نقصها در صورتی که فوراً آنها را پیدا کنیم بسیار ارزانتر است؛ در حالت ایدهآل باید قبل از اینکه نسخه نهایی بررسی شوند، با اجرای تستهای خودکار به صورت محلی در طول توسعه نرمافزار عیبهای سیستم را پیدا کرد. ایجاد و تکامل حلقههای بازخورد برای شناسایی مشکلات در اسرع وقت، کاری ضروری و بیپایان در تحویل مستمر است. اگر در آزمون خود مشکلی پیدا کردیم، نه تنها باید آن را برطرف کنیم، بلکه باید بپرسیم: چگونه میتوانستیم با یک آزمون پذیرش خودکار مشکل را پیدا کنیم؟ هنگامی که یک آزمون ناموفق است، باید بپرسیم: آیا میتوانستیم برای حل این مشکل یک آزمون واحد بنویسیم؟
کار در دسته های کوچک
در رویکردهای سنتی مرحلهای برای توسعه نرمافزار، انتقال از برنامهنویس به فاز آزمون و از فاز آزمون به فاز عملیات شامل نسخههای کامل است، که هر کدام از این فازها شامل ماهها کار تیمهایی متشکل از دهها یا صدها نفر است. اما در تحویل مداوم، ما رویکرد مخالف را در پیش میگیریم و سعی میکنیم هر تغییری را در نسخه تا آنجا که میتوانیم به سمت انتشار دریافت کنیم و بازخورد جامع را در سریع ترین زمان ممکن دریافت کنیم. کار در دستههای کوچک فواید زیادی دارد. زمان دریافت بازخورد در مورد کارمان را کاهش میدهد، رفع مشکلات را آسانتر میکند، کارایی را افزایش میدهد و از تسلیم شدن در برابر اشتباه هزینههای غرقشده جلوگیری میکند.
دلیل اینکه ما در دستههای بزرگ کار میکنیم، هزینه ثابت زیادی برای تحویل تغییرات است. یک هدف کلیدی از تحویل مداوم، تغییر اقتصادی فرآیند تحویل نرمافزار است تا کار در دستههای کوچک از نظر اقتصادی مقرونبهصرفه باشد تا بتوانیم از مزایای بسیاری از این رویکرد برخوردار شویم.
کامپیوترها کارهای تکراری را انجام میدهند، تیم مشکلات را حل میکنند
هدف این است که کامپیوترها کارهای ساده و تکراری مانند آزمایش رگرسیون را انجام دهند تا انسانها بتوانند روی حل مسئله تمرکز کنند. بنابراین کامپیوترها و افراد مکمل یکدیگر هستند. بسیاری از مردم نگران هستند که اتوماسیون آنها را بیکار کند. هدف این نیست؛ هیچ وقت در یک شرکت موفق کمبود کار وجود نخواهد داشت. درعوض، افراد برای تمرکز بر فعالیتهایی با ارزش بالاتر، از کار طاقت فرسا رها میشوند. این مزیت بهبود کیفیت را نیز دارد، زیرا انسانها در هنگام انجام کارهای بی ارزش در معرض خطا هستند.
بی وقفه به دنبال بهبود مستمر باشید
تایچی اوهنو، یکی از چهره های کلیدی در تاریخ شرکت تویوتا، زمانی گفت:
فرصتهای بهبود بی نهایت هستند. فکر نکنید که اوضاع را بهتر از قبل کردهاید و آسوده خاطر باشید. این مانند دانش آموزی است که افتخار میکند زیرا در شمشیربازی دو بار از سه بار استاد خود را شکست داده است. هنگامی که جوانههای ایدههای بهبود را برداشتید، مهم است که در کار روزانه خود این نگرش را داشته باشیم که درست زیر یک ایده بهبود، ایده بهتر دیگری وجود دارد.
تحول را به عنوان پروژهای تلقی نکنید که باید شروع شود و سپس تکمیل شود تا بتوانیم طبق معمول به تجارت بازگردیم. بهترین سازمانها سازمانهایی هستند که در آنها کار بهبود بخشی ضروری از کار روزانهشان است و هیچکس از وضعیت موجود راضی نیست.
همه مسئول هستند
در سازمانهایی با عملکرد بالا، هیچ چیز "مشکل شخص دیگری" نیست. توسعه دهندگان مسئول کیفیت و پایداری نرم افزاری هستند که میسازند. تیمهای عملیاتی مسئول کمک به توسعهدهندگان برای ایجاد کیفیت هستند. همه با هم برای دستیابی به اهداف سطح سازمانی کار میکنند، نه اینکه برای تیم یا بخش خود بهینهسازی کنند.
اکثر مردم میخواهند کار درست را انجام دهند، اما رفتار خود را بر اساس نحوه پاداشی که دریافت میکنند تطبیق میدهند. بنابراین، ایجاد حلقههای بازخورد سریع از چیزهایی که واقعاً مهم هستند، پس نحوه واکنش مشتریان به آنچه ما برای آنها میسازیم و تأثیر آن بر سازمان ما میتوان یک معیار خوب باشد.
تحویل مستمر بر سه پایه استوار است: مدیریت پیکربندی جامع، یکپارچه سازی مداوم و آزمایش مداوم.
در این قسمت مروری بر هر یک از این پایهها خواهیم داشت.
اتوماسیون نقشی حیاتی در حصول اطمینان از اینکه میتوانیم نرمافزار را بهطور تکراری و قابل اطمینان منتشر کنیم، ایفا میکند. یکی از اهداف کلیدی این است که فرآیندهای دستی تکراری مانند ساخت، استقرار، آزمون رگرسیون و تامین زیرساخت و خودکارسازی آنها را انجام دهیم. برای دستیابی به این هدف، ما باید هر چیزی را که برای انجام این فرآیندها لازم است، از جمله کد منبع، اسکریپتهای آزمون و استقرار، زیرساختها و اطلاعات پیکربندی برنامه، و کتابخانههایی که به آنها وابسته هستیم، کنترل کنیم. ما همچنین میخواهیم پرس و جو از وضعیت فعلی و تاریخی محیط خود را ساده کنیم.
ما دو هدف اساسی داریم:
این قابلیت ها چندین مزیت قابل توجه به ما می دهد:
هنگام تلاش برای دستیابی به مزایا، همیشه باید با تعریف اهدافی که میخواهیم به آنها برسیم، شروع کنیم. این به ما امکان میدهد تعیین کنیم که کدام یک از مسیرهای ممکن برای رسیدن به هدف ما احتمالاً بهترین است و اگر متوجه شدیم رویکرد ما بسیار گران یا طولانی است، مسیر خود را تغییر دهیم یا اهداف خود را دوباره ارزیابی کنیم.
از چه ابزارهایی برای مدیریت پیکربندی استفاده کنم؟
انتخاب ابزار موضوع پیچیدهای است و در بسیاری از موارد انتخاب ابزار عامل مهمی در موفقیت است. من توصیه میکنم تحقیقاتی را انجام دهید تا فهرست کوتاهی را بر اساس فناوریهایی که تیم شما با آنها آشناست تهیه کنید و سپس یک هدف کوتاهمدت تعیین کنید و برای دستیابی به آن تلاش کنید. به این نوع نرمافزارها در حوزه نرمافزار SCM گفته میشود؛ به عنوان مثال میتوانید از ابزارهای زیر استفاده کنید.
یک مانیتور پیکربندی سرور است که برای شناسایی تغییرات پیکربندی غیرمجاز در سرورها و برنامههای شما ارائه شده است. این به شما کمک میکند تا تنظیمات سرور و برنامههای کاربردی را در ویندوز و لینوکس پایه گذاری کنید. این قابلیت دید و مسئولیت پذیری تیم را بهبود میبخشد و زمان عیبیابی را کاهش میدهد.
این ابزار اساساً یک پلت فرم اتوماسیون است که راهی برای پیکربندی و مدیریت زیرساخت ارائه می دهد. زیرساخت به عنوان کد مستلزم اجرای با کدگذاری به جای اجرای دستی است. همچنین برای نوشتن تنظیمات روی Ruby و DSL کار میکند.
ترکیب کار چندین توسعه دهنده سخت است. سیستمهای نرم افزاری پیچیده هستند و یک تغییر ظاهرا ساده و مستقل به یک فایل میتواند به راحتی عواقب ناخواستهای داشته باشد که صحت سیستم را به خطر میاندازد. در نتیجه، برخی از تیمها از توسعهدهندگان میخواهند که روی شاخههای خود، جدا از یکدیگر کار کنند. با این حال، با گذشت زمان این شاخهها از یکدیگر جدا میشوند. در حالی که ادغام یکی از این شاخهها در خط اصلی معمولاً مشکل ساز نیست، ولی کار مورد نیاز برای ادغام چندین شاخه با عمر طولانی در خط اصلی توسعه معمولاً مشکل ساز است و به مقدار قابل توجهی از کار مجدد نیاز دارد.
تیمها در زمانهایی نیاز به فریز کردن کد، یا حتی فازهای یکپارچهسازی دارند، زیرا آنها برای ادغام این شاخهها قبل از انتشار کار میکنند. با وجود ابزار مدرن، این فرآیند هنوز گران و غیرقابل پیش بینی است. این مشکل با افزایش اندازه تیم و با افزایش طول عمر شاخه ها به طور تصاعدی شدیدتر می شود.
عمل ادغام مداوم برای رسیدگی به این مشکلات ابداع شده است. CI (ادغام پیوسته) از اصل XP (برنامه نویسی شدید) پیروی میکند که اگر چیزی درای مشکل است، باید آن را بیشتر انجام دهیم و مشکل را جلو ببریم. بنابراین در CI توسعه دهندگان تمام کارهای خود را به طور منظم (حداقل روزانه) در trunk ادغام میکنند. مجموعهای از آزمونهای خودکار هم قبل و هم بعد از ادغام اجرا میشوند. اگر این آزمونهای خودکار با شکست مواجه شوند، تیم کاری را که انجام میدهند متوقف میکند و شخصی بلافاصله مشکل را برطرف میکند.
مزایای یکپارچه سازی مداوم بسیار قابل توجه است - تحقیقات نشان می دهد که منجر به سطوح بالاتری از توان عملیاتی، سیستمهای پایدارتر و نرمافزار با کیفیت، میشود. با این حال این عمل به دو دلیل اصلی هنوز بحث برانگیز است.
اول، توسعه دهندگان را ملزم می کند که ویژگیهای بزرگ و سایر تغییرات را به مراحل کوچکتر و تدریجی تر تقسیم کنند که می توانند در trunk/ master ادغام شوند. این یک تغییر پارادایم برای توسعه دهندگانی است که عادت ندارند به این روش کار کنند. درواقع ما میخواهیم بتوانیم تغییرات را در سریعترین زمان ممکن بررسی، ادغام، آزمایش و اجرا کنیم و این فرآیند زمانی سریعتر و ارزانتر است که تغییرات کوچک و مستقل باشند، و شاخههایی که در آنها زندگی میکنند کوتاه مدت و در دستههای کوچک باشد. دوم، ادغام مداوم مستلزم مجموعه ای سریع از آزمونهای واحد خودکار جامع است. این آزمونها باید به اندازه کافی جامع باشند تا سطح خوبی از اطمینان حاصل شود که نرم افزار همانطور که انتظار میرود کار میکند، در حالی که در چند دقیقه یا کمتر اجرا می شود. اگر آزمایشهای واحد خودکار بیشتر طول بکشد، توسعهدهندگان مایل به اجرای مکرر آنها نیستند و نگهداری از آنها سختتر میشود. ایجاد مجموعههای قابل نگهداری از تستهای واحد خودکار پیچیده است و بهتر است از طریق توسعه آزمون محور (TDD) انجام شود.
با وجود این موانع، کمک به تیمهای توسعه نرمافزار برای اجرای یکپارچهسازی مستمر باید اولویت شماره یک هر سازمانی باشد که میخواهد تحویل مستمر را آغاز کند. CI با ایجاد حلقههای بازخورد سریع و حصول اطمینان از کار توسعهدهندگان در دستههای کوچک، تیمها را قادر میسازد تا کیفیت را در نرمافزار خود ایجاد کنند، در نتیجه هزینه توسعه مداوم نرمافزار را کاهش میدهد و هم بهرهوری تیمها و هم کیفیت کاری را که تولید میکنند افزایش میدهد.
از چه ابزارهایی برای کپارچهسازی مداوم استفاده کنم؟
یک پلت فرم مدیریت کد، که به سرعت در حال رشد برای توسعه دهندگان مدرن است. این ابزارها را برای مدیریت مسائل، نمایش کد، یکپارچه سازی و استقرار مداوم، همه در یک داشبورد فراهم میکند. GitLab بستههای از پیش ساخته شده را برای توزیعهای محبوب لینوکس ارسال میکند، در عرض چند دقیقه نصب میشود، یک رابط کاربری دوستانه دارد و مستندات دقیقی را در مورد هر ویژگی ارائه میدهد.
ویژگی های کلیدی:
هزینه: رایگان برای نسخه انجمن، شرکتی با شروع از 16 دلار برای هر کاربر
یک پلت فرم CI است که فرآیند تست نرم افزار و استقرار برنامهها را خودکار میکند. این به عنوان یک پلتفرم ساخته شده است که با پروژه های GitHub شما یکپارچه میشود تا بتوانید آزمایش کد خود را در هر لحظه شروع کنید. با مشتریانی مانند فیس بوک، موزیلا و توییتر قرارداد دارند. این یکی از ابزارهای یکپارچه سازی مداوم موفق در بازار است.
ویژگی های کلیدی:
هزینه: رایگان برای مخازن باز، Enterprise برای خصوصی
به طور سنتی، استفاده گسترده از بازرسی دستی تغییرات کد و آزمون دستی به منظور نشان دادن درستی سیستم انجام میشد. این نوع آزمایش معمولاً در مرحلهای پس از «تکمیل برنامه» انجام میشود. با این حال، این استراتژی چندین اشکال دارد:
برای ایجاد کیفیت در نرم افزار، باید رویکرد متفاوتی را اتخاذ کنیم. هدف ما این است که انواع مختلفی از آزمونها اعم از دستی و خودکار را به طور مداوم در طول فرآیند تحویل اجرا کنیم. نمودار زیر به خوبی این هدف نشان داده شدهاند:
هنگامی که ما یکپارچه سازی مداوم و آزمون اتوماسیون را در محل خود داریم، یک pipeline استقرار (الگوی کلیدی در تحویل مداوم) ایجاد میکنیم. در الگوی pipeline استقرار، هر تغییری یک بیلد را اجرا میکند که ابتدا بستههایی را ایجاد میکند که میتوانند در هر محیطی مستقر شوند و ثانیا آزمایشهای واحد را اجرا میکند، و بازخوردهایی را به توسعهدهندگان در فضای چندگانه میدهد.
در pipeline استقرار، هر تغییری عملاً کاندیدای انتشار است. وظیفه pipeline استقرار یافتن مسائل شناخته شده است. اگر نتوانیم هیچ مشکل شناخته شدهای را تشخیص دهیم، باید با آزاد کردن بستههایی که از آن عبور کرده اند، احساس راحتی کنیم. اگر اینطور نیستیم، یا اگر بعداً نقصهایی را کشف کردیم، به این معنی است که باید خود را بهبود دهیم، شاید باید آزمونهایی را اضافه یا به روز کنیم.
هدف ما باید این باشد که مشکلات را در اسرع وقت پیدا کنیم، و زمان تحویل از ورود تا انتشار را تا حد امکان کوتاه کنیم. بنابراین ما میخواهیم فعالیتها را در خط لوله استقرار موازی کنیم، نه اینکه مراحل زیادی به صورت سری اجرا شوند.
با ساختن یک pipeline اولیه استقرار را شروع کنید، که دارای یک آزمون واحد، یک آزمون پذیرش واحد، یک اسکریپت استقرار خودکار که یک محیط آزمون را ایجاد میکند، است؛ سپس پوشش آزمون خود را افزایش دهید و pipeline استقرار خود را با تکامل محصول یا خدمات خود گسترش دهید.
از چه ابزارهایی برای آزمون مداوم استفاده کنم؟
هنگامی که صحبت از آزمون خودکار وب به میان میآید، احتمالاً سلنیوم نام شناخته شدهای است. سلنیوم یک چارچوب منبع باز است که کاندیدای عالی برای تیمی است که به سمت پذیرش آزمون مداوم تمایل دارد.
سلنیوم برای مهندسین تضمین کیفیت (QA) با سطح پیشرفته مهارت برنامه نویسی انتخابی مناسب است. این نیاز به درک عمیقی از نحوه کار چارچوب برای تنظیم و پیاده سازی چرخه توسعه فعلی شما دارد.
سلنیوم از طیف گستردهای از سیستمعاملهای محبوب (ویندوز، macOS، لینوکس) و مرورگرها (Chrome، Firefox، Safari) برای آزمایش بین محیطی پشتیبانی میکند.
با این حال، هنگام ادغام سلنیوم با سایر ابزارها در خط لوله CI/CD چالشهای زیادی وجود دارد، زیرا باید دانش و مهارتهای فنی خاصی داشته باشید. به همین دلیل است که برخی جایگزینها بر روی سلنیوم ساخته شدهاند (مانند استودیو Katalon) که اجزای آزمایش مداوم را بدون نیاز به کاربران برای نوشتن اسکریپت و پیکربندی از ابتدا ارائه میدهد.
این محصولی از SmartBear است، یک ابزار اتوماسیون آزمون برای برنامههای دسکتاپ، وب و موبایل است. این ابزار از زبانهای برنامه نویسی مختلف از جمله Python، Javascript، VBScript پشتیبانی میکند.
این ابزار به شما امکان می دهد آزمونهای مبتنی بر کلمه کلیدی یا داده محور را انجام دهید. سازندگان TestComplete اخیراً ویژگیهای هوش مصنوعی را برای تشخیص و نگهداری شیء آزمایشی پویا معرفی کردهاند. TestComplete میتواند بهطور خودکار آزمایشها را در صورت ایجاد تغییرات در رابط کاربری AUT شناسایی و بهروزرسانی کند. همچنین میتوانید پوشش آزمون خود را با اجازه دادن به چارچوبهای آزمون دیگر، مانند TestNG، Selenium Webdriver، و همچنین SOAP UI برای تست API، به حداکثر برسانید.
ابزار TestComplete با اکوسیستم CI/CD از طریق پلاگینها پشتیبانی میکند. میتوانید از این افزونهها برای ادغام با ابزارهای معروف CI/CD مانند Jenkins، GIT، Zephyr استفاده کنید. یا می توانید پلاگینهای سفارشی را برای ادغام با سیستم موجود توسعه دهید.
سازمانهایی که تلاش میکنند تحویل مستمر را مستقر کنند، معمولاً دو اشتباه رایج مرتکب میشوند. اولین مورد این است که تحویل مستمر را به عنوان یک حالت نهایی، به خودی خود یک هدف در نظر بگیرید. دوم این است که زمان و انرژی زیادی را صرف نگرانی در مورد اینکه از چه محصولاتی استفاده کنید. در این بخش مجموعهای از الگوها را مشاهده کنید که با موفقیت برای افزایش توان عملیاتی، پایداری و کیفیت اعمال شدهاند.
الگوها
لیندا رایزینگ یک الگو را به عنوان "یک استراتژی نامگذاری شده برای حل یک مشکل تکراری" تعریف میکند.
الگوی کلیدی معرفی شده در تحویل مستمر، pipeline استقرار است. این الگو از چندین پروژه که در آن با فرآیندهای دستی پیچیده، شکننده و دردناک برای آمادهسازی محیطهای آزمایش و تولید و استقرار در آنها دست و پنجه نرم میکردند، پدیدار شده است.
در الگوی pipeline استقرار، هر تغییر در کنترل نسخه، فرآیندی (معمولاً در یک سرور CI) را راهاندازی میکند که بستههای قابل استقرار ایجاد میکند و آزمونهای واحد خودکار و اعتبارسنجیهای دیگر مانند تجزیه و تحلیل کد استاتیک را اجرا میکند. این مرحله اول طوری بهینه شده است که اجرای آن تنها چند دقیقه طول می کشد. اگر این مرحله commit اولیه با شکست مواجه شد، مشکل باید فوراً برطرف شود؛ اگر commit شد، مرحله بعدی را در pipeline آغاز میکند، که ممکن است شامل مجموعهای جامع تر از آزمونهای خودکار باشد. نسخههای نرمافزاری که تمام آزمونهای خودکار را پشت سر میگذارند، میتوانند در صورت تقاضا در مراحل بعدی مانند آزمونهای اکتشافی، آزمونهای عملکرد، مرحلهبندی و تولید، مانند شکل زیر، مستقر شوند.
این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است.
مراجع:
2- wikipedia