پیش‌نمایش‌های پیوسته (CP): تا زمانی که پیش‌نمایش نکنید، ادغام نشوید

پیتر مک کی داکر با بنیانگذاران Uffizzi، گریسون ادکینز – که به عنوان رئیس محصول خدمت می کند – و جاش تورمن – که به عنوان رئیس روابط توسعه دهنده خدمت می کند – برای پرسش و پاسخ در مورد روش CP می نشیند.

پخش زنده را ببینید. پخش جریانی از 26 آگوست برای
Docker Build: Enableting Full-Stack Continuous Previews with Uffizzi

(رونوشت زیر برای وضوح و فرمت ویرایش شده است)

Peter McKee:[09]خیلی خوب است، 19459 نمایش زنده من عاشق ایده پیش‌نمایش‌های مداوم هستم، به من بگویید چه چیزی شما را به این مفهوم رساند؟ ما همچنان دو مشکل را مشاهده کردیم که مانع پیشرفت رو به جلو بود.

در آن زمان جهت محصول Uffizzi به سمت آسان کردن توسعه‌دهندگان برای استقرار برنامه‌های خود در فضای ابری حرکت می‌کرد و زمانی که متوجه شدیم می‌توانیم «کد کثیف در اصلی» را اصلاح کنیم. و مشکلات "آیا هنوز می توانم آن را ببینم" با همان فرآیند من متوجه شدم که می توانیم آنچه را که ساخته بودیم به عنوان یک موتور پیش نمایش برای برنامه های تمام پشته و میکروسرویس ها تغییر کاربری دهیم – چیزی که در آن شما می توانید "پیش نمایش مستمر" آنچه را که در خط لوله ویژگی شما وجود دارد. 19659006] جاش تورمن: دو عنصر تصویر بزرگ دیگر وجود دارد که این موضوع را برای ما مورد توجه قرار داده است. همه موفقیت ابزارهای Frontend Preview را توسط پلتفرم های سایت ایستا مانند Netlify و Vercel دیده اند. موفقیت آنها به ما آموخت که آسان کردن پیش نمایش برای تیم ها بسیار ارزشمند است، اما هیچ کس واقعاً مفهوم و فناوری پشتیبانی را برای برنامه های پیچیده تر رسمی نکرده بود. بنابراین ما متوجه شدیم که مفهوم Preview نباید فقط برای frontendها اعمال شود، بلکه باید در مورد هر چیزی که ما می سازیم اعمال شود. با افزایش اندازه و پیچیدگی تیم ها و اکوسیستم های اپلیکیشن. بنابراین مفهوم Continuous Previews در واقع در مورد از بین بردن موانع برای همکاری زودهنگام و اغلب است – این در مورد از بین بردن همه موانع بین برنامه‌نویس برنامه‌نویس ویژگی و عضو تیمی است که آن را بررسی یا تأیید می‌کند.

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

پیتر مک کی:  من مانیفست CP (www.cpmanifesto.org / https://github.com/UffizziCloud/Continuous_Previews_Manifesto) را خوانده‌ام که اصول CP را برای نوشتن و انتشار مطالب الهام گرفته است. که؟

جاش تورمن:  برای ما واضح بود که CP بسیار بزرگتر از هر ابزار یا سرویسی است، و همچنین می‌دانیم که به راحتی می‌توان ابزارها یا محصولات را با مفاهیم اشتباه گرفت. بنابراین ما از مانیفست چابک سرنخ گرفتیم و به این نتیجه رسیدیم که مفهوم CP و اصول زیربنایی آن باید وجود داشته باشد تا همه بتوانند از "چرا؟" بهره ببرند و درک کنند.

گریسون ادکینز: سند حاکم برای نحوه ساختن نرم‌افزار به‌عنوان یک تیم است، و ما CP را به‌عنوان بهترین روشی می‌بینیم که در چتر Agile قرار گرفته است. من درک خوبی از CP در سطح استراتژیک دارم، اما در مورد سطح تاکتیکی به من بگویید، چگونه تیم ها را به صورت روزانه تحت تاثیر قرار می دهد؟ جریان های کاری که با حلقه چابک طراحی، توسعه، ادغام، تست و ارائه هماهنگ هستند. وقتی این فرآیند را دنبال می‌کنید، یک برنامه‌نویس بلیطی را برمی‌دارد، شعبه‌ای را چک می‌کند و شروع به توسعه می‌کند. هنگامی که آنها فکر می کنند شرایط را برآورده کرده اند، سپس با باز کردن یک PR نشان می دهند که بلیط آنها آماده ادغام است.

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

مشکل این فرآیند این است که شما QA را خیلی دیر در بازی وارد می‌کنید. هنگامی که یک ویژگی ادغام شد و به کار گرفته شد، یافتن و رفع اشکال 10 برابر دشوارتر می شود، به جای اینکه مشکل(ها) زود هنگام و رسیدگی به آن در سطح شاخه ویژگی، جایی که، دوباره، یافتن و رفع آن نسبتاً آسان است، مخالف است.

هنگامی که یک توسعه‌دهنده کد جدیدی را با استفاده از روش CP فشار می‌دهد، می‌تواند بدون ادغام QA'd شود – و همچنین بدون اینکه برنامه‌نویس مجبور باشد از گردش کار Git خود خارج شود. پیش‌نمایش مانع همکاری را از بین برده است، و فرآیند تکراری Develop – Preview, Develop – Preview سریع‌تر انجام می‌شود، و همچنین در مراحل توسعه زودتر اتفاق می‌افتد.

به معنای واقعی‌تر، شما QA را به فرآیند توسعه وارد می‌کنید، جایی که به‌طور سنتی به عنوان یک تابع الحاقی عمل می‌کرده است. تیم یا تیم محصول حتی اگر می‌بینیم که اکثر سازمان‌ها در قالب تیم توسعه‌دهنده و تیم محصول سازماندهی می‌کنند، به نظر من این ساختار می‌تواند مانعی برای همکاری باشد. CP فرآیندی است برای "تیم" به معنای همه کسانی که در موفقیت یک محصول سهیم هستند.

پیتر مک کی: شما بچه ها به موانع همکاری اشاره کرده اید – دقیقاً آن موانعی که تیم ها اکنون با آن روبرو هستند چیست؟ تمیزترین راه برای دسترسی آسان به برنامه شما برای همه اعضای تیم برای آزمایش این است که آن را در فضای ابری مستقر کنید و از طریق یک نقطه پایانی URL امن قابل دسترسی باشد. در اینجا باید تأکید کنم که نقطه پایانی می تواند آزمایش برنامه تمام پشته یا هر یک از اجزای جداگانه آن مانند یک API یا یک عنصر جلویی به عنوان مثال باشد.

برای استقرار یک نسخه از برنامه خود، به یک محیط میزبانی نیاز دارید – و تنظیم آن – به ویژه برای یک برنامه پیچیده یا مبتنی بر میکروسرویس – کار آسانی نیست. اکثر تیم‌ها محیط‌های پایداری مانند Test، QA، Staging و Production دارند که توسط اعضای تیم DevOps و Ops شما نگهداری می‌شوند. راه اندازی یک محیط جدید فقط برای آزمایش یک شاخه ویژگی یک مانع مهم است.

روش CP محیط‌های میزبانی درخواستی را فراخوانی می‌کند که چرخه حیات هدف‌محور دارند. آنها برای پیش نمایش و تست یک شاخه ویژگی ایستاده و سپس پس از ادغام آن ویژگی، حذف می شوند. اینجاست که تکنولوژی وارد می شود و این همان کاری است که Uffizzi به خوبی انجام می دهد. Uffizzi به تیم ها راه حلی ارائه می دهد که محیط های میزبانی درخواستی را به طور کامل خودکار می کند و راه انداز های مبتنی بر خط مشی که پیش نمایش را تسهیل می کند. شما می توانید به تعداد محیط های آزمایشی که نیاز دارید، در زمان نیاز، برای مدت زمانی که به آنها نیاز دارید، داشته باشید.

و من فقط اضافه می‌کنم که با این روش، زمانی که یک محیط QA پایدار یا تست پایین می‌آید و مجبور هستید بیشتر روز را صرف رفع آن کنید، نقطه‌ی شکست خود را نیز حذف می‌کنید.

گریسون ادکینز: مانع دیگر، تخصص DevOps است. فقط به عنوان یک مثال – این یک جهش قابل توجه در پیچیدگی است که از یک فایل 20+ خطی Docker Compose به یک فایل YAML 1000+ خطی بروید. تخصص DevOps اغلب گلوگاه خود در یک سازمان است، و اگر بتوانید با یک راه حل خودکار تقاضای آنها را کاهش دهید، یک پیروزی بزرگ است.

برای پیروی از بهترین روش‌های DevOps، محصول را حول زیرساخت به‌عنوان کد از طریق یک uffizzi-compose.yml متمرکز کرده‌ایم که از نظر نحوی همان docker-compose.yml است (براساس نسخه 3.9) اما با برخی ورودی‌های اضافی.

اما ما همچنین یک رابط کاربری گرافیکی و مفهوم الگوهایی داریم که به منظور افزایش دسترسی هستند – مفهوم CP چیزی است که می‌تواند برای تیم‌ها در همه اندازه‌ها و سطوح مهارت مفید باشد، و ما می‌خواهیم به عنوان یک ضرب‌کننده نیروی DevOps در آن موارد عمل کنیم.

پیتر مک کی: در مورد موانع، به نظر شما بزرگ‌ترین مانع برای تیم‌هایی که روش CP را اتخاذ می‌کنند، چیست؟ با فناوری ای که استفاده از آن به اندازه کافی آسان است و واقعاً شروع به تکثیر می کند. مجدداً برای اشاره به آنچه Netlify و Vercel انجام داده‌اند، آن‌ها آنقدر ساده کردند که پیش‌نمایش‌های Frontend در چند سال اخیر واقعاً شروع به کار کرده است.

البته این همان چیزی است که ما سعی می کنیم با Uffizzi در زمینه برنامه های کاربردی تمام پشته و میکروسرویس انجام دهیم. ما ابزار بسیار خاصی را ارائه می دهیم که اجرای CP را با انتزاع کردن پیچیدگی مدیریت محیط های میزبانی و استقرار آسان می کند.

گریسون ادکینز:  من فکر می‌کنم مسئله دیگر غلبه بر اینرسی «به اندازه کافی خوب» است—همه در حال انجام کار هستند، پس چرا به روش جدیدی برای انجام تجارت نیاز دارند؟

این همان مانع با هر فرآیند و فناوری جدید است. قبل از Agile، Waterfall به اندازه کافی خوب بود. قبل از ارکستراسیون کانتینر، VM ها (ماشین های مجازی) به اندازه کافی خوب بودند. بنابراین من فکر می‌کنم که ما دوره اولیه پذیرش را پشت سر می‌گذاریم، و در نهایت به نقطه‌ای می‌رسی که مزیت رقابتی به گونه‌ای است که سازمان‌ها را ملزم می‌کند CP را پیاده‌سازی کنند، در غیر این صورت در خطر عقب ماندن هستند.

پیتر:   همانطور که ما آنچه را که می‌توانیم از Uffizzi منتظر آن باشیم به پایان می‌رسانیم – در نقشه راه چه چیزی وجود دارد؟

گریسون ادکینز:  ویژگی‌های جدید و هیجان‌انگیزی داریم که در حال عرضه هستند. در کوتاه مدت، ما در حال گسترش ادغام خود با ثبت تصاویر و نرم افزارهای همکاری هستیم. ما در حال حاضر در حال ادغام با ثبت تصاویر در تمام ارائه دهندگان ابر بزرگ – AWS، Azure و GCP هستیم. سپس طی چند ماه آینده، Gitlab و Bitbucket را برای مخازن و سپس Slack، Jira، Microsoft Teams، و Asana را در سمت همکاری اضافه خواهیم کرد. زمان و رهبری فکر شما من می توانم ببینم که چگونه این یک تغییر بازی برای نحوه ساخت و آزمایش سازمان ها است. من مشتاقانه منتظرم تا ببینم چگونه CP و Uffizzi به سود جامعه توسعه دهندگان ادامه می دهند.

اگر سؤالی در رابطه با Docker دارید، لطفاً در توییتر به آدرس @pmckee در توییتر بپیوندید و در انجمن ما به ما بپیوندید.

اگر سؤالات مربوط به Uffizzi دارید، لطفاً با خیال راحت در توییتر به آدرس @uffizzi_ بپیوندید و در جامعه کاربران uffizzi ما به ما بپیوندید – Josh Thurman  (@JoshThurman19) یا Grayson Adkins (29Adkins) ).

می توانید مانیفست CP را در اینجا مشاهده کنید- www.cpmanifesto.org 

و مخازن منبع باز اینجا- UffizziCloud/Continuous_Previews_Manifesto: منبع برای: https://cpmanifesto.org[1965901thub] .com/UffizziCloud/uffizzi_controller

https://github.com/UffizziCloud/uffizzi_app