۳ راه که devops می تواند از معماری پیوسته پشتیبانی کند

معماری پیوسته انعطاف پذیری را برای انطباق با نیازهای تجاری جدید و نیازهای کاربر ارائه می دهد.

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

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

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

توازن ممکن است از طریق اصول معماری پیوسته حاصل شود. Manifesto Continuous Architecture از «حرکت از رویکرد آبشار سابق که در آن معماری عمدتاً قبل از پیاده‌سازی ویژگی‌ها به یک باند فرود پیوسته انجام می‌شد» پشتیبانی می‌کند. اصول شامل معماری “محصولات بلند مدت، نه فقط راه حل های پروژه” و “اعتبار بخشیدن به معماری از طریق پیاده سازی” است. اصول آنها برای تیم‌هایی مناسب است که معماری‌های ابری را توسعه می‌دهند، از بهترین شیوه‌های توسعه استفاده می‌کنند و از اثبات مفهومی و چابک های چابک تا راه حل های خود را اعتبار سنجی کنید.

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

توسعه خودکار و ایجاد محیط آزمایشی

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

امیر روزنبرگ، معاون مدیریت محصول در Quali، موافق است و می‌گوید: «سازمان‌های ارائه‌دهنده برنامه‌های کاربردی وابسته هستند و باید دسترسی آسانی به محیط‌های قابل اعتماد، در دسترس و سازگار داشته باشند تا خطوط لوله تحویل نرم‌افزار مستمر خود را تأمین کنند.»

>

Rozenberg پیشنهاد می‌کند که معماران با تیم‌های devops برای ایجاد طرح‌های زیرساخت ابری همکاری کنند. او می‌گوید، «تیم‌های Devops باید طرح‌های محیطی را مدل‌سازی کنند تا زیرساخت ابری مناسب را برای مؤلفه‌های کسب‌وکار خود، مانند تیم‌های توسعه، مدیران محصول، آزمایش‌کنندگان و پیش‌فروش‌ها به شیوه‌ای سلف‌سرویس فراهم کنند که زمان‌های انتظار طولانی را حذف کند. p>

تیم لوکاس، موسس و مدیرعامل Buildkite، موافق است. او می گوید: «معماری مستمر، هم فنی و هم فرهنگی، مستلزم تعهد تیم توسعه و کسب و کار است. یکی از اصول کلیدی که او پیشنهاد می‌کند «ایجاد نقش اختصاصی است که بر تجربه توسعه‌دهنده تمرکز دارد و پاسخگوی آن است». .

هنگام تعریف معماری تولید، نیازهای مشتری و کاربر را در نظر بگیرید

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

لوکاس یک اصل کلیدی طراحی را برای محیط‌های تولید اضافه می‌کند و پیشنهاد می‌کند “سرمایه‌گذاری در کاهش شکست زیرا برای اینکه چیزی پیوسته باشد، وقفه‌ها باید کاهش یابد.”

برای دانشمندان داده، ادغام و استقرار اغلب نیازمندی‌های متفاوتی نسبت به آنچه برای تیم‌های توسعه نرم‌افزار معمول است دارند. مایکل برتولد، یکی از بنیانگذاران و مدیرعامل KNIME، می‌گوید: «فرآیند تولید علم داده که در طول یکپارچه‌سازی ساخته شده است، با آنچه تیم علم داده ایجاد کرده است، متفاوت است و نظارت در تولید ممکن است منجر به به‌روزرسانی و استقرار مجدد خودکار شود».

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

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

رهبران تجاری اغلب بر فرصت‌های کوتاه مدت تمرکز می‌کنند و تیم‌های توسعه‌دهنده بهترین تلاش خود را برای توسعه مؤلفه‌های نرم‌افزاری ماژولار و قابل توسعه انجام می‌دهند. برخی از بهترین روش‌ها برای پشتیبانی از معماری پیوسته عبارتند از:

• در حال توسعه با معماری‌های بومی ابری و بدون سرور
• استاندارد کردن خطوط لوله استقرار
• پشتیبانی از شیوه های آزمایش مداوم
• ساخت میکروسرویس ها و پشتیبانی از چرخه عمر API
• استفاده از راه‌حل‌های کم‌کد که در آن پلت‌فرم‌ها ساده‌سازی می‌کنند و به جلوگیری از راه‌حل‌های سفارشی کمک می‌کنند

وینس پادوآ، معاون اجرایی و مدیر ارشد نوآوری و فناوری در Axway، بر معماری‌های باز تمرکز دارد و می‌گوید: «ادغام و همکاری B-to-B، تحول دیجیتال آن را که بر پشت APIها و فضای ابری ساخته شده است، تسریع می‌بخشد. از آنجا که رویکردهای Cloud-Native و API-first به یک معماری همه چیز باز رسیده اند، زمان و هزینه نوآوری از طریق مشارکت و همکاری به طور قابل توجهی کاهش یافته است.”

بسیاری از کسب‌وکارها در حال حاضر روی نرم‌افزارهای سفارشی برای تجربیات مشتری، ادغام‌ها و گردش‌های کاری دیجیتالی سرمایه‌گذاری می‌کنند و باید بهترین شیوه‌ها را برای اثبات سرمایه‌گذاری‌های خود در آینده در نظر بگیرند. پادوآ پیشنهاد می‌کند، «از آنجایی که سطح سازمانی مبتنی بر API است، نوآوری بیشتری با جداسازی و بازگردانی پیشنهادات و زنجیره‌های تأمین در صنایع و بخش‌های عمودی باز می‌شود. سرمایه‌گذاری‌های قابل توجهی و فرصت‌های رشد راه‌اندازی در پیشنهادات B-to-B برای سفر، تدارکات، انبارداری، تولید، وام، بیمه، و خرده‌فروشی بوتیک وجود دارد.”

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