چگونه DevOps را برای پایگاه داده پیاده سازی کنیم؟

یک طرح جامع برای مدیریت تغییرات در پایگاه داده.

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

مهم است که بدانید هیچ فرمول جادویی واحدی وجود ندارد که بتواند همه مشکلات شما را حل کند. هر راه حلی همیشه به پیچیدگی و به هم پیوستگی معماری شما بستگی دارد. هدف این مقاله توضیح این نیست که چرا تغییرات پایگاه داده می تواند دشوار باشد، بلکه به شما دیدگاه متفاوتی در مورد بهینه سازی تغییرات پایگاه داده و یک راه حل عملی برای اینکه چگونه DevOps می تواند این فرآیند را تسهیل کند، ارائه می دهد.

روش سنتی اعمال تغییرات روی یک پایگاه داده به این شکل آغاز می‌شود که توسعه‌دهندگان تغییراتی را که مایل به انجام آن هستند، روی فایل‎هایی با فرمت SQL می‌نویسند. سپس، این تغییرات توسط فردی که تجربه بیشتری در پایگاه‌های داده دارد، مورد بازبینی قرار می‌گیرد. معمولا یک مدیر پایگاه داده (DBA) که تمام مدت با پایگاه داده سروکار دارد، این بازبینی را انجام می‌دهد. این شخص بهتر از هر فرد دیگری با پیامدهای حاصل از اعمال تغییرات (نه‌تنها در وضعیت عملکرد، بلکه در ادغام داده‎ها) آشنا است. تا اینجا به نظر همه‌چیز درست و بدون نقص است، اما مشکل اینجا است که مدیر پایگاه داده معمولا درست قبل از رسیدن به مرحله تولید نهایی وارد ماجرا می‌شود که دیگر خیلی دیر است و اعمال تغییرات مناسب پرهزینه خواهد بود. در اینجا منظور این نیست که توسعه‌دهندگان به شخص دیگری برای بازبینی کاری که آن‌ها انجام می‌دهند نیاز دارند، بلکه چیزی که اینجا شرح داده شد یک سناریوی رایج در بیشتر شرکت‎های بزرگ است. به‌کارگیری دواپس برای پایگاه داده به تغییر مراحل این فرآیند مربوط است و خودکارسازی باعث می‌شود تا این فرآیند روان‎تر انجام شود. البته این موضوع تنها به اتوماسیون مربوط نمی‌شود. (شکل۱)

اتوماسیون تنها بخشی از این معادله است

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

فقدان یک استاندارد واحد بین موتورهای پایگاه داده

تغییرات پایگاه داده یک استاندارد سازگار ندارد، زیرا هرکدام از موتورهای آن به روش متفاوتی برای مدیریت کردنشان نیاز دارند. از سویی تاثیر این تغییرات از موتوری به موتور دیگر تفاوت دارد. برای مثال، میزان تاثیر ایندکس‎ها در SQL Server به‌اندازه ایندکس‎ها در Oracle یا MySQL نیست. زبان پرس‌وجوی ساخت‌یافته (SQL) ممکن است تنها چیزی باشد که بین موتورهای جست‌وجو مشترک است. اما حتی در این زمینه هم این فرامین نتایج متفاوتی را ارائه می‌کنند.
اما در آینده ممکن است ما شرایط راحت‎تری در این صنعت داشته باشیم، زیرا روش تعامل خود با پایگاه‌های داده را استانداردسازی خواهیم کرد. اما تا آن زمان برای چگونگی نحوه تغییرات موتور جستجوی خود برنامه‌ریزی کنید. برای سهولت در انجام این کار می‌توانید از فریم ورک‎های ORM (سرنام (Object-Relational Mapping یا سایر ابزارهای موجود در این زمینه استفاده کنید.

همچنین بخوانید : همه چیز در باره برنامه‌ریزی منابع سازمان(ERP)

معماری‎های به‌هم‌پیوسته

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

فقدان فرهنگ درست برای پیش بردن درست چرخه تولید

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

راهکارهای فنی برای پایگاه داده
ما متوجه شدیم که چگونه پایگاه‌های داده می‌توانند به یک مشکل ویژه در دواپس (DevOps) تبدیل شوند و چگونه می‌توان اوضاع را سروسامان داد. اما چند راهکار فنی نیز وجود دارد که پیاده‌سازی دواپس (DevOps) در تغییرات پایگاه داده را تقویت می‌کند.

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

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

ابزار اتوماسیون پایگاه داده

نمی‌شود در مورد پایگاه‌های داده صحبت کرد و به چند ابزار مرتبط اشاره‎ای نکرد. ابزارهای زیادی برای این منظور وجود دارد و هر از گاهی نمونه‎های جدیدی از آن منتشر می‌شود. در ادامه چند نمونه از معروف‎ترین آن‌ها آورده شده است:
• Liquibase (رایگان)
• Datical (نسخه غیر رایگان Liquibase)
• Redgate (Microsoft Stack)
• Delphix (بیشتر از تنها تغییرات پایگاه داده)
• DBmaestro (در واقع به‌عنوان دواپس (DevOps) برای پایگاه‌های داده فروخته می‌شود)
علاوه بر ابزارهایی برای موتورهای پایگاه داده، فریم ورک‎هایی نیز وجود دارد که از migration پشتیبانی می‌کنند:
• Entity Framework
• GORM
• Compose
• Hibernate

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

منبع : شبکه مگ