یکپارچه سازی مداوم

یکپارچه سازی مداوم

یکپارچه سازی پیوسته یا ( Continuous Integration ) جنبه ای از خط لوله ارائه مستمر است که در آن عملکردهای جدید برای آماده سازی، استقرار و انتشار، توسعه و آزمایش، ادغام و تأیید می شود.
یکپارچه سازی پیوسته (CI) دومین جنبه در خط لوله ارائه مستمر چهار قسمتی اکتشاف مستمر (CE)، یکپارچه سازی مداوم (CI)، استقرار مداوم (CD) و انتشار بر اساس تقاضا می باشد. یکپارچه سازی پیوسته (CI) یک عمل فنی حیاتی برای هر قطار انتشار چابک (ART) است. کیفیت را بهبود می بخشد، ریسک را کاهش می دهد و سرعت توسعه سریع، قابل اعتماد و پایدار را ایجاد می کند. با یکپارچه سازی پیوسته (CI)، سیستم همیشه اجرا می شود، به این معنی که به طور بالقوه قابل استقرار است، حتی در طول توسعه. یکپارچه سازی پیوسته (CI) به راحتی در راه حل های نرم افزاری اعمال می شود که در آن رشته های عمودی کوچک و آزمایش شده می توانند به طور مستقل ارزش ارائه دهند. در سیستم های نرم افزاری بزرگتر و چند پلتفرمی، چالش سخت تر است. هر پلتفرم دارای ساختارهای فنی است که برای تأیید عملکرد جدید نیاز به یکپارچه سازی پیوسته (CI) دارد. زمانی که سیستم‌ها شامل نرم‌افزار، سخت‌افزار، اجزا و خدمات ارائه‌شده توسط تامین‌کنندگان باشند، یکپارچه سازی پیوسته (CI) پیچیده‌تر می‌شود. اما این واقعیت باقی می ماند که ادغام و آزمایش مکرر ویژگی ها با هم تنها راه عملی برای تأیید کامل یک راه حل است.
در نتیجه، تیم‌ها به یک رویکرد متعادل نیاز دارند که به آنها امکان می‌دهد کیفیت را ایجاد کنند و بازخورد سریعی در مورد کار یکپارچه خود دریافت کنند. برای راه‌حل‌های صرفاً مبتنی بر نرم‌افزار، یکپارچه سازی پیوسته (CI) با ابزارهای مدرن نسبتاً آسان است. برای سیستم‌های پیچیده‌تر با سخت‌افزار و نرم‌افزار، یک رویکرد یکپارچه‌سازی پیوسته مورد نیاز است (به مقاله تحویل راه‌حل سازمانی مراجعه کنید) تا تعادل اقتصادی بین فرکانس، محدوده یکپارچه‌سازی و آزمایش برقرار شود.

یکپارچه سازی مداوم در زمینه خط لوله تحویل پیوسته.

شکل ۱. یکپارچه سازی مداوم در زمینه خط لوله تحویل پیوسته.

 

چهار فعالیت یکپارچه سازی مداوم

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

  1. Develop شیوه‌های لازم برای پیاده‌سازی داستان‌ها و تعهد کد و مؤلفه‌ها به کنترل نسخه را توصیف می‌کند
  2. Build تکنیک‌های مورد نیاز برای ایجاد باینری‌های قابل استقرار و ادغام شاخه‌های توسعه در Trunk را توصیف می‌کند.
  3. تست انتها به انتها شیوه‌های لازم برای تایید راه‌حل را توصیف می‌کند.
  4. Stage مراحل مورد نیاز برای میزبانی و اعتبارسنجی راه حل ها را در یک محیط مرحله بندی قبل از تولید توصیف می کند.چهار فعالیت یکپارچه سازی مداوم

 

شکل ۲. چهار فعالیت یکپارچه سازی مداوم

توسعه

توسعه راه‌حل به پیاده‌سازی داستان‌ها از طریق اصلاح ویژگی‌های ای آر تی بک لاگ ( ART Backlog ) در صورت نیاز و سپس کدگذاری، آزمایش، و تعهد محصول کاری به سیستم کنترل منبع اشاره دارد. آزمایش در این فعالیت بر روی آزمایش در سطح واحد و داستان متمرکز است و اغلب به آزمایش دوگانه نیاز دارد (به توسعه تست محور مراجعه کنید) تا سایر اجزا یا زیرسیستم‌هایی را که به آسانی در دسترس نیستند یا به راحتی آزمایش نمی‌شوند تکرار کنند.

چندین روش با توسعه راه حل همراه است:

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

توسعه رفتار محور ( Behavior-Driven Development ) – BDD فرآیندی است که صاحبان محصول و تیم ها از آن برای درک بهتر الزامات و بهبود کیفیت با ایجاد معیارهای پذیرش و تست های خودکار، اغلب قبل از نوشتن کد استفاده می کنند. BDD با TDD کار می کند و در اینجا توضیح داده شده است.
توسعه تست محور ( Test-Driven Development ) – TDD شامل نوشتن آزمون واحد ابتدا، سپس ساخت حداقل کد مورد نیاز برای قبولی در آزمون است. این تکنیک تست منجر به طراحی بهتر، کیفیت بالاتر و افزایش بهره وری می شود. TDD با BDD کار می کند و در اینجا بیشتر توضیح داده شده است.
کنترل نسخه – کنترل نسخه موثر به تیم ها اجازه می دهد تا به سرعت مشکلات  و کیفیت را بهبود بخشند و از یکپارچگی اجزای مناسب اطمینان حاصل کنند. تجمیع دارایی ها تحت کنترل نسخه یک شاخص پیشرو برای بلوغ یکپارچه سازی مداوم است.
کیفیت داخلی – کیفیت داخلی اقدامات مربوط به جریان، کیفیت معماری و طراحی، کیفیت کد، کیفیت سیستم و کیفیت انتشار را تجویز می‌کند.
دورسنج کاربردی – دورسنج کاربردی مکانیزم اولیه ای است که داده های کاربردی را به دست می آورد و سپس از آن برای کمک به تعیین نتایج فرضیه های مربوطه استفاده می کند.
مدل‌سازی تهدید – علاوه بر مدل‌سازی تهدید که در اکتشاف مستمر انجام می‌شود (مرحله معمار)، طراحی سیستم باید آسیب‌پذیری‌های احتمالی را که تیم‌ها ممکن است با عملکرد جدید معرفی کنند، شناسایی کند.

ساخت

در طول مرحله ساخت، تیم ها به طور مداوم کدهای جدید را ادغام می کنند. خودکارسازی ابزارهای ساخت و تست برای اجرا بر روی commit کد یکی از بهترین راه‌ها برای ادغام است.
پذیرفته شدن در مقایسه با عدم پذیرش تست های خودکار که هنوز قبول نشده اند و شکسته خورده اند، شاخص های عینی پیشرفت هستند. ایجاد کد خودکار تیم ها را قادر می سازد تا مشکلات را قبل از اینکه بر بخش های مهم تری از سیستم تأثیر بگذارند، به سرعت برطرف کنند. پرداختن به یک فرم و چارچوب شکسته باید بالاترین اولویت باشد. یک «تعهد دروازه‌ای» تضمین می‌کند که نرم‌افزار قبل از بررسی در پایگاه کد اصلی یا ترانک، از گیت عبور کرده است (مانند واحد تست شده، تست عملکرد، عاری از نقص شناخته‌شده و غیره). کدهایی که تست ها را پشت سر می گذارند به طور خودکار یکپارچه می شوند، که پیچیدگی های مدیریت چندین شاخه کد منبع را حذف می کند. توسعه مبتنی بر Trunk کمک می کند تا اطمینان حاصل شود که کد می تواند در صورت تقاضا به طور قابل اعتماد و بدون انجماد کد پرهزینه منتشر شود. پنج روش می تواند به ایجاد یک راه حل با کیفیت بالا کمک کند:

ادغام کد پیوسته – commit کد باید به طور خودکار کامپایل و آزمایش تغییرات را آغاز کند. در حالت ایده آل، این اتفاق در هر commit می افتد و باید چندین بار در روز اتفاق بیفتد.
ساخت و تست اتوماسیون – فرآیند کامپایل خودکار شامل تست‌های سطح واحد و داستان برای تأیید تغییرات است، که اغلب به دوبار آزمایش برای فعال کردن ساخت‌های سریع و تکرار سیستم‌های دیگر نیاز دارد.
توسعه مبتنی بر Trunk – تیم ها باید کد را به سرعت، حداقل یک بار در روز، یا در حالت ایده آل پس از انجام تعهد، یکپارچه کنند، و همه تیم ها باید از یک تنه استفاده کنند، و از شاخه های طولانی مدت اجتناب کنند.
تعهد دروازه‌ای – تعهد به صندوق اصلی خطرناک است، زیرا تغییرات شکسته می‌تواند بر بسیاری از تیم‌ها تأثیر بگذارد. بنابراین، فقط تغییراتی که از طریق فرآیند ساخت و آزمایش تأیید شده اند در این شاخه ادغام می شوند.
امنیت برنامه – ابزارهای تجزیه و تحلیل کد، کد و بسته های شخص ثالث را برای آسیب پذیری های شناخته شده بازرسی می کنند. به طور ایده آل پس از هر commit، تست سطح سیستم اغلب در طول تکرار اتفاق می افتد. با این حال، هر شرایطی که باشد، چنین یکپارچه سازی کامل سیستم باید حداقل یک بار در هر تکرار انجام شود. در غیر این صورت، کشف دیرهنگام عیوب و مسائل از تکرارهای قبلی باعث ایجاد دوباره کاری و تأخیر قابل توجهی می شود.

راه حل انتها به انتها آزمایش کنید

در حالی که تست داستان محلی و خودکار حیاتی و خودکار کافی نیست. یکپارچه سازی و آزمایش در سطح سیستم برای آزمایش کامل ویژگی ها مورد نیاز است. شکل ۳ نشان می دهد که چگونه تیم سیستم به ادغام کار همه تیم ها در ART به طور مکرر کمک می کند و شواهد عینی از پیشرفت ارائه می دهد.
پنج روش می تواند به بهبود تست سیستم انتها به انتها کمک کند:

تطابق محیط آزمایش و تولید – تطابق محیط اطمینان می دهد که آزمایش راه حل را همانطور که در مقابل کاربران زنده رفتار می کند اعمال می کند و احتمال فرار از عیوب به تولید را کاهش می دهد.
اتوماسیون تست – تست خودکار باید شامل انواع تست ها مانند عملکرد، ادغام، رگرسیون و غیره باشد. مقاله Agile Testing یک ماتریس آزمایشی را توضیح می دهد که چه چیزی می تواند و باید خودکار شود.
مدیریت داده های تست – برای ایجاد ثبات، تست ها باید سازگار و واقع بینانه باشند و تولید را تا حد امکان تکرار کنند و تحت کنترل منبع باشند.
مجازی سازی سرویس – انواع مختلف تست به محیط های متفاوتی نیاز دارند. مجازی‌سازی‌های سرویس به تیم‌ها اجازه می‌دهد تا یک محیط تولید را بدون هزینه‌ها و تلاش‌های مرتبط با ایجاد و مدیریت زیرساخت‌های فیزیکی شبیه‌سازی کنند.
تست الزامات غیرعملکردی (NFR) – ویژگی‌های سیستم، مانند امنیت، قابلیت اطمینان، عملکرد، مقیاس‌پذیری و قابلیت استفاده، حیاتی هستند و نیاز به آزمایش دارند.
ادغام مستمر با تامین کنندگان – تامین کنندگان کمک های منحصر به فردی را به ارمغان می آورند که زمان تحویل را کاهش می دهد و تحویل ارزش را بهبود می بخشد و نیاز به یکپارچگی مداوم دارد. این به اتخاذ یک آهنگ یکپارچه سازی مشترک و ایجاد نقاط عطف ارزیابی عینی کمک می کند.

 

یکپارچه سازی کار همه تیم ها در ART

شکل ۳. یکپارچه سازی کار همه تیم ها در ART

صحنه

در نهایت، ART باید کل راه حل را در مرحله بندی بر اساس شیوه های زیر تأیید کند:
یک محیط صحنه سازی را حفظ کنید – یک محیط صحنه سازی که بسیار شبیه به تولید است، مکان چنین اعتبار سنجی را فراهم می کند.

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

 

ایجاد فرهنگ یکپارچه سازی مدوام

ادغام مداوم سیستم های بزرگ و پیچیده سفری زمان بر است. بخش زیر پیشنهادهایی برای ایجاد فرهنگ و عمل CI پر رونق ارائه می دهد.

ادغام مکرر – هر چه تیم ها بیشتر ادغام شوند، سریعتر مشکلات را پیدا می کنند. و هر چه انجام آن سخت‌تر باشد، بیشتر اوقات نیاز به انجام آن دارند. این روش موانع را از بین می برد و اتوماسیون را در طول مسیر اضافه می کند و در نتیجه چرخه های یادگیری سریع تر و دوباره کاری کمتر می شود.
نتایج یکپارچه سازی را قابل مشاهده کنید – وقتی فرآیند یکپارچه سازی شکسته می شود، همه باید بدانند که چرا شکست خورده است. وقتی رفع شد، ایجاد تست‌های جدید باید مشکل را زودتر تشخیص دهد و از تکرار آن جلوگیری کند.
رفع ادغام‌های ناموفق اولویت اصلی است – تیم‌هایی که از طریق شکست‌های یکپارچه‌سازی به کار خود ادامه می‌دهند از ارزش‌ها و فرهنگ مرتبط با ساخت سیستم‌های آماده تولید کوتاهی می‌کنند. تیم‌ها اغلب از چراغ‌های چشمک زن یا اعلان‌های دیگر استفاده می‌کنند، که توجه را به ساختار شکسته جلب می‌کند و نشانگرهای قابل مشاهده را نشان می‌دهد که درصد زمان خراب شدن سیستم را نشان می‌دهد.
یک ریتم مشترک ایجاد کنید – نقاط ادغام زمانی قابل دسترسی تر هستند که همه تیم ها از یک ریتم ثابت پیروی کنند. فرض کنید تیم ها نتوانند یک ادغام کامل را در یک تکرار انجام دهند.
در آن صورت، آنها می‌توانند در کوتاه‌مدت در مورد آنچه ممکن است معاوضه کنند و در عین حال تکنیک‌ها و زیرساخت‌های خود را برای رسیدن به این هدف بهبود می‌بخشند.
توسعه و حفظ زیرساخت مناسب – یکپارچگی مداوم مؤثر به در دسترس بودن محیط های آزمایش و مرحله بندی بستگی دارد. البته زیرساخت یک سرمایه گذاری است. اما Lean-Agile Leaders دیدگاه بلندی دارند و سرمایه‌گذاری‌های لازم را امروز برای افزایش سرعت برای ماراتن پیش رو انجام می‌دهند.
اعمال روش‌های مهندسی نرم‌افزار پشتیبان – یکپارچه‌سازی مستمر هنگام طراحی سیستم‌ها با در نظر گرفتن این نگرانی‌ها قابل دسترس‌تر است. توسعه آزمایشی و برنامه ریزی برای آزمایش پذیری نیاز به راه حل های مدولارتر و تفکیک نگرانی ها و همچنین استفاده از رابط های اولیه و نقاط آزمایش فیزیکی دارد.

یکی دیگر از جنبه های مهم فرهنگ CI تضمین جریان سریع ارزش از طریق خط لوله است. برای اطلاعات بیشتر در مورد ایجاد جریان ارزش بدون وقفه به مقاله ART Flow مراجعه کنید (اصل شماره ۶).

فعال کردن یکپارچه سازی مداوم با DevOps

یکپارچه‌سازی مستمر شامل فعالیت‌های «توسعه» حیاتی است که در ابتدا الهام‌بخش «Dev» در DevOps بود. این فعالیت ها بر توسعه راه حل و جریان خط لوله از طریق محیط های پیش تولید متمرکز هستند. استفاده از تفکر، شیوه‌ها و ابزار DevOps در این بخش از جریان ارزش، توسعه سریع، ادغام مکرر کد، و کیفیت داخلی و انطباق را امکان‌پذیر می‌سازد. همانطور که در شکل ۴ نشان داده شده است، DevOps (مرکز) یکپارچگی مداوم و چندین حوزه کاربردی را (حلقه های داخلی) را امکان پذیر می کند. هر یک از چهار فعالیت (به رنگ سبز) یک تلاش مشترک است که از تخصص DevOps از چندین رشته برای به حداکثر رساندن سرعت و کیفیت تحویل استفاده می کند. به عنوان مثال، ساخت راه‌حل‌ها در خط لوله تحویل پیوسته از چندین دامنه DevOps عبور می‌کند.

بررسی کد در کنترل نسخه، خط لوله استقرار را برای فراخوانی خودکار ادغام، کیفیت و بررسی های امنیتی فعال می کند، سپس پیکربندی های ذخیره شده به عنوان کد را برای ساخت باینری های قابل حمل و تمام پشته اعمال می کند. با استفاده از DevOps، این فرآیند معمولاً کد منبع را به سرعت به راه حل های آزمایش شده و قابل استقرار تبدیل می کند. هر چهار فعالیت ادغام پیوسته توسط DevOps فعال می‌شوند، هرچند با ترکیب‌های متفاوتی از شیوه‌های فنی و ابزار. برای راهنمایی دقیق تر در مورد DevOps و نحوه اجازه دادن به خط لوله تحویل مداوم، سری مقالات DevOps را ببینید.

DevOps یکپارچه سازی مداوم را امکان پذیر می کند

شکل ۴. DevOps یکپارچه سازی مداوم را امکان پذیر می کند

 

جهت ارتقاء سطح کیفی مقالات و تکمیل مباحث مربوطه، لطفا نظرات و دیدگاههای خود را در پایان این مقاله درج کنید، همچنین چند مقاله مرتبط با موضوع استراتژی بازاریابی کششی برای مخاطبان سایت شریف استراتژی به اشتراک گذاشته شده است.

0 پاسخ
دیدگاه خود را ثبت کنیدتمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *