10 بهروش در پیاده سازی CI/CD

تمرین 1- کل پروسه را در اختصاص یک تیم درآورید:اگر کل پروسه CI/CD، از برآورد نیازهای توسعه تا انجام مانیتورینگ در انحصار یک تیم هر چند کوچک DevOps باشد معنی DevOps تجلی خواهد یافت(برای سازمانهای بزرگ و Enterprise میتوان از راهکار مبتنی بر SRE جهت تشکیل تیمهای مرتبط استفاده کرد). استفاده از یک تیم مستقل ملاحظات زیر را در بر خواهد داشت:مالکیت هر یک از مراحل و Pipelineهای تحویل مستمر، شامل اینکه نرم ­افزار چگونه ساخته شده و پروسه تست و پیاده ­سازی آن به چه نحوی صورت گرفته است منحصر به یک تیم خواهد بوداجتناب از داشتن یک متخصص Pipeline، بطوریکه تمامی افراد تیم میبایست قادر به نوشتن Pipelineها باشنداستفاده از یک ابزار مناسب جهت نمایش وضعیت فعلی Pipeline، مثلاً استفاده از یک صفحه تصویری بزرگاگر تمامی اعضای تیم DevOps شامل توسعه ­دهندگان، QA و مهندسین IT دارای تخصصهای مجزایی بودند، اطمینان حاصل کنید که در یک تیم مشترک کار خود را انجام دهند، داشتن تیمهای مجزا به معنی داشتن مسؤولیتهای مجزا می­ باشددادن استقلال به تیم موجب افزایش رضایت و افزایش جلب توجه اعضا و داشتن محصول بسیار خوب خواهد شدتمرین 2-همه چیز را خودکار کنید:هر چیزی، از نیازهای کسب ­و کار در قالب تستهای UAT، تا پروسه ارائه محصول را خودکارسازی کنید. هرگونه روال دستی که بر روی کاغذ نوشته شود، تاریخ مصرف گذشته و بی­ مصرف گردیده و موجب ایجاد دانش محلی می ­شود و کند شدن انجام کارها و روزمرگی را بهمراه خواهد داشت. بطور خلاصه هر کاری که برای بار دوم بصورت مشابه انجام شود، قابلیت خودکارسازی دارد:تمامی مراحل دستی را حذف نمایید، چراکه مستعد اشتباه می ­باشند. کل پروسه میبایست تکراپذیر و قابل اطمینان باشدهیچگونه عملیاتی نمیبایست بصورت دستی در محیطهای اجرایی انجام شود، تمامی کارها بهتر است از طریق ابزارهای مدیریت تنظیمات صورت بگیرداز مکانیزمهای مشابه، جهت پیاده ­سازی محصول در محیطهای مختلف استفاده نماییدهمیشه از یک Smoke Test خودکارسازی شده، جهت محکم ­کاری و اطمینان از صحت انجام کار در مراحل مختلف استفاده نماییداز Schema Migration جهت خودکارسازی در پروسه تغییرات پایگاه داده استفاده نماییداز Scriptهای خودکارسازی شده جهت پشتیبان­ گیری و پاکسازی محیطهای مختلف استفاده نماییدتمرین 3- برای هر چیزی یک سیستم نسخه ­سازی ایجاد کنید:برای هر چیزی نسخه ­های مختلف ایجاد نمایید، از سورس کد Build شده، کد باینری اصلی­ ، تستهای خودکارسازی شده، مدیریت تنظیمات، کدهای باینری­ جانبی، مانیتورینگ، مستند­سازی، اسکریپتهای مختلف و هر چیز دیگری. تمامی کارهای را مبتنی بر Task انجام دهید، بطوریکه نتیجه آن Task در یک Repository قرار بگیرد. این Taskها میتوانند از جمع­ آوری نیازها تا طراحی معماری و تنظیمات باشد. در این حالت تنها یک منبع حقیقت یا Single Point of Truth را بدست خواهید آورد:در مورد سیستم کنترل نسخه ­ها یا Version Control سخت­گیر باشید، همه چیز یعنی همه چیزسورس ­کد را داخل یک Repository، باینری­ها را داخل یک Artifact Repository و Taskها را در داخل یک سیستم ردیابی مبتنی بر Agile قرار دهید.سیستم تحویل مستمر (Continuous Delivery) را مبتنی بر کد(Pipeline As Code) توسعه دهیدپروسه انتقال پایگاه ­داده (Database Migration) را مورد استفاده قرار داده و آنرا در داخل یک Repository قرار دهیدمستندات ­سازی را در مسیر کد و در فایل مربوطه قرار داده و آنرا در یک Repository نگهداری کنیدتمرین 4- از زبان­ کسب و کار جهت تعریف تستهای سمت کاربر استفاده کنید:از زبان سمت کلاینت و کسب­ و­کار برای انجام تستهای UAT و ارتباطات دوسویه و ایجاد شناخت مشترک از نیازمندیها، استفاده نمایید(یک زبان مشترک مابین کسب­­ و­ کار و تکنولوژی). سوء تفاهم ریشه بوجود آمدن مشکلات است:یک چارچوب گفتاری مشترک ایجاد کرده و در پروژه از آن استفاده نماییداز یک چارچوب­ کاری مشخص جهت انجام تستها و درگیر کردن تیمهای مختلف مرتبط با کسب­ و­ کار استفاده کنید(نظیر Cucumber یا FitNesse)ارزشهای کسب ­و ­کار را تشریح کرده و در پروسه توسعه­­ ی نرم­ افزار، مورد استفاده قرار دهید. انحراف از این ارزشها و انجام کارهای بیهوده بسیار آسان و بی­ نتیجه استتستهای UAT را همواره نگهداری و بهبود دهید و انجام آنها را همیشه تجدید نماییدبرای همه روشن کنید محصول تنها زمانی ارائه خواهد شد که تستهای UAT را با موفقیت سپری کرده باشدتمرین 5- همیشه برای بازگرداندن نسخه و Roll back آمادگی داشته باشید:همیشه برای Roll back آماده باشید، چراکه دیر یا زود اتفاق می­افتد. هر چقدر تعداد پرسنل QA کمتر باشد، پروسه Roll back میبایست در زمان کوتاه تری برنامه ریزی و اجرا شود. اگر هر گونه اشتباهی در محیط عملیاتی اتفاق بافتد، اولین کار، انجام کار امن و بازگرداندن به بهترین نسخه­ ی موجود است:یک استراتژی Roll back و یک روال را برای انجام کارها در صورت از مدار خارج شدن سرویس، توسعه دهید پایگاه ­داده ­هایی که با نسخه ­ی نرم ­افزاری سازگار نیست را از پایگاه ­داده ­های سازگار جدا و برای آنها بصورت مستقل برنامه­ ریزی کنیداز یک روال مشابه با Release استاندارد، برای Roll back نیز استفاده نماییداز یکی از متدهای پیاده­ سازی پیشرفته نظیر Blue-Green یا Canary استفاده نماییدهیچوقت از باگها وحشت نداشته باشید. اگر شما سریع عکس ­العمل داشته باشید، کاربران هیچوقت شما را ترک نمی­ کنندتمرین 6- هیچوقت پیامدهای مربوط به نیروی انسانی را دست کم نگیرید:هیچوقت نیروی انسانی را دست کم نگیرد، اگر بخواهید پروسه تحویل مستمر را خودکارسازی نمایید ولی پرسنل همکاری نکنند، آن پروسه به شکست خواهد انجامید.در انتها این پرسنل هستند که از پروسه ­ها آگاه می ­باشند بنابراین برای تمام تیمها(حتی کسب­ و­ کار) نقش افراد را با اهمیت در نظر گرفته و آنها را در پروسه ها دخیل نمایید:حتماً تیمهای مختلف عملیات (IT Operations) و تیمهای تضمین کیفیت (QA) را در داخل تیم DevOps قرار دهید چراکه تخصص آنها مورد نیاز می­ باشدآموزشهای مختلف را جهت تبدیل نمودن کارها از حالت دستی به حالت خودکارسازی شده، به تمامی اعضا، ارائه دهیدداشتن ساختار یک پارچه (Flat Structure) به داشتن سازمان با ساختار سلسله مراتبی و همچنین داشتن ساختار ارتباطی غیررسمی به ساختار ارتباطی رسمی اولویت داردتمرین 7-ردیابی درونکاری شده را بکار بگیرید:داشتن یک سیستم ردیابی درونکاری شده در پروسه تحویل مداوم و یا سیستمهای عملیاتی لازم است. هیچ چیز به اندازه­ ی بوجود آمدن اختلال، بدون داشتن لاگهای مرتبط نمی­ تواند مشکل ساز باشد. همیشه تعداد درخواستها، تأخیرها و لود سیستمهای عملیاتی و وضعیت Pipelineها در سیستم تحویل مستمر و هر چیز دیگری که جهت آنالیز وضعیت فعلی بتواند بشما کمک نماید را مانیتور نمایید. بصورت پیشگیرانه لاگها و وضعیت سیستم را همواره بررسی کنید:لاگهای مرتبط با Pipelineها را مانیتور نمایید، در صورت بوجود آمدن اختلال، تیم مرتبط را با پیام مناسب، مطلع نماییدیک پروسه لاگ و مانیتورینگ مناسب برای سیستم در حال اجرا، پیاده­ سازی نماییداز ابزارهای مناسب و استاندارد برای مانیتورینگ استفاده نمایید(نظیر Kibana، Grafana)سیستم مانیتورینگ برای سیستمهای عملیلاتی را با اکوسیستم توسعه نرم افزار، یکپارچه نمایید و از صفحات نمایش بزرگ، جهت نمایش وضعیت استفاده کنیدتمرین 8- عملیات CI را بصورت مستمر انجام دهیدعملیات CI را بصورت مستمر و همیشگی انجام دهید. هیچ چیزی بدتر از این نیست که بخواهید مشکلات Merge کردن سورس­ کد را برطرف کنید. CI کمتر به ابزار مربوط بوده و بیشتر به فرهنگ تیمی مرتبط می­ باشد. همواره از داشتن Feature-Branchهای طولانی مدت با تعییرات زیاد برحذر باشید.بجای ایجاد Branchهای متعدد، سعی کنید کد را در Trunk نگه داشته و از قابلیت Feature Toggle استفاده کنیداگر Branch یا تغییرات محلی وجود داشته باشد، حداکثر یک مرتبه در روز میبایست با Baseline یا کد اصلی ترکیب یا Merge گرددهمیشه تنه­ ی اصلی کد یا Trunkرا سالم نگه داشته و قبل از Merge نمودن، از انجام تستها مطمئن باشیدبلافاصله بعد از ارائه کد یا Commit شدن آن، Pipeline را اجرا نمایید تا بازخورد سریعتری از تغییرات پیدا کنیدتمرین 9-Binaryها را فقط یک مرتبه بسازیدساختن باینریها (Build) میبایست تنها یکبار انجام شود و سپس در محیطهای تعریف شده مورد استفاده قرار بگیرد. رعایت این مورد، ریسک داشتن محیطهای با رفتارهای مختلف را برطرف نموده و صرفه­ جویی در منابع و زمان را بهمراه خواهد داشت:باینری را یکبار ساخته و بین محیطهای مختلف جابجا کنیداز یک Artifact Repository جهت نگهداری باینریها استفاده کرده و همیشه از نگهداری باینری بصورت محلی برحذر باشیدتنظیمات را در یک Repository و سیستم جانبی نگهداری کنید بطوریکه بتواند تفاوت مابین محیطهای مختلف را نمایش دهدتمرین 10- بصورت مستمر محصول و Release را ارائه دهید:ارائه محصول بصورت مستمر، موجب افزایش قابلیت پیش ­بینی و کاهش استرس خواهد شد. همواره از به تأخیر انداختن Release بر حذر باشید:ادبیات خود را به کار انجام شده تغییر دهید تا مقدار کارایی سیستم، ثابت شده یا افزایش یابداز قابلیت Feature Toggle جهت پنهان­ سازی قابلیتهای در حال توسعه نرم­ افزار از دید کاربران استفاده کنیداز پیاده­ سازی Canary و Roll backهای سریع جهت کاهش ریسک مرتبط با باگها، در محیطهای عملیاتی استفاده کنیداز استراتژیهایی که مقدار Downtime در آنها حداقل است (zero-downtime)، برای پیاده ­سازی استفاده نمایید