عرضه یک پروژه جدید به تولید نیازمند تعادل دقیق بین سرعت استقرار و قابلیت اطمینان راه حل است. Slack تکرارهای سریع، چرخه های بازخورد کوتاه و پاسخ سریع به درخواست های کاربر را ارزش گذاری می کند. علاوه بر این، این شرکت دارای صدها برنامه نویس است که تلاش می کنند تا حد امکان سازنده باشند.
نویسندگان مطالبی که امروز ترجمه آن را منتشر می کنیم، می گویند که شرکتی که تلاش می کند به چنین ارزش هایی پایبند باشد و در عین حال رشد کند، باید دائماً سیستم استقرار پروژه خود را بهبود بخشد. شرکت باید روی شفافیت و قابلیت اطمینان فرآیندهای کاری سرمایه گذاری کند و این کار را انجام دهد تا اطمینان حاصل شود که این فرآیندها با مقیاس پروژه مطابقت دارند. در اینجا ما در مورد گردش کاری که در Slack ایجاد شده است و برخی از تصمیماتی که شرکت را به استفاده از سیستم استقرار پروژه که امروزه وجود دارد، صحبت خواهیم کرد.
فرآیندهای استقرار پروژه امروز چگونه کار می کنند
هر PR (درخواست کشش) در Slack باید در معرض بازبینی کد قرار گیرد و باید تمام تست ها را با موفقیت پشت سر بگذارد. تنها پس از برآورده شدن این شرایط، برنامه نویس می تواند کد خود را در شاخه اصلی پروژه ادغام کند. با این حال، این کد فقط در ساعات کاری، به وقت آمریکای شمالی مستقر می شود. در نتیجه، با توجه به اینکه کارکنان ما در محل کار خود هستند، ما آمادگی کامل برای حل هر گونه مشکل غیر منتظره را داریم.
ما هر روز حدود 12 استقرار برنامه ریزی شده را انجام می دهیم. در طول هر استقرار، برنامه نویسی که به عنوان هدایت کننده استقرار تعیین شده است، مسئول تولید ساخت جدید است. این یک فرآیند چند مرحله ای است که تضمین می کند مونتاژ بدون مشکل وارد تولید می شود. به لطف این رویکرد، می‌توانیم خطاها را قبل از اینکه روی همه کاربران ما تأثیر بگذارد، شناسایی کنیم. اگر خطاهای زیادی وجود داشته باشد، استقرار مونتاژ می تواند به عقب برگردد. اگر مشکل خاصی پس از انتشار کشف شود، می توان به راحتی یک راه حل برای آن منتشر کرد.
رابط سیستم Checkpoint که در Slack برای استقرار پروژه ها استفاده می شود
فرآیند استقرار نسخه جدید برای تولید را می توان شامل چهار مرحله در نظر گرفت.
▍1. ایجاد شعبه انتشار
هر نسخه با یک شاخه انتشار جدید شروع می شود، یک نقطه در تاریخچه Git ما. این به شما امکان می‌دهد تگ‌هایی را به نسخه اختصاص دهید و مکانی را فراهم می‌کند که در آن می‌توانید باگ‌هایی را که در فرآیند آماده‌سازی نسخه برای انتشار تا تولید یافت می‌شوند، رفع کنید.
▍2. استقرار در یک محیط صحنه سازی
مرحله بعدی استقرار اسمبلی بر روی سرورهای مرحله‌بندی و اجرای یک تست خودکار برای عملکرد کلی پروژه (تست دود) است. محیط صحنه سازی یک محیط تولیدی است که ترافیک خارجی را دریافت نمی کند. در این محیط، ما تست دستی اضافی را انجام می دهیم. این به ما اطمینان بیشتری می دهد که پروژه اصلاح شده به درستی کار می کند. تست های خودکار به تنهایی برای ارائه این سطح از اطمینان کافی نیستند.
▍3. استقرار در محیط های داگ فود و قناری
استقرار در تولید با یک محیط آزمایشی شروع می شود که توسط مجموعه ای از میزبان ها ارائه می شود که به فضاهای کاری داخلی Slack ما خدمات می دهند. از آنجایی که ما کاربران بسیار فعال Slack هستیم، استفاده از این رویکرد به ما کمک کرد تا در اوایل استقرار باگ های زیادی را پیدا کنیم. پس از اینکه مطمئن شدیم عملکرد اصلی سیستم خراب نیست، مجموعه در محیط قناری مستقر می شود. این نشان دهنده سیستم هایی است که تقریباً 2٪ از ترافیک تولید را تشکیل می دهند.
▍4. عرضه تدریجی به تولید
اگر نشانگرهای نظارتی برای نسخه جدید ثابت باشد و پس از استقرار پروژه در محیط قناری شکایتی دریافت نکردیم، به تدریج به انتقال سرورهای تولید به نسخه جدید ادامه می دهیم. فرآیند استقرار به مراحل زیر تقسیم می شود: 10٪، 25٪، 50٪، 75٪ و 100٪. در نتیجه می توانیم به آرامی ترافیک تولید را به نسخه جدید سیستم منتقل کنیم. در عین حال، ما زمان داریم تا در صورت مشاهده هر گونه ناهنجاری، وضعیت را بررسی کنیم.
▍اگر در حین استقرار مشکلی پیش بیاید چه؟
ایجاد تغییرات در کد همیشه یک خطر است. اما ما به لطف حضور "رهبران استقرار" آموزش دیده ای که فرآیند وارد کردن نسخه جدید به تولید را مدیریت می کنند، شاخص های نظارت را نظارت می کنند و کار برنامه نویسان را که کد را منتشر می کنند هماهنگ می کنند، با این امر کنار می آییم.
در صورتی که واقعا مشکلی پیش بیاید، ما سعی می کنیم مشکل را در اسرع وقت شناسایی کنیم. ما مشکل را بررسی می‌کنیم، روابط عمومی را که باعث خطا می‌شود، پیدا می‌کنیم، آن را به عقب برمی‌گردانیم، آن را به طور کامل تجزیه و تحلیل می‌کنیم و یک ساخت جدید ایجاد می‌کنیم. درست است، گاهی اوقات مشکل تا زمانی که پروژه به مرحله تولید برسد، مورد توجه قرار نمی گیرد. در چنین شرایطی، مهمترین چیز بازگرداندن سرویس است. بنابراین، قبل از شروع بررسی مشکل، بلافاصله به بیلد کاری قبلی برمی گردیم.
بلوک های ساختمان یک سیستم استقرار
بیایید به فناوری هایی نگاه کنیم که زیربنای سیستم استقرار پروژه ما هستند.
▍استقرار سریع
گردش کار شرح داده شده در بالا ممکن است، در نگاهی به گذشته، تا حدودی بدیهی به نظر برسد. اما سیستم استقرار ما بلافاصله به این شکل نشد.
زمانی که شرکت بسیار کوچکتر بود، کل برنامه ما می توانست روی 10 نمونه آمازون EC2 اجرا شود. استقرار پروژه در این شرایط به معنای استفاده از rsync برای همگام سازی سریع همه سرورها بود. پیش از این، کد جدید تنها یک قدم با تولید فاصله داشت که توسط یک محیط مرحله‌بندی نمایش داده می‌شد. مجموعه ها در چنین محیطی ایجاد و آزمایش شدند و سپس مستقیماً به سمت تولید رفتند. درک چنین سیستمی بسیار آسان بود؛ این امکان را به هر برنامه نویسی می داد تا کدی را که نوشته بود در هر زمان اجرا کند.
اما با افزایش تعداد مشتریان ما، مقیاس زیرساخت های مورد نیاز برای حمایت از پروژه نیز افزایش یافت. به زودی، با توجه به رشد مداوم سیستم، مدل استقرار ما، بر اساس فشار دادن کد جدید به سرورها، دیگر کار خود را انجام نمی داد. یعنی افزودن هر سرور جدید به معنای افزایش زمان لازم برای تکمیل استقرار است. حتی استراتژی های مبتنی بر استفاده موازی از rsync محدودیت های خاصی دارند.
ما در نهایت با انتقال به یک سیستم استقرار کاملاً موازی که متفاوت از سیستم قدیمی طراحی شده بود، این مشکل را حل کردیم. یعنی اکنون ما کدی را با استفاده از اسکریپت همگام سازی به سرورها ارسال نکردیم. اکنون هر سرور به طور مستقل اسمبلی جدید را دانلود کرد، زیرا می دانست که باید این کار را با نظارت بر تغییر کلید کنسول انجام دهد. سرورها کد را به صورت موازی بارگذاری کردند. این به ما این امکان را می‌دهد که حتی در محیطی با رشد ثابت سیستم، سرعت بالایی از استقرار را حفظ کنیم.
1. سرورهای تولیدی کلید Consul را نظارت می کنند. 2. کلید تغییر می کند، این به سرورها می گوید که باید شروع به دانلود کد جدید کنند. 3. سرورها فایل های تربال را با کد برنامه دانلود می کنند
▍استقرارهای اتمی
راه حل دیگری که به ما کمک کرد به یک سیستم استقرار چند لایه برسیم، استقرار اتمی بود.
قبل از استفاده از استقرار اتمی، هر استقرار می تواند منجر به تعداد زیادی پیام خطا شود. واقعیت این است که فرآیند کپی فایل های جدید در سرورهای تولیدی اتمی نبود. این منجر به یک پنجره زمانی کوتاه شد که در آن کدی که توابع جدید را فراخوانی می کرد، قبل از در دسترس بودن خود توابع در دسترس بود. هنگامی که چنین کدی فراخوانی شد، منجر به بازگشت خطاهای داخلی شد. این خود را در درخواست های API ناموفق و صفحات وب شکسته نشان داد.
تیمی که روی این مشکل کار کرد با معرفی مفهوم دایرکتوری های "گرم" و "سرد" آن را حل کرد. کد موجود در دایرکتوری داغ وظیفه پردازش ترافیک تولید را بر عهده دارد. و در دایرکتوری های "سرد"، کد، در حالی که سیستم در حال اجرا است، فقط برای استفاده آماده می شود. در حین استقرار، کد جدید در یک دایرکتوری سرد استفاده نشده کپی می شود. سپس، هنگامی که هیچ فرآیند فعالی در سرور وجود ندارد، یک سوئیچ دایرکتوری فوری انجام می شود.
1. بسته بندی کد برنامه را در یک فهرست "سرد" باز کنید. 2. تغییر سیستم به دایرکتوری "سرد" که تبدیل به "گرم" می شود (عملیات اتمی)
نتایج: تغییر در تاکید بر قابلیت اطمینان
در سال 2018، این پروژه به حدی رشد کرد که استقرار بسیار سریع شروع به آسیب رساندن به پایداری محصول کرد. ما یک سیستم استقرار بسیار پیشرفته داشتیم که برای آن زمان و تلاش زیادی صرف کردیم. تنها کاری که ما نیاز داشتیم این بود که فرآیندهای استقرار خود را بازسازی و بهبود بخشیم. ما به یک شرکت نسبتاً بزرگ تبدیل شده ایم که از پیشرفت های آن در سراسر جهان برای سازماندهی ارتباطات بی وقفه و حل مشکلات مهم استفاده شده است. بنابراین، قابلیت اطمینان در کانون توجه ما قرار گرفت.
ما باید فرآیند استقرار نسخه‌های جدید Slack را ایمن‌تر کنیم. این نیاز ما را به بهبود سیستم استقرار خود سوق داد. در واقع، ما این سیستم بهبود یافته را در بالا مورد بحث قرار دادیم. در اعماق سیستم، ما همچنان از فناوری های استقرار سریع و اتمی استفاده می کنیم. نحوه استقرار تغییر کرده است. سیستم جدید ما برای استقرار تدریجی کدهای جدید در سطوح مختلف و در محیط های مختلف طراحی شده است. ما اکنون از ابزارهای پشتیبانی پیشرفته و ابزارهای نظارت بر سیستم نسبت به قبل استفاده می کنیم. این به ما این توانایی را می‌دهد که خطاها را مدت‌ها قبل از اینکه فرصتی برای دستیابی به کاربر نهایی داشته باشند، شناسایی و رفع کنیم.
اما قرار نیست به همین جا بسنده کنیم. ما دائماً در حال بهبود این سیستم هستیم و از ابزارهای کمکی پیشرفته تر و ابزارهای اتوماسیون کار استفاده می کنیم.
خوانندگان عزیز! روند استقرار نسخه های جدید پروژه در جایی که شما کار می کنید چگونه کار می کند؟
منبع: www.habr.com