چگونه وصله های نرم افزاری را در GitLab منتشر می کنیم

در GitLab، ما اصلاحات نرم افزار را به دو صورت پردازش می کنیم: دستی و خودکار. برای آشنایی با کار مدیر انتشار در ایجاد و ارائه به‌روزرسانی‌های مهم از طریق استقرار خودکار در gitlab.com، و همچنین وصله‌هایی برای کار با آنها در نصب‌های خود، به ادامه مطلب مراجعه کنید.

توصیه می‌کنم یک یادآوری در ساعت هوشمند خود تنظیم کنید: هر ماه در 22ام، کاربرانی که با GitLab در امکانات خود کار می‌کنند می‌توانند به‌روزرسانی‌های نسخه فعلی محصول ما را ببینند. نسخه ماهانه شامل ویژگی‌های جدید، پیشرفت‌های موجود است و اغلب نتیجه نهایی درخواست‌های جامعه برای ابزارسازی یا ادغام را نشان می‌دهد.

اما، همانطور که تمرین نشان می دهد، توسعه نرم افزار به ندرت بدون نقص است. هنگامی که یک اشکال یا آسیب‌پذیری امنیتی کشف می‌شود، مدیر انتشار در تیم تحویل یک وصله برای کاربران ما با نصب‌هایشان ایجاد می‌کند. Gitlab.com در طول فرآیند CD به روز می شود. ما این فرآیند CD را استقرار خودکار می نامیم تا از سردرگمی با ویژگی CD در GitLab جلوگیری کنیم. این فرآیند می‌تواند پیشنهادهایی از درخواست‌های کششی ارسال شده توسط کاربران، مشتریان و تیم توسعه داخلی ما را در بر بگیرد، به طوری که حل مشکل خسته‌کننده انتشار وصله‌ها به دو روش بسیار متفاوت حل می‌شود.

«ما اطمینان می‌دهیم که هر چیزی که توسعه‌دهندگان می‌سازند، هر روز در همه محیط‌ها مستقر می‌شود، قبل از اینکه در GitLab.com منتشر شود."، توضیح می دهد مارین یانکوکی، مدیر ارشد فنی، بخش زیرساخت. "نسخه‌های نصب‌شده خود را به‌عنوان عکس‌های فوری برای استقرار gitlab.com در نظر بگیرید، که برای آن مراحل جداگانه‌ای برای ایجاد یک بسته اضافه کرده‌ایم تا کاربران ما بتوانند از آن برای نصب بر روی نصب‌های خود استفاده کنند.'.

صرف نظر از اشکال یا آسیب‌پذیری، مشتریان gitlab.com در مدت کوتاهی پس از انتشار، رفع‌هایی را دریافت می‌کنند که این یکی از مزایای فرآیند خودکار CD است. وصله‌ها برای کاربرانی که نصب‌های خودشان را دارند نیاز به آماده‌سازی جداگانه توسط مدیر انتشار دارد.

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

«هدف تیم تحویل این است که مطمئن شویم ما می توانیم به عنوان یک شرکت سریعتر حرکت کنیم، یا حداقل کاری کنیم که تحویل دهندگان سریعتر کار کنند.مارین می گوید؟

هم مشتریان gitlab.com و هم کاربران تاسیسات خود از تلاش های تیم تحویل برای کاهش زمان چرخه و سرعت بخشیدن به استقرار بهره می برند. در این مقاله شباهت ها و تفاوت های این دو روش را توضیح خواهیم داد. مسائلو همچنین توضیح خواهیم داد که تیم تحویل ما چگونه وصله‌هایی را برای کاربرانی که روی امکاناتشان کار می‌کنند آماده می‌کند، و همچنین نحوه اطمینان از به روز بودن gitlab.com با استفاده از استقرار خودکار را شرح خواهیم داد.

مدیر انتشار چه کاری انجام می دهد؟

اعضای تیم ماهانه انتقال نقش مدیر انتشار نسخه‌های ما برای کاربران در امکانات آنها، از جمله وصله‌ها و نسخه‌های امنیتی که ممکن است بین نسخه‌ها رخ دهد. آنها همچنین مسئول انتقال شرکت به استقرار خودکار و مداوم هستند.

مارین توضیح می‌دهد که نسخه‌های خودنصب و نسخه‌های gitlab.com از گردش‌های کاری مشابهی استفاده می‌کنند، اما در زمان‌های مختلف اجرا می‌شوند.

اول از همه، مدیر انتشار، صرف نظر از نوع انتشار، تضمین می‌کند که GitLab از لحظه راه‌اندازی برنامه در gitlab.com در دسترس و ایمن است، از جمله اطمینان حاصل می‌کند که مشکلات مشابه به زیرساخت مشتریان ختم نمی‌شود. ظرفیت های خود

هنگامی که یک باگ یا آسیب‌پذیری در GitLab ثابت شد، مدیر انتشار باید ارزیابی کند که در وصله‌ها یا به‌روزرسانی‌های امنیتی برای کاربران با نصب‌هایشان گنجانده می‌شود. اگر تصمیم بگیرد که یک باگ یا آسیب‌پذیری مستحق به‌روزرسانی است، کار مقدماتی آغاز می‌شود.

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

همه چیز در مورد اصلاحات است

پچ ها چیست و چرا به آنها نیاز داریم؟

مدیر انتشار بر اساس شدت باگ تصمیم می‌گیرد که آیا اصلاحی را منتشر کند.

خطاها بسته به شدت آنها متفاوت است. بنابراین خطاهای S4 یا S3 می توانند سبک باشند، مانند تغییر مکان پیکسل یا نماد. Marin توضیح می‌دهد که این اهمیت کمتری ندارد، اما تأثیر قابل‌توجهی بر گردش کار هیچ‌کس ندارد، به این معنی که احتمال ایجاد یک اصلاح برای چنین خطاهای S3 یا S4 کم است.

با این حال، آسیب‌پذیری‌های S1 یا S2 به این معنی است که کاربر نباید به آخرین نسخه به‌روزرسانی شود، یا یک باگ مهم وجود دارد که بر گردش کار کاربر تأثیر می‌گذارد. اگر آنها در ردیاب گنجانده شوند، بسیاری از کاربران با آنها مواجه شده اند، بنابراین مدیر انتشار بلافاصله شروع به تهیه یک اصلاح می کند.

هنگامی که یک وصله برای آسیب پذیری های S1 یا S2 آماده شد، مدیر انتشار شروع به انتشار وصله می کند.

به عنوان مثال، وصله GitLab 12.10.1 پس از شناسایی چندین مشکل مسدود کردن ایجاد شد و توسعه دهندگان مشکل اصلی ایجاد شده را برطرف کردند. مدیر انتشار صحت سطوح شدت تعیین‌شده را ارزیابی کرد و پس از تأیید، روند انتشار یک اصلاح راه‌اندازی شد که پس از کشف مشکلات مسدودسازی ظرف ۲۴ ساعت آماده شد.

هنگامی که تعداد زیادی از S4، S3 و S2 انباشته می شوند، مدیر انتشار به زمینه نگاه می کند تا فوریت انتشار یک اصلاح را تعیین کند، و وقتی به تعداد معینی از آنها رسید، همه آنها ترکیب و آزاد می شوند. اصلاحات پس از انتشار یا به روز رسانی های امنیتی در پست های وبلاگ خلاصه می شود.

چگونه یک مدیر انتشار وصله ایجاد می کند

ما از GitLab CI و سایر ویژگی‌ها مانند ChatOps خود برای تولید وصله‌ها استفاده می‌کنیم. Release Manager انتشار رفع مشکل را با فعال کردن تیم ChatOps در کانال داخلی ما آغاز می کند #releases در اسلک.

/chatops run release prepare 12.10.1

ChatOps در Slack برای راه‌اندازی رویدادهای مختلف کار می‌کند که سپس توسط GitLab پردازش و اجرا می‌شوند. به عنوان مثال، تیم تحویل ChatOps را برای خودکارسازی موارد مختلف برای انتشار وصله ها راه اندازی کرد.

هنگامی که مدیر انتشار، تیم ChatOps را در Slack راه اندازی کرد، بقیه کارها به طور خودکار در GitLab با استفاده از CICD انجام می شود. ارتباط دو طرفه بین ChatOps در Slack و GitLab در طول فرآیند انتشار وجود دارد زیرا مدیر انتشار برخی از مراحل اصلی فرآیند را فعال می کند.

ویدئوی زیر مراحل فنی آماده سازی پچ برای GitLab را نشان می دهد.

نحوه استقرار خودکار در gitlab.com

فرآیند و ابزارهای مورد استفاده برای به روز رسانی gitlab.com مشابه مواردی است که برای ایجاد وصله ها استفاده می شود. به روز رسانی gitlab.com به کار دستی کمتری از دیدگاه مدیر انتشار نیاز دارد.

به‌جای اجرای استقرارها با استفاده از ChatOps، از ویژگی‌های CI استفاده می‌کنیم. خطوط لوله برنامه ریزی شده، که با آن مدیر انتشار می تواند اقدامات خاصی را برای انجام در زمان مورد نیاز برنامه ریزی کند. به جای یک فرآیند دستی، خط لوله ای وجود دارد که به صورت دوره ای یک بار در ساعت اجرا می شود که تغییرات جدید ایجاد شده در پروژه های GitLab را دانلود می کند، آنها را بسته بندی می کند و استقرار را برنامه ریزی می کند و به طور خودکار تست، QA و سایر مراحل لازم را اجرا می کند.

مارین می‌گوید: «بنابراین ما قبل از gitlab.com استقرارهای زیادی در محیط‌های مختلف اجرا می‌کنیم، و بعد از اینکه آن محیط‌ها در وضعیت خوبی قرار گرفتند و آزمایش نتایج خوبی نشان داد، مدیر انتشار اقدامات استقرار gitlab.com را شروع می‌کند.

فناوری CICD برای پشتیبانی از به‌روزرسانی‌های gitlab.com کل فرآیند را تا جایی خودکار می‌کند که مدیر انتشار باید به‌طور دستی استقرار محیط تولید را در gitlab.com راه‌اندازی کند.

مارین در ویدیوی زیر به جزئیات در مورد فرآیند به‌روزرسانی gitlab.com می‌پردازد.

تیم تحویل چه کار دیگری انجام می دهد؟

تفاوت اصلی بین فرآیندهای به‌روزرسانی gitlab.com و انتشار وصله‌ها برای مشتریان داخلی این است که فرآیند دوم به زمان بیشتر و کار دستی بیشتری از مدیر انتشار نیاز دارد.

مارین می‌گوید: «ما گاهی اوقات انتشار وصله‌ها را برای مشتریان با نصب‌هایشان به تأخیر می‌اندازیم، زیرا مشکلات گزارش‌شده، مشکلات ابزار، و به دلیل وجود تفاوت‌های ظریف بسیاری وجود دارد که باید هنگام انتشار یک پچ مورد توجه قرار گیرد.

یکی از اهداف کوتاه مدت تیم تحویل، کاهش حجم کار دستی مدیر انتشار برای تسریع در انتشار است. این تیم در تلاش است تا فرآیند انتشار را ساده، ساده و خودکار کند، که به رفع مشکلات کم شدت (S3 و S4، تقریبا مترجم). تمرکز بر سرعت یک شاخص کلیدی عملکرد است: لازم است MTTP - زمان دریافت درخواست ادغام تا استقرار نتیجه در gitlab.com - از 50 ساعت فعلی به 8 ساعت کاهش یابد.

تیم تحویل همچنین در حال کار بر روی انتقال gitlab.com به زیرساخت مبتنی بر Kubernetes است.

NB سردبیر: اگر قبلاً در مورد فناوری Kubernetes شنیده اید (و شک ندارم که دارید) اما هنوز آن را با دستان خود لمس نکرده اید، توصیه می کنم در دوره های فشرده آنلاین شرکت کنید. پایگاه کوبرنتیس، که 28 تا 30 سپتامبر برگزار می شود و Kubernetes Mega، که از 14 تا 16 اکتبر برگزار می شود. این به شما این امکان را می دهد که با اطمینان در این فناوری حرکت کنید و با آن کار کنید.

این دو رویکردی هستند که یک هدف را دنبال می‌کنند: تحویل سریع به‌روزرسانی‌ها، هم برای gitlab.com و هم برای مشتریان در امکانات آنها.

هیچ ایده یا توصیه ای برای ما دارید؟

از همه برای مشارکت در GitLab استقبال می شود و ما از بازخورد خوانندگان خود استقبال می کنیم. اگر ایده ای برای تیم تحویل ما دارید، دریغ نکنید درخواست ایجاد کنید با اخطار team: Delivery.

منبع: www.habr.com