فصل ۴ — استقرار در تولید

اگر به‌زودی مسیر را عوض نکنیم، به همان جایی می‌رسیم که داریم می‌رویم.

— دکتر Irwin Corey

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

خبر خوب این است که استقرار بازآرایی‌های پایگاه داده بسیار امن‌تر از استقرار تغییرات سنتی طرحواره است — البته به‌شرطی که توصیه‌های این کتاب را دنبال کنید. این به چند دلیل درست است. اول، بازآرایی‌های پایگاه دادهٔ تکی کم‌ریسک‌تر از تغییرات سنتی طرحواره‌اند چون کوچک و ساده‌اند. با این حال، مجموعهٔ بازآرایی‌ها — همان چیزی که واقعاً مستقر می‌کنید — اگر خوب مدیریت نشوند می‌توانند پیچیده شوند. این فصل برای همین کار توصیه می‌دهد. دوم، وقتی رویکرد توسعهٔ رانش‌محور تست (Test-Driven Development — TDD) دارید، مجموعهٔ تست رگرسیون کامل برای اعتبارسنجی بازآرایی‌ها در دسترس است. دانستن اینکه بازآرایی‌ها واقعاً کار می‌کنند، به شما اجازه می‌دهد با اطمینان بیشتری مستقرشان کنید. سوم، با داشتن دورهٔ گذار که طرحوارهٔ قدیم و جدید به‌صورت موازی وجود دارند، مجبور نیستید هم‌زمان دسته‌ای تغییر برنامه هم مستقر کنید که بازتاب تغییرات طرحواره باشد.

برای استقرار موفق بازآرایی‌های پایگاه داده در تولید، باید راهبردهایی برای موارد زیر بپذیرید:

• استقرار مؤثر بین sandboxها
• اعمال بسته‌های بازآرایی پایگاه داده
• زمان‌بندی پنجره‌های استقرار
• استقرار سیستم
• حذف طرحوارهٔ منسوخ‌شده

۴.۱. استقرار مؤثر بین sandboxها

فصل ۱، «توسعهٔ تکاملی پایگاه داده»، ایدهٔ داشتن مجموعه‌ای از sandboxها برای پیاده‌سازی، تست و اجرای سیستم‌ها را توضیح داد. همان‌طور که در شکل ۴.۱ می‌بینید، هر تیم پروژه مجموعه‌ای از sandboxهای توسعه‌دهنده و شاید sandbox دمو مربوط به خودش را دارد. sandbox تست پیش‌تولید بین تیم‌ها مشترک است، همان‌طور که محیط تولید. همچنین بین sandboxهای مختلف دروازه‌های استقرار وجود دارد. استقرار بازآرایی‌های پایگاه داده از ایستگاه کاری توسعه‌دهنده به sandbox مشترک یکپارچه‌سازی پروژه باید نسبتاً آسان باشد، چون اثر اشتباه نسبتاً کم است: فقط تیم را تحت تأثیر قرار می‌دهید. استقرار در محیط(های) تست پیش‌تولید باید کمی سخت‌تر باشد، چون اثر اشتباه بسیار بیشتر است: نه‌تنها سیستم شما ممکن است برای تست‌کنندگان در دسترس نباشد، بلکه می‌تواند سایر سیستم‌های این محیط‌ها را هم از کار بیندازد و تیم‌های دیگر را تحت تأثیر قرار دهد. استقرار در محیط تولید اغلب فرایندی سخت‌گیرانه است، چون هزینهٔ بالقوهٔ اشتباه بسیار زیاد است و به‌راحتی می‌توانید مشتریان را تحت تأثیر قرار دهید.

شکل ۴.۱. استقرار بین sandboxها.

برای استقرار در هر sandbox، باید هم برنامه را build کنید و هم اسکریپت‌های مدیریت پایگاه داده را اجرا کنید (change log، update log و data migration log یا معادل آن‌ها، همان‌طور که در فصل ۳، «فرایند بازآرایی پایگاه داده»، توضیح داده شد). گام بعدی اجرای دوبارهٔ تست‌های رگرسیون است تا مطمئن شوید سیستم هنوز کار می‌کند — اگر نه، باید در sandbox توسعه تعمیر کنید، دوباره مستقر کنید و دوباره تست کنید. هدف در sandbox یکپارچه‌سازی پروژه این است که تأیید کنید تغییرات توسعه‌دهندهٔ فردی (جفت‌ها) با هم کار می‌کنند؛ هدف در sandbox تست/QA پیش‌تولید این است که تأیید کنید سیستم شما با سایر سیستم‌های سازمان خوب کار می‌کند.

خیلی رایج است توسعه‌دهندگان چند بار در روز تغییرات را از sandboxهای توسعه به sandbox یکپارچه‌سازی پروژه promote کنند. به‌عنوان تیم، باید تلاش کنید حداقل یک‌بار در هر چرخهٔ توسعه (iteration) سیستم را حداقل در محیط دمو مستقر کنید تا نرم‌افزار در حال کار فعلی را با ذی‌نفعان داخلی مناسب پروژه به اشتراک بگذارید. بهتر است سیستم را در محیط‌های تست پیش‌تولید هم مستقر کنید تا تست پذیرش و تست سیستم انجام شود — ایده‌آل این است که حداقل یک‌بار در هر چرخه. می‌خواهید به‌طور منظم در محیط پیش‌تولید مستقر کنید به دو دلیل. اول، بازخورد ملموسی از اینکه سیستم واقعاً چقدر خوب کار می‌کند می‌گیرید. دوم، چون به‌طور منظم مستقر می‌کنید، راه‌های بهتر شدن در استقرار را کشف می‌کنید — با اجرای منظم اسکریپت‌های نصب، از جمله تست‌هایی که اسکریپت‌های نصب را اعتبارسنجی می‌کنند، به‌سرعت آن‌ها را به‌اندازه‌ای مقاوم می‌کنید که سیستم را با موفقیت در تولید مستقر کنند.

۴.۲. اعمال بسته‌های بازآرایی پایگاه داده

تیم‌های توسعهٔ مدرن در چرخه‌های کوتاه کار می‌کنند؛ در تیم چابک، چرخه‌های یک یا دو هفته‌ای بسیار رایج است. اما اینکه تیم هر هفته نرم‌افزار در حال کار می‌سازد، به این معنا نیست که هر هفته نسخهٔ جدید سیستم را در تولید مستقر می‌کند. معمولاً هر چند ماه یک‌بار در تولید مستقر می‌کنند. پیامد این است که تیم باید همهٔ بازآرایی‌های پایگاه داده‌ای که از آخرین استقرار در تولید انجام داده را بسته‌بندی کند تا به‌درستی اعمال شوند.

همان‌طور که در فصل ۳ دیدید، ساده‌ترین راه این است که هر بازآرایی پایگاه داده را یک تراکنش جدا در نظر بگیرید که ترکیبی از اسکریپت‌های زبان تعریف داده (Data Definition Language — DDL) برای تغییر طرحوارهٔ پایگاه داده و مهاجرت داده در صورت لزوم، به‌علاوهٔ تغییرات کد منبع برنامه‌ای که به آن بخش از طرحواره دسترسی دارد، پیاده‌سازی شده است. این تراکنش باید شناسهٔ یکتایی داشته باشد — عدد یا تاریخ/برچسب زمانی کافی است — تا بتوانید بازآرایی‌ها را مرتب کنید. این امکان را می‌دهد بازآرایی‌ها را به ترتیب، با اسکریپت دستی یا ابزار عمومی، در هر sandboxی که لازم است اعمال کنید.

چون نمی‌توانید فرض کنید همهٔ طرحواره‌های پایگاه داده با یکدیگر یکسان‌اند، به راهی برای اعمال امن ترکیب‌های مختلف بازآرایی به هر طرحواره نیاز دارید. مثلاً طرح مبتنی بر عدد در شکل ۴.۲ را در نظر بگیرید. پایگاه‌های دادهٔ مختلف توسعه‌دهندگان هر کدام در نسخه‌های متفاوتی‌اند. پایگاه دادهٔ شما در نسخهٔ ۸۱۳ است، یکی دیگر در ۸۱۱ و دیگری در ۸۱۵. چون پایگاه دادهٔ یکپارچه‌سازی پروژه در نسخهٔ ۸۱۱ است، می‌فهمیم طرحوارهٔ شما از آخرین همگام‌سازی با محیط یکپارچه‌سازی پروژه تغییر کرده، توسعه‌دهندهٔ دوم نسخهٔ طرحواره را تغییر نداده و هنوز جدیدترین نسخه را نگرفته (۸۰۹ کمتر از ۸۱۱ است)، و توسعه‌دهندهٔ سوم به‌صورت موازی با شما تغییر داده. تغییرات باید موازی بوده باشند چون هیچ‌کدام تغییرات را هنوز به محیط یکپارچه‌سازی promote نکرده‌اید (وگرنه آن محیط همان عدد یکی از دو پایگاه داده را داشت). برای به‌روزرسانی پایگاه دادهٔ یکپارچه‌سازی پروژه، باید تغییرات را از ۸۱۲ اجرا کنید؛ برای به‌روزرسانی پایگاه دادهٔ تست پیش‌تولید از اسکریپت تغییر ۸۰۶ شروع می‌کنید؛ برای محیط دمو از ۸۰۱؛ و برای پایگاه دادهٔ تولید از شمارهٔ تغییر ۷۵۸. علاوه بر این، شاید نخواهید همهٔ تغییرات را به همهٔ نسخه‌ها اعمال کنید — مثلاً شاید فقط تولید را برای انتشار بعدی تا نسخهٔ ۷۹۴ بالا بیاورید.

شکل ۴.۲. پایگاه‌های دادهٔ مختلف، نسخه‌های مختلف.

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

۴.۳. زمان‌بندی پنجره‌های استقرار

پنجرهٔ استقرار (deployment window)، که اغلب پنجرهٔ انتشار (release window) هم نامیده می‌شود، نقطهٔ زمانی مشخصی است که مجازید سیستمی را در تولید مستقر کنید. پرسنل عملیات احتمالاً قوانین سخت‌گیرانه‌ای دربارهٔ زمان مجاز تیم‌های برنامه برای استقرار سیستم‌ها دارند. قوانینی مثل این بسیار رایج است: تیم‌های برنامه فقط شنبه شب‌ها بین ساعت ۲ تا ۶ صبح انتشار جدید مستقر کنند، و رفع باگ بین ۴ تا ۶ صبح در شب‌های دیگر. این پنجره‌ها معمولاً با دوره‌های کاهش فعالیت سیستم هم‌زمان تعریف می‌شوند. علاوه بر این، ممکن است قوانینی دربارهٔ زمان مجاز تغییر طرحوارهٔ پایگاه داده داشته باشند — مثلاً فقط سومین شنبهٔ هر ماه. سازمان‌های کوچک‌تر، به‌ویژه آن‌هایی که پروژهٔ توسعهٔ زیادی در جریان ندارند، ممکن است پنجرهٔ استقرار هر چند ماه یک‌بار را انتخاب کنند.

پیامد این است که تیم هر وقت بخواهد نمی‌تواند سیستم را در تولید مستقر کند، بلکه باید استقرار را در پنجرهٔ از پیش تعریف‌شده زمان‌بندی کند. شکل ۴.۳ این مفهوم را نشان می‌دهد: دو تیم پروژه چگونه استقرار تغییراتشان (شامل بازآرایی‌های پایگاه داده) را در پنجره‌های استقرار موجود زمان‌بندی می‌کنند. گاهی چیزی برای استقرار نیست، گاهی یک تیم تغییر دارد و گاهی هر دو تیم تغییرات طرحواره برای استقرار دارند. پنجره‌های استقرار در شکل ۴.۳ با استقرار نهایی از محیط تست پیش‌تولید به محیط تولید در شکل ۴.۱ هم‌زمان‌اند.

شکل ۴.۳. تغییرات طرحواره را در نقاط زمانی از پیش تعریف‌شده در تولید مستقر کنید.

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

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

۴.۴. استقرار سیستم

معمولاً بازآرایی‌های پایگاه داده را به‌تنهایی مستقر نمی‌کنید. در عوض، آن‌ها را بخشی از استقرار کلی یک یا چند سیستم مستقر می‌کنید. استقرار وقتی یک برنامه و یک پایگاه داده برای به‌روزرسانی دارید ساده‌ترین است و این وضعیت در عمل هم پیش می‌آید. اما واقع‌بینانه باید وضعیتی را در نظر بگیرید که چند سیستم و چند منبع داده را هم‌زمان مستقر می‌کنید. شکل ۴.۴ نمودار فعالیت UML‌ای را که فرایند استقرار را مرور می‌کند نشان می‌دهد. باید کارهای زیر را انجام دهید:

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

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

3. استقرار برنامه(های) تغییر یافته. طبق روال موجود این کار را انجام دهید.

4. استقرار بازآرایی‌های پایگاه داده. باید اسکریپت‌های تغییر طرحواره و مهاجرت دادهٔ مناسب را روی منابع داده اجرا کنید.

5. اجرای تست‌های رگرسیون فعلی. پس از استقرار برنامه(ها) و بازآرایی‌های پایگاه داده، باید نسخهٔ فعلی مجموعهٔ تست را اجرا کنید تا تأیید کنید سیستم(های) مستقرشده در تولید کار می‌کنند. باز هم از اثرات جانبی تست‌ها مراقب باشید.

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

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

شکل ۴.۴. فرایند استقرار.

۴.۵. حذف طرحوارهٔ منسوخ‌شده

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

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

۴.۶. آنچه آموختید

نه‌تنها باید بازآرایی‌های پایگاه داده را پیاده‌سازی کنید، بلکه باید آن‌ها را در تولید هم مستقر کنید؛ وگرنه اصلاً چرا انجامشان دهید؟ با داشتن sandboxهای جداگانه می‌توانید بازآرایی‌ها را به‌امن پیاده‌سازی و تست کنید تا برای استقرار آماده شوند. با استقرار منظم نسخه‌های توسعهٔ سیستم در محیط تست پیش‌تولید، اسکریپت‌های استقرار را خیلی قبل از نیاز به اعمال در تولید بهبود و اعتبارسنجی می‌کنید. اگرچه ممکن است به‌طور منظم — گاهی هفتگی — نرم‌افزار در حال کار بسازید، معمولاً آن‌قدر مرتب در تولید منتشر نمی‌کنید. در عوض، بازآرایی‌های پایگاه داده را بسته‌بندی می‌کنید و مجموعه‌ای از آن‌ها را یک‌جا در پنجرهٔ استقرار از پیش تعریف‌شده مستقر می‌کنید. برنامهٔ شما ممکن است تنها برنامه‌ای نباشد که در یک پنجرهٔ استقرار مشخص در تولید مستقر می‌شود؛ بنابراین شاید برای استقرار موفق با تیم‌های دیگر هماهنگی لازم باشد.