فصل بیست‌وچهارم: تحویل پیوسته و مهندسی نرم‌افزار در گوگل

تا حالا به این فکر کردید که چرا بعضی از نرم‌افزارها مدام و بدون مشکل به‌روزرسانی می‌شوند، در حالی که انتشار یک نسخه جدید در بعضی شرکت‌ها مثل یک پروژه نجات گروگان است؟ وقتی سرعت تغییرات در دنیای فناوری بالا است، مزیت رقابتی هر محصولی به توانایی آن در ارائه سریع ایده‌ها به دست کاربران بستگی دارد، اما این سرعت معمولاً پشت سد فرآیند استقرار گیر می‌کند. کتاب «مهندسی نرم‌افزار در گوگل» در فصل بیست‌وچهارم با عنوان تحویل پیوسته (Continuous Delivery) به ما نشان می‌دهد که چطور سرعت و ایمنی در توسعه نرم‌افزار در تناقض با هم نیستند، بلکه دست در دست هم دارند. این فصل برای هر کسی که می‌خواهد چالش‌های مقیاس‌پذیری و انتشار نرم‌افزار را درک کند، حیاتی است. اولین چالش جدی در این مسیر، هزینه‌بر بودن انتشارها است که تیم‌ها را وادار می‌کند انتشارها را عقب بیندازند تا آن‌ها را بیشتر تست کنند. وقتی حجم تغییرات انباشته می‌شود، فرآیند انتشار پیچیده و پرخطا می‌شود و کسی جرئت ندارد دکمه انتشار را فشار دهد. راه‌حل سنتی اضافه کردن نظارت و مدل‌های برنامه‌ریزی قدیمی است که فقط سرعت را می‌گیرد، اما نویسندگان کتاب پیشنهاد می‌کنند به جای این کار، معماری سیستم را به سمت ریزسرویس‌ها (Microservices) ببرید تا تغییرات کوچک و مستقل شوند. به عنوان مثال، در سیستم‌های قدیمی که کدهای بزرگ و به هم ریخته دارند، تیم‌ها هفته‌ها درگیر تست دستی می‌شوند، در حالی که معماری ماژولار اجازه می‌دهد بخش‌های مختلف به صورت مستقل توسعه پیدا کنند. چالش دوم مدیریت ویژگی‌هایی است که هنوز کامل نشده‌اند و نباید همه کاربران آن‌ها را ببینند. گزینه‌های پیش روی تیم‌ها این است که یا منتظر بمانند کل پروژه تمام شود یا از مکانیزم پرچم ویژگی (Feature Flag) برای کنترل نمایش کدها استفاده کنند. فایده پرچم ویژگی این است که کد جدید در کنار کد قدیمی در برنامه وجود دارد اما با یک کلید دینامیک پنهان شده است و می‌توان آن را بدون انتشار نسخه جدید فعال یا غیرفعال کرد. مثلاً وقتی قرار است هم‌زمان با یک کمپین مطبوعاتی ویژگی جدیدی رونمایی شود، تیم توسعه نیازی ندارد نگران لو رفتن کدها از قبل باشد؛ کافی است پرچم ویژگی را در لحظه مناسب روشن کنند تا قابلیت برای کاربران نمایان شود. چالش سوم برخورد با باگ‌ها و کمال‌گرایی در انتشار است که می‌تواند کل چرخه را معطل کند. خیلی از تیم‌ها فکر می‌کنند برای انتشار نسخه جدید باید همه باگ‌ها، حتی کوچک‌ترین موارد برطرف شوند، اما این رویکرد سرعت را کاملاً فلج می‌کند. نویسندگان این کتاب معتقدند هیچ باینری (Binary) کاملی وجود ندارد و فرآیند ساخت باید قطعی باشد؛ یعنی اگر یک ویژگی به قطار انتشار نرسد، باید بدون تعارف بماند برای قطار بعدی که چند ساعت یا چند روز بعد حرکت می‌کند. به عنوان مثال، در پروژه جستجوی گوگل، به جای اینکه کل انتشار به خاطر یک باگ در یک گویش محلی بسیار نادر متوقف شود، قطار انتشار حرکت خود را حفظ می‌کند و تیم‌ها یاد می‌گیرند که ضرب‌الاجل‌ها غیرقابل مذاکره هستند و سرعت بالا خودش عامل کاهش ریسک است. چالش چهارم این است که رشد محصول معمولاً باعث انباشته شدن کدهای استفاده‌نشده تورم نرم‌افزاری می‌شود که به دستگاه کاربران آسیب می‌زند. وقتی نرم‌افزاری برای مدت طولانی توسعه پیدا می‌کند، حجم زیادی از کدهای قدیمی یا ویژگی‌های بدون استفاده روی گوشی کاربر دانلود می‌شود. راه‌حل این است که با استقرارهای پویا و تست‌های ای/بی (A/B Testing)، یعنی روشی برای مقایسه دو نسخه مختلف نرم‌افزار روی گروه‌های کاربری مشابه برای سنجش دقیق عملکرد، فقط کدهایی که واقعاً ارزش دارند روی دستگاه کاربر نهایی ارسال شوند. پیشنهاد عملی من به شما این است که اگر در تیم خودتان مدام نگران انتشار نسخه‌های بزرگ هستید، به جای سخت‌تر کردن تست‌ها، سعی کنید اندازه دسته‌های تغییرات را کوچک‌تر کنید و سیستم خود را طوری بسازید که انتشار مداوم برایتان تبدیل به یک روال عادی شود. در نهایت، سرعت بیشتر به معنای ریسک کمتر است، به شرطی کهdiscipline انضباط تیمی را در تمام مراحل توسعه و استقرار رعایت کنید.